Мой блог
Создание автономного терминального агента из Opencode на Emacs Lisp
Современный этап развития больших языковых моделей и инструментов разработки ПО ставит вопрос о возможности создания локальных автономных систем. Эксперименты показывают, что в качестве основы для такого решения можно использовать терминальный агент из Opencode, адаптированный под конкретную среду разработки и локальные модели с небольшим количеством параметров.
В ходе полугодовой работы исходный код Opencode был перенесен на Emacs Lisp, что позволило получить гибкую платформу для локальных ИИ-задач без привязки к облачным сервисам и внешним API провайдерам.
Выбор технологического стека и подготовка базы
В качестве отправной точки был взят проект Opencode с открытым исходным кодом, опубликованный на GitHub. Вместо исходной версии на Go было принято решение выполнить миграцию приложения на Emacs Lisp. Выбор среды обусловлен тем, что Emacs представляет собой полноценную систему со множеством портов, встроенной средой выполнения и возможностью прямого вызова функций без обращения к внешней командной оболочке.
Для предотвращения возможных сбоев и защиты файловой системы хоста на базе Ubuntu Linux оба приложения запускались в изолированных контейнерах Docker. Процесс миграции выполнялся самим экземпляром Opencode с подключенной моделью minimax m2.5, который проанализировал собственную кодовую базу и сформировал план переноса на Emacs Lisp.
Архитектура памяти и верификация кода
Полученный прототип был дополнен специализированным хранилищем для сессий и артефактов разработки. В качестве основы выбрали платформу Apache Jena Fuseki с поддержкой OWL/RDF triplestore, SPARQL-эндпоинтов и расширений Lucene/HNSW. Такой подход обеспечивает не только структурированное хранение данных, но и возможность федеративных запросов для обмена информацией между агентами.
Для борьбы с галлюцинациями моделей при генерации кода используется механизм семантического поиска. Если языковая модель обращается к несуществующим функциям, система ищет похожие описания в хранилище и передает их в контекст для повторного запроса.
Типовой сценарий работы с терминальным агентом
Процесс выполнения задач организован в парадигме конечных автоматов, состояния которых описаны в виде OWL/RDF/TTL онтологий. Типичная итерация включает в себя несколько последовательных шагов от получения формулировки до финального тестирования.
Основные этапы обработки задач
После запуска агент проверяет состояние хранилища на предмет незавершенных процессов. Пользователь формирует задачу в окне чата, после чего система создает соответствующую структуру артефактов и инициирует генерацию чернового варианта кода.
На следующем шаге модель формирует список предположений и допущений, сохраняемый в файл requirements.md. После пользовательского ревью запускается создание спецификаций и написание тестов в файл tests.el. При обнаружении ошибок в тестах активируется отдельная цепочка доработок с автоматической проверкой байт-компиляции и самопроверкой.
Особенности генерации кода на Emacs Lisp
Практика показала, что генерация Lisp-кода вызывает трудности у большинства языковых моделей из-за обилия вложенных круглых скобок. Поскольку архитектура трансформеров ориентирована на последовательное прогнозирование токенов, модели нередко пропускают закрывающие элементы.
Подобные дефекты устраняются за счет дополнительных итераций агента, что увеличивает расход токенов. При тестировании локальных решений через Ollama лучшие результаты продемонстрировала модель ministral-3:8b, обеспечивающая стабильную скорость работы и реже остальных допускающая синтаксические ошибки при написании кода.
Заключение
Созданный прототип насчитывает около 22 тысяч строк кода на Emacs Lisp и функционирует в связке с локальным сервером Ollama и базой Apache Jena Fuseki. Хотя проект еще не способен полностью автономно модифицировать собственную кодовую базу, существующая инфраструктура позволяет последовательно развивать инструменты локальной автоматизации программирования.
