Память, планирование и мультиагентность

Контекстное окно — это вся «оперативная память» агента, и она конечна. Чем длиннее задача, тем острее вопрос: что держать в контексте, что выносить наружу и когда вместо одного агента запускать несколько. Это главные темы инженерии агентов после базового цикла.

Интуиция

Представь, что решаешь большую задачу, а все заметки можно вести только на одной доске фиксированного размера. Сначала места полно. Потом доска забивается логами и черновиками, важное тонет в шуме, а новые записи вытесняют старые. Что делает разумный человек? Стирает отработанное, оставляя короткое резюме; ведёт отдельный блокнот, куда выносит важное; а большие независимые куски отдаёт коллеге с его собственной чистой доской. Ровно эти три приёма — компакция, внешняя память и субагенты — и составляют управление памятью агента.

Как это работает

Контекст — рабочая память (working memory). В окно контекста попадает всё: системный промпт, план, вызовы инструментов и их результаты. Окно конечно, и хуже того — качество деградирует ещё до переполнения: модель хуже пользуется информацией из середины длинного контекста (эффект «lost in the middle»). Практические тактики:

• Компакция (compaction) / суммаризация. Старые сообщения — особенно многословные результаты инструментов — сжимаются в короткое резюме. История «100 токенов логов» превращается в «тесты падали из-за импорта, исправлено» за 10 токенов.
• Заметки во внешние файлы (scratchpad). Агент пишет важное в файл вне контекста: находки, решения, todo. Файл переживает любую компакцию и переполнение — это долговременная память.
• Выборочная подгрузка. Вместо того чтобы таскать всю историю, агент по мере надобности подтягивает нужные фрагменты своих заметок — по сути это RAG по собственной истории.

Планирование. Для сложной задачи план полезно материализовать как артефакт — todo-список в контексте или файле. Он фиксирует декомпозицию, переживает компакцию и позволяет заметить дрейф: если агент давно делает не то, что в плане, — что-то пошло не так.

Мультиагентность. Оркестратор (orchestrator) раздаёт подзадачи субагентам (subagents). Главный профит: у каждого субагента свой чистый контекст — он может прочитать двадцать файлов, перепробовать пять гипотез, и весь этот шум останется у него; оркестратору вернётся только короткий результат. Отсюда паттерны: параллельный fan-out на независимые подзадачи, вертикальные роли (исполнитель, ревьюер, критик). Цена: потеря информации на передаче (субагент не знает всего диалога), больше токенов суммарно, сложнее отладка. Поэтому для простой линейной задачи, влезающей в один контекст, мультиагентность — оверинжиниринг.

Что держать в контексте, а что выносить

Хорошая эвристика — три яруса. Всегда в окне: системный промпт, текущий план, последние наблюдения. Сжато: давняя история — в виде резюме после компакции. Снаружи: объёмные артефакты (логи, дампы, промежуточные документы) — в файлах, откуда агент подгружает нужное. Симптом нарушения ярусов: агент «забывает» договорённости из начала сессии — значит, важное попало под компакцию, вместо того чтобы жить в плане или scratchpad.

Когда включать мультиагентность

Сигналы «за»: подзадачи независимы и их можно исполнять параллельно (fan-out: «проверь эти 5 модулей»); подзадача порождает много шума, который не нужен наверху (глубокий поиск по кодовой базе); нужна независимая перспектива (ревьюер, который не видел рассуждений автора и потому не заражён его ошибками). Сигналы «против»: задача короткая и линейная; подзадачи плотно связаны общим состоянием — тогда передача контекста между агентами съест весь выигрыш и добавит ошибок на «испорченном телефоне».