Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Порядок инструментов в списке перед запуском влияет на то, сможет ли ИИ-агент выполнить многошаговую задачу. Bo Yan, Weikai Lin и Song Wang предложили State-Path Tool Menu, и на ToolBench доля успешных задач выросла с 73,7 до 89,8%; работа не прошла рецензирование, а числа получили сами авторы. Для больших библиотек это переносит часть работы с модели-исполнителя на слой, который готовит ей набор доступных действий.
Почему релевантный инструмент не образует маршрут
Практический агент редко видит всю библиотеку API. Перед запуском система выбирает короткое меню инструментов — упорядоченный список интерфейсов, которыми модель сможет пользоваться на протяжении задачи. Такое ограничение сокращает пространство выбора, но создаёт две точки отказа: нужный инструмент может не попасть в меню или оказаться там раньше своих зависимостей.
Обычный поиск ставит выше инструменты, чьи названия и описания похожи на запрос. Для просьбы отправить квитанцию он легко найдёт SendEmailReceipt. Но этот вызов не сработает, пока другие инструменты не получат заказ, не создадут квитанцию и не найдут адрес получателя.
Слабо связанный с формулировкой запроса промежуточный вызов может оказаться важнее ещё одного похожего финального действия. Поэтому авторы рассматривают меню как заданный до запуска приоритет исполнения: верхние позиции подсказывают агенту, с чего начать и какие данные подготовить.
State-Path описывает задачу как путь между состояниями. В начале доступны поля из запроса, затем инструменты добавляют новые данные, а последний вызов достигает нужного результата. Цепочка считается исполнимой, если требования каждого следующего инструмента удовлетворяют исходные данные или результаты предыдущих вызовов.
Как State-Path собирает исполнимую цепочку
Конструктор использует три вида сигналов. Он проверяет, какие инструменты можно вызвать из начального состояния, сопоставляет выходные поля одних API со входными полями других и учитывает порядок вызовов в успешных обучающих траекториях. Так система находит связи, которые нельзя восстановить только по сходству текста.
Сначала модуль отбора собирает меню из 32 инструментов. Он ищет доступное начальное действие, промежуточные вызовы, целевой инструмент и при необходимости действие, которое сохраняет или отправляет результат. Штраф за дублирование не даёт нескольким взаимозаменяемым финальным инструментам вытеснить незаметный, но обязательный промежуточный вызов.
Затем модуль упорядочивания ставит производителей данных перед их потребителями. Он последовательно обновляет предполагаемое состояние: после добавления инструмента считает его выходы доступными и проверяет, какой вызов теперь можно выполнить. Сам агент, его цикл работы и бюджет вызовов при этом не меняются.
Полнота цепочек выросла на 19,4 процентного пункта. Короткое меню State-Path по этому показателю также обошло официальный список из 128 инструментов: ширина списка не компенсировала пропущенные зависимости.
Одно упорядочивание официально отобранных кандидатов прибавило 3,6 процентного пункта к доле успешных задач. Полный метод дал ещё 12,5 пункта относительно этого варианта, потому что одновременно менял состав и порядок меню. Разрыв увеличивался на длинных маршрутах, где несколько промежуточных инструментов конкурируют за ограниченное число позиций.
Когда порядок инструментов меняет архитектурный план
Работа меняет планы команд, которые выбирают более крупную модель из-за ошибок при вызове API. Если агент видит финальное действие, но регулярно пропускает подготовительные шаги, сначала стоит проверить слой отбора инструментов. Замена исполнителя не исправит меню, в котором отсутствует исполнимая цепочка.
Эксперимент на ToolBench охватывает 304 задачи с единым исполнителем Qwen2.5-72B-AWQ, одинаковыми настройками запуска и общим оценщиком. Дополнительные проверки на AppWorld, TRAJECT-Bench, UniToolCall и ToolHop измеряли первый вызов, упорядоченный префикс и полноту маршрута; положительный эффект также сохранился у нескольких семейств исполнителей.
Подход требует содержательных схем API. Названия помогают понять назначение инструмента, но именно входные и выходные поля показывают, может ли один вызов подготовить данные для другого. История успешных траекторий улучшает отбор, хотя вариант на одних схемах тоже работает.
Меню строится один раз до первого вызова. На одной B200 задержка конструктора укладывалась в 0,6 секунды для 95% запросов, причём основное время занимали построение признаков пути и упорядочивание, а не нейронные модули. Для долгих агентных сценариев это отдельная начальная стоимость, а не задержка на каждом шаге.
State-Path не заменяет планировщик, который обновляет набор действий после новых наблюдений. Эти механизмы работают в разные моменты: меню даёт агенту начальный исполнимый маршрут, а динамический планировщик может изменить его по ходу задачи. Практический вывод узкий: в больших библиотеках API состав и порядок доступных инструментов следует тестировать как самостоятельную часть архитектуры, а не считать нейтральным контекстом для LLM.
Источники
Иллюстрация: рисунок из статьи «The Menu Is an Execution Prior: State-Path Tool Menus for Online Agents», Bo Yan, Weikai Lin, Song Wang, CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
