מערכות Multi-Agent הפכו בתוך שנה מנושא למאמרים אקדמיים לשאלה תקציבית שנשאלת בישיבות הנהלה. התרחיש חוזר על עצמו כמעט בכל ארגון ישראלי שאנחנו נכנסים אליו: צוות הפיתוח בנה סוכן AI אחד, הדמו היה מרשים, ואז הוא נפגש עם המציאות — שלושים כלים, פרומפט של 12 אלף טוקנים, ותשובות שנעשות פחות צפויות בכל שבוע. הבעיה כמעט לעולם איננה המודל אלא הארכיטקטורה. מערכות Multi-Agent הן התשובה ההנדסית לכך: פירוק המשימה לכמה סוכנים צרים ומתמחים, מעל שכבת תזמור (orchestration) שקובעת מי רץ מתי, מה עובר ביניהם ומי מאשר. במאמר הזה נפרק את הדפוסים שעובדים בפרודקשן, את נקודות הכשל שגובות את מרב זמן הפיתוח, את העלות האמיתית בטוקנים ובחודשי עבודה, ואת ההחלטה הקריטית של build מול buy — מנקודת המבט של צוות שכבר העלה מערכות כאלה לאוויר בארגונים בישראל.
מה הן מערכות Multi-Agent ובמה הן שונות מסוכן בודד
סוכן AI בודד הוא לופ אחד: מודל שפה גדול (LLM) מקבל מטרה, בוחר כלי, מריץ אותו, קורא את התוצאה וממשיך עד שהוא מחליט שסיים. מערכות Multi-Agent מחליפות את הלופ הבודד בצוות — כל סוכן מקבל תחום אחריות צר, סט כלים מוגבל וקריטריון הצלחה מוגדר, ומעליהם רץ מתזמר שמנתב את העבודה.
ההשוואה המדויקת ביותר היא מונולית מול מיקרו-סרוויסים. סוכן בודד עם 30 כלים הוא מונולית: כל שינוי בפרומפט משנה התנהגות בכל התרחישים, ואי אפשר לבדוק רגרסיה בצורה מבודדת. פירוק לסוכנים מאפשר לבצע evaluation נפרד לכל רכיב, לגרסן אותו ולהחליף מודל מתחתיו בלי לגעת בשאר המערכת.
יש כאן גם היבט אבטחתי שנוטים לפספס. סוכן אחד שמחזיק גם הרשאת קריאה למסד הנתונים, גם הרשאת כתיבה למערכת ה-CRM וגם הרשאת שליחת מייל ללקוח הוא נקודת כשל בודדת ובלתי מבוקרת. בארכיטקטורת סוכנים מרובים, ההרשאות מחולקות לפי תפקיד — וזה לרוב מה שמאפשר בכלל לקבל אישור מקצין אבטחת המידע.
שלוש נקודות השבירה של סוכן AI בודד
הראשונה היא עומס כלים. דיוק בחירת הכלי מתחיל לצנוח כשמספר הכלים הזמינים לסוכן עולה מעל 12 עד 15 בערך, כי תיאורי הכלים מתחילים להתחרות זה בזה על תשומת הלב של המודל. פירוק לצוות סוכנים מוריד כל סוכן חזרה לחלון של 4 עד 6 כלים.
השנייה היא ניפוח פרומפט. פרומפט שהתחיל בעמוד אחד וגדל ל-12 אלף טוקנים תמיד מכיל בסופו הוראות שסותרות זו את זו, ואף אחד בצוות לא זוכר איזו הוראה נוספה בשביל איזה תרחיש קצה. זה חוב טכני שמצטבר בקצב שבועי.
השלישית היא חוסר יכולת לדבג. כשהסוכן מחזיר תשובה שגויה אחרי 14 קריאות כלים בתוך לופ אחד, אין נקודת כניסה לחקירה. במערכות Multi-Agent כל העברה בין סוכנים היא גבול מוגדר שניתן לרשום, למדוד ולהתריע עליו. אצל לקוח בתחום הלוגיסטיקה, המעבר הזה לבדו קיצר את זמן האיתור של תקלות מייצור משעות לדקות.
שווה לומר גם מה סוכן בודד עדיין עושה טוב יותר. כשהמשימה צרה, הכלים מעטים והדרישה היא זמן תגובה מינימלי, פירוק לצוות סוכנים רק מוסיף השהיה ועלות. המבחן המעשי שאנחנו מריצים לפני כל פירוק הוא פשוט: האם יש לפחות שני תפקידים שדורשים סטים שונים של כלים או הרשאות שונות? אם התשובה שלילית, אין מה לפרק.
\n\n
ארכיטקטורת מערכות Multi-Agent: שלושה דפוסים שעובדים בפרודקשן
הדפוס הראשון והנפוץ הוא Supervisor, או orchestrator-worker: סוכן מתזמר מקבל את הבקשה, מפרק אותה ומנתב לסוכני עבודה מתמחים, ואוסף את התוצאות. הוא מתאים כשהמשימות עצמאיות זו מזו — למשל מענה לפנייה שדורשת גם שליפת נתוני לקוח, גם בדיקת מצב הזמנה וגם חישוב זכאות.
הדפוס השני הוא pipeline סדרתי: כל סוכן מקבל את הפלט של קודמו ומעביר הלאה. זה הדפוס הנכון לתהליכים רגולטוריים שבהם הסדר הוא חלק מהדרישה — חילוץ נתונים, אימות, סיווג, החלטה, תיעוד. הוא צפוי, קל לביקורת ופחות יצירתי.
הדפוס השלישי הוא היררכי עם mesh מקומי: מתזמר עליון קובע אסטרטגיה, ומתחתיו קבוצות סוכנים שמדברות ביניהן ישירות בלי לעבור דרך המרכז. זה הדפוס היחיד שמחזיק כשמספר הסוכנים עולה מעל עשרה, אבל הוא גם היחיד שדורש ניהול state אמיתי. הכלל הפשוט שאנחנו עובדים לפיו: אל תתחילו מכאן. תתחילו מ-Supervisor עם שלושה סוכנים, ותעברו להיררכי רק כשהמידה מכריחה.
Handoff וניהול Context: כאן קורות מרבית התקלות
אם יש מסקנה אחת אחרונה מהשנה האחרונה, זו זו: רוב מה שנראה ככשל של סוכן הוא בפועל כשל בהעברת ההקשר בנקודת ה-handoff, ולא כשל ביכולת המודל. סוכן ב' לא קיבל שדה שסוכן א' הכיר, או קיבל סיכום חופשי שאיבד את הפרט הקריטי.
הפתרון ההנדסי הוא להפסיק להעביר טקסט חופשי בין סוכנים. העברה בין סוכנים צריכה להיות חוזה מובנה — סכמת JSON עם שדות חובה, ולידציה, וכשל מפורש כשהחוזה לא מתקיים. זה מרגיש מסורבל בשבועיים הראשונים ומחזיר את ההשקעה כבר בחודש הראשון בפרודקשן.
מעל זה נדרש shared state: מקום אחד שמחזיק את מצב המשימה, כך שסוכן שנכנס באמצע לא תלוי בכל היסטוריית השיחה. כאן גם המקום לשלב שכבת AI של שליפת ידע ארגוני בגישת RAG — כדי שכל סוכן ישלוף רק את הפיסה הרלוונטית לו, במקום לגרור חלון הקשר ענק שמייקר כל קריאה. תיעוד מפורט של אתגרי התיאום הללו מופיע גם במאמר AutoGen של Microsoft Research, שהיה אחד הראשונים לתאר את הבעיה בצורה שיטתית.
Observability, בקרה וממשל לפני עלייה לאוויר
מערכת סוכנים בלי tracing היא קופסה שחורה שמקבלת החלטות בשם הארגון. הדרישה המינימלית שאנחנו מגדירים לכל פרויקט: רישום מלא של כל צעד — איזה סוכן רץ, איזה כלי נקרא, אילו פרמטרים, מה חזר, כמה טוקנים נשרפו וכמה זמן זה לקח. בלי זה אין דרך לשפר ואין דרך להסביר.
מעל התיעוד נדרשים שני מנגנוני בקרה. הראשון הוא גבולות הרשאה קשיחים ברמת הסוכן — לא בפרומפט, אלא בשכבת הקוד שמעל הכלי. השני הוא שערי human-in-the-loop בנקודות ההחלטה בעלות ההשלכה הגבוהה: אישור תשלום, שינוי מצב חוזה, שליחת תכתובת ללקוח.
בישראל יש לזה גם צד רגולטורי מוחשי. גוף פיננסי שמפוקח על ידי רשות שוק ההון או בנק ישראל, וכן כל ארגון שעובד מול נתוני אזרחים אירופיים תחת GDPR, יידרש להציג מסלול ביקורת שמסביר איך התקבלה החלטה ספציפית. ארכיטקטורת סוכנים מרובים עם תיעוד לכל צעד היא דווקא יתרון כאן, בדיוק מפני שהיא מפרקת החלטה אחת גדולה לשרשרת מתועדת.
נקודה שעולה כמעט בכל דיון עם קצין אבטחת מידע היא הזרקת פרומפט דרך תוכן חיצוני. במערכת סוכנים, מסמך שהגיע מספק או פנייה שנכתבה על ידי גורם חיצוני יכולים להכיל הוראות שמנסות להשפיע על סוכן במורד השרשרת. הכלל שאנחנו אוכפים: תוכן שהגיע מבחוץ מסומן כנתון ולא כהוראה, וכל פעולה בעלת השפעה חייבת לעבור דרך גבול הרשאה שנאכף בקוד ולא בטקסט.
\n\n
העלות האמיתית: טוקנים, latency וחודשי הטמעה
הנתון שמפתיע כל מי שעובר מסוכן בודד: מערכות Multi-Agent שורפות בין פי שלושה לפי שמונה טוקנים על אותה משימה. הסיבה פשוטה — כל סוכן קורא הקשר, כל העברה מסכמת, והמתזמר מחליט לפחות פעם אחת נוספת. מי שלא מתקצב את זה מראש מקבל הפתעה בחשבון של החודש השני.
שלוש הפעולות שמחזירות את העלות למקום סביר הן ניתוב מודלים — מודל קטן וזול לניתוב ולסיווג, מודל גדול רק לשלב שדורש הסקה אמיתית; prompt caching על החלקים הקבועים בהוראות; והקטנה אגרסיבית של ההקשר שכל סוכן מקבל. בפרויקטים שלנו השילוב הזה מוריד בדרך כלל את עלות הטוקנים בשיעור של עשרות אחוזים בלי פגיעה מדידה באיכות.
ומה עם latency? זה הפרמטר שקובע אם המערכת בכלל אפשרית. בממשק צ'אט אסינכרוני, שרשרת של ארבעה סוכנים בתוך 8 עד 12 שניות היא לגמרי סבירה. בממשק קולי, שבו מעל שנייה וחצי של שתיקה נשמע כמו תקלה, צריך לתזמר במקביל ולא בטור — זה בדיוק האתגר שפתרנו ב-Dialex, פלטפורמת ה-Voice AI שלנו בעברית, שבה תקציב הזמן לכל תור שיחה הוא אילוץ הנדסי שהארכיטקטורה נבנית סביבו.
Build או Buy: מתי פריימוורק מוכן מספיק
יש היום פריימוורקים בוגרים לתזמור — LangGraph, AutoGen, CrewAI — ופלטפורמות מנוהלות שמריצות סוכנים בענן. לתרחישים פנים-ארגוניים בסיכון נמוך, כמו סוכן שמסכם ישיבות או מנתב פניות פנימיות, הם הבחירה הנכונה: זמן העלייה לאוויר נמדד בשבועות ואין סיבה לבנות תשתית.
שלוש סיטואציות מחייבות פיתוח עמוק. הראשונה היא דרישת on-premise או סביבה מנותקת — ארגוני ביטחון, תעופה וגופים פיננסיים שלא מוציאים דאטה מהרשת. השנייה היא עברית: תזמור שמסתמך על הבנת כוונה בעברית מדוברת, על שמות ישראליים ועל מספרי זהות דורש fine-tuning על דאטה מקומי, ולא רק פרומפט מתורגם. השלישית היא אילוצי זמן אמת קשים, כמו ראייה ממוחשבת בקו ייצור או ניטור בעיר חכמה.
בפועל, רוב הארגונים שאנחנו עובדים איתם מגיעים לתמהיל: פריימוורק פתוח לשכבת התזמור, ורכיבים שפותחו בהתאמה במקומות שבהם התוצר הוא היתרון התחרותי. כך נבנתה ב-MaiTech שכבת סוכנים למערכת חינוך שדרשה התאמה לעברית ולתוכן הלימודי הישראלי, וכך גם ב-Quantap בתחום הנדל"ן והבנייה, שבו הסוכנים נדרשו לקרוא תוכניות ומסמכים בפורמטים שאין להם פתרון מדף.
תוכנית 90 יום להטמעת מערכות Multi-Agent
בשלושים הימים הראשונים בוחרים תהליך אחד מדיד עם קלט וקלט-פלט ברורים, ובונים סוכן בודד סביבו. המטרה איננה ארכיטקטורה מרשימה אלא בסיס השוואה: מה הדיוק, מה העלות לפנייה, מה זמן התגובה. בלי המדידה הזו אין דרך להוכיח שהפירוק לסוכנים שיפר משהו.
בימים 31 עד 60 מפרקים לצוות סוכנים בדפוס Supervisor, מגדירים חוזי handoff מובנים, ומחברים tracing ו-evaluation אוטומטי לכל סוכן בנפרד. כאן גם מוסיפים את שערי האישור האנושיים ואת גבולות ההרשאה. זה השלב שבו המערכת הופכת ממדגם למוצר.
בימים 61 עד 90 מרחיבים לתהליך שני, מייצבים עלויות באמצעות ניתוב מודלים ו-caching, ובונים את תהליך התחזוקה השוטף — מי מסתכל על הדשבורד, מי מאשר שינוי פרומפט, ואיך נראית רגרסיה לפני deploy. ארגון שעובר את שלושת השלבים האלה מגיע לסוף הרבעון עם סוכני AI לארגונים שעובדים בפרודקשן, ולא עם עוד הוכחת היתכנות במגירה.
מערכות Multi-Agent הן פרויקט הנדסי, לא רכש כלים. הן דורשות החלטות על ארכיטקטורה, הרשאות, מדידה ועלות — ורוב הכשלים שראינו נבעו מדילוג על אחת מההחלטות האלה, לא מבחירת מודל שגויה.
אם אתם שוקלים ארכיטקטורת סוכנים מרובים לארגון שלכם ורוצים לדעת איפה הסיכונים האמיתיים בתרחיש הספציפי שלכם, אנחנו כאן: לשיחת ייעוץ ללא עלות.
