בשנתיים האחרונות המיומנות הכי מבוקשת בעולם ה-AI הייתה לכתוב prompt טוב. ״הנדסת prompt״ הפכה לתואר, לקורסים, למשרות. וזה הגיוני: כשיש לך מודל אחד וצריך להוציא ממנו את המיטב, הניסוח הוא הכל. אבל ברגע שאתה עובר מלשחק עם מודל בודד לבנות מערכת אמיתית, מתגלה משהו שאף קורס לא מספר לך: prompt לא סקיילבילי.

הבעיה לא מופיעה בסוכן הראשון, היא מופיעה בשלושים ואחד. כשיש לך מערכת של סוכנים, כל אחד עם התפקיד שלו, ואתה כותב לכל אחד prompt נפרד, אתה בונה בשקט חוב טכני עצום. אותו כלל נכתב שוב ושוב במקומות שונים. וברגע שמישהו משפר עותק אחד, כל השאר נשארים מאחור. זה לא מתפוצץ, זה מרקיב.

למה prompt לא סקיילבילי

קחו דוגמה פשוטה. נניח שיש לכם ״מבקר״, סוכן שבודק תוכן לפני פרסום: מחפש טענות לא-מבוססות, טון לא נכון, קניבליזציה. עכשיו יש לכם מבקר גם במוצר השני, וגם בשלישי. אם כתבתם את הכללים שלו בתוך ה-prompt של כל מוצר, כתבתם את אותו ידע שלוש פעמים. שיפרתם את המבקר במוצר אחד? השניים האחרים עכשיו סותרים אותו. הכפלתם את זה בעשרה מוצרים וחמישה תפקידים, ויש לכם חמישים עותקים של ידע שנסחפים כל אחד לכיוון אחר.

זו לא בעיה של ניסוח, אף prompt מבריק לא פותר אותה. זו בעיה של ארכיטקטורה. הידע נמצא במקום הלא נכון. הוא כלוא בתוך ה-prompt של כל סוכן, במקום לחיות במקום אחד שכולם ניגשים אליו.

מהנדסת prompt להנדסת יכולות

הפרדיגמה שבאה אחרי הנדסת prompt היא הנדסת יכולות. הרעיון פשוט: תפסיקו להתייחס לידע כאל טקסט שכותבים בכל מקום, ותתחילו להתייחס אליו כאל נכס, בדיוק כמו שאתם מתייחסים לקוד. לקוד יש מקור אחד, יש גרסאות, ומתקנים אותו במקום אחד וכולם מקבלים את התיקון. ליכולת של סוכן מגיע אותו יחס.

ברגע שמסתכלים ככה, השאלה משתנה. היא כבר לא ״איך אני מנסח את הסוכן הזה טוב יותר״, אלא ״איך אני בונה את היכולת פעם אחת כך שכל הסוכנים יחלקו אותה״. זו קפיצה מרמת הפרט לרמת המערכת, ובדיוק שם נמצא הערך האמיתי כשיש לך יותר מחופן סוכנים.

הנוסחה: סוכן = ארכיטיפ × דומיין

הדרך הכי פשוטה להבין את המעבר היא נוסחה אחת: סוכן = ארכיטיפ × דומיין. כל סוכן הוא מכפלה של שני דברים נפרדים. הארכיטיפ הוא איך הוא חושב: חוקר, יוצר, מבקר, עורך. הדומיין הוא מה הוא יודע: SEO, חוזים, מכירות, פיננסים, נגישות.

הטעות הרווחת היא לדחוס את שניהם לתוך prompt אחד ענק לכל סוכן. הנוסחה אומרת להפריד: הארכיטיפ נשאר בקוד של הסוכן, כי הוא ההתנהגות שלו. הדומיין נטען מסקיל משותף, כי הוא ידע שאפשר לחלוק. ״מבקר של SEO״ ו״מבקר של חוזים״ חולקים את אותו ארכיטיפ (איך מבקרים), ונבדלים רק בדומיין (מה בודקים). במקום חמישים סוכנים עם חמישים prompts, יש לך קומץ ארכיטיפים וספרייה של יכולות, והסוכן הוא פשוט הצומת שביניהם.

סוכן טוב הוא לא prompt מבריק. הוא ארכיטיפ ברור שטוען יכולת משותפת. ההבדל בין השניים הוא ההבדל בין קוד שמרקיב לקוד שמתחזק את עצמו.

מודל שלוש השכבות

אם הידע חי בסקיל משותף, עולה שאלה מעשית: כמה ממנו לטעון בכל פעם. ידע עמוק עולה טוקנים, וטוקנים עולים כסף וזמן. התשובה היא לבנות את היכולת בשלוש שכבות, לפי עומק ולפי הצורך:

  • שכבה אופרטיבית: כללי-מפתח קצרים שנטענים תמיד, בכל קריאה. זולים, וזה מה שהסוכן צריך ב-90 אחוז מהמקרים.
  • שכבת עומק: המדריך המלא, עם טבלאות החלטה, נוסחאות ודוגמאות, שנטען רק כשהסוכן באמת נתקל במקרה שדורש אותו. עומק בלתי-מוגבל בלי לתמחר כל קריאה.
  • שכבת קוד: סקריפט דטרמיניסטי שבודק במקום לנחש. במקום שהסוכן ״יעריך״ אם סכמה תקינה או אם ניסוח נקי, קוד בודק את זה בוודאות ומחזיר תשובה.

השכבה השלישית היא אולי המעניינת ביותר, כי היא משנה את אופי הסוכן. סוכן שמנחש טועה לפעמים, בביטחון. סוכן שמריץ בדיקה יודע. ככל שמעבירים יותר החלטות דטרמיניסטיות מ״ניחוש של המודל״ ל״קוד שרץ״, המערכת נהיית אמינה יותר, לא חכמה יותר.

מה זה לא פותר

הנדסת יכולות היא לא קסם, וכדאי להגיד את זה בכנות. עומק עולה טוקנים, ולכן צריך את המשמעת של שלוש השכבות ולא סתם להעמיס הכל. ספרייה משותפת דורשת משמעת של סנכרון, מישהו צריך לוודא שהעדכון מגיע לכל מקום. וזה לא מחליף שיפוט אנושי בהחלטות רגישות. מה שזה כן עושה: מפסיק את הריקבון השקט של ידע משוכפל, ונותן עקביות שאי אפשר להשיג עם prompts מפוזרים.

איך זה עובד ב-HELIX

כל מוצר ב-HELIX בנוי כצוות סוכנים, לא כמערכת אחת. במקום שכל סוכן יחזיק את הידע שלו, בנינו ספריית יכולות משותפת: כל יכולת נכתבת פעם אחת, וכל הסוכנים בכל המוצרים טוענים ממנה. מבקר התוכן, החוקר, מומחה ה-SEO, כולם שולפים את אותו ידע-דומיין מגורס, ומיישמים אותו לפי ההקשר שלהם. כשמשפרים יכולת, כל הצוות משתפר יחד. זה ההבדל בין מערכת שמרקיבה עם הזמן למערכת שנעשית חדה יותר.

השורה התחתונה: הנדסת prompt הייתה המלאכה של השלב הראשון, והיא לא נעלמת, היא פשוט יורדת לרמת הפרט. השלב הבא הוא הנדסת יכולות, לבנות את הידע פעם אחת כנכס משותף, מגורס ומדיד. מי שינצח בעידן הסוכנים לא יהיה זה עם ה-prompt הכי חכם, אלא זה עם ספריית היכולות הכי טובה.

מקורות

  1. Anthropic, Equipping agents for the real world with Agent Skills
  2. Anthropic, Agent Skills documentation
  3. The DRY principle (Hunt & Thomas, The Pragmatic Programmer)