Текст статьи обрезан: раздел с экспериментами не дочитан. Цифры взяты из аннотации и введения.
TL;DR
Главный практический вывод: оценивать агента только по конечному результату недостаточно. Агент может добиться цели, но по пути нарушить обязательное условие. Например, на минуту уйти ниже минимального остатка на счёте, а потом вернуть деньги. Итог выглядит «успешно», хотя нарушение уже случилось. BizBench — тест на 50 длинных задач из реальных платёжных процессов. Он проверяет не только результат, но и каждый шаг: «цель достигнута», «правила соблюдены по ходу», «защищённое не тронуто». Задача засчитывается, только если выполнены все три условия.
Что идёт не так. Даже лучшие модели проходят такие задачи «чисто» примерно в 60–64% случаев. У одной из моделей цель достигается в 42% задач, а «чисто» — только в 32,7%. Остальные «успехи» содержат скрытые нарушения. Результат нестабилен: полностью успешно во всех трёх прогонах проходит лишь около 40% задач. Модели путаются в устаревших и конфликтующих документах. Они делают на ~70% больше вызовов инструментов, чем нужно. Слабые модели много раз лезут в закрытые ресурсы. Причина в том, что у модели нет «счётчика»: она проверяет условие в момент решения и не следит за ним до конца процесса.
Что можно взять в работу. Метод простой: три отдельные проверки (цель, процесс, защита) и проверка журнала действий, а не только финала. Авторы делали это детерминированным кодом, а не промптом. Принцип переносится в обычную работу с агентом: просить его фиксировать действия, а потом проверять журнал по списку обязательных условий.
Схема метода
Критерий успеха из статьи: Успех = G ∧ P ∧ F.
ШАГ 1 (G, цель): нужный результат достигнут? → да/нет + доказательство
ШАГ 2 (P, процесс): правила соблюдены на КАЖДОМ шаге? → да/нет по каждому условию
(согласие на конкретную операцию ДО неё;
минимальный остаток ВСЁ время)
ШАГ 3 (F, защита): защищённое не тронуто, побочных эффектов нет? → да/нет
ИТОГ: успех только если все три «да»
Правило: исправление нарушения потом (возврат денег) не отменяет самого нарушения.
Пример применения
Задача: Вы продавец на Ozon и подключили ИИ-агента к управлению расчётным счётом ИП. Правила: на счёте всегда должно быть не меньше 50 000 ₽ — 28-го числа налоговый платёж. Любой платёж поставщику свыше 20 000 ₽ требует вашего явного подтверждения именно на эту сумму и этого получателя. Агент отработал неделю, и вы хотите проверить не «сошлись ли деньги», а «не нарушал ли он правила по пути».
Промпт:
Ты — аудитор процесса. Проверяешь журнал действий ИИ-агента по трём независимым критериям.
Итоговый результат не отменяет нарушений на промежуточных шагах.
P1. Остаток на расчётном счёте не должен опускаться ниже 50 000 ₽ ни в какой момент
(проверяй баланс после КАЖДОЙ операции, а не только в конце).
P2. Платёж свыше 20 000 ₽ допустим только если ДО него есть подтверждение владельца
на эту сумму и этого получателя. Общее «ок, делай» не считается.
Если условия платежа изменились — нужно новое подтверждение.
F1. Нельзя трогать резерв на налоги и менять реквизиты получателей.
Оплатить поставщику ООО «Ромашка» 65 000 ₽ до 25 числа.
{журнал_действий_агента_с_балансами}
1. G: достигнута ли цель? Укажи строку журнала с доказательством.
2. P: пройди по журналу шаг за шагом. После каждой операции выпиши баланс
и отметь, выполнены ли P1 и P2. Любое нарушение фиксируй, даже если позже исправлено.
3. F: проверь F1.
4. Итог: УСПЕХ только если G, P и F — все «да». Иначе — ПРОВАЛ с указанием шага нарушения.
Результат: Модель выдаст построчную таблицу: шаг, операция, баланс, статус по P1 и P2. Затем отдельно оценит G и F. В конце будет вердикт «УСПЕХ/ПРОВАЛ». Если агент на минуту опускал остаток ниже 50 000 ₽, это будет отмечено нарушением, даже если деньги потом вернулись.
Почему это работает
Слабость. Модель проверяет условие в момент решения и не держит его «в голове» до конца процесса. Нарушение, которое потом «починили», в итоговой картине исчезает. Поэтому проверка только финала даёт ложные «успехи».
Сильная сторона. Модель хорошо идёт по журналу пошагово и сверяет каждую строку с явным правилом, если правило сформулировано однозначно.
Как метод это использует. Он заставляет выписывать состояние после каждой операции и проверять правила отдельно от цели. Нарушение становится видимым фактом в строке журнала, а не вопросом интерпретации.
Рычаги: - Список правил P/F — меняйте под свой процесс (лимиты, согласования, запреты). - «Баланс после каждой операции» — замените на любое состояние, которое нужно отслеживать: статус заказа, остаток на складе, бюджет кампании. - Условие «согласие на конкретную операцию с условиями» — ужесточайте или ослабляйте под свой уровень риска.
Шаблон промпта
Ты — аудитор процесса. Проверяешь журнал действий агента по трём независимым критериям.
Исправление нарушения позже не отменяет самого нарушения.
P1. {обязательное_условие_на_всё_время_выполнения}
P2. {требование_согласования_до_операции}
F1. {что_нельзя_трогать_и_запрещённые_побочные_эффекты}
{цель_задачи}
{журнал_действий_агента_с_состоянием_после_каждого_шага}
1. G: достигнута ли цель? Укажи доказательство из журнала.
2. P: пройди по журналу шаг за шагом. После каждой операции выпиши состояние
и отметь соблюдение каждого правила P. Фиксируй любое нарушение, даже исправленное.
3. F: проверь защищённые объекты и побочные эффекты.
4. Итог: УСПЕХ только если G, P и F — все «да». Иначе ПРОВАЛ с указанием шага.
Что подставлять: {обязательное_условие...} — то, что должно выполняться непрерывно (минимальный остаток, действующая гарантия). {требование_согласования...} — что должно быть подтверждено до действия. {журнал...} — выгрузка действий агента с состоянием после каждого шага.
Важно: авторы проверяли агентов детерминированным кодом, а не промптом. Шаблон переносит их принцип «цель / процесс / защита» в текст. Сам промпт как способ проверки они не тестировали.
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита журнала агента по принципу «цель / процесс / защита».
Адаптируй под мою задачу: [опиши, что делает твой агент и какие у него правила].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие условия должны соблюдаться непрерывно, что требует согласования до действия и что нельзя трогать. Это нужно, чтобы разнести правила по трём проверкам: без них проверка снова сведётся к «получилось или нет».
Ограничения
⚠️ Лечение не проверено: авторы измерили проблему, но не тестировали промпты, которые её исправляют. Шаблон выше — перенос принципа, а не доказанный приём.
⚠️ Одна область: все задачи из платёжного бизнеса, всего 50 штук, с симулированным клиентом. Перенос на другие сферы — ваша гипотеза.
⚠️ Проверка кодом, не LLM: оценка в статье детерминированная, без LLM-судьи. Модель-аудитор по журналу может сама пропустить нарушение. Выборочно проверяйте её вручную.
⚠️ Журнал нужен полный: если у агента нет записи действий с состоянием после каждого шага, проверять по процессу нечего.
⚠️ Текст неполный: детали экспериментов (ablation по документам, стабильность симулятора) не дочитаны.
Как исследовали
Авторы из Ant International взяли реальные процессы платёжной компании и перенесли их в игровую среду. В ней 789 документов и 601 бизнес-инструмент, которые агент должен сам находить через девять постоянных. В документах нарочно оставили устаревшие и конфликтующие правила с указанием сфер действия и сроков. Клиента играет другая LLM: она раскрывает данные по ходу и подтверждает операции.
Главная идея — проверять не «что получилось», а «что происходило». Для каждой из 50 задач написали проверки цели, процесса и защиты. Они работают по журналу действий и не требуют одного «эталонного пути». Каждую задачу прогнали вручную («золотой след»), чтобы убедиться, что она вообще решаема, и проверили проверки на допустимых и недопустимых вариантах решения.
Результаты. Лучшие модели набрали строгий успех 64,0% и 61,3%. Полностью успешно во всех трёх прогонах прошла лишь ~40% задач. У Qwen3.8-27B цель достигалась в 42,0%, а строгий успех был 32,7%. У нескольких прогонов DeepSeek остаток «в конце» был в норме, а по пути лимит нарушался. Они же в среднем делали 191,3 вызова инструментов, на ~70% больше эталона. Qwen3.5-9B в среднем делала 187,2 вызова, больше половины из них с ошибкой (попытки зайти в закрытые ресурсы). Ни один из её 150 прогонов не достиг всех целей.
Удивляет разрыв между «цель достигнута» и «всё сделано правильно». Практический инсайт: метрика «задача решена» маскирует нарушения процесса.
Адаптации и экстраполяции
Это мои идеи, не из статьи, авторы их не проверяли.
🔧 Техника: правило в инструкцию агенту → превентивная проверка
В системный промпт или файл инструкций агента можно добавить:
Перед каждой операцией, которая меняет остаток, статус или бюджет: 1. Выпиши состояние ДО и рассчитай состояние ПОСЛЕ. 2. Если после операции нарушится любое правило из— не выполняй её, спроси меня. 3. Для операций свыше {лимит} запроси подтверждение именно этой операции с суммой и получателем. Эффект — агент проверяет нарушение до действия, а не оправдывается после. Эффект не измерен.
🔧 Техника: документы с датами → меньше путаницы со старыми правилами
Если агент читает регламенты, в начале каждого документа укажите «Действует с … по …; применимо к …». Статья показывает, что устаревшие и конфликтующие документы — отдельный источник ошибок. Нужно добавить в инструкцию: «Если два документа противоречат друг другу, сравни даты действия и сферу применения и назови, какой взят за основу».
Ресурсы
- BizBench: Unveiling Hidden Challenges in Deploying Long-Horizon Agents for Real-World Business
- Авторы: Enhan Zhao, Yongqi Tong, Xuejun Yu, Hang Wang, Pan Wang, Yichao Wang, Di He, Jianshe Li, Wei Wu — Peking University, Ant International
- GitHub: github.com/ant-intl/BizBench
- Hugging Face: huggingface.co/datasets/ant-intl/BizBench
- Смежные бенчмарки: τ-bench, AutomationBench