Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Вызов инструмента у LLM-агента может измениться между генерацией и запуском, хотя в журнале останется исходная команда. Хотя препринт не рецензирован и числа получили сами авторы, предложенный ими IntAct восстановил 79,2% сбоев, при которых путь исполнения исказил вызов. Для агентных систем это переносит часть контроля качества с модели на среду запуска.
Команда меняется после того, как модель её отправила
Авторы называют соответствием намерения и исполнения ситуацию, когда программа получает действие, которое обозначал исходный вызов по контракту инструмента. Намерением здесь считается не цель пользователя и не рассуждение модели, а конкретная команда, которую агент уже сформировал.
Между агентом и программой команда проходит через сериализацию, оболочку среды запуска, синтаксический анализатор командной оболочки, интерфейс процесса и анализатор целевой программы. Каждый переход может повторно разобрать кавычки, обратные косые черты, переносы строк или список аргументов. В результате аргумент разделяется, часть текста исчезает, а управляющий символ получает новое значение.
В рабочих сеансах изучили 47 828 команд оболочки. Bash-инструмент Claude Code изменил 12% вызовов, которые содержали код, управляющие последовательности или длинный текст. Это доля внутри указанного класса команд, а не оценка для любого вызова Claude Code.
Особенно опасны тихие искажения: для 80,7% вызовов с изменёнными обратными косыми чертами программа выполнила неправильное действие, но не вернула ошибку. Агент видел успешное завершение и мог перейти к следующему шагу с неверным результатом.
Анализ только по журналу работы приписал модели 95,1% производственных сбоев, хотя больше половины вызвал путь исполнения. На IEC-Bench эти искажения увеличили расход токенов на успешно решённую задачу в 2,4 раза: агент повторял корректные команды или пытался исправить ошибку, которой в его тексте не было.
Как находят первый переход, исказивший вызов
Обычный журнал хранит команду агента и окончательный ответ инструмента. Он не показывает, какой текст получила оболочка, какие аргументы дошли до процесса и что разобрала целевая программа. Поэтому по журналу нельзя отличить ошибку генерации от ошибки доставки.
Протокол IEC ставит на переходах наблюдателей, которые фиксируют полученное значение, но не исполняют записанную команду. Например, вместо целевой программы можно запустить безопасную заглушку, которая возвращает принятый список аргументов. Для оболочек протокол использует их собственные анализаторы с отключённым исполнением.
Сравниваются не строки, а действия. Два текста могут различаться экранированием, но обозначать одну команду. Поэтому решение принимает анализатор принимающей стороны: для Bash сравниваются операторы и слова, для PowerShell — дерево разбора, для обычной программы — упорядоченный список аргументов.
Первый переход, где действие изменилось, считается источником расхождения. Затем записанный запуск повторяют, исправив только этот переход. Такой повтор подтверждает причину и обнаруживает следующий дефект, который раньше мог быть скрыт первым.
Методику проверяли на рабочих сеансах Linux, путях запуска Windows, командах оболочки и структурированных инструментах, включая MCP. IEC-Bench воспроизводит цепочки зависимых вызовов из реальных искажений; сравнение охватывает четыре LLM и несколько распространённых сред запуска. Поэтому работа прежде всего описывает агентные системы, где команда проходит через оболочки и повторный разбор.
Что IntAct меняет в архитектуре агентных систем
IntAct исправляет не текст после ошибки, а канал на конкретном переходе. Если оболочка повторно разбирает кавычки, команда передаётся через файл или закодированный аргумент. Если проблема возникает на границе процесса, IntAct формирует список аргументов по правилам принимающей программы. Несколько исправлений можно соединить в порядке прохождения команды.
Когда доставить действие без изменений нельзя, IntAct отказывается от запуска и сообщает, какой переход не поддерживает команду. Это безопаснее, чем выполнить похожее действие и вернуть успешный код завершения. Модель получает явный отказ вместо косвенного симптома и не тратит токены на попытки исправить собственный корректный вызов.
Для команд, которые строят агентную среду, работа меняет приоритеты тестирования. Проверки только конечного результата и журналов модели недостаточно: путь нужно наблюдать по переходам, а тесты должны сравнивать действие до и после каждого анализатора. При сравнении LLM следует фиксировать среду запуска, иначе разница в результатах может принадлежать оболочке, а не модели.
IntAct реализовали как модуль Claude Code, промежуточную оболочку, MCP-сервер и ядро запуска настольного агента. Это показывает, что проверку можно поставить перед существующими инструментами без изменения самой LLM. При этом правила разрешений должны анализировать исходный вызов, а не его техническое представление после перекодирования.
Практический вывод для новой системы прост: контракт инструмента должен охватывать не только схему вызова, но и его доставку. Корректная команда обязана дойти до программы без изменения либо завершиться явным отказом до исполнения.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
