ReasoningBank: как агент превращает ошибки в правила работы

16 октября 2026 · 7 минут чтения

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

Мне интересен следующий шаг: сохранить небольшое правило, которое меняет начало следующей работы. Например: «Если ошибка зависит от даты, сначала проверь источник времени и часовой пояс». У такого правила есть шанс пережить переименование файлов и смену библиотеки.

Этой задаче посвящена работа Сиру Оуян, Цзюнь Яня и соавторов ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory. Ниже — самостоятельный разбор версии v2 от 16 марта 2026 года, с моим условным примером и предложением проверок. Первая версия вышла 29 сентября 2025 года. Карточка исследования.

Что именно попадает в память

В ReasoningBank опыт превращается в записи с заголовком, кратким описанием и содержанием урока. Перед новой задачей система ищет похожие прежние запросы и помещает связанные записи в контекст — доступную модели информацию. После выполнения языковая модель оценивает успех или неудачу и извлекает новые уроки. Исходные запросы и траектории действий также сохраняются. В базовой реализации новые записи просто добавляются: слияние и забывание не реализованы как полноценная политика. §3.2 и приложение A.2.

Дальше я рассмотрю этот механизм на вымышленной задаче разработки. Ситуация, тексты записей и критерии проверки придуманы для объяснения; это не кейс из экспериментов авторов.

Первая задача: найти причину ошибки даты

Пусть агент разработки исправляет приложение библиотеки. Оно должно показывать срок возврата книги, но тест иногда получает соседнюю дату. Разработчик сообщает, что на его компьютере всё проходит, а на сервере проверки — нет.

В первой попытке агент меняет ожидаемую строку теста. Проверка проходит в одном окружении. Затем он запускает её с другим часовым поясом и снова получает ошибку. В журнале уже есть полезное различие: одинаковые данные дают разные результаты в зависимости от окружения. Оно позволяет сформулировать проверяемую гипотезу о работе со временем.

Допустим, этот запуск завершён, и модуль оценки признаёт его неудачным. Извлекатель уроков может записать: «При расхождении календарных дат проверь, какое время используется при преобразовании; сравни результаты в нескольких часовых поясах до изменения ожидаемого ответа». Это существенно полезнее заметки «в тесте возврата книги возникла ошибка».

В нашем примере задачу запускают заново: агент явно задаёт часовой пояс и проходит выбранные проверки. Из неё можно извлечь дополнительный урок: «Отделяй момент времени от календарной даты, которую показывает приложение». Здесь переносится вопрос для диагностики. Конкретное исправление по-прежнему зависит от требований программы.

Я бы сохранил вместе с уроком основание: какая проверка обнаружила расхождение и при каких входных данных. Это моя рекомендация к рабочей системе. Она помогает позднее отличить наблюдение от объяснения, которое модель сочинила уже после удачного результата.

Следующая задача показывает ценность записи

Через неделю агент получает другую ошибку: в отчёте по посещаемости события около полуночи попадают не в тот день. В названиях файлов нет ничего про книги или возвраты. Повторить прежнюю последовательность правок почти невозможно.

Однако извлечённый урок может изменить порядок действий. Агент сначала выяснит, по какому часовому поясу должен строиться отчёт, затем сравнит границы суток с форматом хранимых событий. Даже если причина окажется другой, стартовая проверка будет осмысленной.

Слабая запись здесь тоже быстро обнаружится. Совет «всегда переводить даты в UTC» может противоречить требованию показывать местный календарный день. Чем шире сформулирован урок, тем важнее сохранить условие его применения. Короткая фраза без условия легко превращает частное исправление в универсальный рецепт.

Для такого переноса я предложил бы проверять две вещи отдельно. Сначала — нашлась ли подходящая запись. Затем — повлияла ли она на нужное действие. Найденный текст, который агент прочитал и проигнорировал, ещё не объясняет улучшение результата. А полезное действие, выполненное и без памяти, нельзя автоматически записывать в её заслугу.

Самооценка может закрепить неверное объяснение

В механизме ReasoningBank оценку исхода даёт модель без эталонного ответа. Итоговые исследовательские метрики при этом считают по правилам контрольных наборов задач. Это разные проверки. Авторы отдельно рассматривают шум оценки и признают зависимость от её качества. §5 и приложение E.

В нашем примере агент мог остановиться после первого зелёного теста. Тогда память получила бы совсем другой урок: «При расхождении даты исправляй ожидаемую строку». Он звучит конкретно и основан на реальном запуске, но скрывает непроверенное предположение о причине.

Поэтому я бы сопоставлял самооценку с проверками, которые агент не выбирал под свою правку. Нужен случай с другим часовым поясом, соседней датой и входом около полуночи. Цель — выяснить, выдерживает ли объяснение изменение условий. Успешный повтор на тех же данных отвечает только на более узкий вопрос.

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

Больше опыта требует отдельной проверки

Авторы предлагают и расширение MaTTS: несколько попыток одной задачи сравниваются либо последовательно дорабатываются, чтобы обогатить уроки. Это дополнительный расход вычислений, отдельный от базового цикла памяти. §3.3.

В библиотечном примере несколько попыток могли бы проверить разные объяснения: формат даты, настройки окружения, ошибку фильтра. Но одинаковая слепая зона нескольких запусков останется слепой зоной. Согласие попыток особенно мало говорит о правильности, если они пользовались одним и тем же неполным тестом.

Накопление записей тоже нуждается в наблюдении. Если рядом лежат советы «используй UTC» и «сохраняй локальную дату», следующая задача должна дать достаточно условий, чтобы выбрать подходящий. Сам факт хранения обеих фраз ещё не разрешает противоречие. Для рабочей реализации я бы предусмотрел исправление и отзыв спорной записи с сохранением её происхождения. Это расширение моей предлагаемой системы, а не заявленная возможность базового ReasoningBank.

Как я проверял бы пользу на своём потоке задач

Исследование оценивает веб-задачи и исправление программного кода; перенос на конкретный проект требует собственной проверки. §4 и приложение B.

Для библиотеки я подготовил бы последовательность новых ошибок и сохранил порядок поступления. В каждой точке агент получает только память из уже завершённых задач. До начала испытания нужно зафиксировать модель, инструменты, лимит попыток и независимый способ проверки ответа.

Сравнил бы три режима: без памяти, с историей прошлых действий и с извлечёнными уроками. Полезно считать не только исправленные ошибки, но и обращения к инструментам, затраченное время, стоимость извлечения уроков и количество вредных советов. Так видна цена преимущества.

Особенно показательны задачи с похожими словами и другой причиной. Например, неверная дата из-за ошибочного фильтра должна проверить, способен ли агент отказаться от подсказки про часовой пояс. Ещё один набор должен менять названия сущностей, сохраняя проблему: это проверяет перенос содержания урока.

Я начал бы с небольшого банка записей, для каждой из которых можно восстановить исходный опыт. Решение расширять память принимал бы после ответа на практический вопрос: помогает ли она находить причину новой ошибки быстрее и точнее при сопоставимых затратах?

Все материалы по теме: «Организационная и агентская память».

Автор: Данил Письменный · Дата: 16 октября 2026