Кодинг-агент Codex умеет читать проект, менять код, запускать тесты и делать ревью — но у него нет памяти между сессиями. Каждый новый чат начинается с нуля: разработчику приходится снова объяснять, где должны лежать проверки прав, какие импорты считаются нормальными, какие старые решения уже признаны плохими. Это не просто раздражает — это прямые расходы токенов на повторение того, что по смыслу должно быть памятью агента.
Проблема усугубляется тем, что Codex работает в цикле: прочитал запрос → подумал → вызвал инструмент → получил вывод → снова подумал → полез в файл → запустил тесты. Чем длиннее тред, тем больше накопленной истории едет рядом с задачей. Длинный промпт с правилами проекта в этой схеме — не память, а «чемодан без колёсиков»: его можно тащить с собой, но он дорог, шумит нерелевантным содержимым и важное правило рискует утонуть в старых сообщениях.
| Проблема длинного промпта | Что происходит |
|---|---|
| Дорого | Лишний контекст всё равно считается в токенах |
| Шумно | Модель читает много нерелевантного содержимого |
| Нестабильно | Важное правило может утонуть в старых сообщениях |
Hermes Codex Plugin решает задачу иначе. Плагин сохраняет в локальную SQLite-базу пользовательские правила, архитектурные решения, краткие summaries задач и повторяемые workflow — не весь чат целиком, а выжимку вида «Permission checks should be represented as reusable specifications». Перед каждым новым запросом плагин ищет в базе релевантные записи и подкладывает в контекст Codex небольшой фрагмент — например, напоминание о том, что логика прав живёт в specification-объектах, а инфраструктурный слой транслирует её в SQL-предикаты. Вместо 20 тысяч токенов истории агент получает ровно то, что нужно для текущей задачи.
Для поиска используется полнотекстовый движок FTS5; если он недоступен — fallback через LIKE.
Для поиска используется полнотекстовый движок FTS5, встроенный в SQLite; если он недоступен в конкретной сборке — автоматический fallback через LIKE. Автор намеренно отказался от векторных баз, embedding-сервисов и семантического поиска. Большинство правил проекта — конкретные короткие формулировки вроде «imports at top», «run unit tests», «do not keep alias modules» — для них лексический поиск работает достаточно хорошо. Дополнительный бонус: если агент что-то вспомнил, можно открыть базу и проверить, откуда взялась эта запись.
Четвёртая функция плагина — помощь в оформлении повторяющихся правил в SKILL.md-файлы. Если одно и то же ограничение всплывает в нескольких задачах подряд, это сигнал: правило переросло статус memory entry и заслуживает отдельного переиспользуемого workflow. Hermes подсказывает, когда пора сделать этот шаг.
Подход вписывается в более широкую дискуссию об архитектуре памяти для ИИ-агентов. Большинство production-решений — LangChain Memory, Mem0, различные RAG-пайплайны — предполагают внешний embedding-сервис и векторное хранилище. Это оправдано при больших объёмах и необходимости семантического поиска по неструктурированному тексту. Но для одного разработчика или небольшой команды такая инфраструктура избыточна: она добавляет зависимости, стоимость индексации и сложность отладки. Hermes занимает нишу «достаточно хорошей» памяти, которую можно поднять без дополнительных сервисов и которая остаётся полностью локальной и inspectable.