תפקידי סוכנים

Coroid אינו משתמש בסוכן כללי אחד. כל שלב התהליך מהתיאור ועד pull request מטופל על ידי סוכן עם תפקיד ממוקד וסט כלים מוגבל בכוונה.

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

התפקידים#

תפקיד	שלב	יכול לשנות את הקוד שלך
אדריכל	מפרט ותכנית	לא
מפתח	בנייה	כן
בקרת איכות (QA)	לאשר	לא
מבקר	סקירה	לא
בודק אינטרנט	לאשר, זרמי דפדפן	לא
חוקר	מחקר, כל שלב	לא
מנתח תלותיות	ניתוח	לא

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

אדריכל → מפתח → בקרת איכות (QA) → מבקר

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

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

שתי דרכים שבהן משימה מתנהלת#

משימה מתנהלת באחד משני המצבים. ה- AI profile והפריסה שלכם קובעים איזה מצב יופעל.

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

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

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

הרכז#

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

מה הרכז עושה#

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

מה הרכז אינו יכול לעשות#

הרכז מכוון; הוא אינו שופט. הפלטפורמה מטילה את המגבלות הללו, כך שהן אינן תלויות בהחלטת הרכז:

1. הפסקי דין שייכים ל-QA ול-Reviewer. רק QA וה-Reviewer נותנים פסקי דין, כל אחד דרך התוצאה שלו. בהנחיות של הרכז אין מקום לפסק דין, והרכז אינו יכול לסמן בדיקה כמוצלחת.
2. סיום דורש עמידה במחסומים. משימה יכולה להסתיים רק לאחר ש-QA אישר את הגרסה המדויקת שתישלח לשוק (או את הקוד כפי שהוא, כשאין שינויים), וכן לאחר שהמבקר אישר את הגרסה הזו אם המשימה דורשת סקירה. אם הענף השתנה לאחר ביצוע ה-QA, הסיום נדחה והגרסה החדשה תוחזר ל-QA.
3. עיבוד מחדש מוגבל. כל סוכן יכול להתחיל לפעול רק מספר מוגבל של פעמים למשימה, ותוכנית יכולה להתעדכן רק מספר פעמים. גם מספר השלבים וזמן הריצה הכולל מוגבלים. כשמגיעים לגבול, הרכז יכול רק לסיים או לגרום לכישלון של המשימה.
4. ההמתנה מוגבלת. לכל המתנה יש תאריך יעד.

לכן, משימה שנוהלה על ידי רכז מסתיימת באחת משלוש דרכים: pull request שעליך לאשר; אישור מ-QA שהקוד כבר מבצע את מה שהמשימה דורשת, כך שאין צורך בשינויים; או משימה שנכשלה ומסבירה מדוע. המשימה אינה מסתיימת רק כי הסוכן האחראי הכריז על כך.

נתיבים אפשריים עבור רכז#

הרכז בוחר כיצד משימה תגיע לשערי הבקרה. השערים שצוינו לעיל זהים בכל נתיב.

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

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

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

כאשר נדרש מבקר#

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

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

• המבקר כבר החל לעבוד על המשימה, או שכללי הסקירה של הפרויקט או תרשים האיכות של הארגון דורשים זאת;
• השינוי נוגע לאימות, פעילויות, הרשאות, סיסמאות או הצפנה, שינויים במסד נתונים, תצורת בנייה ופריסה, קבצי תלות, או קוד שמתקשר לשירותים חיצוניים;
• השינוי גדול (כברירת מחדל, יותר מ-80 שורות משונות), או כולל קבצים בינאריים, קישורים סימבוליים או תת-מודולים;
• Coroid אינו יכול לקרוא את המדיניות או את השינוי עצמו. במקרה של ספק, המבקר נדרש.

שינוי שאינו משנה דבר אינו זקוק למבקר. הקוד מקבל את ההחלטה הזו, לא הרכז, והרכז אינו יכול לעקוף אותה. שורה בסוף תיאור ה-pull request מציינת באיזה כיוון נלקחה ההחלטה ומדוע. היא מתחילה ב"מבקר נדרש" או "מבקר אינו נדרש".

Architect#

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

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

מפתח#

מבצע את העבודה: קורא את הקוד הרלוונטי, מבצע את השינויים, כותב או מעדכן בדיקות, ובדק אותן במקום העבודה עד שהן עוברות.

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

בקרת איכות#

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

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

מסקר#

קורא את ה־diff המוגמר ומייצר ממצאים, תוך יישום כללי הסקירה שהארגון שלך הגדיר. הממצאים מועברים בחזרה אל המפתח כעבודת תיקון או מצורפים ל־pull request עבורך.

בודק אינטראקציה#

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

חוקר#

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

מנתח תלותיות#

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

מדוע ההפרדה חשובה#

ארבע תכונות נובעות מהפרדת העבודה בצורה זו:

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

הבא#

חזור אל כיצד משימה הופכת ל־pull request עבור השלבים שאליהם התפקידים הללו מתויגים, או מהו Coroid עבור סקירה קצרה יותר.