Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Передачу незавершённой задачи между агентами научились выполнять без перезапуска: новый агент сохраняет принятые решения и завершает только остаток. Хотя препринт не рецензирован и числа получили сами авторы, команда Nanjing University и Singapore Management University показала, что CFRC сохраняет качество сильной модели при 22,0–34,6% её затрат на вывод. Для каскадов это превращает передачу контекста из подсказки модели в проверяемый протокол перед доступом к рабочим инструментам.
Контракт отделяет завершённую работу от оставшихся обязательств
Обычная передача истории диалога не определяет, что новый агент обязан сохранить. Он может повторить необратимое действие, пересмотреть подтверждённый выбор или объявить задачу выполненной, забыв последний шаг.
Авторы показывают проблему на оплате счёта. Первый агент выбрал счёт, получил подтверждение пользователя и провёл платёж, но не отправил квитанцию. Преемник не должен выбирать другой счёт или платить повторно: ему остаётся отправить документ, проверить доставку и только после этого сообщить об успехе.
CFRC сначала строит замороженный контракт из исходного запроса, принятой истории, достигнутого состояния, подтверждений инструментов и их публичных схем. В контракт входят подтверждённые пользователем значения, уже выполненные действия, доступные сущности и незакрытые обязательства. Преемник не может переписать этот контракт своим планом, поэтому пропущенное им действие не исчезает из цели.
Такой контракт отличается от пересказа истории. Фраза «счёт оплачен» помогает модели понять контекст, но не запрещает второй платёж и не требует отправить квитанцию. Контракт отдельно фиксирует защищённый эффект оплаты, допустимые следующие действия и свидетельство, которое подтвердит доставку.
На структурированных задачах обязательства извлекают по запросу и схемам инструментов. В диалоговых задачах их выделяет отдельный запрос к модели, после чего результат связывают с доступными интерфейсами и подтверждёнными сущностями. Поэтому полнота всей схемы зависит от того, попало ли каждое смысловое обязательство в контракт.
Полный план проверяют до первой записи
После фиксации контракта сильная модель составляет не следующий шаг, а весь оставшийся план. Если среду можно копировать, агент работает в изолированной копии и видит результаты пробных вызовов, не меняя рабочее состояние. В остальных случаях он использует уже полученные подтверждения и символические зависимости между будущими вызовами.
План превращается в граф без циклов: узлы содержат вызовы инструментов и итоговый ответ, а связи показывают зависимости данных и доказательств. Например, проверка доставки ссылается не на пробный идентификатор отправки, а на поле подтверждения, которое вернёт реальный вызов. При исполнении система подставляет значение из рабочего результата.
Перед доступом к записи CFRC проверяет граф целиком. Он отклоняет план, если тот не покрывает обязательство, повторяет защищённый эффект, использует неподтверждённую сущность или не показывает происхождение аргумента. Это отличает метод от пошагового фильтра: локальная проверка способна остановить плохой вызов, но не замечает действие, которого вообще нет в плане.
После допуска система исполняет узлы по порядку и собирает новые подтверждения от рабочих инструментов. Пробные результаты не засчитываются, а финальный ответ разрешается только после закрытия всех обязательств. Если доказательств недостаточно, CFRC прекращает работу без заявления об успехе.
Архитектуру каскада придётся менять, маршрутизатор — не обязательно
Метод проверили в пяти средах для работы с инструментами: от диалоговых сценариев до задач с изменяемым состоянием. Для пары GPT-5.4-mini/GPT-5.5 средний результат CFRC составил 70,8% против 69,6% у сильной модели, которая выполняла задачу целиком. Затраты считали как расходы поставщика на вызовы агентов без эффекта кэширования; вызовы симуляторов и оценщиков не включали.
Работа меняет планы команд, которые уже строят каскад из дешёвой и сильной модели вокруг необратимых действий. Одной передачи диалога недостаточно: оркестратору понадобятся структурированные подтверждения инструментов, адаптеры их схем, отдельное представление обязательств и запрет рабочих записей до проверки полного остатка.
Изолированная копия среды полезна, но не обязательна. Если её нельзя создать, граф можно собрать из текущих подтверждений и зависимостей, не выполняя новые изменяющие вызовы. Это делает подход применимым к платёжным, почтовым и административным API, где пробное действие само создаёт внешний эффект.
Результаты пока не дают основания заменять существующую маршрутизацию: CFRC изучает одну передачу от дешёвой модели к сильной и не выбирает момент переключения. Его формальная гарантия также относится к записанному контракту, а исходную задачу покрывает только полный контракт. При проверке построения контрактов система нашла 62 из 68 обязательств с устойчивой записью; пропуски возникали у неявных обновлений без названной сущности.
Практический вывод уже конкретен: если агент может списать деньги, отправить сообщение или изменить запись, передача управления должна работать как продолжение транзакции, а не как новый запрос с длинной историей. Начинать внедрение стоит со схем подтверждений и реестра открытых обязательств — без них сильная модель всё равно будет восстанавливать состояние по тексту и иногда повторять уже сделанное.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
