Оркестрація

Один агент добре робить одну річ. Деякі запити більші за це: «досліди ринок для X і напиши документ про позиціювання», «реалізуй цю фічу від початку до кінця», «перевір цей модуль і виправ те, що знайдеш». Оркестрація — це те, як Control Center дає раду таким запитам: оркестратор (зазвичай ваш CEO-агент) пропонує план для всієї команди, ви затверджуєте його один раз, а детермінований матеріалізатор перетворює його на конвеєр, який виконує роботу.

Вона стоїть між двома наявними способами виконувати роботу:

Коли ви хочете…	Використовуйте
Передати одне завдання одному агенту	Повідомлення в просторі
Закодувати вручну процес, який ви вже знаєте	Шаблон конвеєра
Назвати мету й дозволити команді визначити план	Оркестрація

Як виглядає пропозиція

Коли ви даєте оркестратору мету, він повертає структурований OrchestrationProposal: типізований план, який застосунок може перевірити й виконати, а не довільний текст. Пропозиція містить:

Мета: ваш запит високого рівня, переформульований.
Ролі: хто виконує роботу. Кожна роль — це або наявний агент, якого ви обираєте, або новий найм, який оркестрація створює після затвердження.
Підтікети: робота, розбита на DAG із тікетів.
Дослідження (необов’язково): фаза дослідження, яка виконується першою й живить решту.
Обговорення (необов’язково): обмежене коло, у якому кожна роль публікує структуровану позицію до початку роботи.
Синтез: фінальний крок, який створює результат.
Бюджет: заявлена стеля витрат.

Де ви це переглядаєте

Два інтерфейси показують ту саму оркестрацію.

Картка пропозиції живе в розмові, яка створила план. Це одне повідомлення, що перемальовується протягом усього життєвого циклу — запропоновано, виконується, завершено — і має на собі дії затвердження та скасування.

Plan Studio — це редактор: полотно DAG, інспектор вузлів, панель ревізій і diff та панель затвердження з оцінкою. Він відкривається як вкладка редактора прямо з цієї картки. Пункту «Плани» в бічній панелі навмисно немає; /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