Рассмотрев особенности мышления закрытого (нет) Claude Code, рассмотрим наиболее популярный среди реально открытых OpenCode (далее — OC).
Оффтопиком сразу стоит отметить, что это один из агентов, в которых предпринята попытка оптимизации промптов и параметров моделей под конкретные семейства.
В основе цикла рассуждений лежит всё тот же классический ReAct. Каких-либо принципиальных отличительных особенностей, которые стоило бы отметить, нет. А вот реализация Plan & Execute заслуживает внимания. Режим планирования здесь реализован, как отдельный агент
plan с мультиагентным воркфлоу:1️⃣ Initial Understanding — агент запускает до 3-х
explore суб-агентов параллельно для исследования кодовой базы, задаёт уточняющие вопросы пользователю.2️⃣ Design — запускает
general суб-агента для проектирования плана реализации на основе собранного контекста.3️⃣ Review — читает релевантные файлы, сверяет план с запросом.
4️⃣ Final Plan — записывает план в специальный файл.
5️⃣ Exit — вызывает инструмент
plan_exit для передачи плана обратно в build агент.Мультиагентная архитектура реализована через делегирование. Основной агент порождает специализированных суб-агентов, каждый из которых работает в изолированной сессии со своей историей сообщений. Агенты описываются через Zod-схему (мордоровский аналог Pydantic).
Ключевые свойства:
mode (является ли агент пользовательским "primary", вспомогательным "subagent" или обоими "all"), permission (набор правил, контролирующих доступ к инструментам через glob-паттерны),
model (опциональная привязка к конкретной модели),
steps (максимальное число итераций цикла),
prompt (кастомный системный промпт, заменяющий стандартный).Есть возможность определять собственных агентов , а также программно генерировать конфигурацию нового агента через LLM с помощью мета-промпта.
Для работы с кодом OC не использует RAG и векторные/формальные модели кода, отдавая это на откуп внешним MCP. Вместо этого применяется обычный поиск через обертки для ripgrep, glob, нечеткий поиск по именам файлов, и ± стандартные файловые тулы.
Организация памяти также заслуживает внимания:
1️⃣ История сообщений сессии. Каждая сессия хранит полную цепочку сообщений в SQLite. При каждой итерации ReAct, в
runLoop() загружаются все сообщения сессии. Модель видит всё — каждый предыдущий шаг ReAct, каждый вызов инструмента и его результат, до тех пор, пока контекстное окно не переполнится.2️⃣ Сжатая память. Когда контекстное окно переполняется, запускается двухфазный процесс сжатия. Сначала система проходит по истории и вычищает содержимое результатов инструментов, оставляя лишь 40К «свежих» токенов. Затем агент
compaction генерирует структурированное резюме по шаблону: цель, инструкции, находки, выполненная работа, релевантные файлы. В дальнейшем, вместо полной истории используется только это резюме — аналог «эпизодической памяти», сжатый пересказ предыдущего опыта, из которого агент может продолжить работу.3️⃣ История дочерних сессий. У суб-агентов своя изолированная история сообщений — они не видит истории родителя и друг-друга, только тот промпт, который им передали. Результаты сжимаются до текстового ответа и возвращаются в историю родительской сессии как результат тулкола.
4️⃣ Список задач. Инструмент
todowrite сохраняет список задач в SQLite-таблицу TodoTable сессии, который потом передается между итерациями ReAct основного агента.5️⃣ Сохранённый полный вывод инструментов. Когда вывод инструмента превышает 2К строк или 50 КБ,
truncate сохраняет полный текст в файл ~/.opencode/tool-output/<id> на 7 дней. Агенту возвращается усечённая версия плюс подсказка: делегировать explore суб-агенту обработку полного файла. Это «внешняя память», вынесенная за пределы контекстного окна, но доступная через явное действие.✨
Из подходов Claude Code и OpenCode уже может быть очевиден принцип: чем проще инструмент внутри, тем он популярнее. На самом деле, так оно и есть. Но о причинах мы ещё поговорим, чуть позже 😉
#агенты #гайд