איך בונים מערכת מולטי-אג׳נט אמיתית - מאחורי הקלעים של Qodo

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

הילה פוקס, Principal Engineer ב-Qodo, פותחת את הארכיטקטורה שמאחורי Codogen: agent שעוזר לכתוב קוד ולייצר בדיקות. זו לא הרצאה על “הנה עוד framework”. זה הסיפור על החלטות שהתקבלו כשהשוק השתנה תוך כדי הבנייה - ולמה גם החלטה נכונה היום עדיין דורשת תכנית יציאה למחר.

לא עוד קונטקסט - הקונטקסט הנכון

בשלב הראשון, agent ידע לבצע רצף פעולות מוגדר. אבל משימות פיתוח אינן מגיעות כרצף מוגדר. לפעמים צריך להבין dependency tree, לפעמים לקרוא קבצים, לפעמים לתכנן שינוי ולפעמים קודם לכתוב בדיקה. לכן Qodo רצתה לעבור מ-flow יחיד למערכת שיכולה לבחור בין כמה flows לפי המשימה.

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

גם לבוא ולתת למודלים את כל הקונטקסט בעולם, לא פותר את המשימות הכי טוב שאפשר.

MCP הפך יכולות פנימיות לכלים שהמודל יכול לבחור

Qodo כבר החזיקה יכולות פנימיות, למשל הבנת תלויות. המהלך הבא היה לחשוף אותן כ-tools שהמודל יכול להשתמש בהם לפי הצורך. ואז, ערב פגישת ארכיטקטורה, MCP יצא לעולם והפך את השאלה מ”איך נממש את זה?” ל”האם זה הפרוטוקול שעליו כדאי להמר?”

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

בארכיטקטורה שהילה מציגה, הרחבות VS Code ו-JetBrains פועלות כלקוחות MCP. לכל אחת יש servers מקומיים שמחוברים, בין השאר, לכלי Local RAG ולמערכת הקבצים. במקביל, הבקאנד מפעיל אורקסטרציה ויכול לעבוד עם servers מרוחקים. ההפרדה הזו חשובה במיוחד לארגונים שרוצים לנהל אינטגרציות בצורה מרכזית, ולא להגדיר אותן מחדש אצל כל מפתח.

הפרוטוקול עבד. ה-transport לא.

החלק המעניין הוא לא שהצוות אימץ MCP. הוא מה שקרה כשהגיע ל-JetBrains. ב-VS Code, סביבת TypeScript, מימוש ה-proof of concept רץ בלי דרמה. אבל JetBrains כתוב ב-Kotlin, והמימוש הסטנדרטי גרם לכל MCP server לפתוח process נפרד של Node.

זו לא הייתה תלות שהמוצר רצה להטיל על המשתמשים. במקום לבקש מכל משתמש JetBrains להתקין Node או לארוז אותו עם המוצר, Qodo השתמשה בממשק של MCP למימוש transport מותאם אישית. הכלים הפכו ל-in-process: הם נשארו בתוך אותו process ופעלו כ-built-in tools. אותו פרוטוקול, אבל התאמה לאילוץ של המוצר.

זה בדיוק המקום שבו ארכיטקטורה agentic פוגשת מוצר. תקן אינו פוטר אתכם מהחלטות. הוא רק נותן לכם נקודת חיבור טובה יותר.

LangGraph: לבחור flow, לא רק להפעיל כלי

MCP פתר את צד איסוף הקונטקסט. האורקסטרציה היא בעיה אחרת: איך מחליטים איזה flow ירוץ ואיך לא נותנים ל-agent להסתובב בלי גבולות.

Qodo בחרה אז ב-LangGraph, כי הוא אפשר להגדיר workflows כגרף של nodes וקשרים ביניהם. ככל שנותנים למערכת יותר אפשרויות, היא יכולה ליצור יותר flows - אבל גם נעשית פחות צפויה. הבחירה הייתה ללכת לכיוון strict ויותר opinionated, כדי לשמור על גבולות ברורים למערכת בתחילת הדרך.

ה-flow שהילה מציגה כולל supervisor שמקבל את בקשת המשתמש ומזהה את סוג המשימה, context collector שבוחר את הכלים המתאימים דרך MCP, task planner, executor ו-validator. אם ה-validator נכשל, ה-flow חוזר לביצוע נוסף. זה לא agent שיוצר קוד ומקווה לטוב. ה-validation הוא חלק מהתהליך.

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

להישאר רלוונטיים בלי להעמיד פנים שיודעים את העתיד

סטארטאפ AI לא מקבל שבועות כדי להחליט אם טכנולוגיה חדשה משנה את השוק. Qodo מתמודדת עם זה דרך קהילות open source, תרומה לפרויקטים, dogfooding ושימוש גם בכלים של מתחרים. כשכלי חדש יוצא, מפתחים בודקים אותו, משתפים תובנות ומנסים להבין מה באמת שווה לבנות סביבו.

צריך כל הזמן להכיר מה קורה בשוק ובסופו של דבר צריך להמר.

הילה מתארת את זה כ-fail fast. לא “לרוץ אחרי כל הייפ”, אלא לחקור, לקבל החלטה, וללמוד מהר אם היא לא מחזיקה. גם העתיד שהיא מסמנת - agent-to-agent communication - מגיע עם אותו סימן שאלה. אפשר להשתתף בקהילה ובבניית פרוטוקולים, אבל אי אפשר להבטיח איזה כיוון ינצח.

מה הדמו הראה בפועל

בדמו, הילה מבקשת מה-agent לייצר בדיקת Playwright שנכנסת לאתר של Qodo ומוודאת שתוכן של Codogen קיים. ה-agent בוחר כלי MCP, פותח session, מנווט באתר, מחפש טקסט גלוי, ניגש למערכת הקבצים ומייצר את קובץ הבדיקה.

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

השורה התחתונה

• מערכת מולטי-אג׳נט צריכה לבחור קונטקסט ו-flow, לא רק לייצר טקסט.
• MCP מאפשר לחבר tools וקונטקסט בצורה סטנדרטית, אבל עדיין צריך להתאים את המימוש לאילוצי המוצר.
• אורקסטרציה טובה מגדירה גם validation ומסלול חזרה לתיקון.
• LangGraph, MCP וכל framework אחר הם החלטות ארכיטקטוניות עם tradeoffs.
• בשוק שמשתנה מהר, dogfooding ו-fail fast חשובים יותר מניסיון לנחש את העתיד.

ההרצאה המלאה מציגה את הבחירות האלה מתוך מוצר שעובד מול מפתחים. אם אתם בונים agentic workflow, מתחילים ב-MCP או מנסים להבין מתי agent צריך עוד חופש ומתי הוא צריך גבולות - שווה לראות אותה עד הסוף.