Codex снова забыл про импорты? Даём ему память на SQLite за 20 минут

Если вы работаете с Codex дольше одного чата, вы уже знаете этот сценарий: объяснил правила в понедельник, во вторник объясняешь снова, в среду хочется повесить табличку на монитор. Hermes Codex Plugin решает именно это — без векторных баз, без облака, без отдельного демона.

Почему длинный промпт — это не память, а чемодан без колёсиков

Стандартный способ дать агенту контекст — вставить всё руками: архитектура, правила, примеры из прошлых чатов, список команд. Работает. Но дорого и нестабильно.

У Codex есть особенность: он работает в цикле. Прочитал запрос — подумал — вызвал инструмент — получил вывод — снова подумал — полез в файл — запустил тесты. Чем длиннее тред, тем больше истории тащится рядом с задачей. В итоге три проблемы:

• Дорого — лишний контекст считается в токенах, даже если он нерелевантен.
• Шумно — модель читает много лишнего и может упустить важное.
• Нестабильно — ключевое правило тонет в старых сообщениях.

Идея Hermes простая: не нести весь чемодан, а вытащить из него только отвёртку, которая нужна прямо сейчас.

Что внутри Hermes Codex Plugin

Hermes — это локальный плагин для Codex, который добавляет долговременную память через четыре механизма:

1. Сохранение контекста — правила проекта, архитектурные решения, summaries задач, повторяемые workflow.
2. Поиск перед задачей — когда приходит новый запрос, плагин ищет релевантные правила и прошлые решения по локальной базе.
3. Инъекция маленького фрагмента — не весь старый чат на 20 000 токенов, а пара абзацев по теме.
4. Накопление — после задачи сохраняется компактное summary, которое работает в следующий раз.

Стек намеренно минималистичный: SQLite + FTS5 (встроенный полнотекстовый поиск SQLite) + MCP tools (Model Context Protocol — стандарт для подключения инструментов к агентам) + хуки Codex. Никаких embedding-сервисов, никакого Pinecone, никаких дополнительных процессов.

Данные хранятся локально в SQLite и Markdown-файлах — в облако ничего не уходит. Это важно, если у вас в проекте чувствительные архитектурные решения или NDA.

Установка и первый запуск

Ниже — базовый путь подключения плагина к Codex. Точные команды берите из репозитория Hermes, здесь показана логика.

Шаг 1. Клонируем репозиторий и ставим зависимости

``bash git clone https://github.com/your-org/hermes-codex-plugin cd hermes-codex-plugin npm install ``

Шаг 2. Инициализируем локальную базу

``bash npm run init-db ``

Это создаёт hermes.db — SQLite-файл с таблицами для правил, summaries и workflow. FTS5-индекс поднимается автоматически.

Шаг 3. Подключаем MCP-сервер к Codex

В конфиге Codex добавляем Hermes как MCP-инструмент:

``json { "mcpServers": { "hermes": { "command": "node", "args": ["./hermes-codex-plugin/server.js"], "env": { "HERMES_DB_PATH": "./hermes.db" } } } } ``

Шаг 4. Добавляем хуки в AGENTS.md

Чтобы Codex автоматически обращался к памяти до и после задачи, прописываем инструкцию:

```markdown

Hooks

```

• Before each task: call hermes_recall with the task description
• After each task: call hermes_save with a compact summary of decisions made

После этого Codex при каждом новом запросе сначала спросит у Hermes, что он помнит по теме, и только потом начнёт работу.

Как сохранять правила вручную

Автоматика — хорошо, но первый слой памяти лучше заполнить руками. Hermes предоставляет MCP-инструмент hermes_save с несколькими типами записей.

Пример сохранения правила проекта:

``json { "tool": "hermes_save", "type": "rule", "content": "Permission checks should be represented as reusable specifications. The same rule must support in-memory checks and SQL filtering.", "tags": ["permissions", "architecture"] } ``

Пример сохранения прошлого решения:

``json { "tool": "hermes_save", "type": "decision", "content": "Chose repository pattern over active record because of testability requirements in the payments module.", "tags": ["payments", "architecture", "testing"] } ``

Через несколько задач база наполняется сама — Codex сохраняет summaries автоматически через хук hermes_save.

Как выглядит поиск в момент задачи

Когда вы пишете Codex новый запрос, плагин вызывает hermes_recall:

``json { "tool": "hermes_recall", "query": "add permission check to the new endpoint" } ``

FTS5 ищет по всем сохранённым записям и возвращает релевантные фрагменты. Codex получает что-то вроде:

`` Relevant memory: [rule] Permission checks should be represented as reusable specifications. [decision] In payments module, permission logic lives in the application layer, not in controllers. [workflow] Run npm test -- --filter=permissions before committing permission-related changes. ``

Это 3-4 строки вместо 40 пунктов в промпте. Токены экономятся, правила не тонут в шуме.

Где ломается

FTS5 — не семантический поиск. Если вы написали правило про «спецификации прав», а запрос содержит «авторизация», совпадения может не быть. Решение: добавляйте синонимы в теги при сохранении.

Качество summaries зависит от модели. Если Codex сохраняет слишком общие summaries («сделал задачу»), память быстро засоряется. Стоит добавить в AGENTS.md требование к формату: что именно должно быть в summary.

База растёт бесконтрольно. Через несколько месяцев активной работы hermes.db может раздуться. Периодически чистите устаревшие записи вручную или настройте TTL на уровне таблицы.

Память общая для агентов. Если вы используете Claude Code или Cursor параллельно с Codex, они видят ту же базу. Это фича, но может стать проблемой, если агенты сохраняют противоречивые решения.

Что попробовать дальше

• Настроить разные базы для разных проектов через переменную HERMES_DB_PATH — чтобы правила одного репозитория не смешивались с другим.
• Добавить экспорт памяти в Markdown для ревью командой: полезно, когда нужно показать коллегам, что агент «знает» о проекте.
• Попробовать гибридный поиск: FTS5 для точных совпадений + простой TF-IDF поверх SQLite для более мягкого ранжирования — без внешних зависимостей.

Источники

• Habr AI: Codex жрёт контекст? Я дал ему локальную память на SQLite — и перестал кормить его простынями промптов