Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Код-агента научили восстанавливать ход долгой задачи так, чтобы он не принимал старые тесты и наблюдения за актуальные после изменений в репозитории. MemTrace прибавил 21,2 процентного пункта к доле задач DeepSWE, решённых с первой попытки. Работа пока не рецензирована, а числа получили сами авторы; для команд, которые строят многошаговых агентов, память теперь стоит рассматривать как проверяемое состояние, а не архив сообщений.
Как память связывают с изменениями в коде
Обычная внешняя память сохраняет сообщения, результаты команд и сводки, а затем ищет среди них подходящий фрагмент. Этого недостаточно, когда агент уже изменил код: прежняя ошибка могла исчезнуть, успешный тест — потерять силу, а старое решение — уступить место новой реализации.
MemTrace делит выполненную работу на неизменяемые записи. В запись попадают само свидетельство, состояние репозитория на момент его получения и ссылки на связанные файлы, символы и тесты. Исправление не переписывает старую запись, а создаёт новую и явно отмечает, что она уточняет, проверяет или заменяет прежнюю.
Такие записи образуют граф истории выполнения. Его связи показывают порядок действий и отношения между диагнозом, правкой, проверкой и последующим исправлением. Поэтому после очистки контекста агент восстанавливает не просто последовательность сообщений, а текущую границу работы: что уже завершено, что осталось нерешённым и какие выводы были отменены.
Второй граф описывает актуальный репозиторий: файлы, символы, тесты, импорты, вызовы и связи тестов с кодом. Общие ссылки соединяют его с историей выполнения. Так агент может найти записи, относящиеся к нужной функции или тесту, даже если их полный текст уже убрали из активного контекста.
В контексте остаются короткие якоря и сводки, а полные записи лежат во внешнем хранилище. Перед восстановлением MemTrace сверяет условия, при которых появилось свидетельство, с текущим кодом. Для результата теста проверяется не только целевая функция, но и записанные зависимости; если условия изменились или их нельзя подтвердить, агент читает код заново либо повторно запускает тест.
Согласованность оказалась важнее простого хранения
Метод проверяли на DeepSWE, SWE-EVO и SWE-Milestone через Codex CLI и mini-swe-agent. Эти наборы охватывают задачи уровня репозитория, последовательное развитие программ и работу по этапам. Внутри каждого сравнения сохраняли одну базовую модель и тот же каркас агента, поэтому менялся прежде всего способ работы с памятью.
В Codex CLI доля полностью решённых задач SWE-EVO выросла на 4,4 процентного пункта, а оценка пройденных этапов SWE-Milestone — на 17,8 пункта. Улучшение проявилось именно в завершении всей задачи: высокая доля применимых исправлений сама по себе не гарантировала, что агент доведёт последовательность изменений до рабочего результата.
Причину видно в истории запусков: у 57% записей, связанных с файлами, хотя бы один из этих файлов позднее менялся. Значит, сохранённое наблюдение часто переживает состояние кода, для которого оно было верным. Извлечение по сходству может вернуть такой фрагмент, но не определит, можно ли ему ещё доверять.
Разбор компонентов подтверждает разницу между архивом и согласованной памятью. На DeepSWE плоское хранилище записей получило 32,1%, а полный вариант с графом выполнения и графом репозитория — 56,6%. Особенно заметно помогло связывание истории с кодом в широких задачах, где агент переходил между разными файлами, символами и тестами.
Когда эту схему стоит закладывать в архитектуру агента
Работа меняет планы команд, если агент должен переживать очистку контекста, координировать правки в нескольких файлах и многократно возвращаться к тестам. Увеличить окно контекста или добавить поиск по истории в таком сценарии недостаточно: оба подхода помогают найти старый факт, но не подтверждают его применимость.
Практическая схема памяти складывается из нескольких правил:
- Хранить происхождение свидетельства. Результат команды, теста или чтения кода нужно связывать с файлами, символами и состоянием репозитория, в котором он появился.
- Не переписывать историю. Новая проверка или правка создаёт отдельную запись и указывает, что она подтверждает, исправляет либо заменяет.
- Проверять данные при восстановлении. Перед возвратом в контекст запись должна пройти сверку с текущим кодом и незавершённой частью задачи.
- Разделять хранение и активный контекст. Полная история может оставаться во внешнем хранилище, а модель получает только данные, нужные для следующего действия.
Это отдельный архитектурный рычаг, а не ещё один повод сразу менять базовую модель: прирост получен при одинаковой модели и каркасе внутри сравнений. Сначала можно проверить, теряет ли агент состояние после сжатия контекста, повторяет ли отменённые действия и использует ли результаты тестов после изменения зависимостей.
Эксперименты охватывают долгие задачи внутри одного запуска и восстановление после обновления контекста. Работу в одном репозитории через несколько отдельных задач и сессий авторы оставляют следующим этапом, поэтому для постоянного автономного разработчика потребуется дополнительная проверка этой архитектуры.
Источники
Иллюстрация: рисунок из статьи «MemTrace: State-Consistent Memory for Long-Horizon Coding Agents», Hongming Xu, Le Zhou, ZhongHe Jin и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
