הקשר, לא שליטה

הקשר, לא שליטה

כל כלל בהנחיה של הסוכן שלך התחיל כבאג.

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

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

זו חשיבה בסגנון שליטה. ואני חושב שזו אחת הטעויות העיצוביות הגדולות ביותר שצוותים עושים כשבונים סוכני AI.

דוגמה קטנה שחושפת דפוס גדול יותר

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

יש שתי דרכים להגיב.

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

סגנון הקשר: להסביר לסוכן מה באמת קורה.

הופעלת על ידי משימה מתוזמנת ב-3:00 בבוקר לפי שעון פסיפיק. מזהה משימה: sched_29x8f. הרצה מתוזמנת היא ביצוע מבודד עם תחום מוגדר שהמשתמש אישר במקור. יצירת משימה מתוזמנת חדשה תרחיב את התחום הזה מעבר לאישור המקורי.

הגישה הראשונה מתקנת התנהגות אחת. השנייה נותנת לסוכן מודל של המצב.

עכשיו הוא יכול להפעיל שיקול דעת גם לגבי שאלות דומות: האם לשלוח התראה ב-3 בבוקר? האם ליצור תהליך המשך שהמשתמש לא ביקש במפורש? האם לשנות משהו שמרחיב את התחום מעבר להרצה המקורית?

אין צורך בכלל. הסוכן הבין לבד.

הרבה צוותים פונים לשליטה כשמה שהם באמת צריכים זה הקשר.

אותו הבדל מופיע גם בתוך הנחיות

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

הנחיה בסגנון הקשר: בעיקר עובדות, מינימום דעה:

אתה פועל בגלל משימה מתוזמנת. הופעלת ב-3:00 בבוקר לפי שעון בייג'ינג. מזהה משימה: sched_29x8f. המשתמש אישר את ההרצה הזו לתחום מסוים.

הנחיה בסגנון שליטה: דעות, הוראות קונקרטיות:

הימנע מיצירת משימות מתוזמנות. עליך להודיע למשתמש באמצעות כלי X. לעולם אל תעשה Y אלא אם כן Z.

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

איך הנחיות הופכות לבירוקרטיה

זו נקודת הכשל העמוקה יותר.

צוות מזהה בעיה ומוסיף כלל. ואז עוד אחד. ואז עוד אחד. כל אחד פותר בעיה מקומית, אבל יחד הם יוצרים מערכת מלאה בתחליפים.

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

זה בדיוק מה שקורה במערכות סוכנים.

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

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

עובדות מתיישנות. דעות נרקבות.

עובדה כמו "ההרצה הזו הופעלה על ידי משימה מתוזמנת ב-3 בבוקר" היא יציבה. היא נשארת נכונה בלי קשר לאיזה מודל קורא אותה: Claude, GPT, Gemini, או כל מה שיגיע ברבעון הבא.

הצהרה כמו "עליך להימנע מיצירת תתי-משימות מתוזמנות" היא שברירית. היא תלויה בפרשנות. היא עשויה לעזור במקרה אחד ולהיכשל בשקט במקרה אחר.

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

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

מלכודת הייחודיות של המודל

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

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

התיקון הזה הוא הימור שהבעיה תישאר. כמעט אף פעם זה לא קורה.

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

כך הנחיות מערכת הופכות לקוד מורשת.

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

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

מקרה מבחן טוב: הרשאה נדחתה

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

סגנון שליטה:

TOKEN חסר. הרץ "zero permissions request gmail.send" כדי לתקן.

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

סגנון הקשר:

process.env.GMAIL_TOKEN → קיים zero connectors inspect gmail → מחובר zero permissions inspect gmail.send → נדחה

אפשרויות:

1. לבקש אישור מהמשתמש עבור gmail.send
2. להשתמש בנתיב שכבר אושר אם קיים

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

ההמלצה

הנה מה שאני חוזר אליו שוב ושוב:

בכל פעם שאתה עומד לכתוב "אל", "הימנע" או "לעולם אל" בהנחיה — עצור. שאל: איזו עובדה הכלל הזה מפצה עליה?

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

כתוב את העובדה הזו. מחק את הכלל.

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

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

המטרה

המטרה היא לא סוכן ששינן רשימת בדיקה.

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

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

הראשונה מובילה לבירוקרטיה. השנייה מובילה להבנה.

בנו הקשר. מחקו את הצלקות. שחררו סוכנים שיכולים לחשוב.