תזמור

סוכן בודד טוב בדבר אחד. יש בקשות גדולות מזה: “חקרו את השוק של X וכתבו מסמך מיצוב”, “השלימו את התכונה הזו מקצה לקצה”, “בקרו את המודול הזה ותקנו את מה שמצאתם”. תזמור הוא הדרך שבה Control Center מתמודד עם אלה: מתזמר (בדרך כלל סוכן ה-CEO שלכם) מציע תוכנית של צוות שלם, אתם מאשרים אותה פעם אחת ומממש דטרמיניסטי הופך אותה לפייפליין שעושה את העבודה.

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

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

הצורה של הצעה

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

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

איפה סוקרים אותה

שני משטחים מציגים את אותו תזמור.

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

Plan Studio הוא העורך: קנבס DAG, לוח הצומת, מגירת גרסאות והבדלים וסרגל האישור שנושא את האומדן. הוא נפתח כלשונית עורך ישירות מאותו כרטיס. במכוון אין פריט “תוכניות” בסרגל הצד; /plans ו־/plans/:kind/:id קיימים כקישורים ישירים לשיתוף.

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

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

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

אומדנים כנים, או כלום

האומדן בסרגל האישור נבנה מהיסטוריית הרצות שהושלמו בפועל עבור כל תפקיד, כטווח בין־רבעוני (p25–p75). סכומי העלות מסכמים את הצמתים הניתנים לאומדן; המשך הוא המסלול הקריטי דרך ה-DAG ולא הסכום (ענפים מקבילים חופפים).

צומת שלתפקיד שלו אין היסטוריית הרצות שהושלמו מדווח sampleSize: 0 וטווחי null. זה מוצג בדיוק כך — לא ידוע — ולעולם לא כערך נקודתי מומצא, כי אומדן שאי אפשר לסמוך עליו גרוע מאין אומדן. כשלחלק מהצמתים יש היסטוריה ולחלק אין, הסכום מסומן כחלקי. רדיוס הפגיעה מופיע רק כשצומת הצהיר על הפניות מקור מסוג symbol או file; צומת בלעדיהן נשאר “לא ידוע” במקום להסיק מפרוזה.

אישור אחד, ואז הרצה דטרמיניסטית

זה הרעיון המרכזי: הסוכן מתכנן; פונקציה דטרמיניסטית מבצעת. כשאתם מאשרים, ה־OrchestrationMaterializer, פונקציה טהורה בלי LLM ובלי I/O, ממיר את ההצעה לפייפליין אמיתי. בהינתן אותה הצעה ואותם תפקידים שנפתרו, הוא תמיד מפיק את אותו DAG. זה חשוב כי הפייפליין שנוצר יורש הכול שהמנוע כבר עושה בחינם: השהיה וחידוש על פני אתחולים, שחזור מקריסה, צבירות עלות ואסימונים לפי הרצה וממשק פירוט ההרצה.

האישור גם יוצר את התשתית שהעבודה צריכה:

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

מחזור החיים

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

סטטוס	משמעות
`proposed`	התוכנית מוכנה וממתינה לאישור החד־פעמי שלכם
`approved`	אישרתם אותה; המימוש בעיצומו (גיוסים, צוות, פרויקט, פייפליין)
`executing`	הפייפליין שנוצר רץ: תת־כרטיסים, דיון, עבודה
`synthesizing`	תת־הכרטיסים הסתיימו; שלב הסינתזה מפיק את התוצר
`completed`	הסתיים: כרטיס האב מסומן כהושלם והתוצר מתפרסם במרחב המשותף
`failed`	המימוש נכשל, או שהרצת הפייפליין שנוצרה נכשלה
`cancelled`	ביטלתם אותה

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

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

מה קורה כשהוא מסתיים

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

אפשר לבטל תזמור בכל עת; הביטול מפרק את העבודה שבאוויר.

ראו גם

פייפליינים ואוטומציה: המנוע שתזמור ממומש רץ עליו
כרטיסים והאצלה: כרטיס האב שהתזמור מעוגן עליו
מודל הסוכן: התפקידים שהתזמור ממלא או מגייס
הרצת תזמור
עבודה ב־Plan Studio