Я вырезал стандартную память Markdown в OpenClaw и создал API-слой на Node.js/Postgres

Разработчик, создающий когнитивный анализатор продуктивности на OpenClaw, столкнулся с проблемой при использовании файла MEMORY.md по умолчанию после нескольких недель работы. Плоский текстовый файл превратился в генератор галлюцинаций — агент вспоминал устаревшие проекты API как истинные и забывал согласованные компромиссы системы. Решение: отключить плагин memory-core и построить детерминированный уровень принуждения.

Детали архитектуры

• База данных: PostgreSQL со строгими схемами для system_architecture_rules, api_design_decisions и feature_roadmaps.
• Промежуточный слой: Бэкенд на Node.js/Express, доступный OpenClaw через пользовательские вызовы инструментов.
• Типизированные контракты: Агент должен выполнять POST /memory/architecture с JSON-нагрузкой, проверенной TypeScript, чтобы записать архитектурные решения или маршруты API.
• Неизменяемая инъекция контекста: При запросе инструментальный слой извлекает точные строки из Postgres и внедряет их в контекстное окно до того, как агент начнет рассуждение.

Результаты

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

Вывод

Разработчик утверждает, что память агента — это не проблема хранения, а проблема проектирования API. Принуждение LLM категоризировать мысли через строгие границы инструментов предотвращает повреждение состояния на сотнях итераций. Рассматривается возможность открыть исходный код Node-репозитория.