Введение

Это продолжение предыдущей статьи ИИ: личный опыт без хайпа. Часть 0. Термины, связи и устройство / Хабр. В этот раз поговорим о более конкретной вещи — настройке рабочего места для начала разработки.

В чём проблема

Подключить модель к редактору и попросить её написать код несложно.

Сложности дальше. На чём работать, если не хочется зависеть от одного поставщика? И как предсказуемо передавать полное описание задачи, а не устную договорённость? Второе важно и руководству, и исполнителям: человек часто достраивает контекст сам, машине нужны те же инструкции и детали. В этой статье я это не закрываю. Здесь только техническая основа рабочего места. Требования и их формализацию разберу отдельно. Отдельный вопрос — как всё это сделать удобно в ежедневной работе.

Что я хотел и что я нашел в OpenCode. Главное — никакой привязки к одному поставщику. Основное преимущество OpenCode в том, что можно собрать свою комбинацию провайдеров и ролей. Цена — больше настройки и ответственности за её сопровождение. Второе — сценарии работы: служба, desktop, TUI и плагин для VS Code. Это разные входы в одну среду, а не разные агенты. Третье — открытый инструмент с библиотекой плагинов. К ним вернусь дальше в статье. Если команда готова к привязке или хочет быстро попробовать, есть смысл смотреть решения вроде Codex.

В этой статье разбираю OpenCode как среду для работы с кодом и Oh My OpenCode как надстройку для ролей и распределения задач.

OpenCode — основа моего рабочего места

На самом деле несколько шире:

Последний сценарий для меня особенно удобен. Особенность агентной разработки:

• много чего делается в фоне

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

Установка OpenCode на Linux

Вариантов установки множество — скрипт, npm, есть штатные поставки под разные дистрибутивы. Способы установки перечислены на странице OpenCode | Download. Документации очень много: Intro | OpenCode.

Лично я использую оба. Штатный скрипт для одних машин, на сборочном узле с Arch — штатный yay. Замечу, что Desktop сам по себе не тянет агента, только GUI. Придётся поставить отдельно. Второе замечание: на момент написания статьи (сентябрь 2026 года) вышла версия 2.x.x. Она не тестировалась мной, так как были ограничения по работе с Oh My OpenCode из-за смены API: “V1 plugin implementations do not run in V2. Moving a file or renaming its config entry is not enough.”. Есть issue: Plugin fails to load on OpenCode V2: exports {id, server} instead of {id, setup} · Issue #8548 · code-yeongyu/oh-my-openagent · GitHub. Проверить версию и найти путь к установщику можно так:

command -v opencode
opencode --version

Запуск

Для serve (мой основной сценарий) удобнее создать службу systemd —user и включить linger, чтобы сервер запускался без входа пользователя. Так получается круглосуточный сервер разработки. Вот простой пример для доверенной сети — без авторизации, с env-файлом, доступный отовсюду. Для реального использования настройте авторизацию и ограничьте доступ к серверу: привязка к 0.0.0.0 открывает порт на всех сетевых интерфейсах.

:~$ cat ~/.config/systemd/user/opencode.service
[Unit]
Description=opencode headless server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
Environment=HOME=%h
Environment=XDG_CONFIG_HOME=%h/.config
Environment=XDG_DATA_HOME=%h/.local/share
EnvironmentFile=%h/.config/opencode/proxy.env
ExecStart=/home/alexey/.opencode/bin/opencode serve --hostname 0.0.0.0 --port 4096 --print-logs
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

Подключение провайдера LLM

Провайдер — не модель и не агент. Он предоставляет доступ. Далее вы выбираете модель для выполнения задач своим агентом. Вариантов много. Из тех, которыми я пользовался, отмечу:

• подписки ChatGPT и Grok (OAuth)

• Zia coding plan

• OpenAI-совместимый API (например, при подключении локальных инстансов или LiteLLM, а также как альтернатива при проблемах с подписками Kimi) Настроить подключение можно через opencode.json или команду /connect. Я предпочитаю мастер настройки в Desktop или веб-интерфейсе. Далее в сессии будет доступен выбор LLM для неё.

Добавлю ещё немного полезных команд:

opencode models --refresh              # обновить каталог моделей из models.dev. обновляет каталог моделей, а не авторизацию и не условия подписки
opencode models                        # показать модели
opencode models zai-coding-plan        # отфильтровать по ID провайдера
opencode models --verbose              # показать метаданные, включая стоимость

MCP, плагины и skills

В предыдущей статье я объяснил эти термины. OpenCode поддерживает MCP, плагины и навыки. MCP, например, помогает получать актуальную документацию. Плагины могут менять поведение агента, а навыки — описывать последовательность действий для типовых задач. О плагине Oh My OpenCode расскажу ниже.

Пример раздела MCP в opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp",
      "enabled": true
    }
  }
}

Проверить можно так:

opencode mcp list

Можно подключать локальные и сетевые серверы и настраивать авторизацию:

opencode mcp auth ИМЯ
opencode mcp debug ИМЯ

Плагин меняет поведение OpenCode, поэтому сначала проверьте его источник и совместимость с используемой версией. npm-плагин указывается в массиве plugin файла opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["имя-проверенного-пакета"]
}

Навыки хранятся в .opencode/skills. Например, файл навыка для ревью может находиться по пути .opencode/skills/review-checklist/SKILL.md:

---
name: review-checklist
description: Проверять изменение кода по проектному чек-листу перед ревью
---

## Что делать
- Прочитать diff и связанные требования.
- Запустить предусмотренные проектом проверки.
- Сообщить о непроверенных пунктах; не объявлять их успешными.

И не забывайте перезапускать самого агента после изменений конфигов.

Агенты и субагенты OpenCode

OpenCode предоставляет агентов и субагентов. Два агента доступны сразу:

• plan — планирование без изменений; удобно, чтобы сначала составить план.

• build — основной режим для выполнения задач; он может быть неудобен, если нужно только спланировать работу.

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

Oh My OpenCode: удобство работы

Поводом стал неудобный рабочий процесс: пока выполняются задачи, сессия фактически перестаёт быть интерактивной. Я уже начал PoC собственного набора настроек, но решил поискать готовое решение и нашёл Oh My OpenCode. OpenCode уже умеет работать с основными агентами и субагентами. Oh My OpenCode помогает распределить исследование, планирование, реализацию и проверку между ролями, назначить им разные модели и не задавать маршрутизацию вручную в каждом запросе. Это особенно удобно на больших проектах.

Процесс выглядит так:

1. Пользователь ставит задачу основному агенту.

2. Основной агент распределяет её между специализированными ролями.

3. Роли возвращают результат и изменения.

4. Выполняются проверки.

5. Пользователь получает итог.

Установка описана в руководстве Oh My OpenCode.

Далее потребуется перезапуск агента. После этого в сессии появятся новые агенты и субагенты.

Sisyphus

• Тип: основной агент.

• Роль: главный orchestrator.

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

Prometheus

• Тип: основной агент.

• Роль: planner.

• Что делает: занимается стратегическим планированием, интервьюирует пользователя и готовит план.

Atlas

• Тип: основной агент.

• Роль: todo orchestrator.

• Что делает: ведёт выполнение уже сформированного плана или списка задач и контролирует прогресс. На этапе внедрения иногда были проблемы. Поэтому я оставил родных агентов OpenCode. Для этого в omo.json:

"sisyphus_agent": {
  "default_builder_enabled": true,
  "replace_plan": false
}

• plan сохранён как основной агент — OmO его здесь не заменил.

• build сохранён, но в обычном запуске показан как субагент, а не как основной.

Свои шаблоны Oh my Opencode

Исторически я использую несколько подписок:

• тестирование разных подписок

• разные подписки хорошо подходят под разные задачи

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

• модель основного диалога в сессии — из OpenCode

• библиотека шаблонов — модели по ролям агентов и субагентов. Хранится на уровне OmO

• применённый шаблон в проекте. Копируется из библиотеки.

~/.config/opencode/opencode.jsonc
	└─ провайдеры и модели opencode, регистрация oh-my-openagent
~/.omo/omo.jsonc
	└─ общие пользовательские настройки OmO
~/omo-policies/
	├─ chatgpt.omo.jsonc
	├─ zai.omo.jsonc
	├─ kimi.omo.jsonc
	├─ grok.omo.jsonc
	└─ localllm.omo.jsonc
	└─ моя библиотека шаблонов. OmO не переключает их автоматически

<проект>/.omo/omo.jsonc
	└─ проектные назначения моделей ролям и категориям OmO

Я называю эти файлы “шаблонами” или “профилями” в бытовом смысле. У OmO есть и собственный механизм именованных profiles.<имя>, активируемых, в частности, через OMO_PROFILE, но в описанной схеме он не используется. Выбор шаблона определяет назначения моделей для ролей OmO в конкретном проекте. Это не обязательно встроенная команда OmO “переключить шаблон” и не обязательно отдельная сущность конфигурационного формата. Для переключения проекта на другой вариант меняется его .omo/omo.jsonc. Теперь у меня есть шаблоны под разные подписки. Чтобы применить один из них, достаточно открыть сессию и выполнить три действия:

• Выбрать агента (Prometheus или другого).

• Выбрать для него модель.

• Попросить агента применить шаблон.

Пример такого шаблона:

cat ~/omo-policies/chatgpt.omo.jsonc  
// omo-policy: chatgpt  
// Isolated quota-conscious ChatGPT/OpenAI policy. Live ids confirmed 2026-09-24.  
// PoC/MVP: session default openai/gpt-6-sol. gpt-6-astra only via category ultrabrain.  
// momus uses gpt-6-sol — gpt-5.6-terra is not in opencode.jsonc.  
{  
 "[opencode]": {  
   "telemetry": false,  
   "agents": {  
     "sisyphus": { "model": "openai/gpt-6-sol", "reasoning": "medium" },  
     "hephaestus": { "model": "openai/gpt-6-sol", "reasoning": "medium" },  
     "oracle": { "model": "openai/gpt-6-sol", "reasoning": "high" },  
     "librarian": { "model": "openai/gpt-6-luna", "reasoning": "low" },  
     "explore": { "model": "openai/gpt-6-luna", "reasoning": "low" },  
     "multimodal-looker": { "model": "openai/gpt-6-sol", "reasoning": "medium" },  
     "prometheus": { "model": "openai/gpt-6-sol", "reasoning": "medium" },  
     "metis": { "model": "openai/gpt-6-luna", "reasoning": "low" },  
     "momus": { "model": "openai/gpt-6-sol", "reasoning": "high" },  
     "atlas": { "model": "openai/gpt-6-sol", "reasoning": "medium" },  
     "sisyphus-junior": { "model": "openai/gpt-6-luna", "reasoning": "medium" }  
   },  
   "categories": {  
     "visual-engineering": { "model": "openai/gpt-6-sol", "reasoning": "high" },  
     "ultrabrain": { "model": "openai/gpt-6-astra", "reasoning": "high" },  
     "deep": { "model": "openai/gpt-6-sol", "reasoning": "medium" },  
     "artistry": { "model": "openai/gpt-6-sol", "reasoning": "high" },  
     "quick": { "model": "openai/gpt-6-luna", "reasoning": "low" },  
     "unspecified-low": { "model": "openai/gpt-6-luna", "reasoning": "medium" },  
     "unspecified-high": { "model": "openai/gpt-6-sol", "reasoning": "high" },  
     "writing": { "model": "openai/gpt-6-luna", "reasoning": "medium" }  
   }  
 }  
}

Что мне дал Oh My OpenCode

Основные плюсы:

• Сессия почти всегда остаётся интерактивной: можно запускать задачи, следить за статусами и добавлять новые.

• Параллелизация ускорила выполнение моих задач, особенно при использовании гибридных профилей.

• На мой взгляд, качество ревью выросло: проверки стали строже.

Минус — расход токенов возрастает, поэтому мои квоты заканчиваются быстрее.

Отступление про параллелизацию. Opencode сам по себе предоставляет такую функцию. OmO добавляет готовую оркестрацию, роли, назначение моделей и управление фоновыми задачами. Он упрощает запуск и управление несколькими независимыми работами, распределёнными между ролями и моделями. Ускорение возможно по времени выполнения набора задач, но зависит от делимости работы, квот/лимитов провайдеров, очередей и последующей интеграции результатов.

OpenSpec

OpenSpec — фреймворк для SDD (spec-driven development). Он помогает описать изменение: от его цели и решаемой проблемы до технического дизайна. Его можно использовать как с ИИ, так и без него; с ИИ работать удобнее. Установка простая, через npm:

npm install -g @fission-ai/openspec@latest

Прямой интеграции с OpenCode нет. Это отдельный инструмент, который создаёт проектные инструкции для OpenCode. Применяется на уровне проекта. Но всё чуточку сложнее. Чтобы начать работу, инициализируйте OpenSpec в проекте. При настройке указывается и используемый агент:

cd $PROJECT_DIR
openspec init --tools opencode

После этого в каталоге проекта появятся следующие файлы:

Больше никакой “интеграции” нет: OpenCode просто подхватывает markdown из .opencode/ при запуске в этом каталоге. Глобально команды ставить смысла нет — без openspec/ в репо они не работают. Проверки простые:

openspec doctor          # в каталоге проекта - "OpenSpec root: ok"
cd PROJECT_DIR && opencode    # /opsx-propose должен появиться в списке команд

Ещё несколько удобных решений

• Настройки агентов я вынес в отдельный каталог и подключил символическими ссылками.

• Сначала синхронизировал конфигурации через Nextcloud, затем перешёл на Git.

• Добавил навыки, чтобы не повторять ручные действия.

• Сохранил полный комплект агентов OpenCode и Oh My OpenCode.

Резюме

OpenCode даёт общую среду и доступ к моделям. Oh My OpenCode задаёт роли и модели для них, а конфигурация проекта фиксирует этот выбор. Между машинами настройки переносятся уже через git, а не через смену интерфейса. OpenSpec помогает описывать требования и предлагаемые изменения. Такой стек не заменяет согласование требований, тесты, ревью и приёмку человеком. Он не задаёт процесс. Это часть, на которой процесс можно строить.

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

• Могу подбирать модели и не быть привязанным к одному провайдеру.

• Могу назначать ролям разные модели, в том числе более дешёвые. Общий расход от этого сам не падает: с ролями квоты у меня заканчиваются быстрее.

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

• Могу спланировать работу, запустить её на сервере и заняться другими делами. Сессия продолжится, даже если связь пропадёт; агенты могут работать ночью.

• Спецификации дают агенту более точную рамку, чем набор промптов. Это про реализацию по описанию, не про замену всего процесса разработки.

Отдельно добавлю, что всё это хорошо ложится на рекомендации Anthropic по проектированию надежных агентных систем: отказ от концепции “одного всемогущего черного ящика” в пользу композиции четко разграниченных уровней: Control Plane (управление и надзор), Execution Plane (исполнение и вызов инструментов) и Storage / State Plane (состояние и контекст):

«Building Effective Agents» (Архитектурные паттерны: Orchestrator-Workers, Evaluator-Optimizer, Human-in-the-loop): https://www.anthropic.com/research/building-effective-agents

«Model Context Protocol (MCP)» (Стандарт разделения контекста, инструментов и среды исполнения): https://www.anthropic.com/news/model-context-protocol

Anthropic Engineering / Interactive Workflows (Инженерные практики работы с кодовыми базами и артефактами): https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop