Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Вызовы инструментов LLM-агента можно автоматически проверять и исправлять до того, как ошибочная команда попадёт в API. В препринте University of Illinois Urbana-Champaign и Microsoft Research, который не рецензировался и содержит замеры самих авторов, такой слой поднял долю выполненных задач на 9,8 процентного пункта, когда среда скрывала причины сбоев. Для продуктовой команды это отдельный проверяемый контур между моделью и API, а не ещё одна подсказка в контексте.
Как документация превращается в исполняемые правила
Symbolic Constraint Agents, или SCA, начинает с описаний API. Отдельный агент по очереди разбирает каждый инструмент, находит связанные методы и формулирует условия, которым должен соответствовать вызов.
Условия охватывают происхождение аргументов, порядок действий, допустимые значения и наблюдаемое состояние среды. Например, ключ доступа для чтения каталога должен прийти из предыдущего вызова входа, авторизация должна предшествовать защищённой операции, а количество товара не может превышать уже полученный остаток.
Каждое условие сохраняется в двух формах: как понятное модели описание и как формула для Z3, решателя выполнимости формул. История вызовов тоже переводится в формальные факты: какой инструмент вызвали, с какими аргументами и что он вернул. Если новый вызов противоречит накопленным фактам и правилу, решатель отмечает нарушение.
Такой подход отделяет проверку от поведения основной модели. Модель по-прежнему выбирает инструменты и строит план, но корректность конкретного шага проверяет детерминированная программа. Одинаковая история и одинаковый вызов дают один и тот же вердикт.
Как трассы исправляют черновой каталог ограничений
Одной документации недостаточно: она может не описывать фактическую зависимость между методами или допускать несколько трактовок. Поэтому второй агент уточняет правила по трассам — последовательностям вызовов, аргументов, ответов среды и ошибок.
Если правило запрещает вызов, который среда приняла, агент ослабляет или удаляет его. Если среда отклонила вызов, а каталог не заметил проблемы, агент добавляет условие. После уточнения каталог фиксируют и используют на тестовых задачах, поэтому проверяющий слой не переписывает правила во время каждого пользовательского запроса.
Во время работы SCA вмешивается двумя способами. Предупреждение оставляет вызов без изменений, но добавляет в контекст объяснение нарушения. Этот режим подходит для ошибок, которые видны только после ответа API: например, заказ не проходит из-за недействующего промокода, и агенту нужно выбрать другое действие.
Автоматическое исправление срабатывает до выполнения вызова. MaxSMT ищет минимальное изменение аргументов, после которого все правила выполняются, а затем отдельно проверяет, что допустимая замена только одна. Если вариантов несколько, SCA ничего не выбирает за агента и возвращается к предупреждению. В одном из примеров система заменила токен почтового сервиса на уже полученный токен файлового хранилища, не меняя остальные аргументы.
Метод проверяли на AppWorld с 417 заданиями и каталогом из 457 API, а также на 60 заданиях τ2-bench для авиакомпании и розничного магазина. В экспериментах участвовали модели OpenAI, Anthropic и Qwen; правила строила GPT-5.5. AppWorld возвращает ошибки вызовов, тогда как в отдельных режимах и в τ2-bench агент получает мало сведений о причине сбоя.
Когда проверяющий слой меняет архитектурный план
Уточнение по трассам повысило F1 обнаружения ошибочных вызовов GPT-5.5 на 21,3 процентного пункта. При жёстком лимите действий автоматическое исправление добавило GPT-5.4-mini 5,4 пункта успешных задач, а доля устранённых неудачных вызовов доходила до 87%. На τ2-bench прирост достигал 5,6 пункта, то есть подход перенёсся с большого каталога приложений на среды с явными корпоративными правилами.
SCA стоит учитывать в архитектуре, если агент работает с состоянием нескольких сервисов, переносит идентификаторы и токены между шагами или платит за каждый ошибочный вызов. Проверяющий слой можно разместить между оркестратором и исполнителем инструментов, а каталог ограничений обновлять вместе с документацией API и набором проверочных трасс.
Работа не предлагает универсальную защиту агента. Ограничения замечают ошибки, которые видны в истории: неверный аргумент, пропущенную предпосылку или действие в неподходящем состоянии. Они не находят необходимый вызов, который агент вообще не сделал, и не видят скрытое состояние, если агент его предварительно не запросил.
Польза также зависит от профиля ошибок. В обычном AppWorld, где API подробно объясняет сбой и разрешает много повторов, прирост был небольшим; Sonnet 5, который реже ошибался на уровне отдельных вызовов, получил мало пользы. Ложное ограничение способно направить модель на ненужный повтор, поэтому каталог нельзя считать политикой безопасности без отдельной проверки.
Практический вывод уже применим без замены основной модели: часть надёжности можно вынести из подсказок в исполняемые правила. Но для этого команде понадобятся доступ к трассам, процесс проверки каталога и чёткая граница, где разрешено автоматическое исправление, а где агент должен получить только предупреждение.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
