Claude и Opencode собрали автономного терминального агента на локальной машине
Эксперимент показал, что терминальный агент можно собрать так, чтобы он работал без привязки к внешним сервисам и помогал с задачами разработки на локальном компьютере. В основе проекта — перенос Opencode в Emacs Lisp, хранение артефактов в RDF-хранилище и пошаговая проверка сгенерированного кода.
Зачем вообще понадобился такой эксперимент
Автора интересовал простой практический вопрос: можно ли на машине с 12 ГБ видеопамяти заставить компактную LLM уровня 8 млрд параметров решать задачи разработки почти на уровне куда более крупных моделей. Для этого выбрали не закрытый сервис, а открытый и гибкий терминальный агент, который можно дорабатывать под свои сценарии.
В качестве базы взяли Opencode в состоянии на конец апреля 2026 года и решили не делать обычный форк на Go, а перенести проект в Emacs Lisp. Такой вариант удобен тем, что Emacs сам по себе открыт, умеет работать в разных средах, а его Lisp-экосистема позволяет строить инструментальные вызовы без лишней завязки на shell.
Как устроили прототип и что в него добавили
Чтобы эксперимент не повредил файлы пользователя, и исходный Opencode, и будущий порт запускались в Docker-контейнерах. На практике тестировали разные доступные модели, включая семейства minimax, deepseek, mimo, glm и nemotron, а саму миграцию сначала выполнил тот же Opencode, который проанализировал свою кодовую базу и предложил план переноса.
Прототип сделали минимально рабочим: он был рассчитан не на весь проект целиком, а на отдельные задачи. По ходу работы стало понятно, что агенту нужна собственная память не только для сессий, но и для промежуточных артефактов разработки. Для этого выбрали OWL/RDF triplestore с SPARQL endpoint на Apache Jena Fuseki и расширениями для поиска по смыслу, а это дало ещё и возможность делиться частью решений между агентами через федеративные запросы.
Что получилось после сотен итераций
Через полгода после старта автор получил рабочий сценарий, который прошёл почти 500 итераций и закрыл около 2000 задач. Когда пользователь пишет задачу в чат, прототип сначала понимает, новая это задача или продолжение старой, затем создаёт набор связанных сущностей в хранилище и сохраняет исходную формулировку.
Дальше включается процесс в виде конечного автомата: система переходит по состояниям, генерирует код, проверяет его и при необходимости ищет в хранилище похожие функции, чтобы уменьшить число выдуманных вызовов. Это полезно на практике, потому что модель получает не только запрос, но и список реально существующих решений из прошлых задач. В итоге получается более приземлённый рабочий инструмент для локальной разработки, где часть рутины можно отдать агенту без зависимости от облачных сервисов.