מערכות agentic כבר לא מרשימות רק כי הן יודעות לקרוא לכלים. השאלה השקטה יותר היא אם הן עושות את זה באופן צפוי, משאירות אחריהן ראיות, ועוצרות כשצריך.
1. להעדיף workflows עד שממש הרווחתם agent
הדרך המהירה ביותר לבנות מערכת שבירה היא להתחיל מ-planner משוטט רק כי זה מרגיש מתקדם.
אם למשימה יש רצף ידוע ברובו, workflow נותן כמעט בחינם:
- דיבאג נקי יותר
- latency ועלות שאפשר להסביר
- שטח כשל קטן יותר כשהמודל טועה בקריאת הסיטואציה
Agent אוטונומי יותר מתאים רק כשהגרסה מבוססת ה-workflow כבר באמת נוקשה מדי למשימה. לפני זה, אוטונומיה נוספת היא בדרך כלל עוד שטח פנים שאפשר לקלקל.
2. שימוש בכלים הוא חוזה API, לא תכונת אופי
תיעוד ה-Agents של OpenAI טוב בדיוק כי הוא לא עושה רומנטיזציה לכלים. web search, file search, connectors או computer use הם משטחי ביצוע. לכן רף האיכות דומה לכל אינטגרציה אחרת.
חוזה כלי טוב כולל:
- סכמת קלט צרה
- מצבי כשל ברורים
- הרשאות מפורשות
- עיבוד המשך דטרמיניסטי
כלי לא יקר ערך כי מודל יכול להפעיל אותו. הוא יקר ערך כי החוזה משאיר פחות דרכים להיות חכם ברגע הלא נכון.
3. retrieval הוא שכבת שליטה, לא רק הקשר
הרבה כשלים של agents הם כשלים של retrieval בתחפושת של reasoning.
מערכות עם עוגן במקורות מתנהגות טוב יותר כשמתייחסים ל-retrieval כשכבת שליטה:
- מביאים רק את מה שהשלב הנוכחי צריך
- עושים rerank או סינון לפני generation
- שומרים על זהות המסמך לאורך כל הריצה
- מאפשרים abstain כשהתמיכה דקה
ב-loop agentic זה חשוב אפילו יותר, כי retrieval חלש בתחילת הריצה מרעיל את כל מה שבא אחריו.
4. אישור אנושי שייך לקצה היקר
שערי אישור לא צריכים להיות בכל מקום. הם צריכים להופיע במקום שבו המערכת חוצה גבול שלמישהו יהיה אכפת ממנו אחר כך.
דוגמאות טיפוסיות:
- לשלוח, למחוק או לפרסם משהו
- לשנות מצב פיננסי או משפטי
- לבצע שינוי בקוד או בתשתית עם side effects אמיתיים
- לענות בביטחון בתחום רגיש
את כל השאר עדיף לאוטומט, ללוג ולשמור הפיך ככל האפשר.
5. Context engineering בריא יותר מזיכרון סנטימנטלי
צוותים רבים אומרים שהם צריכים memory, כשבפועל הם צריכים thread יציב של state וראיות.
זה בדרך כלל מגיע משלושה מקורות:
- מצב הריצה הנוכחי
- העדפות מתמשכות שבאמת שווה למחזר
- artifacts שאפשר לשלוף לפי הצורך, כמו receipts, סיכומים ופלטים קודמים
הכתיבה האחרונה של Anthropic על context engineering מתקנת בדיוק את הטעות הזאת. המשימה היא לא לצבור עוד טקסט, אלא להחליט איזה context שייך ללולאה, מה צריך retrieval לפי דרישה, מה אמור לפוג, ומה חייב להישאר inspectable.
מה שלא רוצים הוא blob גדל של שיחה קודמת שאי אפשר לבדוק. אם אי אפשר לבדוק, לפוג או לשחזר אותו מ-artifacts, הוא יהפוך מהר למיתולוגיה.
6. evals הם מערכת ההפעלה
ההכוונה של OpenAI והעבודה של Anthropic על agent evals נפגשות באותה מסקנה: אם המערכת יכולה לעשות כמה צעדים, לגעת בכלים או להסתעף תחת אי-ודאות, evals מפסיקים להיות קישוט מחקרי והופכים לדבר שמאפשר לישון.
הסטאפים החזקים יותר משלבים בדרך כלל:
- בדיקות הצלחה למשימה
- בדיקות נכונות לקריאות הכלים
- בדיקות grounding או ציטוט
- בדיקות refusal ו-escalation
- תקציבי latency ועלות
- trace grading כשמה שקורה באמצע חשוב כמו התשובה הסופית
Agent בלי evals הוא פשוט workflow שבחרתם עדיין לא למדוד.
7. טלמטריה צריכה להסביר החלטות, לא רק שגיאות
רוב הצוותים כבר אוספים כשלים. פחות מהם אוספים גבולות reasoning, בחירת כלים, snapshots של retrieval, מסלולי approval ו-triggerים של policy.
זה בדיוק ההקשר שחסר כשמנסים להבין למה incident הפך יקר.
ברמת המינימום צריך טלמטריה עבור:
- הכלי שנבחר
- הארגומנטים שנשלחו
- המסמכים שנשלפו
- אירועי policy או guardrails
- בקשות לאישור אנושי
- צורת התשובה הסופית וה-posture שלה
Trace טוב מאפשר למהנדס אחר לענות על שאלה פשוטה:
למה המערכת חשבה שמותר לה לעשות את זה?
8. הדפוס המנצח קטן יותר ממה שנדמה
הדפוס שאני סומך עליו נראה צנוע למדי:
- מסווגים את המשימה
- טוענים רק context רלוונטי
- בוחרים מתוך סט כלים תחום
- מבצעים עם receipts
- מריצים checks
- עונים, נמנעים או מסלימים
זה לא זוהר. זאת גם בדיוק הסיבה שהוא עובד.