Запускать агентов параллельно

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

Единица изоляции — пространство, а не агент

Когда в пространстве начинается работа, Control Center подготавливает по одной рабочей копии с copy-on-write на каждый зарегистрированный репозиторий в собственном корне этого пространства — в ветке, произведённой от шаблона ветки рабочего пространства. Затем каждый агент в пространстве получает собственный рабочий каталог оверлея, но эти оверлеи делят каталог repos/ данного пространства.

Отсюда следует:

Два агента в разных пространствах работают в разных рабочих копиях и в разных ветках. Это настоящая изоляция.
Два агента в одном пространстве работают в одной рабочей копии и в одной ветке. Их пути оверлеев различаются, поэтому блокировка пути запуска (она сериализует запуски, только когда они запрашивают один и тот же рабочий каталог) их тоже не сериализует. Они могут писать в одни и те же файлы одновременно.

Отсюда правило: одно пространство на параллельную задачу.

Запускать задачи параллельно — отдельные пространства

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

Это тот рецепт, который нужно применять всегда, когда агенты будут редактировать файлы.

Работать вместе в одном пространстве — несколько @-упоминаний

В одном пространстве упомяните через @ более одного агента:

@alice refactor the auth module. @bob review what alice lands.

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

Веерный запуск из конвейера

Встроенный шаблон pr_review — поставляемый пример веерного запуска: несколько узлов-ревьюеров работают одновременно от одного триггера, а узел Consolidate (join) сводит их находки в один отчёт. Запустите его с экрана конвейеров — и каждый ревьюер запустится параллельно.

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

Наблюдать за их работой

Наблюдаемость → Онлайн (нижняя часть боковой панели → Наблюдаемость, затем вкладка «Онлайн») показывает список агентов этого рабочего пространства, обновляясь каждую секунду: статус (выполняется / простой / на паузе / прерван), чем занят каждый агент, токены и стоимость его последнего запуска и кнопка прерывания для выполняющегося процесса. Выбор строки открывает панель живого транскрипта.

Настройки → Рабочее пространство → Агенты показывает тот же список с другим, ориентированным на внимание словарём статусов, выведенным из истории запусков каждого агента, — выполняется, заблокирован, с ошибкой, простой, ни разу не запускался, — отсортированным так, что всё требующее внимания всплывает наверх. Вкладка Журнал каждого агента содержит его собственную историю запусков.

Обе поверхности ограничены активным рабочим пространством.

Разбираться с конфликтами

Между пространствами каждое пространство находится в своей ветке, поэтому столкновение проявляется как обычный конфликт слияния Git, когда вы мержите второй pull request. Разрешайте его так же, как любой конфликт слияния.

Внутри одного пространства нет ни границы ветки, ни блокировки: агенты пишут в одни и те же файлы в реальном времени, и проигравший просто перезаписывается. Если вам захотелось, чтобы два агента редактировали в одном пространстве, разделите работу на два пространства.

Чтобы уменьшить число столкновений в любом из случаев:

Дайте каждому агенту отдельную область — разные файлы, разные модули.
Перед запуском проверьте через граф кода, чего касается изменение. См. Искать код через граф кода.
Своевременно проверяйте и мержите pull request каждого агента.

Соображения о ресурсах

Каждый работающий агент стоит:

Рабочая копия пространства — на диске она ничтожна, пока доступен copy-on-write; в Windows это git worktree. Файловая система, не поддерживающая reflink, приводит к отказу подготовки, а не к копированию.
Процесс на хосте сервера
Токены модели, которые накапливаются по каждому агенту

Затраты попадают в Наблюдаемость → Инсайты. Учтите, что у обычного интерактивного хода нет потолка расходов; см. Управлять затратами, где описаны две команды, у которых он есть.