Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Сводки длинной истории могут сбивать LLM-агента: компрессор записывает собственный план рядом с фактами, а агент затем исполняет его как установленное состояние. Работа University of Virginia показывает рост доли задач, успешно решённых во всех повторных запусках, на 2,1–8,9 процентного пункта после удаления таких записей; препринт не рецензирован, а числа получили сами авторы. Для существующей системы это означает, что повысить надёжность можно без замены агента и компрессора.
Почему план в сводке превращается в факт
Долгие задачи постепенно заполняют контекст действиями агента, ответами инструментов, ошибками и промежуточными результатами. Когда история перестаёт помещаться, отдельный компрессор заменяет старую часть контекста короткой структурированной сводкой. Агент продолжает работу, используя её как память.
Проблема появляется, когда сводка описывает не только произошедшее, но и будущие действия. Из изученных запросов к компрессорам 21 из 29 требовал записывать решения или следующие шаги. После сжатия агент уже не видит, где закончился ответ среды и началось рассуждение компрессора.
Особенно часто это происходило в разделах с незавершённой работой: 67,7% таких записей не опирались ни на ответы среды, ни на предыдущую сводку. В разборе неудачных запусков 29 из 35 ошибок начались с действия, которое агент выполнил по конкретной записи из сводки.
Один пример показывает механизм ошибки. Пользователь попросил скопировать дневник привычек, указав, что в этот день не медитировал. Компрессор превратил это в решение удалить строку о медитации, хотя формат дневника требовал оставить привычку и отметить отрицательный ответ. После сжатия агент принял это решение за установленный факт и удалил строку.
Такие записи нельзя убрать один раз при настройке запроса. Компрессор заново рассуждает о дальнейших действиях на каждой границе сжатия, поэтому неподтверждённые планы возвращаются в следующих сводках.
Как SJC отделяет наблюдения от рассуждений
Source-Judged Compaction, или SJC, работает после обычного компрессора. Метод не создаёт новую сводку и не исправляет её формулировки. Он либо сохраняет запись без изменений, либо удаляет её целиком.
Сначала SJC делит структурированную сводку на отдельные записи, сохраняя заголовки разделов. Затем для каждой записи ищет подходящие фрагменты среди ответов инструментов и среды. Эти фрагменты объединяются в сокращённый набор доказательств, поэтому проверяющей модели не приходится читать всю историю.
Классификатор Jev получает записи, найденные доказательства и предыдущую принятую сводку. Для каждой записи он возвращает вероятность того, что информация пришла из ответа среды или уже подтверждённой памяти. Это именно проверка происхождения: правдоподобный план без источника должен быть удалён, даже если он выглядит разумно.
Исходная инструкция остаётся в контексте агента, поэтому её пересказ не считают источником для сводки. Такой пересказ не нужен для памяти и может незаметно изменить смысл ограничения. Напротив, идентификаторы, результаты вызовов инструментов и наблюдаемое состояние обычно проходят проверку.
Все записи проверяются одним запросом к Jev на каждой границе сжатия. Принятая версия становится памятью агента и основой для следующего сжатия. Так неподтверждённое решение не закрепляется в цепочке последующих сводок.
Когда команде стоит менять архитектуру агента
SJC проверили на AppWorld и OfficeBench с моделями GPT-5.6 Luna и MiniMax-M3. Во всех сочетаниях он повысил надёжность относительно обычной сводки, причём наибольший выигрыш пришёлся на сложные задачи и сценарии с несколькими приложениями. Расход токенов самого агента не вырос.
Метод подходит системам, где агент доступен только через API или его переобучение слишком дорого. Он не меняет модель агента, запрос компрессора и формат естественно-языковой памяти. Для внедрения нужны структурированные записи, сохранённые ответы среды и отдельный вызов Jev при каждом сжатии.
Работа не показывает, что любую агентную память следует фильтровать этим способом. Эксперименты охватывают один компрессор, а сжатие запускали при небольших окнах контекста, чтобы оно происходило внутри каждой задачи. Исходная инструкция во всех тестах оставалась видимой; в многоходовом диалоге ранние сообщения пользователя тоже придётся считать источниками, но такой режим не проверяли.
Проверка происхождения также не равна проверке правильности. Запись может точно ссылаться на реальный ответ инструмента, но делать из него ошибочный вывод — SJC её сохранит. В обратную сторону метод иногда удаляет полезный план, если тот появился только в рассуждении компрессора. Поэтому SJC закрывает конкретный класс ошибок: он не даёт неподтверждённым решениям маскироваться под состояние среды, но не заменяет проверку логики и результата действий.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
