# Полгода, 2000 задач и ни одной подписки: как один разработчик собрал автономного AI-агента на 8B модели
Каноническая страница: https://plainews.ru/posts/lokalnyj-terminal-agent-emacs-lisp-llm
Опубликовано: 2026-10-26T14:01:14.844Z

Разработчик за полгода построил суверенного терминального агента на Emacs Lisp и локальной LLM — 500 итераций, 2000 задач, ноль подписок.
Пока большинство спорит, какой облачный AI-инструмент лучше, автор под ником v1st на Habr провёл шестимесячный эксперимент в другую сторону: взял Opencode, мигрировал его на Emacs Lisp и получил терминального агента, который работает полностью локально. Видеокарта на 12 Гб, модель с 8 млрд параметров, контекст 32К — и никакой зависимости от внешних API.

## Зачем вообще отказываться от облака

Вопрос, который лежит в основе эксперимента, сформулирован жёстко: можно ли на локальной машине с GPU 12 Гб получить от компактной LLM (8B параметров) пользу, сопоставимую с моделями на 100B–1T параметров из облака? Не «похожую», а реально сопоставимую для задач разработки ПО.

Для проверки гипотезы нужен был агент с тремя свойствами: не привязан к конкретной модели, полностью открытый исходный код, достаточно гибкий для быстрых экспериментов. Claude Code и аналоги отпали сразу — закрытые. Opencode подошёл.

## Почему Opencode переписали на Emacs Lisp

Оригинальный Opencode написан преимущественно на Go. Вместо того чтобы форкать его и работать с чужой архитектурой, автор решил мигрировать кодовую базу на Emacs Lisp. Логика здесь не ностальгическая, а прагматичная — три причины в одном инструменте.

Emacs — это одновременно терминал с портами под разные платформы (включая Android через Termux), среда исполнения, где LLM может вызывать встроенные функции Emacs Lisp напрямую без обращения к shell, и экосистема с живыми репозиториями пакетов Elpa/Melpa. Для агента, которому нужен гибкий tool calling, это удобнее, чем городить обёртки поверх Go.

Сама миграция была выполнена с помощью того же Opencode: репозиторий склонировали локально, запустили экземпляр с моделью minimax m2.5 (на тот момент доступной бесплатно), попросили агента проанализировать собственную кодовую базу и предложить план переноса на Emacs Lisp. Агент задал уточняющие вопросы, предложил план — и выполнил его. MVP появился в конце апреля — начале мая 2026 года.

> **К сведению.** Оба приложения — оригинальный Opencode и его Emacs Lisp-порт — запускались в Docker-контейнерах. Это мера предосторожности, чтобы агент или сгенерированный им код не повредили файлы основной системы Ubuntu.

## Как агент хранит память и борется с галлюцинациями

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

В качестве хранилища выбрали OWL/RDF triplestore с SPARQL-эндпоинтом на базе Apache Jena Fuseki с расширениями Lucene/HNSW. Это не самый очевидный выбор, но у него есть конкретное преимущество: поддержка федеративных SPARQL-запросов. Проще говоря, если несколько агентов складывают решения в свои хранилища и часть из них публикуется, любой агент в сети может запросить эти решения стандартным запросом. Задел на мультиагентную архитектуру.

Галлюцинации — вызовы несуществующих функций — решаются на шаге верификации кода. Когда LLM генерирует функцию, прототип обращается в хранилище за списком реально существующих функций, семантически похожих на вызываемые. Этот список передаётся в контекст повторного запроса, и модель переписывает код с опорой на то, что действительно есть. Не идеально, но работает без дополнительных параметров или файн-тюнинга.

## Как выглядит типовая сессия

За полгода — почти 500 итераций и 2000 закрытых задач — сложился устойчивый рабочий сценарий. Вот как выглядит одна сессия в хронологии из статьи:

| Время (UTC) | Событие |
| --- | --- |
| 13:16:50 | Запуск прототипа, проверка состояния хранилища (тёплый старт или новая задача) |
| 13:16:59 | Пользователь формулирует задачу в чате |
| 13:17:25 | Агент классифицирует задачу, формирует структуру артефактов в хранилище, сохраняет формулировку |

Структура артефактов задачи описана как шаблон OWL/RDF/TTL-онтологии — её можно запросить через SPARQL прямо из хранилища. Это означает, что агент не держит контекст задачи только в памяти сессии: он материализует его в граф, к которому можно вернуться после перерыва.

## Что это значит для разработчика, который хочет попробовать

Эксперимент показывает: локальный суверенный агент — не теоретическая конструкция. При правильно выбранном стеке 8B-модель на потребительском GPU справляется с реальными задачами разработки. Правда, порог входа здесь выше, чем подключить Cursor или GitHub Copilot.

Нужно понимать Emacs Lisp хотя бы на базовом уровне, разобраться с Docker-окружением, поднять Apache Jena Fuseki и настроить SPARQL-эндпоинт. Это несколько часов работы, а не пятиминутная установка расширения в VS Code.

Зато результат — агент, который не отправляет ваш код в облако, не зависит от доступности API конкретного провайдера и накапливает знания о вашем проекте в структурированном локальном хранилище. Для задач, где конфиденциальность кода критична, или для работы в изолированных сетях — это реальная альтернатива, а не компромисс.

В ходе эксперимента также тестировались модели из семейств minimax, deepseek, mimo, glm, nemotron — агент изначально проектировался как не привязанный к конкретной модели, и это свойство оказалось полезным: можно переключаться между моделями без переработки логики агента.

## Источники

- Habr AI: Мастерим суверенного терминального агента из Opencode с помощью Opencode