Как настроить OpenCode, чтобы ИИ-агент помогал в работе
Обычный чат с LLM быстро упирается в потолок: модель не видит ваш контекст, правила команды и рабочие файлы. В статье разбирается, как собрать вокруг OpenCode более полезную среду, чтобы агент меньше требовал ручных объяснений и лучше справлялся с рутиной.
Почему одного чата с ИИ уже мало
Автор статьи начинает с знакомого сценария: открыл чат, задал вопрос, получил ответ. Это удобно, но для реальной работы такого подхода часто недостаточно, потому что модель не знает проект, не видит документацию и не помнит внутренние правила команды.
Чтобы ИИ действительно помогал, а не просто отвечал на разовые запросы, вокруг него нужно выстроить рабочую среду. В этом кейсе роль такой среды выполняет OpenCode — оболочка, которая дает модели доступ к файлам, инструкциям, локальным инструментам, API и MCP-серверам.
Как разнести настройки и сделать агент стабильнее
Первый практический совет — разделить конфигурацию на глобальную и проектную. В общий конфиг удобно вынести провайдеров, модели, базовые разрешения и универсальные инструкции, а в папке проекта оставить только то, что относится именно к этому репозиторию: архитектурные ограничения, команды сборки и тестирования, документацию и проектные навыки.
Отдельно автор советует использовать файл AGENTS.md только для постоянных правил: не выдумывать факты, перед правками изучать связанные участки кода, не делать commit, push и merge без разрешения, а при неясной задаче — уточнять детали. Если туда складывать вообще все подряд, файл быстро станет слишком большим и неудобным в поддержке.
Документация, skills и роли агентов
Если одна и та же схема работы повторяется часто, ее лучше оформить как skill. Например, для code review можно заранее описать порядок проверки: сначала изучить измененные файлы, потом связанные вызовы, затем поискать регрессии, ошибки и отсутствие тестов. Для типовых сценариев удобны и команды: одна команда может запускать заранее заданную последовательность действий вместо того, чтобы каждый раз объяснять ее вручную.
Еще один полезный прием — разделять роли между несколькими агентами. Например, reviewer может работать только в режиме чтения, а developer — иметь право менять файлы. Это безопаснее и удобнее, чем давать одному универсальному агенту все доступы сразу.
Как подключать рабочие системы без лишней ручной работы
Следующий шаг — дать агенту доступ не только к локальному workspace, но и к внешним источникам знаний. Через MCP или API можно подключить GitLab, GitHub, Jira, Confluence, внутренние сервисы и базы документации. Тогда агент сможет не просто отвечать на вопрос, а сам искать связанную задачу, читать документацию и сопоставлять это с текущей реализацией.
При этом автор отмечает, что с GitLab не всегда стоит полагаться только на MCP. В ее случае сервер запускался, но возникла проблема со схемой инструментов: формат ответа не совпадал с тем, что ожидал OpenCode. Это хороший пример того, что на практике важна не только идея, но и проверка совместимости с конкретным инструментом. Для бизнеса и команды это значит одно: чем аккуратнее вы соберете доступы, инструкции и роли, тем меньше времени ИИ будет тратить на лишние уточнения и тем больше — на реальную помощь.