Что такое context rot и почему агент «тупеет» на длинных задачах
Context rot - это падение точности и качества рассуждений у долгоживущих агентов, когда в контекстном окне скапливается больше инструкций, результатов вызовов инструментов и промежуточных данных, чем модель способна удержать. Проблема проявляется не на первом шаге, а на длинной задаче: агент стартует собранным и точным, а к середине работы начинает путаться, повторять пройденное или терять исходную цель.
Стоит разделять две вещи: качество модели и качество контекста. Модель не менялась, но её ответы деградируют. Причина в том, что внимание распределяется по всему содержимому окна, а не концентрируется на главном. Чем больше вокруг нерелевантного шума, тем сильнее размывается сигнал, который реально нужен для следующего шага.
Бытовая аналогия: представьте стол, за которым вы решаете задачу. Сначала на нём лежат нужные документы, и вы работаете быстро. К концу дня стол завален черновиками, распечатками и чужими записками. Исходный документ всё ещё на месте, но добираться до него каждый раз дороже. С агентом происходит то же самое, только роль мусора играют накопленные результаты инструментов и промежуточные файлы.
Особенно быстро это накапливается на многошаговых задачах. Возьмём агента конкурентного анализа: за один запуск он выгружает рыночные данные по компании A (десятки тысяч строк), ищет новости, читает статьи и пишет заметки, повторяет всё это для компаний B, C, D и E, а потом составляет черновик отчёта, дорабатывает его по обратной связи и форматирует. К четвёртому шагу в контексте уже лежат данные по пяти компаниям, и это только начало.
Здесь есть тонкость. Богатый контекст сам по себе помогает: чем больше релевантных данных на входе, тем связнее результат, что хорошо видно на разборе граундинга и привязки генерации к входным данным. Вред приносит не объём как таковой, а доля нерелевантного. Именно поэтому борьба с context rot не сводится к «запихнуть поменьше», важно управлять составом окна.
Почему «просто больше контекста» не работает
Логика «окно большое, значит, влезет всё» не выдерживает проверки. Увеличение окна отодвигает момент, когда данные перестают помещаться, но не отменяет деградацию. Нерелевантные фрагменты продолжают конкурировать за внимание, и точность падает даже при формально свободном месте.
Окно - это лимит, а не гарантия качества. Можно иметь миллион доступных токенов и при этом получать ответы хуже, чем от модели с коротким окном, если половина длинного входа забита мусором. Задача звучит иначе: не расширить окно, а сделать так, чтобы в каждый момент в нём лежало именно нужное.
Две категории техник: предотвращать и управлять
Все приёмы против context rot делятся на две группы. Первая предотвращает попадание ненужной информации в окно: агент не тянет туда то, что не пригодится на следующем шаге. Вторая управляет тем, что уже оказалось в окне: фильтрует, сжимает, убирает в сторону.
Из пяти техник Deep Agents к первой группе ближе offloading, skills и subagents, они мешают лишнему войти. Суммаризация работает со второй категорией, сжимая накопленное. Долговременная память стоит особняком: она выводит знания за пределы окна и переносит их в следующие беседы. Само это разделение на категории и общий набор из пяти техник описывает LangChain в разборе контекст-инжиниринга для Deep Agents.
Deep Agents и харнесс: где именно живёт управление контекстом
Чтобы понять, откуда берутся эти техники, разложим агента на две части. Агент - это модель плюс харнесс вокруг неё. Харнесс обвязывает LLM: решает, что подать на вход, что сохранить, что выбросить в файл. Собственно «ум» живёт в модели, а дисциплина работы с контекстом - в харнессе.
Deep Agents - открытый харнесс агентов от LangChain. Он оборачивает выбранную модель и применяет техники контекст-инжиниринга, чтобы подсунуть ей правильный контекст в правильный момент. То, что модель подставляется снаружи, важно: техники не привязаны к конкретной LLM, их можно нести на разных провайдерах.
LangChain развивает харнесс итеративно, и не только в сторону контекста длинных бесед. В версии v0.7 удалось срезать входные токены примерно на 65%, с ~6k до ~2k, и отдать разработчикам контроль над промптами и стеком middleware. Это те же принципы, только применённые к стартовой обвязке, а не к накопленной истории (разбор Deep Agents v0.7).
Middleware: код в точках жизненного цикла агента
Техники не живут в промпте абстрактно. Они попадают в запуск агента через middleware - код, который встраивается в точки жизненного цикла: перед запуском, вокруг вызова модели, вокруг вызова инструмента. Каждая точка даёт возможность вмешаться в поток.
Что именно делает middleware:
- перед вызовом модели подменяет большое сообщение на превью, оставляя полный текст в файловой системе;
- вокруг вызова инструмента перехватывает результат и решает, что положить в окно, а что сохранить на диск;
- перед запуском подгружает нужные инструкции (skills) или память из хранилища.
Точные сигнатуры и порядок хуков стоит смотреть в документации пакета. Для понимания темы важна сама механика: middleware врезается в жизненный цикл и меняет то, что видит модель, не трогая её саму.
Пять техник управления контекстом в Deep Agents
Сначала короткая карта, затем разбор каждой техники. Пять приёмов решают одну задачу: вывести контекст из активного окна, не удаляя его. Разница в том, что именно выводится и в какой момент.
- Offloading - крупные результаты инструментов и сообщения уходят в файлы, модель видит превью.
- Summarization - старые сообщения сжимаются в сводку при подходе к лимиту окна.
- Skills - инструкции подгружаются только когда модель решит, что они релевантны.
- Subagents - шумная работа идёт в отдельном окне, обратно возвращается результат.
- Long-term memory - знания агента сохраняются в файл и переносятся в следующую беседу.
Offloading: крупные результаты - в файлы, модели только превью
Инструмент вернул десятки тысяч строк рыночных данных или длинный лог. Тянуть всё это в окно бессмысленно: агенту нужен вывод, а не сырьё. Offloading сохраняет крупные результаты инструментов и пользовательские сообщения в файловую систему, а модель получает только превью.
Ключевое отличие от усечения: данные остаются восстановимыми. Если на следующем шаге понадобится полный файл, агент может к нему вернуться, а не довольствоваться обрезком. Техника относится к категории «предотвращать»: в окно лишнее просто не попадает. Пример: инструмент отдал большой JSON, в контекст уходит короткая выжимка, а полный файл лежит на диске и ждёт, когда его прочитают.
Summarization: сжатие старых сообщений при подходе к лимиту
Второй сценарий: окно почти заполнено, а задача не закончена. Суммаризация сжимает старые сообщения в сводку, когда разговор приближается к лимиту контекста. Модель продолжает работу, но вместо всего диалога видит его сжатую версию.
Здесь речь идёт про управление тем, что уже в окне, а не про предотвращение. Плюс в обратимости: сохранённая история остаётся, и к исходным сообщениям можно вернуться, в отличие от безвозвратного удаления. Конкретные алгоритмы сжатия харнесс может менять, но принцип один - сжать, а не стереть.
Skills: инструкции подгружаются только когда релевантны
Держать в окне все инструкции сразу расточительно. Skills загружают знания о задаче только тогда, когда модель решит, что они релевантны. Это прогрессивное раскрытие: инструкции лежат рядом в виде файлов, но в активное окно попадает лишь тот набор, который нужен для текущего шага.
Пример: у агента есть десяток skills под разные типы отчётов, а в контекст попадает только тот, что отвечает за текущий формат. LangChain развивает механизм и в сторону привязки инструментов к навыкам: схемы инструментов не попадают в контекст, пока агент не прочитает соответствующий навык, а на моделях Anthropic и OpenAI добавление инструментов в середине диалога не ломает кэш промпта (разбор привязки инструментов к навыкам).
Subagents: шумная работа - в отдельном контексте
Часть работы по своей природе шумная: перебор вариантов, чтение множества файлов, десятки вызовов инструментов. Тянуть всё это в основной контекст - верный способ его забить. Subagents выполняют такую работу в отдельном контекстном окне, и обратно возвращается только результат.
Основной агент видит итог, а не процесс. Это изоляция шума: дочерний контекст живёт своей жизнью и закрывается вместе с подзадачей. Техника работает сразу в двух направлениях: шум не долетает до главной линии, а дочерняя сессия не тянет за собой лишние детали.
Long-term memory: знания агента в обычном markdown-файле
Всё, что агент выяснил, часто теряется вместе с беседой. Долговременная память сохраняет узнанное в файл, который переносится в следующую беседу. По данным LangChain, память хранится как обычные файлы в хранилище, которое контролирует пользователь, а не вендор (описание подхода).
Практическое следствие: можно менять модель или провайдера, сохраняя всё, чему агент научился. Для тех, кто работает с локальными LLM, это особенно ценно: контролируемое хранилище снимает привязку к конкретному сервису, а накопленные знания остаются читаемыми markdown-файлами. Похожую задачу решает проект, который выносит состояние проекта в отдельный слой поверх моделей и агентов (разбор Later Bender).
Почему это лучше усечения и удаления: восстановимость и обратимость
Грубые методы работы с контекстом, обрезать хвост диалога или удалить старые сообщения, решают проблему объёма ценой потери данных. Данные исчезают, и агенту негде их взять, если они понадобятся позже.
Подход Deep Agents устроен иначе. Offloading оставляет полный результат в файловой системе, поэтому данные восстановимы: агент может вернуться к исходному файлу в любой момент. Суммаризация обратима через сохранённую историю: сводка заменяет старые сообщения в активном окне, но сами сообщения никуда не пропадают. Память вынесена в контролируемое хранилище, то есть в обычные файлы, которые переживают смену модели.
Практический сценарий: вы обновили модель или перешли на другого провайдера. При удалении контекста агент начал бы с нуля, а здесь память и накопленные файлы остаются на месте. Это снимает одну из главных болей долгоживущих агентов - привязку к вендору. Переход на зарубежного провайдера иногда упирается в оплату: если локальная карта не проходит, подписку закрывают виртуальной картой зарубежного банка (вариант с дистанционным выпуском и пополнением в рублях).
Ограничения и когда техники могут быть избыточны
Техники не бесплатны. Они добавляют сложность и оверхед: нужно хранилище для файлов, нужны middleware, нужно продумывать пороги и правила. Для коротких задач, где окно даже близко не заполняется, всё это может быть избыточным. Простой запрос без истории не выиграет от offloading и subagents, а кода и конфигурации станет больше.
- Offloading и subagents усложняют отладку: часть состояния уходит в файлы и дочерние контексты, и проследить, почему агент принял решение, труднее.
- Суммаризация может терять детали, если сводка сделана неаккуратно. Сжатие всегда компромисс между объёмом и точностью.
- Хранилище нужно где-то держать и обслуживать, а память в файлах требует дисциплины, чтобы не превратиться в свалку.
Категоричных рекомендаций тут нет. Выбор зависит от длины задач, доступного хранилища и требований к воспроизводимости. Если задача укладывается в одно окно и не повторяется, техники можно не трогать. Если агент живёт неделями и накапливает знания, они окупаются.
Общие принципы контекст-инжиниринга и настройка порогов
Соберём принципы, которые переносятся с Deep Agents на любую агентную систему.
- Предотвращать попадание ненужной информации в окно. Не тянуть в контекст то, что не пригодится на следующем шаге.
- Управлять тем, что уже в окне. Фильтровать, сжимать, убирать в сторону, когда контекст растёт.
- Выводить контекст из активного окна, не удаляя его. Данные должны оставаться доступными, а не исчезать без следа.
- Хранить память в контролируемом хранилище. Обычные файлы переживают смену модели и провайдера.
Отдельно про пороги. Дефолты - это отправная точка, а не истина. Порог срабатывания суммаризации, размер превью при offloading, критерии, по которым модель выбирает skills, зависят от задачи. Для агента, который генерирует длинные отчёты, превью можно делать короче и суммаризацию включать агрессивнее. Для агента, который работает с точными числами, лучше сохранять больше исходных данных и реже сжимать, чтобы не потерять детали.
Контекст-инжиниринг - это не разовая настройка, а часть проектирования агента. Разумный старт: взять одну технику, измерить эффект на своей задаче, затем добавлять следующую. Offloading обычно даёт самый предсказуемый выигрыш там, где инструменты возвращают много данных; память в markdown-файле - на длинных сериях бесед. Дальше работает измерение, а не вера в дефолтные значения.