Агент прочитал правило и все равно его нарушил
У рабочего агента может быть хороший системный промпт, подробный регламент и точные описания инструментов. Этого хватает для демонстрации. На длинном процессе конструкция распадается: свежая просьба пользователя вытесняет постоянное правило, результат проверки забывается через несколько шагов, а агент сообщает о соблюдении требования, хотя фактическое состояние системы говорит обратное.
Исследование HANDBOOK.md проверяет именно эту ситуацию. Авторы собрали 65 задач из финансов, страхования, медицинского биллинга, логистики и кадровых процессов. Агент получал регламент объемом от 20 до 124 страниц и работал с файлами, почтой, календарем, системой задач и торговыми сервисами. Результат проверяли 824 детерминированных условия: какие действия обязательны, а какие запрещены.
Лучшая из 30 конфигураций выполнила 36,2% задач. Большинство сильных конфигураций не дошли и до 25%. Причина была не только в том, что модель не нашла нужный абзац. Агенты выполняли проверку, видели отрицательный результат и все равно продолжали запрещенную ветку. Иногда они завершали процесс убедительным отчетом о соответствии правилам, хотя обязательный вызов инструмента отсутствовал.
Такое поведение нельзя исправить еще одним абзацем в промпте. Текст описывает правило, но не исполняет его.
Где заканчивается роль модели
В корпоративном процессе есть два разных типа работы. Первый требует понимания смысла: разобрать письмо, сопоставить документ с запросом, сформулировать ответ. Здесь модель полезна.
Второй тип работы детерминирован. Нельзя проводить выплату до проверки личности. После отказа нельзя переходить к ветке одобрения. Согласие клиента должно быть сохранено до изменения записи. Эти требования похожи на обычную программу: у них есть состояния, условия перехода и запрещенные действия.
COVENANT разделяет эти роли. Текстовый регламент сначала преобразуется в дерево процесса, затем в граф допустимых переходов. Модель видит текущий шаг и предлагает действие. Перед изменением внешней системы отдельный контроллер проверяет условие ветки, разрешенный инструмент и его аргументы.
На 120 случаях из семи процессов успешность выросла с 50,0% до 83,33%. Доля действий, не соответствующих процессу, снизилась с 42,5% до 15,83%. Выборка небольшая, а преобразование регламента тоже может ошибиться. Но эксперимент показывает полезную границу: модель разбирает неоднозначный смысл, программа удерживает порядок и запреты.
Проверять нужно до действия и после него
Проверка перед вызовом инструмента отвечает на вопрос: разрешено ли это действие сейчас? Она не доказывает, что инструмент сработал и система перешла в ожидаемое состояние.
Работа Real-Time Detection and Repair of Failures in AI Agents сравнивает поведенческий монитор с обычными проверяемыми условиями. Монитор анализировал каждый шаг и находил 71% сбоев при допустимых 5% ложных тревог. Обработка занимала около 200 микросекунд на шаг.
Для структурированных задач простые проверки оказались сильнее. Пересчет результата из настоящих ответов инструментов, проверка обязательных вызовов и контроль конечного состояния находили до 96% отказов без ложных срабатываний в исследованной выборке. После тревоги система откатывала состояние и повторяла ветку. Успешность выросла с 52% до 73% примерно за один дополнительный вызов модели.
Поведенческий монитор полезен там, где заранее неизвестно, что именно сломается. Но известное правило не нужно угадывать статистически. Его дешевле записать как условие.
Память тоже нельзя принимать за факт
Даже правильный граф процесса может получить ложный вход из памяти агента. Например, в ней сохранено устаревшее согласие клиента или неверный статус проверки. Если контроллер доверяет памяти, формально допустимый переход приводит к реальному ущербу.
SafeCommit предлагает проверять изменяющее состояние действие сразу в нескольких правдоподобных версиях мира. Они строятся из памяти, наблюдений, ответов инструментов, происхождения данных и правил. Действие разрешается, только если оно безопасно во всех оставшихся версиях. Иначе агент получает право лишь на безопасный запрос, который устраняет конкретную неопределенность, или отказывается от операции.
Пока это формальная схема с небольшим симулятором, не готовая рабочая платформа. Она полезна как архитектурный тест: сомнительное утверждение можно хранить, но нельзя автоматически превращать его в платеж, изменение записи или обещание клиенту.
Минимальная рабочая схема
Для критичного процесса нужен не один огромный промпт, а четыре раздельных слоя.
Регламент хранится в версионируемом виде. Из него извлекаются состояния, обязательные проверки, разрешенные переходы и явные запреты. Модель получает только текущую часть процесса, а не сотню страниц при каждом шаге.
До каждого действия, меняющего внешнюю систему, контроллер проверяет состояние, условие ветки, разрешения и аргументы. После вызова отдельная проверка читает реальное состояние: создан ли заказ, записано ли согласие, совпадает ли итоговая сумма с ответами инструментов.
Если проверка не проходит, система не просит модель убедительнее объяснить результат. Она откатывает обратимые изменения, сохраняет трассу и либо повторяет безопасную ветку, либо передает случай человеку.
Модель остается внутри процесса, но перестает быть его единственным исполнителем и судьей. Это особенно заметно в голосовом обслуживании: хорошая реплика ничего не говорит о том, какой статус агент поставил в CRM после разговора.
Промпт отвечает за интерпретацию. Право изменить систему должно принадлежать проверяемой программе.
Если это разделение нельзя показать на схеме и проверить испытанием, процесс по-прежнему держится на доверии к следующей реплике модели.