ככה תבנו מפעל AI עם סוכנים שמדברים אחד עם השני – בלי להיתקע ביניהם

עומדים לבנות צוות של סוכנים מתמחים? לפני שאתם מתחילים לעבוד, כדאי לדעת מאילו שגיאות להימנע ואיך לעשות את זה בצורה הכי יעילה ומדויקת

איך לנהל סוכני קוד שמדברים אחד עם השני? (צילום: Dreamstime)

מאת עופר מנדלביץ'

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

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

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

איך לנהל סוכני קוד שמדברים אחד עם השני?

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

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

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

בפלטפורמה שלנו, לדוגמה, סוכנים מתקשרים אחד עם השני באמצעות mention@ – ממש כמו ב-Slack או ב-Teams. ההודעה מנותבת לסוכן או לאדם שתויג, ורק הסוכנים שתויגו יכולים לקרוא אותה. יש כאן הפרדה מכוונת: הסוכנים מחליטים מה לומר ולמי לפנות, והמערכת עצמה מטפלת בניתוב ללא קריאה נוספת ל-LLM. החלטה שמשפיעה על כמה סוכנים נשלחת אליהם באמצעות תיוג, כך שיוכלו לעדכן את עבודתם גם אחרי תחילת המשימה.

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

איך נדע מתי להיכנס לשיחה בין סוכנים?

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

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

סוכנים מסביבות שונות עובדים על אותה משימה

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

חברת Qodo בנתה על התשתית הזאת את Dark Factory – מערכת פנימית שמקדמת בקשות פיתוח עד ל-PR שעבר code review ומוכן ל-merge. סוכן הפיתוח, Builder, מתכנן ומממש; Reviewer עצמאי בודק את השינוי; ומהנדס משתתף בשיחה כדי לכוון ולהוסיף קונטקסט. בנוסף, סוכן SRE מסביבה נפרדת מביא מידע מהפרודקשן, בלי להעביר את פרטי הגישה שלו ל-Builder.

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

במקרה של Qodo, ה-Reviewer לא משנה את הקוד שהוא בודק. הוא מחזיר ממצאים, וה-Builder יכול להשיב להם ולתקן את הקוד עם כל המידע הנדרש ועם הכלים האישיים שלו. ממצא מה-review או מידע מה-SRE עשויים גם לשנות את התוכנית תוך כדי. כלי CLI ייעודי מנהל את הפעולות שמשנות קוד ואת מחזור החיים של ה-PR במסלול קבוע ומתועד, ורק לסוכנים הרלוונטיים יש גישה אליו.

איך כל זה נראה בפועל? באחת המשימות, Dark Factory עדכנה בעצמה את הסטנדרטים של ה-code review במערכת סוכנים אחרת של Qodo. החברה מגדירה סטנדרטים מסודרים ל-code review, ועדכונם דרש שינויים בכמה סוכנים ובממשקי ה-API ביניהם, כדי לוודא שכל הסוכנים עומדים בדרישות. צוות הסוכנים פתח draft PR עם תוכנית לפני כתיבת הקוד, השלים מימוש ראשון מקצה לקצה בתוך דקות, והשינוי נכנס לעבודה של כלל הסוכנים כבר באותו בוקר. המהנדס שאישר את ה-PR קיבל תוצר שכבר עבר ריוויו עצמאי, ותרם את ההכוונה המוצרית בזמן שהסוכנים טיפלו במימוש ובביקורת.

איך מרכיבים צוות סוכנים עבור משימה גדולה?

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

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

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

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