Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Ошибочные действия LLM-агента можно останавливать до того, как они незаметно изменят систему. В нерецензированном препринте Asaad Althoubi, где все числа получены самим автором, проверка находила 95,8% некорректных shell-команд, а защищённый механизм применения правок допустил одну скрытую ошибку в 8320 испытаниях. Для разработчиков агентов это переносит часть надёжности из модели в интерфейс исполнения.
Как отличили явный отказ от скрытой ошибки
Скрытой ошибкой в работе называют действие, которое исполнилось без сообщения о сбое, но дало не тот результат. Например, устаревший диапазон строк может успешно заменить чужой фрагмент файла. Агент продолжит работу, потому что исполнитель не вернул ошибку.
Чтобы измерять такие случаи напрямую, правильный результат фиксировали до запуска действия. Для команды заранее определяли, существует ли программа, разбирает ли shell её синтаксис и поддерживает ли установленный инструмент указанные ключи. Для правки сначала создавали целевой файл, затем представляли изменение в разных форматах и сдвигали его относительно исходного кода.
После исполнения результат относили к успеху, явному отказу или скрытой ошибке. Явный отказ считали восстанавливаемым: агент получает сигнал, исправляет действие и пробует снова. Такой подход не смешивает опасную незаметную порчу состояния с обычной ошибкой, которую уже умеют обрабатывать циклы агента.
Проверку команд провели на 9930 примерах для 482 инструментов. Механизмы правки оценивали на 640 изменениях в 224 файлах Python. Команды с ошибками и дрейф расположения правок создавали искусственно; испытания шли на одном Linux-хосте, а выходы реального агента использовали лишь для небольшой дополнительной проверки. Поэтому работа измеряет надёжность отдельного действия, а не успех агента в длинной задаче.
Команды и патчи ломаются по-разному
Проверка shell-команды состоит из независимых слоёв. Парсер shell отсеивает неверный синтаксис, поиск исполняемого файла проверяет программу, а ключи сверяются со справкой установленного инструмента. Первые слои не отклоняли корректные команды и находили половину внесённых ошибок.
Все ложные срабатывания возникли при разборе ключей: инструмент принимал ключ, которого проверяющий механизм не нашёл в справке. Если неоднозначные случаи не блокировать, а возвращать как предупреждение, доля отклонённых корректных команд снижается до 7,0% без потери способности находить ошибки. Получается двухуровневый шлюз: точные проверки запрещают действие, а неполные проверки просят агента перепроверить команду.
Для кода решающим оказался способ указать место изменения. Поиск и замена по содержимому, а также unified diff несут с собой фрагмент исходного текста. Если файл изменился, этот якорь перестаёт совпадать, и исполнитель отказывает явно.
Диапазоны строк ведут себя иначе: после сдвига на строку они повредили 99,1% файлов без сигнала об ошибке. Замена функции только по имени попала не в ту функцию в 12,7% случаев из-за повторяющихся имён. Формат действия здесь определяет безопасность сильнее, чем качество модели: позиция остаётся формально допустимой, даже когда уже указывает на другой код.
Защищённый механизм ищет содержательный якорь, проверяет совпадение и отказывается применять изменение при неоднозначности. Он не пытается угадать наиболее похожий участок любой ценой. Так потенциальная порча файла превращается в дополнительный шаг генерации правки.
Что менять в архитектуре агента
Работа меняет планы не на уровне выбора LLM, а на границе между моделью и исполнителем. Проверку стоит проектировать как обязательный слой перед командой или записью файла, а не как подсказку в системном запросе. Она не требует второго обращения к модели и даёт одинаковые результаты для одинакового состояния среды.
Для shell полезно разделить запреты и предупреждения. Ошибку синтаксиса или отсутствующий исполняемый файл можно блокировать сразу. Сомнительный ключ лучше вернуть агенту вместе с причиной, если справочник инструмента неполон или неоднозначен.
Интерфейс правок следует строить вокруг содержательных якорей: точного фрагмента для замены или контекста diff. Диапазоны строк и одно имя функции не должны служить достаточным адресом изменения. Если совпадений нет или их несколько, исполнитель должен отказаться и запросить новую правку.
Такой слой не решает, полезно ли само действие. Корректная shell-команда может удалить нужные данные, а безошибочно применённый патч — сломать бизнес-логику. Для этого остаются песочница, тесты, проверка прав доступа и рецензирование. Проверка перед исполнением закрывает более узкую дыру: не позволяет технически неоднозначному действию выглядеть успешным.
Практический вывод для новой системы — сначала определить проверяемый формат каждого действия, а затем подключать модель. В существующем агенте начать можно со шлюза перед shell и отказа от позиционных правок. Это не доказывает рост сквозной надёжности на реальных траекториях, но даёт локальное свойство, которое можно измерить и воспроизвести без переобучения модели.
Источники
Иллюстрация: рисунок из статьи «Look Before You Leap: Pre-Action Verification for LLM Agents», Asaad Althoubi, CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
