Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
У инструментальных агентов удалось почти устранить выбор неисправного маршрута перед запросом. В препринте независимых исследователей Manu Agrawal и Shrey Nagpal, который не прошёл рецензирование и содержит их собственные замеры, средние лишние операционные потери сократились на 96,9%. Для продуктовой команды это аргумент передавать модели актуальное состояние среды, но не отдавать ей контроль над измерениями и исполнением.
Модель получает снимок состояния, а хост сохраняет контроль
Описание инструмента обычно отвечает на вопрос, что он умеет. Оно не показывает, работает ли маршрут сейчас, не открыл ли защитный автомат цепь после серии ошибок и не выросло ли время ответа. Эти сведения уже есть у системы исполнения: в журналах запросов, трассировках, мониторах и ограничителях нагрузки.
Если модель видит только статическую схему API, два функционально равных маршрута для неё выглядят одинаково. Она может сформировать корректный вызов и всё же отправить его туда, где недавно возникали ошибки. В работе этот разрыв называют операционной слепотой.
Предложенная схема вставляет перед важным действием дополнительный шаг. Хост собирает свежие наблюдения, сокращает их до небольшого снимка и передаёт модели только сведения, которые нужны для выбора. В снимок могут входить недавние успешные запросы, задержка, последовательные сбои, состояние защитного автомата и возраст наблюдений.
Модель выбирает один из допустимых вариантов, но не измеряет среду сама и не редактирует телеметрию. Перед отправкой хост ещё раз проверяет состояние, применяет жёсткие ограничения и только затем выполняет действие. Поэтому снимок влияет на решение, но не становится новым контуром безопасности.
Такое разделение важно и для защиты от ошибочных рассуждений, и для защиты от подмены данных. Модель не может объявить маршрут исправным, обойти запрет или самостоятельно отправить вызов. Источником истины остаётся инфраструктура.
Как отделили полезные сведения от формы подсказки
В основном тесте ToolRoute модели выбирали между двумя маршрутами, которые одинаково подходили для чтения записи клиента. Задача и описания инструментов не менялись. Менялось только то, что модель знала о текущем состоянии маршрутов.
Контроль построили в трёх вариантах: без телеметрии, с нейтральным снимком одинаковой формы и с проверенным состоянием. Нейтральный вариант нужен, чтобы отделить пользу реальных сведений от эффекта дополнительного блока в контексте. Всего GPT-5.6 Sol, Claude Sonnet 5 и Gemini 3.7 Flash приняли 216 независимых решений без повторных попыток.
Авторы измеряли не только успешное чтение, но и наблюдаемые лишние потери. Метрика сравнивает выбранный маршрут с лучшим доступным по тем же сведениям и учитывает задержку, недавние отказы и открытый защитный автомат. Нулевое значение означает отсутствие предотвратимых потерь, а не мгновенный ответ сервера.
Проверенное состояние подняло долю успешных действий с 69,4% до 95,8% относительно нейтрального снимка. Когда модель всё же выбирала активный маршрут, она каждый раз попадала в лучший наблюдаемый вариант; остаточные ошибки возникли, когда агент предпочитал ждать при двух ухудшившихся маршрутах.
Отдельная проверка провела 27 решений через локальный HTTP-контур с OpenTelemetry и сбоями, которые создавал Toxiproxy. Проверяли задержку, разрыв соединения и ответ HTTP 503. Со снимком состояния все действия завершились успешно и не дали лишних наблюдаемых потерь; нейтральный вариант не завершил четыре действия.
Менять архитектуру стоит там, где выбор зависит от задачи
Работа не предлагает заменить прокси, балансировщик или защитный автомат вызовом LLM. Обычное переключение между равными репликами быстрее и надёжнее выполняет детерминированная инфраструктура. ToolRoute использует равные маршруты, чтобы изолировать влияние информации, а не чтобы предложить производственный шаблон маршрутизации.
Практический шаблон появляется уровнем выше. Агент может выбирать между поставщиками, источниками данных или режимами выполнения, если они различаются не только доступностью, но и качеством результата, сроком, квотой или требованиями задачи. В таком случае прокси уже не всегда знает, какой компромисс приемлем, а модель может учесть его вместе с текущим состоянием.
Команде, которая строит такого агента, имеет смысл разделить контур на четыре части: инфраструктура измеряет состояние, детерминированный код сокращает и очищает сведения, модель выбирает среди разрешённых действий, хост повторно проверяет выбор и исполняет его. Возраст снимка стоит передавать явно, иначе модель может принять устаревшее наблюдение за текущее.
Границы результата узкие: проверяли чтение без побочных эффектов, первый вызов без повторов, небольшой набор равных маршрутов и сетевые сбои. Работа показывает, что модели используют свежую проверенную телеметрию, но не сравнивает эту схему с полноценной политикой повторных попыток и не проверяет операции, которые нельзя безопасно повторить.
Поэтому планы меняются точечно. Если агент уже принимает решения между несколькими внешними действиями, снимок состояния стоит добавить в ближайший архитектурный эксперимент. Если задача сводится к переключению между одинаковыми репликами, её по-прежнему следует оставлять в балансировщике или клиентской библиотеке.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
