# OpenCode: пошаговая настройка AI-агента вместо чата с LLM

> 2026-09-29 · AI Release · @ai_release1

> #opencode #ai-агенты #llm #настройка

### ⚡ Главное за 5 секунд - OpenCode — это оболочка, где LLM получает доступ к файлам, инструкциям, локальным инструментам, API и MCP-серверам. - Подключить можно внешнего провайдера или локальную LLM: Настройки → Провайдеры → Выбрать провайдера → Подключить. - Для рабочих проектов нужно учитывать корпоративные правила: какие модели разрешены и можно ли передавать код во внешние сервисы. ### 🔍 Что обнаружено Автор материала — Арина, аналитик в Selectel. Она описывает переход от стандартного сценария «открыть чат, вставить текст, сформулировать запрос, получить ответ» к полноценному агенту. По её словам, такой чат быстро упирается в потолок: модель не знает контекст проектов, документацию, код и правила команды. В качестве рабочей среды используется OpenCode — оболочка, в которой LLM получает доступ к файлам, инструкциям, локальным инструментам, API и MCP-серверам. Подключение модели: для личных проектов достаточно скопировать API-ключ от популярного провайдера в настройках. Для локальной LLM нужно заполнить поля: ID провайдера, отображаемое имя, базовый URL, ключ API, доступные модели. Конфигурация разделяется на два уровня. Global config (~/.config/opencode/) содержит opencode.json, AGENTS.md и skills для всех проектов. Project config (в репозитории) включает AGENTS.md, opencode.json, docs, contexts, scripts и.opencode/ с skills, commands и agents. В JSON-примере указаны модели glm-5.3 с контекстом 262 000 и kimi-k2.6 с контекстом 203 000, а также default_agent: "plan". ### 💡 Почему это важно Разделение конфигурации и вынос повторяющихся алгоритмов в skills и commands позволяет агенту работать стабильнее и снимать рутину. Например, skill для code review задаёт последовательную проверку изменённых файлов, связанных вызовов, возможных регрессий, обработки ошибок и наличия тестов. Command /fix-bug запускает чёткий алгоритм: изучить описание, найти код, определить причину, предложить решение, после подтверждения изменить код, запустить тесты, показать diff и риски. Это избавляет от ручного описания одного и того же сценария каждый раз. ### 🧩 Контекст Для правил, которые должны применяться почти всегда, используется файл AGENTS.md: не придумывать несуществующие факты, изучать связанные реализации перед изменением кода, не выполнять commit, push и merge без разрешения, задавать уточняющие вопросы при неоднозначности. При разрастании конфигурации автор советует разделять роли на отдельных агентов: developer, reviewer, researcher, docs. У них могут отличаться доступные инструменты, модель, промпт, permissions и skills. Например, reviewer работает в read-only, а developer имеет доступ к изменению файлов — это безопаснее, чем давать универсальному агенту максимальные права.

[Источник](https://habr.com/ru/companies/selectel/articles/1087524/)