Настройка OpenCode: безопасный ИИ-агент под ваши проекты за вечер

Вы в десятый раз вставляете в чат с моделью кусок документации, объясняете, как устроен проект, и просите не трогать то, что трогать нельзя. Модель отвечает толково, но на следующий день всё приходится повторять заново. К вашим файлам и трекеру она так и не получила доступа.

Разберемся, из чего состоит настройка OpenCode: какую модель подключить бесплатно, как ограничить права агента, куда положить правила проекта и когда добавлять skills и интеграции.

Цель на вечер – минимальная безопасная конфигурация на бесплатной модели и понятный план, что достраивать дальше.

Что такое OpenCode и чем он отличается от чата с LLM

OpenCode – это оболочка вокруг языковой модели. Внутри неё модель читает ваши файлы и инструкции, запускает локальные инструменты, обращается к API и MCP-серверам. Поэтому он полезен не только программистам: аналитик может дать агенту папку с документами и правила оформления, а менеджер – доступ к трекеру.

В обычном чате всё держится на том, что вы скопировали в окно. В OpenCode контекст, правила и инструменты лежат рядом с проектом и подхватываются при каждом запуске. Модель можно менять – рабочее пространство остаётся.

Отсюда главная мысль: результат определяет не столько модель, сколько то, что вы построили вокруг неё. Строить это лучше от малого. Не подключайте в первый же вечер MCP, несколько агентов и десяток skills. Соберите минимум, опробуйте его на настоящей задаче – и только потом расширяйте.

Схема простая: пять шагов именно в таком порядке – модель, права, правила проекта, skills, внешние системы.

Шаг 1. Бесплатные модели в OpenCode: подключение через Zen

Начать можно бесплатно. У OpenCode есть сервис Zen: после входа в него на октябрь 2026 года доступна бесплатная модель Muse Spark 1.3 Contributor Free – по условиям Zen, на ограниченное время. Для первого вечера этого достаточно – проверить, как агент читает проект и как работают права и правила, можно на ней.

Установите OpenCode, выберите эту модель в списке и проверьте связку запросом в папке проекта:

Прочитай README текущего проекта и кратко объясни, что делает этот сервис.

Ответил по делу – значит, модель подключена и видит проект.

Но важно: в обмен на бесплатный доступ разработчик модели может использовать ваши промпты и ответы для обучения своих будущих моделей. Рабочий и конфиденциальный код туда не отдавайте.

Бесплатная модель здесь не игрушечная. Она принимает на вход текст, изображения, видео и файлы, так что ей можно отдать, например, скриншот интерфейса.

Появится задача серьёзнее – модель можно сменить, остальная конфигурация останется прежней. Это ещё одна причина вкладываться в рабочее пространство, а не привязываться к конкретной модели.

Уровни мышления и лимиты бесплатной модели

У модели в OpenCode есть уровни мышления: от «минимального» через низкий, средний и высокий до «очень высокого». Режима Max, в котором разработчик приводил результаты модели на бенчмарках, у бесплатной версии на октябрь 2026 года нет. Поэтому цифры из анонсов на ваших задачах могут не повториться.

Для несложной работы самый высокий уровень не нужен: он расходует токены, а результат почти не меняется. Разумный старт – высокий уровень.

В одном тесте бесплатная модель отработала быстро: небольшую интерактивную 3D-сцену она собрала примерно за 1 минуту 48 секунд, а браузерную игру по длинному подробному промпту – за 6 минут 46 секунд, и бесплатного лимита на это хватило. Гарантии при этом нет: на большой задаче лимит может закончиться посередине. Запасной вариант – заранее подключить ту же модель через внешнего провайдера, например OpenRouter, и продолжить там уже платно. На конец сентября 2026 года платный доступ к обычной версии модели, не Contributor, стоил 1,25 доллара за миллион входящих токенов и 4,25 доллара – за миллион исходящих.

Кстати, сила модели неровная. С кодом она справлялась хорошо, а картинку в 3D-модель перенесла слабо. Проверяйте модель на своих типах задач, а не на чужих примерах.

Шаг 2. Права агента задаются технически

Самая частая ошибка новичков – написать в правилах «не делай push» и считать вопрос закрытым. Текстовую инструкцию модель в принципе может проигнорировать. Технический запрет на git push в настройках прав она обойти уже не сможет.

Поэтому права настраивают технически – в глобальном конфиге ~/.config/opencode/opencode.json, через раздел permission (разрешения агента). Минимум на первый вечер:

• режим ask («спрашивать») для правки файлов – агент спрашивает перед каждым изменением;
• режим ask и для shell-команд;
• запрет (deny) на опасные git-команды – commit и push;
• отключённый share ("share": "disabled" – отдельный ключ того же конфига) – функция, через которую сессией делятся по ссылке. Так сессию нельзя отдать наружу даже случайно.

Целиком такой конфиг выглядит так:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git status": "allow",
      "git diff *": "allow",
      "git commit *": "deny",
      "git push *": "deny"
    },
    "edit": "ask"
  },
  "share": "disabled"
}

Здесь edit – правка файлов, bash – shell-команды: любая команда идёт с вопросом, git status и git diff – без вопроса, commit и push запрещены.

С такими настройками OpenCode запрашивает ваше согласие, прежде чем что-то поменять в файлах или запустить команду. Поначалу это замедляет работу, зато вы видите, как агент действует, и через пару дней поймёте, что можно разрешить без вопросов.

Шаг 3. Глобальный конфиг и правила проекта в AGENTS.md

Правила для агента в OpenCode живут на двух уровнях настроек. Глобальный конфиг – то, что действует везде: подключённые модели, права, общее поведение. В папке проекта лежат его собственные правила, и главный файл для них – AGENTS.md.

AGENTS.md агент читает при работе с проектом: здесь описывают, как устроен проект, какие соглашения приняты и чего делать нельзя. Соблазн – переносить туда всё, что пришло в голову. Но чем длиннее файл, тем труднее держать его в актуальном состоянии и тем сложнее понять, какие правила действительно важны.

По общему правилу в AGENTS.md попадает только то, что верно почти всегда: не придумывать факты, перед изменением кода изучать существующую реализацию, при неоднозначной задаче задавать уточняющие вопросы, не делать commit, push и merge без разрешения. Разовые договорённости и длинные алгоритмы туда не кладите – для повторяющихся процедур есть skills.

Начните с пяти-десяти строк. Для старта хватит такого файла в корне проекта:

# Общие правила

- Не придумывай отсутствующие факты.
- Перед изменением кода сначала изучи существующую реализацию.
- Если задача неоднозначна — задай уточняющие вопросы.
- Не выполняй commit, push и merge без явного разрешения.
- После изменений перечисли затронутые файлы и возможные риски.

Если агент ошибся на реальной задаче из-за незнания, допишите правило. Так файл растёт из практики, а не из предположений.

Шаг 4. Skills в OpenCode: выносить повторяющееся, а не готовить заранее

Skill – это описание процедуры, которую агент подключает, когда она нужна. OpenCode находит их сам в папке .opencode/skills/<имя>/SKILL.md. У каждого skill обязательно есть name и description: по описанию агент решает, когда skill применить. Поэтому description пишут так, чтобы из него было понятно, к какой задаче он относится.

Например, skill для code review – файл .opencode/skills/code-review/SKILL.md:

---
name: code-review
description: Проверка изменений в коде на ошибки, регрессии и отсутствие тестов
---

# Code review

1. Изучи измененные файлы.
2. Проверь связанные вызовы и зависимости.
3. Найди возможные регрессии.
4. Проверь обработку ошибок.
5. Проверь наличие тестов.
6. Не предлагай изменения, не связанные с задачей.
7. В конце выведи найденные проблемы и рекомендации.

Создавать skill стоит тогда, когда вы второй-третий раз объясняете агенту один и тот же алгоритм. Готовить десяток skills заранее «на всякий случай» – та же ошибка, что и раздутый AGENTS.md: их трудно поддерживать, а агенту труднее выбрать нужный.

Практичный порядок такой. Когда задача решена вместе с агентом и видно, что подобное повторится, попросите его оформить процедуру в SKILL.md. На следующей похожей задаче проверьте, как он работает.

Шаг 5. MCP в OpenCode и внешние системы: когда REST-скрипт надёжнее

Когда агенту понадобится трекер или репозиторий, первое, что приходит в голову, – MCP-сервер. На самом деле это не всегда лучший путь.

Реальный случай: GitLab подключали к OpenCode через MCP-сервер. Сервер запускался, но описание инструментов, которое он отдавал, расходилось с форматом, нужным OpenCode, и интеграция так и не заработала. А штатный REST API GitLab справлялся со всем этим сам: находил проект, читал файлы, показывал структуру репозитория и README.

Правило выбора: если прямой запрос к API или небольшой скрипт на вашей машине справляются быстрее и надёжнее, выбирайте их и не усложняйте систему без причины.

Ключевые термины

• AGENTS.md – Файл с короткими правилами поведения агента, которые должны действовать почти всегда, – в корне проекта или в глобальной папке OpenCode.
• Skill – Описанный в файле SKILL.md повторяющийся алгоритм, который агент сам находит и применяет, ориентируясь на его name и description.
• MCP-сервер – Сервер по протоколу MCP, который отдаёт агенту набор инструментов для работы с внешней системой – трекером, репозиторием, базой знаний.
• Permissions – Настройки OpenCode, которые технически разрешают, запрещают или требуют подтверждения для действий агента – правки файлов, shell-команд, отдельных git-команд.
• Уровень мышления – Настройка того, сколько модель рассуждает перед ответом: выше уровень – больше расход токенов и времени.
• Global config – Общие для всех проектов настройки OpenCode в ~/.config/opencode: провайдеры, модели, разрешения, универсальные инструкции и skills.

Итог: план настройки OpenCode – вечер и дальше

Главное: OpenCode полезен не моделью, а рабочим пространством вокруг неё – вашими файлами, правилами, правами и инструментами. Строить его стоит от минимума и расширять, только когда реальная задача показала, чего не хватает. Права задавайте технически, правила проекта держите короткими, skills заводите по факту повторов, а интеграции начинайте с самого простого рабочего способа.

• Подключить бесплатную модель через Zen, уровень мышления – высокий
• Положить в ~/.config/opencode/opencode.json конфиг прав: ask для правки файлов и shell, deny для git commit и push, share отключён
• Написать короткий AGENTS.md для одного проекта
• Проверить связку на реальной задаче
• Вынести алгоритм в skill, когда объясняете его агенту второй-третий раз
• Подключить внешнюю систему, когда агенту не хватит данных, – начав с API или скрипта

Проверьте себя

1. Вы хотите, чтобы агент никогда не выполнял git push. Какой способ надёжнее?

• А. Запретить git push в permissions конфига OpenCode
• Б. Написать в AGENTS.md «Никогда не делай push»
• В. Напоминать об этом в каждом запросе

2. Агент уже неделю работает в проекте, и вы третий раз объясняете ему один и тот же порядок code review. Что разумнее сделать?

• А. Вынести алгоритм в skill в .opencode/skills/code-review/SKILL.md с name и description
• Б. Сразу создать десяток skills на все возможные случаи
• В. Дописать подробный алгоритм в AGENTS.md

3. MCP-сервер для вашего репозитория запускается, но OpenCode не принимает его список инструментов. При этом REST API покрывает все нужные операции. Что делать?

• А. Использовать REST API или локальный скрипт
• Б. Отказаться от подключения внешних систем вообще
• В. Писать обёртку и добиваться работы MCP любой ценой

4. Вы начали работать на бесплатной модели в OpenCode. Какие решения разумны? (Верных ответов несколько.)

• А. Отправлять в бесплатную облачную модель внутренний код компании, не сверяясь с правилами
• Б. Для несложной задачи выбрать высокий, а не самый высокий уровень мышления
• В. Считать, что раз модель хорошо пишет код, она так же хорошо справится с любой задачей
• Г. Держать запасной вариант на случай, если бесплатный лимит закончится

5. Что лучше положить в глобальный конфиг ~/.config/opencode, а не в папку проекта?

• А. Архитектурные ограничения конкретного сервиса
• Б. Команды сборки и тестов конкретного репозитория
• В. Провайдеров, модели и общие permissions