ИИ: личный опыт без хайпа. Часть 1. Техстек на базе OpenCode

Это продолжение предыдущей статьи ИИ: личный опыт без хайпа. Часть 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 помогает описывать требования и предлагаемые изменения. Такой стек не заменяет согласование требований, тесты, ревью и приёмку человеком. Он не задаёт процесс. Это часть, на которой процесс можно строить.

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

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

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

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

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

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