מעבר ללולאת הסוכנים (Agentic Loop): תבנית ה-Orchestrator ב-TS
רוב האנשים בונים מערכות מרובות-סוכנים (multi-agent systems) באמצעות לולאת סוכנים (agentic loop).
ה-LLM משמש כמוח וכזרם הבקרה (control flow). הוא חושב, קורא לכלי, צופה בתוצאה וחוזר על הפעולה. זה עובד עבור שלבי מחקר (exploration), אך זה מביא עמו שלוש בעיות גדולות:
- חוסר יכולת חיזוי: משימה עשויה לדרוש 3 קריאות או 9 קריאות. לעולם לא תדעו מה יהיה זמן התגובה (latency) או העלות עד שהתהליך ירוץ.
- אי-דטרמיניזם: אותה שאלה עוקבת אחר מסלולים שונים בכל פעם. זה מקשה על אמון בסוכנים שמבצעים פעולות עם השפעות לוואי (side effects), כמו ביצוע הזמנות.
- יכולת תצפית (observability) נמוכה: ניפוי שגיאות (debugging) דורש השמעה מחדש של תמלולים מבולגנים של תהליכי חשיבה וקריאות לכלי.
אם אתם מכירים את הסוכנים שלכם ואת הפונקציות שלהם, השתמשו בתבנית ה-Orchestrator במקום.
ה-Orchestrator מפריד בין קבלת ההחלטות לבין הביצוע. הוא משתמש בשלושה שלבים נפרדים:
- ניתוב (Route): קריאת LLM אחת בוחרת את הכלים. היא אינה עונה למשתמש.
- ביצוע (Execute): קוד TypeScript רגיל מריץ את הסוכנים. לא נעשה שימוש ב-LLM בשלב זה.
- סינתזה (Synthesize): קריאת LLM אחת הופכת את הנתונים לתגובה טבעית.
תבנית זו יוצרת שלושה מצבי ביצוע:
• בודד (Single): סוכן אחד מטפל בשאילתה.
• מקבילי (Parallel): מספר סוכנים עצמאיים רצים בו-זמנית באמצעות Promise.all. זה חוסך זמן.
• סדרתי (Sequential): סוכנים רצים לפי הסדר. כל שלב משתמש בתוצאות מהשלב הקודם.
באמצעות גישה זו, אתם מקבלים:
- תוכנית שניתן לסמוך עליה: אתם רואים את תוכנית הביצוע לפני שכל קוד רץ.
- מהירות גבוהה יותר: ביצוע מקבילי מטפל במספר שאילתות (lookups) בו-זמנית.
- בדיקות טובות יותר: ניתן לבצע בדיקות יחידה (unit test) לשלב הביצוע ללא מפתח API.
- עלויות צפויות: כל בקשה משתמשת בדיוק בשתי קריאות LLM.
השתמשו בלולאת הסוכנים (agentic loop) לצורך מחקר. השתמשו ב-orchestrator עבור מערכות ייצור (production) הזקוקות למהירות ולאמינות.
Optional learning community: https://t.me/GyaanSetuAi