תזמור רב-סוכנים (Multi-Agent Orchestration)
במה זה שונה מ-Subagents
בפרק 3 ראינו subagent: הורה שמאציל משימה ממוקדת לילד, מחכה שהוא יסיים, ומקבל תקציר בחזרה — יחס היררכי, חד-כיווני ולרוב טורי מנקודת המבט של ההורה. תזמור רב-סוכנים הוא משהו אחר: כמה agents שרצים כעמיתים (peers), לא בהכרח ביחסי הורה-ילד, שיכולים לתקשר ישירות זה עם זה או דרך רכיב מתאם משותף, ולעיתים קרובות במקביל ממש — לא רק "מחכים בתור".
ההבדל המעשי: subagent הוא כלי לפירוק משימה אחת פנימה (ההורה שולט בכל התהליך), בעוד תזמור רב-סוכנים עוסק בכמה תהליכי עבודה עצמאיים-יחסית שצריכים להתקדם יחד לקראת מטרה משותפת או חלקית-משותפת.
טופולוגיה 1: Coordinator ועובדים מתמחים
דפוס נפוץ: agent אחד משמש "מתאם" (coordinator/manager) שמפרק את המשימה הכוללת ומחלק חלקים ל-agents "עובדים" מתמחים — כל אחד עם תפקיד, הקשר וסט כלים ממוקדים משלו. המתאם לא בהכרח מבצע עבודה בעצמו; תפקידו הוא לתזמן, לחלק ולאסוף.
הדמיון ל-subagents ברמת המנגנון (הפעלת agent נפרד עם משימה ממוקדת) הוא לא מקרי — coordinator/worker לרוב בנוי מהמנגנון הטכני של subagents, רק שהעובדים יכולים לרוץ במקביל זה לזה ולתקשר דרך המתאם, ולא רק אחד אחרי השני בטור.
טופולוגיה 2: Pipeline ותקשורת חופשית בין עמיתים
דפוס אחר: pipeline — סדרת agents שכל אחד מקבל את הפלט של הקודם לו כקלט, מבצע את חלקו, ומעביר הלאה (למשל agent אחד שאוסף מידע, השני שמנתח אותו, השלישי שכותב דוח). אין כאן מתאם מרכזי — כל שלב פשוט יודע מי בא לפניו ואחריו.
דפוס פחות נפוץ אך אפשרי: תקשורת חופשית בין עמיתים (peer-to-peer), שבה agents שולחים הודעות זה לזה ישירות לפי הצורך, בלי היררכיה קבועה מראש — גמיש יותר, אך גם קשה משמעותית לעקוב אחריו ולדבג כשמשהו משתבש.
האתגר המרכזי: מצב משותף ועבודה כפולה
מעבר מ-agent בודד לכמה agents שפועלים יחד מוסיף בעיה שלא קיימת כלל בלולאה אגנטית יחידה: כמה מקורות פעולה עצמאיים עלולים לגעת באותו משאב בו-זמנית (למשל שני agents שעורכים את אותו קובץ), לבצע את אותה עבודה פעמיים בלי לדעת אחד על השני, או להגיע למסקנות סותרות שמישהו צריך ליישב.
אין פתרון אחד גורף — אבל דפוסים נפוצים כוללים: חלוקת עבודה מראש כך שלכל agent יש תחום אחריות בלעדי (למשל קבצים/תיקיות נפרדות), ושלב "איחוד" מפורש בסוף (ע"י המתאם או agent ייעודי) שמזהה ופותר סתירות בין תוצרים, במקום להניח שהם יתאחדו מעצמם.
דוגמה מלאה: כמה סוכנים סוקרים קוד במקביל
נניח משימה: "סקור את כל הפרויקט ומצא בעיות". coordinator agent מחלק את הפרויקט לשלושה תחומי אחריות נפרדים (למשל: auth, API, ממשק משתמש) ומפעיל שלושה worker agents במקביל, כל אחד עם גישה לתיקייה שלו בלבד — כך שאין חפיפה ואין סיכון שנוגעים באותו קובץ בו-זמנית.
כל worker מחזיר רשימת ממצאים ממוקדת לתחום שלו. ה-coordinator מחכה שכל השלושה יסיימו, מאחד את הרשימות לדוח אחד, ומזהה אם יש חפיפה או סתירה בין ממצאים משני תחומים (למשל בעיה שנוגעת גם ל-auth וגם ל-API) — שלב שקוד לא יכול לבצע אוטומטית, כי הוא דורש שיפוט של מה בעצם חשוב ומה כפול.
async function reviewProject(areas: string[]) {
const findings = await Promise.all(
areas.map((area) => runWorkerAgent(area)) // רץ במקביל, כל worker בתיקייה משלו
);
return mergeCoordinatorReport(findings); // מזהה חפיפות/סתירות בין הממצאים
}