סוכנים שמשתמשים בכלים — ולא יוצאים מהמסילה.

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

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

סכמות כלים הן חוזה, לא רמז

המודל יקרא רק לכלים שאתם מתארים. התיאורים חשובים כמו הפרמטרים. אם התיאור של כלי ה-send_email שלכם אומר ״שולח אימייל״, המודל ישתמש בו לכל כוונה שנראית כמו אימייל — כולל טיוטות, תזכורות, והתראות שלא התכוונתם שיטפל בהן. אם התיאור אומר ״שולח אימייל ללקוח; קרא רק אחרי אישור משתמש מפורש״, מצב הכשל משתנה.

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

מדיניות ה-retry קובעת את חוויית המשתמש

שגיאות רשת, rate limits, כשלי מודל זמניים — כל אלה קורים. התשובה הנאיבית היא לנסות שוב. התשובה הנכונה תלויה אם הכלי היה idempotent.

אנחנו מחלקים כלים לשתי דליים. כלי קריאה (חיפוש, lookup, fetch) מקבלים retry אוטומטי עם exponential backoff. כלי כתיבה (שליחה, יצירה, עדכון, מחיקה) לא מקבלים retries אוטומטיים. הם מעלים את הכשל למודל, שאז מחליט אם לקרוא שוב, לשאול את המשתמש, או להסלים. זה מונע את מצב הכשל שבו רשת לא יציבה שולחת שלוש הזמנות רכש זהות.

בני אדם בלולאה, לא על הספסל

לכל סוכן ששילחנו יש לפחות כלי אחד שדורש אישור אנושי מפורש. הדפוס זהה: המודל מציע פעולה, המערכת מסדרת אותה ל-payload מובנה, אדם רואה את ה-payload ב-UI ולוחץ approve או reject, התוצאה חוזרת למודל.

הטריק הוא להפוך את ה-UI של האישור מהיר מספיק שאנשים באמת ישתמשו בו. אם אישור לוקח שלושים שניות כי המשתמש צריך לחפור בקונטקסט, הם יתחילו לחתום ב-rubber stamp. אנחנו מרנדרים את trace השיקולים של הסוכן ליד הפעולה המוצעת, כדי שהאדם יכול לבקר את ה-why, לא רק את ה-what.

שלוש דוגמאות פרודקשן

סוכן ה-sales-ops למפיץ B2B קורא RFQs נכנסים, מנסח הצעות מחיר מול קטלוג של 60k SKUs, ושם בתור לאישור אנושי. כלי קריאה הם autoretry. הצעת המחיר המנוסחת היא יחידת האישור. אדם סוקר ולוחץ שלח. ה-throughput עלה מ-40 הצעות ביום ל-600.

סוכן ה-triage לתמיכה לחברת SaaS קורא tickets נכנסים, עושה lookup ללקוח, מסווג את הבעיה מול טקסונומיה ידועה, ומציע פעולה. חלק מהפעולות (סגור כפול, בקש מידע נוסף) מבוצעות אוטומטית. חלק (זיכוי, השעיית חשבון) דורשות אישור אנושי. הדיוק של הסוכן בסיווג הוא 91%; לפעולות ה-auto-execute יש ״undo״ בלחיצה אחת לצוות התמיכה.

סוכן התיעוד לצוות הנדסה פנימי קורא pull requests, עושה lookup לנתיבי קוד מושפעים, ומנסח release notes. אין מסלול auto-execute. כל פלט נסקר. הזכייה היא לא להסיר את האדם — היא להסיר את בעיית הדף הריק בחמש אחה״צ ביום שישי.

זה שנכשל

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

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