Режими

Що таке режим

Режим — це властивість простору, що зберігається в одній колонці рядка простору. Його поділяють усі розмови всередині простору, гілки включно — гілка успадковує режим свого простору, як і будь-яка інша розмова. Тож той самий агент може одночасно перебувати в різних режимах у різних просторах, а зміна режиму простору змінює те, що станеться на наступному ході, не торкаючись агента.

Їх рівно чотири: chat, review, plan, orchestrate. Сам перелік значень не несе жодної політики. Усе, що гарантує режим, оголошується один раз у профілі можливостей, з якого проєктує кожен шар забезпечення:

Поверхня інструментів — які інструменти взагалі існують у цьому режимі, виражені як максимальний рівень схвалення, список дозволених, список заборонених і набір відхилених класів ефектів.
Обов’язкове дієслово виводу — що запуск має викликати, щоб уважатися таким, що щось створив.
Заборонені класи ефектів — те, що запобіжник дій відхиляє одразу.
Стан worktree — чи можна писати в worktree. Це забезпечується тим, що з поверхні вилучають інструменти, які вносять зміни, і саме тому воно тримається на кожному хості. Там, де хост має пісочницю ОС, той самий стан також визначає правила запису у файлову систему — режим лише читання монтує worktree лише для читання — але це друга копія гарантії, а не та, що виконує роботу.
Блок системного промпту — згенерована преамбула можливостей, виведена з фактичного матеріалізованого списку інструментів, плюс писане від руки керівництво.

Кожен шар забезпечення проєктує з цього єдиного профілю, тож поверхня інструментів, запобіжник, стан 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, і результати за осями, згорнуті в нього, можуть зробити його лише суворішим: вісь зі шлюзом, що провалилася, примусово дає block, а вісь зі шлюзом, яка не змогла виконатися, примусово дає щонайменше hold. Відсутність доказів ніколи не робить шлюз зеленим.

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

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

Режим оркестрації перетворює одну мету на план для всієї команди. Як і режим плану, він доступний лише для читання й не може писати файли; поверх дослідницької поверхні він має єдине привілейоване дієслово, propose_orchestration, яке видає структуровану пропозицію: ролі, дерево підтікетів, крок синтезу й бюджет. Промпт називає лише ті інструменти, що є на поверхні, тож модель не витрачає ходи на переповідання найму чи роботи з тікетами, які не може викликати.

Ніщо в пропозиції не виконується, доки ви її не схвалите. Після схвалення детермінований матеріалізатор наймає агентів, створює тікети й проєкт і запускає згенерований конвеєр. Схвалювати може лише оператор: інструмента MCP для цього немає, тож агент може запропонувати, але ніколи не схвалити власний план. Повторні пропозиції, ініційовані агентом, обмежуються перервою у дві хвилини, тож послідовні перепланування відхиляють і радять об’єднатися. Див. Оркестрація.

Два правила, які варто знати

Власне дієслово виводу режиму не можна відхилити ніколи. submit_plan і propose_orchestration закріплено в поверхні інструментів і попередньо схвалено в обхід фільтра інструментів, шлюзу схвалення та запобіжника дій однаково, тож регулятор автономності для кожного простору не може заглушити результат режиму. ask_user у harness закріплено з тієї ж причини: саме через нього запуск дістається до оператора, тож шлюз на ньому заблокував би запуск, якому треба щось запитати. Він належить до рівня читання, тож кожен режим лише читання його зберігає, і він не підпадає під обгортку схвалення — запит перед запитом закривається відмовою, коли не під’єднано жодного, хто міг би схвалити, а це позбавило б агента самого акту запитання.

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

Вибір і зміна режиму

Випадний список режимів у композері пропонує три варіанти: Агент (чат), План та Оркестрація. review не вибирає користувач — його задає система під час створення простору рев’ю PR і кроки конвеєра.

Вузол конвеєра, який відкриває простір, може закріпити режим цієї кімнати ключем extras['mode'] (chat, review або plan). Ключ збігається точно: будь-яке інше написання — зокрема orchestrate — мовчки ігнорується, і кімната отримує типове значення тіла (review для тіла create-space). Крок агента приєднується до кімнати, якої не створював, і не перевизначає її дозволи.

Саме визначення просте. Диспетчер читає колонку mode простору; виклик без простору — одноразовий запуск, виклик із CLI або ідентифікатор простору з іншого робочого простору, якого просто немає у файлі бази даних цього робочого простору, — визначається як chat. Зміна режиму набирає чинності з наступного ходу.

Де гарантія справді діє

Поверхню інструментів режиму будує й забезпечує вбудований harness. Це єдиний транспорт, який може зробити інструмент невидимим, а не просто відхиленим, поставити шлюз перед кожним викликом до його виконання та спостерігати за контрактом завершення.

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

Списки дозволених обмежують інструменти рівня запису й вище. Рівень читання вбудованого harness усе одно дістається інструментів, яких не називає жоден список; у Claude Code інструмент, якого бракує у списку дозволених, відхиляється незалежно від того, чи має його сервер.

Пов’язані поняття

Життєвий цикл запуску агента: де режим визначається й проєктується
Модель агента: які транспорти можуть забезпечити режим
Обмеження: політика класів ефектів, у яку входить пресет режиму
Оркестрація: що робить схвалена пропозиція оркестрації
Використовувати режим плану: практичний посібник