Reflexion: как ошибка становится подсказкой для следующей попытки

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

После неудачи можно попросить агента попробовать ещё раз. Можно также сохранить конкретное объяснение ошибки и передать его следующей попытке. Reflexion исследует второй путь. Посмотрим, что именно меняется в этом цикле и почему убедительная рефлексия ещё не подтверждает исправление.

Основа разбора — Reflexion: Language Agents with Verbal Reinforcement Learning Noah Shinn и соавторов. Работа появилась в 2023 году; здесь используется v4 от 10 октября 2023 года. Ниже сначала описан механизм авторов, затем дан мой условный пример с обработкой дат. Пример и предлагаемые проверки не являются экспериментом из статьи.

Три роли в одной петле

В §3 Reflexion разделены исполнитель, оценка результата и текстовая рефлексия. Исполнитель действует, оценщик возвращает сигнал о результате, а модуль рефлексии формулирует, что стоит изменить. Эта запись входит в память и становится частью контекста следующей попытки. Параметры языковой модели не обновляются.

Сигнал может поступать из среды, заранее заданной проверки или самооценки модели. Эти источники не равнозначны по надёжности. История текущих действий и сохранённые выводы предыдущих попыток выполняют разные функции. В описанной реализации буфер выводов ограничен; это не бесконечный архив опыта.

Мой вывод: при разборе такой системы стоит отдельно смотреть на три перехода. Правильно ли определена неудача? Обоснованно ли объяснена её причина? Изменила ли запись следующее действие? Успех на одном переходе не подтверждает остальные.

Условная задача: разобрать дату в двух форматах

Представим учебную задачу для программирующего агента. Нужно написать функцию, которая принимает дату в одном из двух явно заданных форматов: 2026-10-16 или 16.10.2026. Другие форматы должны отклоняться. Дата должна существовать в календаре.

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

В нашем примере полезнее такая запись:

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

Это придуманный для разбора текст, а не цитата из Reflexion. Он связывает видимый сбой с конкретным изменением. Однако в нём остаётся гипотеза: именно такой способ исправления должен пройти проверку.

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

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

Запись, которую можно сопоставить с действием

Для практического применения я бы раскладывал рефлексию на четыре поля. Это моя форма работы с примером, не обязательная структура Reflexion.

Такая запись позволяет после новой попытки проверить не только итоговый ответ, но и связь с памятью. Агент действительно добавил нужную ветвь? Не расширил ли случайно перечень допустимых форматов? Осталась ли проверка календаря?

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

Кто оценивает оценщика

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

В этой ситуации добавление ещё одного размышления не гарантирует появления проверки 31.02.2026. Полезнее сначала посмотреть, какие требования покрывает проверка. Условия задачи и тесты должны оставаться различимыми: успешно выполненный тест подтверждает только то, что он проверяет.

В экспериментах Reflexion, §4, использовались разные области и способы обратной связи: текстовая среда действий, вопросы с поиском и программирование. Для программирования важно отличать тесты, доступные агенту во время попыток, от скрытых тестов итоговой оценки. Результат на них не превращает любую будущую самооценку в достоверный сигнал.

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

Где заканчивается одна задача

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

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

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

Как проверить пользу рефлексии

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

Для задачи с датами нужны несколько разных причин неудачи:

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

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

Авторы в §5 обсуждают ограниченную память и трудности проверки программ с недетерминированным поведением и внешними взаимодействиями. Это важная причина не переносить результат небольшого учебного примера на произвольную производственную задачу без собственной проверки.

Практическая ценность Reflexion для меня — в явном месте для обратной связи между попытками. Там можно увидеть, какое наблюдение превратилось в какой совет и что агент сделал после него. Качество этой связи нужно проверять по результату следующего действия.

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

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