ChatDev בפרודקשן: היכן מתפרק צינור הפיתוח הרב-סוכני
בדמו, פיתוח רב-סוכני נראה משכנע: משימה קטנה ומבודדת, מאגר נקי, תוצאה צפויה בהרצה אחת. במאגר עבודה הצינור פוגש קוד זר, היסטוריית שינויים ארוכה וענפים מקבילים — ושם מתגלות נקודות כשל שלא היו בדמו כלל.
הראשונה והנפוצה ביותר — חוסר סנכרון בין התפקידים בעת תזמור הסוכנים. האדריכל מתאר את הפתרון בקבוצת קבצים אחת, המבצע מתקן באחרת, הבודק מסתכל על קבוצה שלישית: פורמלית כל התפקידים עבדו, אבל בפלט — קבוצת שינויים לא עקבית.
כל עוד אין חוזה מפורש בין התפקידים (מי קורא אילו נתיבים ומי משנה אותם), הצינור יוצר תחושה שגויה של שלמות.
השנייה — תיקונים ללא תיוג. הסוכן יוצא מהאזור המוצהר ומשנה קונפיגורציה, בדיקות או תלויות, בלי לסמן זאת כלל. בקבוצת השינויים הכללית זה מתערבב עם המטרה, והבודק מבזבז זמן על ארכאולוגיה במקום על ניתוח הלוגיקה. זה נסגר באמצעות ייחוס: כל תיקון מקושר לתפקיד, לשלב ולמספר ההרצה.
השלישית — הרצה שאינה ניתנת לשחזור. אם נתוני הקלט, גרסת המודל, ההקשר שנבנה ותוצאות קריאות הכלים לא נרשמו, הרצה חוזרת מפיקה קוד אחר, וחזרה אחורה וניתוח תקלה הופכים לבלתי אפשריים. בהמשך נבחן כיצד זה נסגר ברמת הקונפיגורציה והתהליך.
מה נותן צינור מבוקר לפיתוח סוכני
פיתוח רב-סוכני מניב אפקט מדיד רק כאשר תפקידי הסוכנים, גבולות ההרשאות שלהם ונקודות הביקורת האנושית המחייבת מוגדרים מראש. אנחנו פורשים ChatDev כמתזמר תפקידים — אדריכל, מפתח, סוקר, בודק — וקובעים לכל סוג משימה מסלול: מה הסוכן עושה בעצמו, היכן הוא עוצר וממתין למהנדס.
המדד הראשון — שיעור המשימות האוטונומיות שמגיעות למיזוג בלי השלמה ידנית. בשינויים טיפוסיים, כמו תיקון לוגיקה, כיסוי בבדיקות או עדכון קונפיגורציה, הוא מגיע לערכים יציבים, והביקורת מפסיקה להתעסק בתיקונים מכניים. זמן מחזור התיקונים מתקצר משום שהבדיקות רצות במקביל לכתיבת הקוד, ולא אחריה.
השני — מחלקת כשלים שנמנעה. שינויים שלא עברו בדיקות קוד אוטומטיות, ניתוח סטטי ובדיקות, אינם מגיעים לענף הראשי: סוכן הסוקר מחזיר אותם למחזור ואינו יוצר בקשת מיזוג עד להרצה ירוקה. זה מסיר שכבה של תקלות שנתפסו קודם בביקורת או כבר בסביבת ההפעלה.
יכולת מעקב אחר החלטות הסוכנים — זה שבלעדיו אוטונומיה הופכת לסיכון. כל שלב נרשם ביומן: איזה תפקיד, על בסיס אילו קבצים ותוצאות בדיקה קיבל החלטה, איזה חפץ (ארטיפקט) יצר ומי אישר. מהיומן ניתן לשחזר את לוגיקת השינוי ולראות היכן התערב האדם.
בהמשך נבחן כיצד המדדים הללו נמדדים, לפי אילו ספים מתקבלת ההחלטה על הרחבת האוטונומיה ומה נשאר בידי המהנדס בכל שלב.
מצבי הרצה: אינטראקטיבי, אצווה, אוטונומי
מצב ההרצה קובע היכן בצינור עוצר האדם ומה ניתן לאשר לפי סימנים פורמליים. ב-ChatDev זהו מתג ברמת המשימה: אותה שרשרת תפקידים או רצה עם אישור בכל שלב, או עוברת את המחזור כולו. להלן שלושה מצבים, ואילו מגבלות כל אחד מהם מטיל על הבקרה והקבלה.
| מצב | מתי מתאים | מגבלות ובקרה |
|---|---|---|
| אינטראקטיבי | תחומי דעת חדשים, דרישות שנויות במחלוקת, מעברים ראשונים במאגר לא מוכר | האדם מאשר כל שלב: ההרצה נמשכת זמן רב יותר, אבל התיקונים נעשים לפני שהפתרון התפזר על פני עשרה קבצים |
| אצווה | משימות אחידות לפי תבנית מוכרת: מיגרציות, בדיקות, תיעוד | קבלה לפי קריטריונים פורמליים — בנייה, מערך בדיקות, ניתוח סטטי; פערים מהותיים נראים רק בפלט של האצווה, והחזרה אחורה נעשית עבור המשימה כולה |
| אוטונומי | שרשראות שלבים ארוכות עם סימן מובהק למוכנות, הרצות רגרסיה | נדרשים מגבילים: תקרת שלבים, איסור על שינוי נתיבים קריטיים, נקודת חזרה מחייבת — אחרת השגיאה מתרחבת על כל הענף |
בפועל, המצבים אינם סותרים זה את זה. מצב האצווה הוא ברירת המחדל: זמן הרצה צפוי וקבלה ניתנת לבדיקה. את האוטונומי מפעילים בקטעים שיש בהם בדיקות, נתוני בדיקה וחזרה אחורה מהירה, ואת האינטראקטיבי משאירים למעברים הראשונים ולמשימות שבהן הדרישות עדיין מתחדדות.
הטמעת ChatDev: מביקורת מאגר ועד מסירה
הטמעת ChatDev אינה מתחילה בהרצת סוכנים, אלא במיפוי מה שכבר קיים בקוד. סדר השלבים זהה לכל מאגר: קודם אוספים עובדות, אחר כך מתכננים תפקידים, ורק לאחר מכן נותנים לסוכנים גישה לעבודה. כל שלב מסתיים בארטיפקט שניתן לבדוק — בלעדיו השלב הבא אינו מתחיל.
- ביקורת המאגר. בוחנים את מבנה המודולים, כיצד נבנה הפרויקט, היכן נמצאות הבדיקות ואילו נתיבים קריטיים הן מכסות. בפלט — מפת תלויות ומדדים בסיסיים: זמן הבנייה, שיעור הנתיבים תחת בדיקות.
- סכמת תפקידי הסוכנים. מגדירים מי מתכנן, מי כותב קוד, מי בודק ומי מריץ בדיקות, ובאילו שלבים המשימה עוברת הלאה. הסוכנים אינם כותבים ישירות לענפים מוגנים.
- הגדרת סביבות. פורשים סביבות מבודדות עם גישה לקריאה בלבד לענף הראשי, ומחזיקים מפתחות וטוקנים מחוץ לקוד. קובעים מגבלות על נפח ההקשר ומספר האיטרציות — ההרצה אינה נכנסת ללולאה אינסופית.
- הרצה יבשה. לוקחים משימה קטנה אחת מהתור הנוכחי ומריצים אותה במלואה, מהגדרת המשימה ועד השינויים. בוחנים כמה תיקונים נדרשו אחרי הסוכנים והיכן התפקידים העבירו עבודה עם אובדן.
- קריטריוני קבלה. לפני הרצות פרודקשן קובעים: הבדיקות עוברות, הניתוח הסטטי אינו מייצר הערות חדשות, ולכל שינוי יש הנמקה ועקבות. לפי קריטריונים אלה נבנה דוח לכל הרצה.
- מסירה לצוות. מוסרים את תקנון ההרצה, תבניות המשימות וניתוח כשלים טיפוסיים. ההרצות הראשונות מתנהלות בליווי שלנו, ומכאן הצוות מנהל את המחזור בעצמו.
קונפיגורציות, סכמות תפקידים ותקנוני הרצה
после ההרצה הראשונה נשאר במאגר של הלקוח לא אוסף תרחישי הדגמה, אלא ערכה עובדת: היא מספיקה כדי להפעיל מחדש פיתוח רב-סוכני בלעדינו. כל הארטיפקטים מנוהלים בגרסאות יחד עם הקוד — תיקון של תפקיד או של כלל גישה עובר את אותו ניתוח בקבלה כמו שינוי בשירות.
- מפת תפקידים — אילו תפקידים הוקצו למשימה, על איזה קטע עבודה אחראי כל אחד, ולפי איזה סימן מתקבלת התוצאה שלו.
- כללי גישה לסוכנים — מה התפקיד קורא, לאן כותב, והיכן לפני המיזוג חובה בדיקה אנושית.
- קונפיגורציות הרצה — הרכב הצוות, סדר העברת המשימות, מגבלות איטרציות ותנאי עצירה, כדי שהתוצאה לא תהיה תלויה במבצע.
- תקנון חזרה אחורה — אילו נקודות שמירה נעשות לפני ההתחלה, כיצד לחזור למצב הקודם ומה נחשב אות לחזרה אחורה.
- ניתוח התנגשויות תיקונים — הבורר של תיקון שנוי במחלוקת, הבדיקות המחייבות והסדר שלפיו שני תפקידים מתכנסים להחלטה אחת.
- יומן הרצות — היכן נמצאים נתוני הקלט, השלבים והתוצאה: לפיו משחזרים תקלה, במקום לדון בה מהזיכרון.
- קטלוג בדיקות — הבדיקות והניתוח הסטטי שההרצה מחויבת לעבור לפני מיזוג לענף הראשי.
הערכה נמסרת למאגר שלכם, ומכאן הצוות מנהל אותה בעצמו: משנה את הרכב התפקידים, מוסיף בדיקות, פותח קונפיגורציות חדשות למשימות שהשתנו. את ChatDev אנחנו מגדירים כך שהקבצים הללו ייקראו ויתוקנו כמו קוד פרויקט רגיל.
מקרה בוחן: קיצור מחזור התיקונים בעמדת סוכנים
לפני הטמעת העמדה, מחזור התיקונים בשירות פנימי נמשך 9–11 ימים: המשימה עברה ביקורת, חזרה להשלמה ושוב עמדה בתור. למיזוג לענף הראשי הגיעו כשליש מהמשימות — את השאר ניתחו ידנית, ואת חוסר הסנכרון בחוזים בין המודולים תפסו כבר באינטגרציה, כשמחיר התיקון הוא המקסימלי.
מה שינינו
הקמנו עמדת סוכנים על ChatDev: תפקידי האנליסט, המפתח, הסוקר והבודק פועלים בדיאלוג אחד ומעבירים זה לזה ארטיפקטים — הגדרת משימה מחודדת, פאטץ', מערך בדיקות. כל משימה חיה בענף נפרד, ואל הענף הראשי מכניסה אותה רשימת בדיקות סגורה: בנייה, בדיקות, השוואת חתימות ומיגרציות.
מה השתנה
שיעור המשימות שהגיעו למיזוג במעבר ראשון עלה מ-35% ל-78%, וזמן מחזור התיקונים החציוני התקצר מ-9–11 ימים ל-2–3. מחלקת הכשלים "מודולים נפרדו בחוזה" הפסיקה להגיע לענף הראשי: סוכן הסוקר משווה חתימות לפני הבנייה, והפער צף בשלב הגדרת המשימה ולא באינטגרציה.
תפקיד המהנדס נותר מכריע: המיזוג הסופי ומקרים שנויים במחלוקת — בידי האדם. אם הסוכן לא מגיע להחלטה, המשימה חוזרת עם לוג הדיאלוג המלא ורשימת האפשרויות שנדחו — הניתוח אורך דקות במקום שעות.
במה ChatDev שונה מבנייה ידנית של תרחישי סוכנים
ההבדל אינו בכך שגישה אחת חכמה יותר, אלא היכן מוטלת האחריות לתוצאת ההרצה. בחיבור סוכנים עצמאי, התפקידים, סדר הקריאות ופורמט העברת ההקשר חיים בקוד שנכתב עבור תרחיש מסוים. כל עוד יש חמש משימות וכולן מאותו סוג, זה מהיר וגמיש. כשהתרחישים נספרים בעשרות ונתוני הקלט מגוונים, החיבור מתחיל להתנהג אחרת על בקשות זהות.
יכולת השחזור של ההרצות נפגעת ראשונה: המצב מפוזר בין זיכרון התהליך, קבצי ביניים ופרומפטים שתוקנו תוך כדי. ניתן לחזור על ההרצה רק אם מההתחלה נשמרו הקלטים, גרסאות התפקידים וסדר השלבים. אבחון תקלות מאותה סיבה מצטמצם לקריאת קוד והרצות חוזרות — היומן מראה מה נפל, אבל לא מה היה הקלט.
| מה משווים | חיבור עצמאי | צינור ChatDev |
|---|---|---|
| שחזור הרצות | תלוי במה שנשמר ידנית | שלבים וארטיפקטים נרשמים כברירת מחדל |
| אבחון תקלות | לפי הקוד והרצות חוזרות | לפי יומן השלבים והנתונים שביניהם |
| תחזוקת הצינור | תיקונים בקוד המשותף לכל תרחיש | כללי תפקידים ומסלולים משותפים |
| גידול במספר המשימות | זמן הניתוח גדל לינארית | חזרות וניתוב ניתנים להגדרה |
עם גידול בעומס, החיבור העצמאי מתייקר לא בפיתוח, אלא דווקא בתחזוקת הצינור: כל סוג בקשה חדש גורר תיקונים בקוד המשותף ובדיקה מחודשת של תפקידים שכבר עובדים. צינור מוכן מכסה את רישום השלבים, החזרות והניתוב — וההשלמות נשארות ממוקדות ולא רוחביות.
ספקות של צוות טכנולוגי: בקרה, חזרות אחורה, בידוד
הרשאות הסוכנים מוגבלות ברמת טוקן הגישה: ChatDev מקבל אישורי גישה לקריאה בלבד של המאגר ולכתיבה לענף שירות נפרד. המיזוג מבוצע בידי אדם דרך בדיקה ידנית, סודות אינם נכנסים להקשר של הסוכן, והגישה הרשתית של הקונטיינר מוגבלת לרשימת כתובות מורשות. מניפסט ההרשאות נבדק בכל הפעלה — יציאה מהמסגרת עוצרת את ההרצה, ולא הורסת את הקוד.
לולאה אינסופית — המקרה הנפוץ השני: הסוכנים כותבים שוב ושוב את אותו קובץ. אנחנו מציבים מגבלה קשיחה של איטרציות ושלבים למשימה, עוקבים האם הפער הסופי מול גרסת הבסיס משתנה, וכאשר השינויים נעצרים ההרצה מסתיימת בדוח על הסיבות. בנוסף תקרה על נפח ההקשר — מחזור ארוך אינו הופך להוצאה בלתי מבוקרת.
למאגר לגאסי אנחנו משלבים את הצינור בהדרגה: מודול אחד, ענף מבודד, בדיקות אפיון להתנהגות הנוכחית. התוצאה של הסוכן עוברת את אותן בניות ובדיקות כמו תיקונים ידניים — חוזים פומביים אינם משתנים בשקט.
כיצד לחזור אחורה מהרצה כושלת?
השינויים חיים בענף שירות ואינם משפיעים על הענף הראשי. התוצאה לא התאימה — הענף נסגר, והיסטוריית ההרצות עם הדוחות נשמרת לניתוח. החזרה אחורה אורכת דקות ואינה דורשת תיקון קוד ידני.
ואם בקוד הלגאסי אין בדיקות?
קודם מכסים את הנתיבים הקריטיים בבדיקות שמקבעות את ההתנהגות הנוכחית, ורק אחר כך מאפשרים לסוכן לתקן. כל פער נראה בבנייה, ולא אחרי שחרור למתחם העבודה.
נדבר על המשימה: מה נדרש להערכת ההטמעה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם ניסוחים כלליים, אנחנו צריכים נתוני פתח על המאגר, הצוות והתהליכים הנוכחיים.
פיתוח רב-סוכני משתלב במתחם הקיים, ולכן קודם בוחנים כיצד בנויים הבנייה, הבדיקות והקבלה של שינויים — מזה תלוי גם היקף העבודה, וגם אילו קטעים ניתן להעביר לסוכנים מיד ואילו להשאיר בידי בני האדם.
- מבנה המאגר: שפות, מספר המודולים, מצב הבנייה והבדיקות, והיכן מרוכזת הלוגיקה העיקרית.
- הסתעפות והוצאת גרסאות: כיצד מכינים שינויים, מי מאשר מיזוג, באיזו תדירות יוצאים שחרורים.
- בדיקות אוטומטיות: מה רץ על כל שינוי, והיכן הבדיקות עדיין נעשות ידנית.
- הרכב הצוות: כמה מהנדסים אחראים על הקוד, מי מקבל את תוצאת הסוכנים וכיצד בנויה בדיקת השינויים ההדדית.
- תהליכי עבודה עם משימות: כיצד מנוסחות הדרישות, היכן מתנהל התיעוד, ולפי אילו קריטריונים משימה נחשבת מוכנה.
- מגבלות הסביבה: סביבות הרצה מבודדות, הרשאות גישה, כללי התנהלות עם קוד ונתונים.
המערך הזה מספיק כדי לחזור עם הערכה ותוכנית עבודה: אילו קטעים מכסים בסוכנים, מה נשאר בידי המהנדסים, וכיצד בודקים את התוצאה בכל שלב. אם חלק מנתוני הפתח עדיין לא נאסף — לא נורא, נחדד בשיחה ונעזור להשיג אותם. תארו את המשימה — נחזור עם הערכה ותוכנית.