ИИ: личный опыт без хайпа. Часть 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 opencodeopencode --version

Запуск

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

:~$ cat ~/.config/systemd/user/opencode.service[Unit]Description=opencode headless serverAfter=network-online.targetWants=network-online.target[Service]Type=simpleEnvironment=HOME=%hEnvironment=XDG_CONFIG_HOME=%h/.configEnvironment=XDG_DATA_HOME=%h/.local/shareEnvironmentFile=%h/.config/opencode/proxy.envExecStart=/home/alexey/.opencode/bin/opencode serve --hostname 0.0.0.0 --port 4096 --print-logsRestart=on-failureRestartSec=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-checklistdescription: Проверять изменение кода по проектному чек-листу перед ревью---## Что делать- Прочитать 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_DIRopenspec 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 помогает описывать требования и предлагаемые изменения. Такой стек не заменяет согласование требований, тесты, ревью и приёмку человеком. Он не задаёт процесс. Это часть, на которой процесс можно строить.

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

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

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

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

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

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