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

Режимы

Режим — это свойство пространства, хранимое как один столбец в строке пространства. Его делят все разговоры внутри пространства, включая ветки: ветка наследует режим своего пространства, как и любой другой разговор. Поэтому один и тот же агент может одновременно находиться в разных режимах в разных пространствах, а смена режима пространства меняет то, что произойдёт на следующем ходу, не затрагивая агента.

Их ровно четыре: chat, review, plan, orchestrate. Само перечисление не несёт никакой политики. Всё, что гарантирует режим, объявлено один раз — в профиле возможностей, из которого проецируется каждый слой принудительного применения:

  1. Поверхность инструментов — какие инструменты вообще существуют в этом режиме; она выражается максимальным уровнем подтверждения, списком разрешённых, списком запрещённых и набором отклоняемых классов эффектов.
  2. Обязательный выходной глагол — что запуск должен вызвать, чтобы вообще что-то выдать.
  3. Запрещённые классы эффектов — что защита действий отклоняет сразу.
  4. Режим worktree — можно ли записывать в worktree. Это обеспечивается тем, что изменяющие инструменты удаляются с поверхности, и именно поэтому гарантия держится на любом хосте. Там, где у хоста есть песочница ОС, тот же режим задаёт и правила записи в файловой системе — режим только для чтения монтирует worktree только для чтения, — но это вторая копия гарантии, а не та, что выполняет работу.
  5. Блок системного промпта — сгенерированная преамбула о возможностях, производная от фактически материализованного списка инструментов, плюс написанные вручную указания.

Каждый слой принудительного применения проецируется из этого единственного профиля, поэтому поверхность инструментов, защита, режим worktree и промпт не могут расходиться.

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

Обратите внимание на название: в композере режим отображается как «Агент», а не «Чат».

Режим плана делает worktree доступным только для чтения и полностью убирает инструменты записи с поверхности, поэтому ограничение структурное, а не предписанное. Агент читает, ищет, исследует и выдаёт ровно одно: вызов submit_plan с типизированным графом зависимостей — цель плюс узлы с ключами, названиями, описаниями и ключами узлов, от которых зависит каждый узел.

План отображается компактной строкой в разговоре и открывает Plan Studio на вкладке рядом. Его подтверждение компилирует граф в оркестрацию, выполняет сгенерированную работу и переключает пространство, в котором создавался план, обратно в режим агента.

Если запуск в режиме плана завершается, так и не вызвав submit_plan, цикл сначала вставляет напоминание: плана не существует, пока этот вызов не завершится успешно. Напоминание явно разрешает честный выход «здесь план не нужен», потому что режим плана — это настройка пространства, и обычный вопрос, заданный в нём, не должен вынуждать создавать фиктивный план.

Есть второй, отдельный путь наружу: exit_plan_mode. Это жёсткий шлюз подтверждения, а не выходной глагол: агент, который вызывает его вместо submit_plan, не выдал ничего. Первый вызов открывает долговечное подтверждение plan_exit и возвращает pending, а пространство остаётся доступным только для чтения; повторные вызовы остаются в состоянии pending и не открывают второй шлюз. И только после того, как подтверждение выдано, следующий вызов переключает пространство в чат. Отказ позволяет агенту открыть новый запрос на переработанный план.

Чтобы выйти из режима плана самостоятельно, переключите выпадающий список в композере (или Shift+Tab). exit_plan_mode решается с помощью инструмента MCP decide_approval. Строки «одобрение агента» во «Входящих» — это другое: запросы подтверждения на каждый ход от работающего агента.

Режим ревью предназначен для проверки PR. Он делает worktree доступным только для чтения, ограничивает поверхность инструментов уровнем ниже уровня исполнения и применяет тщательно подобранный список разрешённых инструментов проверки, работы с тикетами и общения. Пространство, открытое для pull request, создаётся автоматически в режиме ревью.

Вывод агента — это структурированные замечания, узлы проверки, а когда проверка финализируется, — вердикт. Узел несёт тип (bug, suggestion, recommendation, question или ticket), приоритет от P0 (блокирует выпуск) до P3 (желательно), самостоятельно выставленную уверенность, необязательную привязку (файл плюс диапазон строк; у заметок по всему репозиторию её нет) и статус жизненного цикла, который переходит из open в consensusReady, как только его подтверждает другой участник — но никогда автор. Замечание, у которого приоритет или уверенность отсутствуют либо выходят за допустимый диапазон, отбрасывается на границе чтения, а не загрязняет вердикт.

Вердикт — ship, hold или block, и он становится только строже от результатов по осям, которые в него сводятся: ось под шлюзом с результатом fail принудительно даёт block, а ось под шлюзом, которая не смогла запуститься, принудительно даёт как минимум hold. Отсутствие доказательств никогда не превращает шлюз в зелёный.

В отличие от плана и оркестрации, ревью не несёт контракта завершения. Замечания накапливаются через add_review_node и публикуются через finalize_review, и оба могут законно не вызываться ни разу — агент конвейера, работающий в режиме ревью, может находиться там, чтобы вместо этого закрыть тикет.

Оркестрация — только для чтения, предлагает команду

Заголовок раздела «Оркестрация — только для чтения, предлагает команду»

Режим оркестрации превращает одну цель в план для всей команды. Как и режим плана, он только для чтения и не может записывать файлы; поверх поверхности исследований у него есть единственный привилегированный глагол propose_orchestration, который выдаёт структурированное предложение: роли, дерево подтикетов, шаг сведения и бюджет. Промпт называет только инструменты, которые есть на поверхности, поэтому модель не тратит ходы на рассказ о найме или работе с тикетами, вызвать которые она не может.

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

Собственный выходной глагол режима невозможно запретить. submit_plan и propose_orchestration закреплены в поверхности инструментов и подтверждены заранее в обход фильтра инструментов, шлюза подтверждения и защиты действий, поэтому регулятор автономии пространства не может заглушить результат режима. ask_user у харнесса закреплён по той же причине: именно так запуск обращается к оператору, поэтому шлюз перед ним завёл бы в тупик запуск, которому нужно что-то спросить. Он относится к уровню чтения, поэтому его сохраняет каждый режим только для чтения, и он исключён из обёртки подтверждения: подсказка перед подсказкой при отсутствии подключённого подтверждающего срабатывает в сторону отказа, а это лишило бы агента самого действия — задать вопрос.

Режимы только для чтения не запрещают сетевой доступ и секреты. Классы эффектов, которые отклоняют ревью, план и оркестрация, — это те, что меняют мир: удаление файлов, запись за пределами worktree, коммиты, push, создание и публикация PR, записи при синхронизации с вендорами, установка пакетов, запуск процессов, изменение рабочего пространства и управление изолированной средой. Исходящий сетевой трафик и доступ к секретам намеренно остаются на значениях по умолчанию — исследование и есть весь смысл режима только для чтения.

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

Узел конвейера, который открывает пространство, может закрепить режим этой комнаты ключом extras['mode'] (chat, review или plan). Ключ требует точного совпадения: любое другое написание — включая orchestrate — молча игнорируется, и комната получает значение по умолчанию из body (review в body, создающем пространство). Шаг с агентом присоединяется к комнате, которую не создавал, и не перенастраивает её права.

Само определение режима устроено просто. Диспетчер читает столбец mode пространства; запуск без пространства — разовый запуск, вызов из CLI или id пространства из другого рабочего пространства, которого просто нет в файле базы данных этого рабочего пространства, — определяется как chat. Смена режима вступает в силу со следующего хода.

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

На транспорте Claude Code режим, отличный от чата, передаётся как --permission-mode plan. Claude соблюдает это по соглашению; его собственные инструменты чтения, записи и редактирования работают незаметно, а команды shell проверяет только хук, читающий командную строку. Для этого транспорта режим — рекомендация, а не граница Control Center — см. Модель агента.

Списки разрешённых ограничивают инструменты уровня записи и выше. Уровень чтения встроенного харнесса по-прежнему достигает инструментов, которые не названы ни в одном списке; в Claude Code инструмент, пропущенный в списке разрешённых, отклоняется независимо от того, есть ли он у сервера.