Рабочие агенты не должны напрямую записывать в память: паттерн «Куратор-агент»

В многокомпонентной архитектуре загрязнение общей памяти — знакомая проблема. Один разработчик на r/openclaw описывает паттерн, который направляет все записи в память через специального агента Memory Curator, не позволяя рабочим агентам напрямую записывать долговременные факты. Подход вдохновлен исследованиями транзактивной памяти организаций (Ren & Argote) и существующими системами памяти агентов, такими как MemGPT, MemoryBank, LEGOMem и Generative Agents.

Как работает паттерн Memory Curator

Рабочие агенты никогда не пишут в память. Вместо этого они генерируют структурированные события памяти с предложенной областью видимости и доказательствами. Агент Memory Curator проверяет, редактирует, дедуплицирует и распределяет каждое событие по одной из четырех областей или отбрасывает его.

Четыре области

• Память репозитория агента — долговременные проектные решения для одного агента (аналог индивидуальной специализированной памяти)
• Память команды агентов — межкомпонентные процедуры, стандарты передачи, правила безопасности (транзактивная командная память)
• Память проекта — текущее состояние, решения, риски для одного проекта
• Черновик сессии — временные наблюдения, которые, вероятно, не должны сохраняться (кратковременная рабочая память)

Схема события

События представлены JSON с тегами типа: fact, decision, preference, risk, procedure, hypothesis, а также ссылкой на доказательство и предложенной областью видимости. Куратор может изменить предложенную область и является единственным писателем в долговременные хранилища.

Открытые вопросы

Автор отмечает две проблемы:

1. Чрезмерная или недостаточная эмиссия — требование событий может заставить рабочих генерировать все подряд (перегрузка) или прекратить писать (потеря полезных наблюдений).
2. Точность распределения в масштабе — границы сессии и проекта размываются при длинных сессиях; границы проекта и команды размываются, когда урок обобщается.

Репозиторий: github.com/jeongmk522-netizen/agent_memory_curator_agent. Разработчик интересуется, кто-то ещё предварительно фильтрует записи или проводит последующую очистку, отмечая, что очистка позже проще, но загрязнение, вероятно, накапливается быстрее, чем удаляется.