תזמור רב-סוכנים (Multi-Agent Orchestration)

מסוכן אחד למערכת של סוכנים

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

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

טופולוגיה 1: Orchestrator ועובדים מתמחים

הדפוס הנפוץ ביותר: סוכן מתאם (orchestrator) מפרק את המשימה ומחלק חלקים לסוכני "עובדים" מתמחים, כל אחד עם תפקיד, הקשר וסט כלים משלו. המתאם לא בהכרח עושה את העבודה בעצמו — התפקיד שלו הוא לתכנן, לחלק ולאחד.

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

טופולוגיה 2: Pipeline ותקשורת חופשית בין עמיתים

Pipeline: שרשרת סוכנים שבה כל אחד מקבל את הפלט של הקודם, מבצע את החלק שלו ומעביר הלאה — למשל סוכן שאוסף מידע, סוכן שמנתח אותו וסוכן שכותב דוח. אין מתאם מרכזי; הסדר קבוע מראש, בדומה ל-prompt chaining מפרק 3, רק שכל שלב הוא סוכן ולא קריאה בודדת.

תקשורת חופשית בין עמיתים (peer-to-peer): סוכנים שולחים הודעות זה לזה לפי הצורך, בלי היררכיה. זה הדפוס הגמיש ביותר, אבל גם הנדיר ביותר בפרודקשן — קשה לצפות מה יקרה, קשה לדעת מתי העבודה הסתיימה, וקשה מאוד לדבג כשמשהו משתבש.

האתגר המרכזי: מצב משותף ועבודה כפולה

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

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

דוגמה מלאה: כמה סוכנים סוקרים קוד במקביל

משימה: "סקור את כל הפרויקט ומצא בעיות". המתאם מחלק את הפרויקט לשלושה תחומים נפרדים (auth, API, ממשק משתמש) ומפעיל שלושה סוכני עובדים במקביל, כל אחד עם גישה לתיקייה שלו בלבד — כך שאין חפיפה ואין סיכון שניים ייגעו באותו קובץ.

כל עובד מחזיר רשימת ממצאים לתחום שלו. המתאם ממתין לשלושתם, מאחד את הרשימות לדוח אחד, ומזהה חפיפות או סתירות בין תחומים (למשל בעיה שנוגעת גם ל-auth וגם ל-API). את השלב הזה קוד פשוט לא יכול לעשות, כי הוא דורש שיפוט: מה חשוב, ומה בעצם אותה בעיה שנמצאה פעמיים.

async function reviewProject(areas: string[]) {
  const findings = await Promise.all(
    areas.map((area) => runWorkerAgent(area)) // רץ במקביל, כל worker בתיקייה משלו
  );

  return mergeCoordinatorReport(findings); // מזהה חפיפות/סתירות בין הממצאים
}

מתי לא כדאי מערכת רב-סוכנית

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

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

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