Агенты и режимы в OpenCode: план, сборка и разграничение прав
Зачем в OpenCode несколько агентов, чем режим планирования отличается от рабочего, как раздать разные права и модели и когда заводить отдельного субагента.
Один агент на все случаи — удобно ровно до первой ситуации, когда он «немного поправил» не тот файл. Разные задачи требуют разного уровня доверия: разобраться в чужом коде можно и без права на запись, а собрать релиз — нет. В OpenCode это решается несколькими агентами с разными настройками.
Зачем их несколько
Агент в OpenCode — это набор из трёх вещей: инструкции, модели и разрешений. Заводить второго имеет смысл, когда хотя бы одно из трёх должно отличаться.
Типичные поводы:
- Читать, но не трогать. Разбор незнакомого репозитория, ревью, поиск причины бага.
- Разная цена вопроса. Мелкие правки — на дешёвой или локальной модели, сложный рефакторинг — на сильной.
- Узкая задача. Агент, который занимается только миграциями или только тестами, реже уходит в сторону.
Точные имена встроенных агентов и синтаксис их описания сверь с документацией своей версии: раздел активно меняется, и примеры из старых постов бывают не в ту схему.
Сначала план, потом правки
Самый полезный приём — разделить «подумать» и «сделать».
В режиме планирования агент читает проект и предлагает порядок действий, но файлы не меняет. Ты видишь замысел целиком до того, как он начнёт его воплощать, и ловишь неверное понимание задачи на этапе, когда откатывать нечего.
Это особенно окупается на задачах, где правка затрагивает несколько файлов. Агент, который сразу пошёл менять код, к середине задачи уже накопил изменений на приличный diff, и разбираться, где он свернул не туда, дороже, чем прочитать план заранее.
Если агент регулярно предлагает не то, проблема обычно не в модели, а в постановке. План это показывает сразу: в нём видно, что именно он понял под задачей.
Права: чем уже, тем спокойнее
Разрешения стоит раздавать по принципу «что нужно для этой работы», а не «на всякий случай». Читающему агенту не нужна запись. Агенту для тестов не нужен доступ в сеть. Тому, кто правит код, не нужны переменные окружения с ключами.
Ошибка модели сама по себе безобидна — опасно то, что инструмент выполнит её без возражений. Поэтому команды, которые невозможно откатить, лучше держать за подтверждением, а первый прогон незнакомой связки делать на отдельной ветке.
Как это описывается в настройках, смотри в opencode.json. Если агент ходит во внешние сервисы, там же действует правило узких токенов из статьи про MCP-сервер.
Субагент или skill
Их легко перепутать, а разница простая.
Skill описывает, как делать работу: порядок проверок, команды, критерий готовности. Он не меняет ни модель, ни права — про это есть отдельный разбор skills в OpenCode.
Отдельный агент нужен, когда должны отличаться сами условия работы: другая модель, другой набор инструментов, другие разрешения. Если всё, что ты хочешь изменить, — это инструкция, хватит навыка.
С чего начать
Не строй систему из пяти агентов сразу. Заведи одного читающего, без права на запись, и пользуйся им для разбора задач — он окупается быстрее всех и ничего не может сломать. Второго добавляй, когда поймаешь себя на том, что каждый раз вручную меняешь модель или отбираешь доступ.
А если разграничивать права в конфиге не хочется, в Доке инструменты и разрешения включаются в интерфейсе, и видно, что именно агенту сейчас разрешено.