Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агента с внешними инструментами научили проходить зависимые цепочки действий, не обращаясь к модели после каждого ответа инструмента. Работу выпустил Ivan Matveev из Proxima Ultra; поскольку препринт не рецензирован, все числа в нём получены самим автором. На CAR-bench медианные два вызова модели обслужили семь раундов обмена, поэтому расходы и задержка перестают расти вровень с длиной цепочки.
Как программа переживает ответы инструментов
Обычный агент работает по схеме «получить состояние — выбрать следующее действие». Если второй вызов инструмента зависит от результата первого, модель приходится запускать заново. Параллельный запуск помогает только тогда, когда инструменты не зависят друг от друга.
В CAR-bench проблему усиливает устройство проверки. Инструменты выполняет не сам агент, а внешний оценщик: он получает запрос, меняет состояние среды и возвращает результат отдельным сообщением. Поэтому даже короткая зависимая цепочка распадается на несколько раундов.
Предложенная обвязка отделяет эти раунды от вызовов LLM. Модель выдаёт Python-программу, а постоянный рабочий процесс запускает её в интерпретаторе. Когда программа обращается к инструменту, мост приостанавливает текущий стек вызовов и отправляет официальный запрос оценщику.
После ответа мост передаёт результат прямо в заблокированный вызов. Программа продолжает работу с той же точки, может проверить данные, выбрать ветвь и обратиться к следующему инструменту. Модель подключается снова только тогда, когда программа завершилась, вернула ошибку или действительно потребовалось новое решение.
Независимые обращения программа объединяет в пакет, а зависимые описывает обычными условиями и циклами. Все действия при этом остаются видны оценщику: меняется не траектория инструментов, а число промежуточных запусков LLM.
Детерминированные правила переходят из промпта в код
Вторая часть подхода касается политик агента. Правила, которые однозначно следуют из известных фактов, автор переносит в обёртки инструментов. Модель по-прежнему определяет намерение пользователя, но не решает заново, можно ли включить дальний свет при работающих противотуманных фарах или требуется ли подтверждение действия.
Такая проверка срабатывает независимо от того, какое публичное имя инструмента выбрала модель. Для подтверждений среда хранит подготовленное действие и после ответа пользователя продолжает именно его. Обязательные предупреждения также регистрируются отдельно и добавляются к ответу, если модель их пропустила.
Среда нормализует результаты инструментов и заменяет неизвестные значения специальным маркером. Если с таким значением пытаются выполнить содержательную операцию, программа останавливает ветвь вместо того, чтобы достраивать отсутствующий факт. Ошибки изменяющих операций сохраняются до конца пользовательского хода, поэтому итоговый ответ не может объявить успех после неудачного действия.
Обвязку проверяли на публичном наборе из 125 задач и официальном скрытом наборе из 30 задач. CAR-bench моделирует автомобильного помощника с взаимосвязанными инструментами, неоднозначными запросами и намеренно пропущенными данными; в Track 2 использовали Cerebras gpt-oss-120b и сравнивали результат с другими заявками и базовой системой организаторов.
На скрытом наборе решение получило 60% по Pass3 — эта метрика засчитывает задачу, только если агент успешно проходит все повторные прогоны. Это в 4,5 раза выше базовой системы, а расчётная стоимость составила 0,041 доллара за прогон. Ту же обвязку без изменений перенесли на GPT-5.5 и получили прежний итоговый показатель, хотя распределение успешных задач изменилось.
Когда подход меняет архитектурный план
Работа меняет план системы, если агент сейчас вызывает LLM после каждого ответа API. Вместо цикла из коротких решений модель может один раз написать ветвящуюся программу, а оркестратор проведёт её через серию внешних обменов. На длинных зависимых цепочках это напрямую сокращает критический путь.
Перенос политик в код полезен там, где правила можно вычислить из состояния: проверять разрешения, обязательные поля, подтверждения, пределы операций и реакцию на отсутствующие данные. Промпт тогда отвечает за интерпретацию запроса, а код гарантирует соблюдение ограничений. Это также уменьшает риск, что правило потеряется среди каталога инструментов и истории диалога.
Статический промпт усиливает экономию. В этой реализации каталог инструментов и правила образуют неизменный префикс, а состояние задачи добавляется в конец. Провайдер может брать большую часть входа из кеша между вызовами и задачами; частые изменения промпта, напротив, сбрасывают это преимущество.
Границы результата задаёт сам эксперимент: проверяли автомобильного помощника, внешнее выполнение инструментов и один основной класс политик — правила, которые можно выразить строгой логикой. Если следующий шаг требует новой интерпретации неструктурированного ответа, вызов модели всё равно нужен. Состояние рабочего процесса хранится в памяти и не восстанавливается после перезапуска, а 40% скрытых задач хотя бы в одном прогоне остались нерешёнными.
Практический вывод не сводится к замене модели. Команде стоит сначала проверить, какие решения агент действительно должен принимать, а какие он лишь повторно вычисляет вместо обычного кода. Чем больше во второй группе зависимых вызовов и обязательных правил, тем сильнее архитектура влияет на задержку, стоимость и повторяемость результата.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
