Перейти к содержимому

Делегировать работу агентам

Это руководство о том, как снять работу со своих плеч и передать её агенту, и о том, что происходит, когда агенты передают работу друг другу.

  1. Создайте тикет с заголовком и описанием, достаточно точным, чтобы по нему можно было работать.
  2. Укажите в его поле Исполнитель агента, чтобы владение было зафиксировано.
  3. Откройте (или создайте) пространство и @-упомяните этого агента.
  4. Сошлитесь на тикет упоминанием через # в своём сообщении — композер автодополняет тикеты рабочего пространства — и скажите, что нужно сделать.

Агент подхватывает работу из разговора. Ход его работы транслируется в это пространство.

  • Ваше сообщение, включая ссылку на тикет, которую вы отметили.
  • Пространство, в котором можно работать и отчитываться.
  • Изолированный worktree из связанных репозиториев рабочего пространства.
  • Режим пространства — именно он определяет поверхность инструментов запуска.

Режим — свойство пространства, а не тикета: у тикета нет режима. Поэтому один и тот же агент может находиться в режиме chat в одном пространстве и plan в другом. Выберите его в выпадающем списке режимов в композере (Агент, План или Оркестрация); review задают пространства проверки PR, и выбрать его вручную нельзя. См. Режимы.

Контракт вывода объявляется при запуске, а не в тикете: expected_output_schema вместе с output_contract_mode (по умолчанию strict). Агент выполняет его, вызывая submit_output: тот проверяет полезную нагрузку по схеме и отклоняет несоответствующую.

И принятый вывод, и любые отказы попадают в журнал запуска агента. Статус самого тикета при этом не меняется — провалившийся контракт не переводит тикет в состояние сбоя.

  • Пространство — активность агента в реальном времени, основной вид.
  • Тикет — его статус, какой установит тот, кто его двигает.
  • Наблюдаемость → Онлайн (/workspaces/<workspace-id>/observability) — список активных агентов в реальном времени.
  • Наблюдаемость → Инсайты — журнал запусков с затратами и длительностью.

Экрана панели управления нет; голый URL рабочего пространства перенаправляет во «Входящие».

Позволить агентам делегировать друг другу

Заголовок раздела «Позволить агентам делегировать друг другу»

Агент, столкнувшийся с подзадачей, делегирует её с помощью инструмента MCP delegate_task. Тот создаёт дочерний тикет, назначенный другому агенту, и — когда вы передаёте parent_ticket_id — записывает цепочку, чтобы её видели защитные проверки.

Две структурные проверки всегда срабатывают в узловой точке работы с тикетами, а не по инструкции в промпте:

  • Предел глубины — цепочка глубже 3 переходов отклоняется.
  • Обнаружение циклов — переход назад к агенту, уже находящемуся в цепочке, отклоняется.

Когда вы передаёте from_agent_id, срабатывают ещё две проверки (боевая конфигурация всегда предоставляет порты-резолверы):

  • Потолок автономии — действующий уровень делегата в пространстве не должен превышать уровень делегатора.
  • Бюджетный конверт — делегирование списывается с оставшегося бюджета жёсткой остановки делегатора и не может выдать больше. Проверка проходит, когда политики нет или она неограниченна.

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

Этот предел глубины делегирования, равный 3, — иное ограничение, чем предел вложенности субагентов встроенного раннера, равный 2: одно ограничивает тикеты между агентами, другое — субагентов внутри одного запуска.

Поставить несколько агентов на один тикет

Заголовок раздела «Поставить несколько агентов на один тикет»

Добавьте их в тикет как соисполнителей (роли: исполнитель, соисполнитель, ревьюер). Это состав — запись о том, кто участвует, — и сам по себе он ничего не даёт.

Чтобы действительно собрать агентов в одном разговоре, добавьте их как участников из шапки пространства. После этого они могут @-упоминать друг друга там. См. Пространства.

Ни один узел в палитре конвейера не создаёт тикеты, поэтому конвейер не может раздать работу в виде назначенных тикетов.

Существующий путь — оркестрация: подтверждение предложения создаёт проект и команду, компилирует DAG подтикетов из предложения в шаблон конвейера (один шаг promptAgent на подтикет, а не отдельная строка Ticket на каждый) и стартует его. См. Запустить оркестрацию.