ارکستراسیون
یک عامل تنها در یک کار خوب است. برخی درخواست‌ها از این بزرگ‌ترند: «بازار 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 و بازه‌های تهی گزارش می‌دهد. این دقیقاً همان‌گونه نمایش داده می‌شود — ناشناخته — و هرگز به‌شکل یک مقدار نقطه‌ای ساختگی، چون برآوردی که نتوانید به آن اعتماد کنید از نبود برآورد بدتر است. وقتی برخی گره‌ها تاریخچه دارند و برخی ندارند، جمع به‌صورت جزئی علامت می‌خورد. شعاع اثر تنها زمانی پدیدار می‌شود که گرهی ارجاع‌های منشأ 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