Локальная память для Codex на SQLite: как создать плагин Hermes для постоянных правил проекта

Сколько раз вы писали агенту «пожалуйста, используй snake_case» и через три запроса получали camelCase? Или просили не трогать файл config.yaml, а он его перезаписывал? Проблема известная: контекстное окно — как оперативная память. Выключил диалог — всё забыл. Даже в 2026 году с контекстом под 2 млн токенов деградация контекста никуда не делась.

Разработчики из сообщества Hermes (не путать с Hermes MCP — это другой зверь) выпустили плагин для Codex, который решает это раз и навсегда. Никаких облаков, никаких векторных баз — только SQLite, файл .hermes.db в корне проекта и чёткие правила, которые агент читает при каждом новом витке. Давайте разберём, как это работает и почему это лучше, чем тащить с собой PDF с гайдлайнами.

«Умри, но запомни»: как Hermes чинит проклятие контекста

Большинство AI-агентов живут одним дыханием. Вы дали задачу — он выполнил. Но стоит прервать сессию или просто загрузить новый диалог — агент начинает с чистого листа. Плагины Codex 2026 года частично решили проблему интеграцией с GitHub Issues и Wiki, но это внешние источники. А если правила живут только в голове у разработчика?

Hermes подходит иначе. Он не лезет в облако — он просто создаёт SQLite-файл прямо в проекте. В этом файле — таблица rules с колонками id, pattern (правило на естественном языке), category и priority. Каждый раз, когда Codex готовится выполнить действие, плагин подгружает правила с приоритетом >= текущего запроса. Никакого RAG, никаких эмбеддингов — только сырой SQL.

Две строчки, которые меняют всё

Сперва посмотрим, как НЕ надо делать. Типичный провал — пихать правила в системный промпт:

> Напиши мне Makefile, но сначала правило: не используй .PHONY, я ненавижу .PHONY.
> (через 5 запросов) Агент снова сгенерировал .PHONY.

Агент просто забыл, потому что промпт уехал за горизонт внимания. Теперь правильный путь — записать правило один раз в Hermes.

from hermes_codex import HermesDB

db = HermesDB(".hermes.db")
db.add_rule(
    pattern="Never use .PHONY in Makefile. All targets must be real files.",
    category="build",
    priority=10
)

После этого любой вызов инструмента write_file, который попытается записать Makefile с .PHONY, будет заблокирован плагином. Агент получит сообщение: «Rule violation: Never use .PHONY in Makefile».

Архитектура: ничего лишнего

Hermes состоит из трёх частей:

• SQLite-хранилище — файл .hermes.db в корне проекта. Схема:

CREATE TABLE rules (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    pattern TEXT NOT NULL,
    category TEXT DEFAULT 'general',
    priority INTEGER DEFAULT 5,
    created_at TEXT DEFAULT (datetime('now')),
    enabled INTEGER DEFAULT 1
);

• Перехватчик инструментов — использует механизм плагинов Codex (хук before_invoke). Когда агент вызывает, скажем, edit_file, плагин загружает все активные правила с приоритетом >= 5 и проверяет, не конфликтует ли запрос с ними. Если конфликт — кидает исключение.
• CLI-утилита hermesctl — для добавления, удаления и выгрузки правил без кода.

Сравнение с альтернативами

Hermes берёт на себя только правила — он не пытается индексировать всю кодовую базу (как Code-memory) и не требует запуска отдельного сервера (как Neo4j). Это его «киллер-фича» — ноль инфраструктуры.

Пример из жизни: обуздать Legacy

Допустим, у вас проект на выдохшемся Django, где миграции генерируются makemigrations, и нельзя трогать файлы migrations/*.py вручную. Классическая задача для агента — при каждом рефакторинге он норовит пересоздать миграцию. Hermes решает это одной командой:

hermesctl add "Do NOT modify migration files in migrations/ directory manually. Only via manage.py makemigrations" --category "django" --priority 9

Теперь агент, даже если вы попросите «добавить поле в модель и создать миграцию», получит блокировку на редактирование файла миграции. Он будет вынужден предложить другой путь — например, написать скрипт, который запускает makemigrations. Или вы явно снимете правило.

Ещё один сценарий — стиль кода. Записываете: «Все SQL-запросы должны использовать namedtuple cursor, а не словари». И агент перестаёт генерировать cursor.fetchall() с возвратом dict. Без Hermes это правило пришлось бы повторять в каждом запросе. Деградация контекста отступает, когда правила живут отдельно.

Кому это нужно (и кому нет)

Идеально для:

• Команд, где Codex работает над одним репозиторием — единый файл правил синхронизируется через Git (да, .hermes.db можно коммитить, он весит копейки).
• Одиночек, которые устали повторять одни и те же указания агенту.
• Проектов с жёсткими код-стайл гайдами (банковский и медицинский софт).

Не подойдёт, если:

• У вас проект-однодневка — проще скопировать промпт.
• Нужна семантическая память (агент должен «вспомнить» разговор): тогда лучше Neo4j или унифицированная память.
• Правила очень динамичные (меняются каждые 10 минут) — тогда админка Hermes пока сыровата, проще пихать в промпт.

Неочевидный совет напоследок

Не записывайте в Hermes больше 20-30 правил. Когда их становится слишком много, агент начинает банально тормозить — каждое действие проверяется против всех правил (да, SQLite быстрый, но цикл по правилам в Python не бесплатный). Плюс, агент может впасть в ступор, если два правила конфликтуют («не используй `os.system`» vs «используй только `os.system` для shell»). Лучше группируйте правила по категориям и отключайте ненужные через hermesctl disable. И ещё: не верьте, что Hermes заменит ревью кода. Он только ловит явные нарушения, но не понимает семантику. Так что код-ревью всё ещё за вами. Хотя, чёрт возьми, как же приятно, когда агент хотя бы не лепит табы вместо пробелов.

Подписаться на канал