בחירה בין סוכן יחיד לבין נחיל של מספר סוכנים עבור תהליך עבודה מורכב.
→התחל עם סוכן יחיד + כלים. פצל למספר סוכנים רק כאשר גבולות המשימה ברורים, חלונות ההקשר עולים על גדותיהם, או כאשר נדרשות רמות מודל שונות עבור כל תת-משימה.
למה: ריבוי סוכנים מוסיף חביון, שטח שגיאה ועלויות תזמור. רוב עומסי העבודה בסביבת ייצור מצליחים עם סוכן אחד מצויד היטב.
הסוכן חייב להסיק מסקנות מתצפיות לפני שפועל שוב.
→הטמע לולאת ReAct (Reason + Act): המודל מייצר מחשבה, בוחר כלי, מקבל את התוצאה, וחוזר על הפעולה עד שמתקיים תנאי עצירה.
למה: ReAct הופך את ההיגיון הביניים לגלוי, משפר את יכולת הניפוי ומאפשר לך לבדוק את רצף המחשבה.
הסוכן צריך ליצור אינטראקציה עם מערכות חיצוניות (APIs, מסדי נתונים, מערכות קבצים).
→הגדר כלים באמצעות ה-tool_use API. המודל פולט בלוק tool_use; הקוד שלך מבצע אותו ומחזיר tool_result. המודל ממשיך לאחר מכן.
מקור↗
מנהל התזמור חייב לשגר תת-משימות הטרוגניות (בדיקת קוד, חיפוש באינטרנט, ניתוח נתונים).
→השתמש בסוכן מפקח שמפרק את המטרה, מפצל לסוכני משנה מומחים, ומאגד תוצאות. לכל סוכן משנה יש את ה-system prompt וסט הכלים שלו.
מספר סוכני משנה חייבים לתאם ללא תקשורת ישירה עמית-לעמית.
→נתב את כל ההודעות בין הסוכנים דרך מפקח. המפקח מחליט איזה סוכן משנה יפעל הבא, מעביר הקשר, ואוכף אילוצי סדר.
למה: הודעות ישירות בין עמיתים יוצרות מחזורים ומקשות על מעקב אחר מצב. מפקח מרכזי שומר על ה-DAG (Directed Acyclic Graph) של הביצוע מפורש.
הסוכן חייב לזכור הקשר לאורך שיחה מרובת תורות.
→העבר את כל היסטוריית השיחה (system + תורות קודמות של משתמש/עוזר) במערך ההודעות. עבור שיחות ארוכות, סכם תורות ישנות יותר כדי להישאר בתוך חלון ההקשר.
הסוכן זקוק לשמירה מתמשכת בין סשנים או בין משתמשים.
→אחסן עובדות בשכבת זיכרון חיצונית (Vector DB, Key-value store, קובץ). אחזר זיכרונות רלוונטיים באמצעות RAG והזרק אותם ל-system prompt בכל תור.
הצוות מפעיל כברירת מחדל ארכיטקטורת סוכנים עבור כל פיצ'ר של LLM.
→אל תשתמש בסוכנים כאשר prompt יחיד + פלט מובנה מספיקים. סוכנים מוסיפים חביון, עלות ומצבי כשל. שמור לולאות מבוססות סוכנים למשימות הדורשות איטרציה או שימוש בכלים.
משימת חשיבה מורכבת דורשת יותר התלבטות פנימית לפני התשובה.
→אפשר חשיבה מורחבת עם פרמטר budget_tokens. המודל משתמש בבלוק חשיבה לפני המענה, מה שמשפר את הדיוק בבעיות מרובות שלבים.
למה: חשיבה מורחבת סוחרת חביון באיכות. הגדר budget_tokens בפרופורציה למורכבות המשימה; הגבל אותו כדי לשלוט בעלויות.
מקור↗
קריאת כלי מחזירה שגיאה; הסוכן חייב להתאושש בצורה הולמת.
→החזר את השגיאה כ-tool_result עם is_error: true. המודל רואה את הכשל ויכול לנסות שוב עם פרמטרים מתוקנים, לנסות כלי חלופי, או להסביר את הכשל למשתמש.
מקור↗
כשלים זמניים ב-API (429, 529) במהלך לולאת סוכן.
→הטמע exponential backoff עם jitter. עבור 429 (מגבלת קצב), כבד את כותרת ה-retry-after. עבור 529 (עמוס מדי), המתן זמן רב יותר. לעולם אל תנסה שוב שגיאות מסוג 400 באופן עיוור.
מדידת האם מערכת סוכנים משתפרת בפועל לאורך זמן.
→בנה חבילת הערכה: הגדר צמדי קלט-פלט, הרץ את הסוכן, קבל ניקוד עבור הפלטים (התאמה מדויקת, LLM-כשופט, בדיקה אנושית). עקוב אחר אחוז המעבר לכל גרסה.
למה: ללא הערכות, שינויים בפרומפטים הם ניחוש. זיהוי רגרסיה דורש ניקוד אוטומטי וניתן לשחזור.
הסוכן מייצר פלט באיכות נמוכה בניסיון הראשון.
→הוסף שלב רפלקציה: לאחר יצירת תשובה, בקש מהמודל לבקר את הפלט שלו ולתקן. השתמש בתור הודעה נפרד או בחשיבה מורחבת.
תהליך עבודה של סוכן מבצע פעולות בלתי הפיכות (מחיקת משאבים, שליחת מיילים).
→הכנס נקודת בדיקה לפני פעולות הרסניות. הצג את הפעולה המתוכננת למשתמש, המתן לאישור, ולאחר מכן בצע. רשום את ההחלטה לביקורת.