Агентная разработка на OpenCode строится на трёх компонентах: среда и агент OpenCode, набор ролей и плагинов Oh My OpenCode, фреймворк спецификаций OpenSpec. Смысл связки в том, что поставщика LLM вы выбираете сами, комбинируете модели под конкретные задачи и меняете их, когда это становится выгодно, вместо того чтобы жить внутри экосистемы одного вендора. Плата за такую свободу предсказуема: больше настроек, больше заботы об их актуальности и внимательный контроль расхода токенов.
Дальше практическая разборка: из чего состоит стек, как разложить роли между моделями, чем отличаются режимы TUI, плагина VS Code, Desktop и службы serve, и где проходят границы автоматизации.
Что такое агентная разработка на OpenCode и зачем отказываться от привязки к провайдеру
Агентная разработка - это режим, при котором LLM-агенты берут на себя исследование задачи, планирование, написание кода и проверку, а человек задаёт границы, утверждает решения и отвечает за результат. OpenCode здесь работает и как агент, и как среда: открытый инструмент с библиотекой плагинов, на котором можно собрать свою комбинацию провайдеров и ролей. Именно отсутствие привязки к одному поставщику автор разбора техстека называет главным преимуществом OpenCode.
Настройки при этом общие для всей машины. Интерфейс меняет только способ взаимодействия с агентом, но не поведение и не политику разработки: запустили вы TUI, плагин в редакторе или службу, агент работает по одной и той же конфигурации.
Ключевые компоненты: OpenCode, Oh My OpenCode, OpenSpec
- OpenCode - открытый инструмент с библиотекой плагинов, который используют и как агента, и как среду; он функционирует в нескольких сценариях: TUI, плагин VS Code, Desktop и служба serve.
- Oh My OpenCode - набор ролей и плагинов для мультиагентной разработки: задаёт роли агентов и маршрутизацию задач к моделям.
- OpenSpec - фреймворк spec-driven development: фиксирует предлагаемое изменение и требования к нему, а для OpenCode создаёт проектные инструкции и slash-команды.
Обязанности разделены просто. OpenCode отвечает за исполнение работы и за интерфейсы. Oh My OpenCode решает, кто именно и какой моделью делает каждый шаг. OpenSpec определяет, что должно получиться на выходе и как это проверить. Собирая всё вместе, вы получаете рабочее место, где исследование, планирование, код и проверка распределены между специализированными субагентами.
Почему независимость от провайдера важна
Привязка к одному поставщику означает, что смена цен, лимитов или доступности моделей сразу бьёт по вашему процессу: приходится ждать, платить больше или переписывать сценарии. Своя комбинация провайдеров снимает часть этих рисков заранее. Держите две модели близкого класса от разных вендоров и переключайтесь, когда один сервис недоступен или упёрся в квоту. Вторая выгода прямая экономическая: быстрая и дешёвая модель на исследование, сильная на сложный код. Такой расклад возможен только там, где провайдеров и роли назначаете вы, а не платформа.
Цена независимости тоже честная: больше настройки и ответственности за её сопровождение. Стек не работает сам по себе, кто-то должен следить за конфигурацией и шаблонами. Автор разбора отмечает и обратный случай: если команда готова к привязке к одному поставщику или хочет быстро попробовать, есть смысл смотреть решения вроде Codex.
Установка и базовая настройка OpenCode
Начать стоит с установки: способов несколько, и выбор зависит от операционной системы и привычек. Автор разбора перечисляет скрипт, npm и штатные поставки под разные дистрибутивы, полный список способов приведён на официальной странице загрузки OpenCode. Отдельно проверьте окружение: версию рантайма, права на запись в каталог установки и доступ к сети. Часть проблем на старте связана именно с окружением, а не с самим агентом.
Способы установки: скрипт, npm, дистрибутивы
Скрипт удобен для быстрого запуска на чистой машине: одна команда, минимум решений. Пакет из npm подойдёт, если в проекте уже есть Node.js и вы привыкли обновлять инструменты через пакетный менеджер. Штатные поставки закрывают случай, когда нужна предсказуемая версия под конкретный дистрибутив или окружение, где внешние репозитории недоступны. Точный перечень сборок и поддерживаемых версий смотрите на странице загрузки: он меняется от релиза к релизу.
Первичная конфигурация: провайдеры и модели
Конфигурация хранится в файлах, поэтому один раз настроенная машина даёт одинаковое поведение агента во всех интерфейсах. Общий принцип такой: вы описываете список провайдеров, доступные модели и модель по умолчанию, а затем переопределяете выбор для отдельных задач и ролей. Точные имена полей, формат файла и способ подключения локальных провайдеров зависят от версии; в источнике, на который опирается разбор, эти детали не раскрыты, поэтому сверяйтесь с документацией проекта. Схема ниже условная, она нужна, чтобы было понятно, что именно вы раскладываете по полкам.
// условная схема, имена полей уточняйте в документации
{
"providers": [
{ "id": "provider-a", "apiKeyEnv": "PROVIDER_A_KEY" },
{ "id": "provider-b", "apiKeyEnv": "PROVIDER_B_KEY" }
],
"models": {
"default": "provider-a/быстрая-модель",
"heavy": "provider-b/сильная-модель"
}
}Пример с двумя провайдерами решает задачу резервирования: пока один сервис недоступен, второй продолжает работу. Ключи держите в переменных окружения, а не в файлах репозитория, и проверьте, что конфигурация не попала в git. Модель по умолчанию выбирайте по самой частой задаче, а тяжёлые варианты оставляйте для отдельных ролей.
Роли агентов и маршрутизация задач в Oh My OpenCode
Oh My OpenCode добавляет к среде то, чего в ней по умолчанию нет: роли агентов и маршрутизацию задач к моделям. Вместо одного универсального ассистента вы получаете несколько ролей, и каждая часть работы выполняется своей моделью. Логика простая: не тратить дорогую модель на рутину и не доверять дешёвой ответственный участок.
Типовые роли: исследование, планирование, реализация, проверка
- Исследователь изучает кодовую базу, документацию и зависимости, возвращает сжатую выжимку с фактами и указанием файлов.
- Планировщик превращает выжимку в пошаговый план: что менять, в каком порядке, какие проверки пройдут после.
- Разработчик пишет код по плану, не пересматривая архитектурные решения задним числом.
- Ревьюер сверяет результат со спецификацией и ищет типовые ошибки.
Роли работают и последовательно, и частично параллельно. Для задачи «добавить функцию» цепочка выглядит так: исследователь собирает контекст, планировщик режет работу на шаги, разработчик их выполняет, ревьюер сверяет код с требованиями. Параллелизм не бесплатный: каждое обращение к модели - отдельный счёт токенов.
Настройка шаблонов моделей по ролям
Смысл шаблонов в том, чтобы привязать роль к паре «провайдер + модель» и не выбирать модель руками на каждом шаге. Условная раскладка выглядит так:
// условная схема маршрутизации, поля уточняйте в документации
{
"agents": {
"researcher": { "model": "provider-a/fast-cheap" },
"planner": { "model": "provider-b/strong-reasoning" },
"coder": { "model": "provider-b/strong-coding" },
"reviewer": { "model": "provider-a/fast-cheap" }
}
}Ключи провайдеров берите из переменных окружения, чтобы шаблон можно было держать в общем репозитории. Промах в маршрутизации почти всегда бьёт по бюджету: сильная модель на роли исследователя или дублирование ролей на одной задаче расходуют квоту быстрее, чем кажется.
OpenSpec: spec-driven development в связке с OpenCode
OpenSpec закрывает вопрос «что именно мы делаем»: это фреймворк spec-driven development, который фиксирует предлагаемое изменение и требования к нему. Агент получает не устную просьбу в чате, а письменный документ, с которым можно сверять результат.
Как OpenSpec интегрируется с OpenCode
Интеграция идёт через файлы проекта и slash-команды. OpenSpec создаёт проектные инструкции и команды, которые подхватывает OpenCode, поэтому контекст проекта и правила работы доступны агенту без ручного копирования в промпт. Конкретные имена каталогов, файлов и команд зависят от версии, в источнике они не приводятся: проверяйте их в документации OpenSpec и в самом проекте после инициализации. Важнее другое: спецификации и инструкции остаются в репозитории, а значит их можно ревьюить, обсуждать в пул-реквесте и переиспользовать в следующих задачах.
Практический пример: от требования до изменения
- Требование формулируется словами: «пользователь должен видеть историю заказов на отдельной странице».
- OpenSpec превращает её в спецификацию: сценарии, границы поведения, критерии готовности.
- Планировщик на основе спецификации разбивает работу на шаги, разработчик их выполняет.
- Ревьюер проверяет код против спецификации, а не против собственных ожиданий.
- Человек проводит приёмку: тесты, ручная проверка, решение о выпуске.
Выигрыш не в скорости генерации кода, а в снижении неоднозначности: спорные места всплывают на этапе спецификации, где правки дешёвые, а не после мержа. Обратная сторона - дисциплина. Если спецификация отстала от кода, агенты начнут опираться на устаревшие требования. Как связать спецификации с проектированием системы, разобрано в материале про архитектурное мышление разработчика.
Сценарии работы OpenCode: TUI, VS Code, Desktop и serve
Сценариев четыре, и все они работают с одной конфигурацией. Разница только в том, как вам удобно наблюдать за процессом и держать сессии.
TUI и VS Code: для быстрого старта и интеграции в IDE
TUI - самый первый и простой интерфейс OpenCode, он полнофункционален: задачи, плагины и роли доступны без урезаний. Разумный выбор для серверов без графики, быстрых правок и коротких сессий. Плагин VS Code ставит агента рядом с кодом: видно, что меняется в файлах, и не нужно переключаться между окнами. Настройки в обоих случаях одни и те же, поэтому переход из терминала в IDE не требует переноса конфигурации.
Desktop и serve: для фоновой работы и множества сессий
Desktop - отдельное приложение с оконным интерфейсом для тех, кому удобнее графика. Режим serve запускает OpenCode как службу: доступ через браузер, можно настраивать и поддерживать множество сессий параллельно. Для агентной разработки этот сценарий особенно удобен: много работы идёт в фоне, а у подписок есть почасовые, суточные и другие лимиты. Пока одна сессия считает, вторая уже поставлена в очередь, и вы возвращаетесь к результату, а не сидите над прогресс-баром. Автор разбора пришёл к схеме, где основная нода для разработки - ноутбук с запущенным сервисом: работу можно спланировать и запустить, занимаясь другими делами, и потеря связи в дороге или на совещании не ломает процесс.
Запуск сервера OpenCode и работа с сессиями
Режим службы включается отдельным запуском, после чего среда доступна через браузер. Точный синтаксис команды и набор флагов зависят от версии и способа установки, в источнике они не приводятся. Ориентировочный вид запуска такой, а флаги сверьте со справкой установленной версии:
opencode serve --port 8080Команда запуска и параметры
Перед запуском проверьте три вещи. Порт: выберите свободный, чтобы не конфликтовать с другими сервисами на машине. Доступ: если служба должна быть видна только локально, не выставляйте её в общую сеть. Аутентификация: при доступе по сети закройте интерфейс паролем или обратным прокси. После старта сервер слушает выбранный порт, и веб-интерфейс открывается в браузере по адресу с этим портом.
Управление сессиями через браузер
В веб-интерфейсе сессии живут списком: можно создать новую, переключиться на старую и запустить несколько задач одновременно. Фоновая работа здесь главный сценарий: задача поставлена, вы ушли, вернулись к готовому результату. Если служба доступна по сети, обязательно закройте её аутентификацией: агент работает с файлами проекта и ключами провайдеров, публичный доступ к такому интерфейсу недопустим. Схему, где несколько CLI-сессий и панель управления складываются в оркестратор задач, разбирали в отдельном кейсе про пет-проект на Java с Claude Code.
Ограничения и риски: расход токенов, квоты, сопровождение
Стек заметно дороже одиночного чата с моделью, и причины технические, а не маркетинговые.
Почему растёт расход токенов и как его контролировать
Каждый субагент обращается к модели отдельно, а исследование, планирование и ревью часто читают один и тот же код заново. Из-за этого одна задача оплачивается несколько раз. Добавьте сюда лимиты подписок: почасовые и суточные окна легко исчерпать в середине крупной фичи, и фоновая работа в режиме serve встанет на паузу без вашего участия. Практичные меры: держать дешёвую модель на ролях исследователя и ревьюера, не давать роли доступ ко всему репозиторию сразу, разбивать работу на короткие сессии вместо одной длинной и следить, что именно уходит в контекст.
Необходимость сопровождения настроек
Конфигурация живёт своей жизнью: провайдеры меняют модели и лимиты, инструменты обновляются, роли уточняются под проект. Каждое изменение в маршрутизации - это правка файлов и проверка, что агент по-прежнему делает нужное. Ошибка в шаблоне тихо перенаправит тяжёлый участок на слабую модель или, наоборот, сожжёт бюджет на рутине. Это и есть плата за независимость: без сопровождения гибкость превращается в набор устаревших настроек, которым никто не доверяет.
Стек не заменяет тесты, ревью и приёмку человеком
Агенты ошибаются предсказуемо: неверно понятое требование, лишний рефакторинг, зелёный тест не на том сценарии. Spec-driven development снижает риск, но не отменяет его, спецификацию тоже можно понять буквально не там, где вы имели в виду. Поэтому тесты, код-ревью и решение о выпуске остаются за человеком. Почему проверка результата стоит дороже, чем кажется, разобрано в статье о разработке с ИИ-агентами.
Кому подходит такой стек и когда выбрать альтернативы
Стек окупается там, где команда готова вкладываться в настройку и сопровождение ради гибкости и контроля над затратами.
Критерии выбора: гибкость против простоты
- Нужен ли доступ к двум и более провайдерам одновременно, например для резервирования или экономии?
- Есть ли человек, который будет вести конфигурацию и шаблоны ролей?
- Готовы ли вы считать расход токенов и следить за квотами подписок?
- Приняты ли тесты, ревью и приёмка как обязательный этап, а не как формальность?
- Есть ли задачи, которые агенты решают регулярно, или стек понадобится раз в месяц?
Если хотя бы на два вопроса ответ «нет», выигрыш от гибкости сомнителен: время уйдёт на настройку, а не на разработку.
Когда стоит посмотреть в сторону Codex и подобных
Автор разбора отмечает: если команда готова к привязке к одному поставщику или хочет быстро попробовать, есть смысл смотреть решения вроде Codex. Логика простая: меньше настройки на входе и меньше сопровождения, но и меньше свободы при смене цен, лимитов и моделей. Выбор упирается в приоритеты: скорость старта против долгосрочной гибкости. Командам без выделенных ресурсов на поддержку инфраструктуры такое начало часто подходит лучше, чем сразу собирать мультипровайдерный стек.
Начинать разумно с малого: поставить OpenCode, настроить одну-две модели, ввести OpenSpec на одном проекте и неделю следить за реальным расходом токенов. Если бюджет и время окупаются, добавляйте роли и второго провайдера. Если нет, вы потеряете несколько вечеров, а не квартал.