Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Инструментального агента научили заранее проверять, можно ли выполнить запрос доступным набором вызовов, а не подбирать следующий шаг методом проб и ошибок. В работе Washington University in St. Louis система CGAP обошла обычного агента с вызовом инструментов на величину до 28,9 процентного пункта, хотя препринт не рецензирован и числа получили сами авторы. Для продуктовой архитектуры это означает, что планирование можно вынести из LLM в проверяемый слой.
Каталог инструментов становится моделью задачи
CGAP делит работу между LLM и детерминированными компонентами. LLM разбирает запрос и выделяет отдельный результат, который нужно получить: например, прогноз для каждого города и дня. Но порядок вызовов определяет уже не модель, а классический планировщик.
Система преобразует каталог инструментов в формальную модель на PDDL — языке описания задач планирования. Обязательные входные поля становятся предусловиями действия, выходные поля — его результатами. Если прогноз погоды требует координаты, а поиск города их возвращает, планировщик связывает эти операции без отдельного описания зависимости.
Модель хранит не конкретные значения, а факт их доступности. Она знает, что у агента появились широта и долгота, но не различает координаты Paris и Nice. Благодаря этому план можно построить до выполнения инструментов, когда ответы API ещё неизвестны.
Такая абстракция делает план короче фактического исполнения. В примере из работы план содержит пять действий, но для разных городов и дат агент выполняет семь вызовов. LLM добавляет недостающие вызовы для конкретных сущностей, а среда исполнения принимает их, только если они не нарушают оставшийся план.
Аргументы модель тоже не пишет напрямую. Для каждого значения она указывает источник: фрагмент запроса, поле предыдущего ответа или разрешённое приложением преобразование. Перед вызовом система проверяет схему аргументов, предусловия и правила доступа, а после него отдельная LLM сверяет результат с исходным запросом.
Проверка охватила три LLM и четыре набора задач: ToolSandbox, ComplexFuncBench, BFCL multi-turn и τ2-bench retail. Они включают многошаговые запросы, зависимости между инструментами и операции, которые меняют состояние. Это тест архитектуры инструментального агента, а не универсальной способности модели рассуждать.
Детерминированные зависимости дают основную часть прироста
CGAP превзошёл обычный вызов инструментов во всех сопоставлениях моделей и метрик. Особенно заметен результат там, где действие меняет состояние: например, включает настройку, необходимую следующей операции, или отменяет ранее выполненное условие.
Замена поиска планом, который пишет LLM, ухудшила результаты открытых моделей на 4,4–16,8 процентного пункта. Для GPT-5 mini разница чаще оставалась в пределах погрешности. Значит, сильная модель частично компенсирует отсутствие формального планировщика, но более доступные модели выигрывают от жёстко заданных зависимостей.
Упрощённый планировщик по графу зависимостей сохранил большую часть эффекта на задачах без отмены фактов. Полный поиск оказался полезнее, когда действия могли нарушить состояние, нужное следующим шагам. Команде не всегда нужен весь PDDL-стек: иногда достаточно детерминированно построить граф из входов и выходов инструментов.
За надёжность приходится платить вычислениями. С gpt-oss-20b CGAP расходовал в 1,3–1,6 раза больше токенов на задачу, чем обычный агент. Работа не измеряет задержку, поэтому по этим результатам нельзя определить, окупится ли дополнительный цикл планирования в интерактивном продукте.
Что менять в архитектуре инструментального агента
Работа меняет планы команд, если агент связывает несколько API, работает с изменяемым состоянием или выполняет действия с последствиями. В такой системе LLM лучше оставить интерпретацию запроса, выбор конкретных сущностей и проверку смысла результата. Зависимости, допустимость вызова и происхождение аргументов стоит вынести в код.
Первое практическое требование — привести каталог инструментов к строгим контрактам. Входы и выходы должны иметь стабильные названия и схемы. Если каталог не описывает возвращаемые поля, CGAP выводит их из соглашений об именах и связей между инструментами, а это создаёт риск пропустить зависимость или ошибочно объединить разные поля.
Второе требование — отдельно моделировать состояние, которое не выражается схемой API. Если отправка сообщения зависит от включённой связи, приложение должно явно задать это предусловие и описать, какие действия его добавляют или отменяют. Именно такая ручная модель дала планировщику преимущество в сценариях с изменяемым состоянием.
Гарантии CGAP действуют только внутри скомпилированной модели. Если исчерпывающий поиск не находит план, система доказывает лишь то, что запрос нельзя выполнить данным каталогом в его текущем описании. Поиск в ширину также быстро дорожает с ростом числа фактов и может остановиться по лимиту раньше, чем найдёт решение.
Проверки не устраняют смысловые ошибки LLM. Модель может неверно разобрать запрос, связать аргумент не с той сущностью или принять неподходящий результат. Проверка выполняется после вызова и не может отменить действие с побочным эффектом, поэтому авторизацию и подтверждение критичных операций по-прежнему должен обеспечивать продукт.
CGAP полезнее воспринимать не как готовую замену агентного стека, а как схему разделения ответственности. LLM понимает естественный язык, классический планировщик строит зависимости, а детерминированная среда не позволяет свободному рассуждению превратиться в непроверенный вызов API.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
