Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Языкового агента научили после ошибки менять не только следующее действие, но и тот уровень плана, на котором возникла проблема. В препринте, который не прошёл рецензирование и содержит замеры самих авторов, новый контроллер повысил долю выполненных заданий в AppWorld на 22,07 процентного пункта относительно ReAct. Для агентных систем это практический способ сократить циклы из повторных вызовов инструмента, если задача зависит от скрытых предварительных условий.
План хранится как стек целей
Обычный агент на основе ReAct чередует рассуждение, действие и наблюдение. История показывает, что произошло, но явно не связывает конечную задачу, текущую подзадачу и причину сбоя. Поэтому после ошибки модель часто выбирает ещё одно правдоподобное действие на том же неверном уровне.
Verify–Backtrack Loop, или VBL, добавляет к ReAct ограниченный стек целей. Внизу лежит исходное поручение, наверху — активная цель. Каждый элемент хранит описание подзадачи, ссылку на родительскую цель, счётчики ошибок и повторов, а также уже предложенные предварительные условия.
Контроллер проверяет активную цель по двум признакам. Сначала он определяет, приближает ли она к конечному результату. Затем выясняет, можно ли выполнить её в текущем состоянии среды. Разделение важно: полезная подзадача может быть пока недоступна, а выполнимая — уводить в сторону.
Проверка запускается при выборе новой цели, после ошибки и после существенного изменения среды. Если цель уже достигнута, контроллер снимает её со стека. Если не хватает условия, добавляет его сверху как новую подзадачу. Если декомпозиция оказалась неверной, удаляет её ветку и возвращается к родительской цели.
После нескольких неудач отдельный модуль определяет тип причины: отсутствует предварительное условие, выбран неверный план, произошёл временный сбой или продолжать по этому пути нельзя. Причина сразу превращается в одну операцию: добавить подзадачу, повторить действие или вернуться к родителю. Свободное текстовое рассуждение здесь заменяет небольшой набор переходов состояния.
Откат меняет план, но не состояние внешней системы. Уже отправленный запрос, созданную запись или платёж контроллер не отменяет. После возврата агент продолжает работу с текущим наблюдением, поэтому для необратимых операций по-прежнему нужны проверки на уровне приложения.
Добавление условия полезнее слепого повтора
VBL проверили с Qwen3.5-9B, GPT-4o и DeepSeek-V3.2 на AppWorld, ALFWorld и ScienceWorld. Внутри каждого сравнения сохраняли ту же базовую модель, интерфейс среды и бюджет взаимодействия. Контроллер обошёл ReAct и ReflAct во всех сочетаниях моделей и наборов заданий; максимальный прирост относительно ReAct составил 14,21 процентного пункта в ScienceWorld и 10,45 пункта в ALFWorld.
Показательный эпизод AppWorld требовал рассчитаться за общий ужин через Venmo. После ответа HTTP 401 базовые агенты продолжали вызывать защищённые методы, пробовали неверные параметры входа и тратили шаги на документацию. VBL распознал авторизацию как предварительное условие, поместил вход в сервис на вершину стека и только после получения токенов вернулся к платежам.
Чаще всего контроллер именно добавлял недостающую подзадачу, а не отбрасывал весь план. На более сложных заданиях AppWorld откат к родителю встречался чаще, что соответствует другой причине ошибок: агент не пропустил отдельный шаг, а неверно разложил исходную задачу.
Удаление любого из двух механизмов ухудшало результат во всех проверенных сочетаниях. В нескольких случаях стек только с проверкой или только с диагностикой работал хуже обычного ReAct. Само иерархическое хранение целей пользы не гарантирует: ему нужны и ранняя проверка условий, и разбор повторяющихся сбоев.
Командам стоит менять контроллер, а не базовую модель
Работа не требует дополнительного обучения модели. VBL можно рассматривать как слой управления вокруг существующего исполнителя: стек хранит план, проверяющий модуль решает, готова ли текущая цель, диагностический модуль выбирает переход, а исполнитель получает исходное поручение и активную подзадачу.
Такой подход подходит агентам, которые вызывают API, меняют внешнее состояние и сталкиваются с зависимостями, не указанными в пользовательском запросе. Типичные случаи — обязательная авторизация, создание ресурса перед его изменением, получение идентификатора перед следующим вызовом или подготовка объекта перед конечной операцией.
Менять архитектуру особенно разумно, если журналы показывают повтор одного и того же неудачного действия или длинные цепочки после первой ошибки. Вместо новых подсказок для очередного шага система получает явное состояние процесса: конечную цель, активную цель, недостающее условие и точку возврата.
Цена этого контроля зависит от среды. Проверки, диагностика и краткие сводки добавляют вызовы модели: в сложном AppWorld расход токенов на эпизод вырос примерно вдвое, хотя на одно успешное выполнение он снизился. В ScienceWorld накладные расходы, напротив, росли быстрее доли успеха. Поэтому такой контроллер стоит оценивать не только по выполненным заданиям, но и по токенам на успешный результат.
Проверяли один путь внутри одного эпизода, а не поиск по дереву вариантов или память между заданиями. Кроме того, проверку готовности и причин ошибок выполняет та же базовая модель: неверная оценка может испортить стек. Для продукта это не замена защите от повторных операций и подтверждению опасных действий, а более строгий способ управлять восстановлением между ними.
Источники
Иллюстрация: рисунок из статьи «Verify--Backtrack Loop: Structured Precondition Recovery for Long-Horizon Language Agents», Mingyang Liu, Qingcan Kang, Shixiong Kai и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
