Оркестрация

Один агент хорош в чём-то одном. Но некоторые задачи крупнее: «исследуй рынок 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 и без ввода-вывода — превращает предложение в настоящий конвейер. При одном и том же предложении и одном и том же наборе ролей он всегда выдаёт один и тот же DAG. Это важно, потому что сгенерированный конвейер бесплатно наследует всё, что движок уже умеет: приостановку и возобновление после перезапусков, восстановление после сбоев, сводки затрат и токенов по запуску и интерфейс деталей запуска.

Утверждение также создаёт каркас, необходимый для работы:

нанимает все роли, помеченные как новые (и записывает id нанятых агентов, чтобы сбой посреди утверждения можно было возобновить без дублирующих наймов)
команду, объединяющую роли
проект, в который попадает родительский тикет
шаблон конвейера и запуск, которые всем этим управляют

Жизненный цикл

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

Статус	Значение
`proposed`	План готов и ждёт вашего единственного предварительного утверждения
`approved`	Вы его утвердили; материализация идёт (наймы, команда, проект, конвейер)
`executing`	Сгенерированный конвейер выполняется: подтикеты, обсуждение, работа
`synthesizing`	Подтикеты готовы; шаг синтеза создаёт итоговый результат
`completed`	Готово: родительский тикет помечен завершённым, а итоговый результат опубликован в общем пространстве
`failed`	Материализация не удалась или запуск сгенерированного конвейера завершился сбоем
`cancelled`	Вы его отменили

Монотонно возрастающий номер ревизии отслеживает предложение, пока оркестратор дорабатывает его, пока статус ещё proposed; приложение записывает, какую ревизию вы утвердили. propose_orchestration отказывает в новой ревизии, как только статус перестаёт быть proposed.

Оркестрация всегда открывается относительно родительского тикета и использует одно общее пространство обсуждения, так что всё усилие прослеживается до одной единицы работы и команда общается в одной комнате.

Что происходит, когда она завершается

Постоянно работающий слушатель следит за сгенерированным конвейером и переносит его терминальное состояние обратно на оркестрацию и родительский тикет, поэтому завершение и сбой проявляются там, где вы и так следите. Оркестрации не нужен собственный движок выполнения.

Оркестрацию можно отменить в любой момент; отмена сворачивает работу, находящуюся в процессе.

См. также

Конвейеры и автоматизация: движок, на котором выполняется материализованная оркестрация
Тикеты и делегирование: родительский тикет, к которому привязана оркестрация
Модель агента: роли, которые оркестрация заполняет или нанимает
Запустить оркестрацию
Работать в Plan Studio