"Context rot: тихая болезнь AI-агентов, о которой мало говорят"

Представьте: вы наняли команду. Каждый утром приходит на работу и забывает, что делал вчера. Не полностью — какие-то обрывки остаются. Но ключевые решения, договорённости, контекст проекта — стёрты.

Именно так работает большинство мультиагентных систем через пару недель. Это называется context rot.

AI-агенты работают в рамках контекстного окна. У Claude это 200K токенов, у GPT-4 — 128K. Звучит много, но при долгосрочных задачах окно переполняется. Старая информация вытесняется новой. Агент «забывает».

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

Типичный подход — файл общей памяти. Каждый агент пишет туда заметки, каждый читает перед работой.

Проблемы: - Файл растёт линейно, за месяц — нечитаемая простыня - Нет связей между фактами — агент не знает, что решение X влияет на модуль Y - Нет приоритетов — архитектурное решение и дебаг-лог имеют одинаковый вес - Два агента пишут одновременно — данные теряются

На Reddit появился проект Memory Bank — единый memory layer для мультиагентных систем на графовой структуре. Вместо плоского файла — граф знаний, где:

- Узлы — факты, решения, сущности - Рёбра — связи (причинно-следственные, временные) - Каждый узел имеет score релевантности, который обновляется динамически - При запросе агент получает не «всю память», а компактный подграф по теме

Ключевая фича — cross-agent propagation. Когда один агент обновляет граф, другие видят изменения автоматически при следующем обращении к памяти.

Мы переходим от «один агент решает задачу» к «команда агентов работает над проектом». Это другая парадигма — и она требует другой инфраструктуры памяти.

Три принципа, которые вытекают из этого подхода:

1. **Память должна быть структурированной**, а не плоской. Связи между фактами — не роскошь, а необходимость.

2. **Память должна быть общей**, но с разграничением доступа. Единая точка истины, но агент пишет только в свой домен.

3. **Память должна быть активной** — сама определять, что релевантно для конкретного запроса, а не сваливать всё на агента.

Даже без графовой БД можно минимизировать context rot:

- Классифицируйте записи памяти по типу (permanent / operational / ephemeral) - Добавляйте явные ссылки между связанными решениями - Не заставляйте агента читать всю память — дайте ему query-интерфейс - Мониторьте противоречия: если агент делает что-то вопреки ранее зафиксированному решению — это красный флаг

Context rot — проблема архитектуры, не модели. И решается она на уровне архитектуры.

А как вы решаете проблему памяти в своих агентных системах? Flat файлы, RAG, или уже что-то графовое?