Привет ?

Самая неприятная ошибка рабочего AI-агента — не странный ответ. Это убедительное «готово», после которого кто-то идёт проверять, переделывать и извиняться перед коллегами.

Ассистенту, который предлагает формулировки, можно простить неудачный абзац. Агенту, который меняет рабочие данные, этого уже мало. Мне интереснее обсуждать его приёмку: что именно должно произойти, чтобы задачу можно было считать закрытой.

Для конкретики возьмём вымышленный сценарий. После встречи агент получает поручение обновить еженедельный отчёт по заявкам. Это учебный пример, не описание внутренней системы Яндекса и не рассказ о проведённом мною внедрении.

Сначала договоримся, что означает «обновить»

Фраза «обнови отчёт за неделю» отлично подходит для созвона и плохо — для теста. Какую неделю? По какому часовому поясу? В каком файле? Можно ли менять оригинал? Считать закрытые заявки или созданные? Кто принимает результат?

Для первого эксперимента я бы задал узкую задачу:

• Взять заявки из согласованного снимка данных за указанный период.

• Посчитать созданные и закрытые заявки по утверждённым определениям.

• Создать отдельный черновик отчёта со ссылкой на версию источника.

• Передать черновик назначенному проверяющему.

• Не отправлять документ внешним адресатам и не менять исходную таблицу.

Здесь есть проверяемый результат и граница полномочий. Можно обсуждать качество цифр, пояснений и оформления. Уже нельзя незаметно считать успехом любой файл с подходящим названием.

Проверяющий — часть процесса, а не магическое средство от всех ошибок. Если он каждую строку пересчитывает с нуля, мы пока автоматизировали оформление его дополнительной работы.

Текст ответа и состояние системы — разные доказательства

В инженерном разборе Anthropic об оценке агентов полезно различаются запись действий и итоговое состояние среды. Я бы применил это буквально: «отчёт сохранён» в чате не заменяет существующий отчёт с нужными данными.

В нашем примере проверка после выполнения смотрит на сам документ: период, значения показателей, версию источника, место сохранения и адресата. Журнал действий помогает понять, почему получился такой результат. Одно не подменяет другое.

А ещё стоит проверить отсутствие лишнего результата. Например, что агент не перезаписал исходный файл, не отправил вторую копию документа и не разослал черновик всем участникам встречи. Иначе показатель «отчёт создан» будет зелёным, а утро у команды — не очень.

Небольшой набор неудобных сценариев

Я бы начал не с сотни красивых промптов, а с таблицы спорных ситуаций. Ниже — предлагаемые тесты для нашего учебного процесса; это не отраслевой норматив и не результаты замера конкретного продукта.

Некоторые случаи проверяются обычным кодом: существует ли документ, совпадают ли суммы, сколько операций записи произошло. Другие требуют оценки человека: понятно ли пояснение к отчёту, помогает ли уточняющий вопрос, не прячет ли формулировка существенную неопределённость.

Я бы не поручал модели единолично решать, правильна ли арифметика, когда её можно пересчитать. И не пытался бы оценить полезность объяснения только по наличию нужной фразы.

Что сохранять в результате прогона

Минимальная запись для такого эксперимента могла бы выглядеть так:

{
  "case_id": "report-source-unavailable",
  "run_id": "trial-03",
  "input_snapshot": "fixture-v1",
  "expected": "report_blocker_without_writes",
  "observed_writes": 0,
  "outcome_check": "pass",
  "review_minutes": null,
  "model_config": "recorded-separately"
}

Это пример формата, не лог реального запуска. Поле проверки заполняет проверяющий механизм по состоянию тестовой среды, а не сам агент по впечатлению от собственной работы. Время проверки оставлено неизвестным, пока его не измерили.

Для сравнения версий нужно сохранять настройки модели и инструментов, входные данные и условия окружения. Иначе после смены промпта легко сравнить две разные задачи и торжественно объявить прогресс.

Повторять сценарии тоже полезно: один удачный прогон ещё не показывает устойчивость. Число повторов имеет смысл выбирать под цену ошибки и доступный бюджет. Из трёх попыток не стоит делать вид, что мы получили точную оценку редких отказов.

Не сводить все ошибки к одному проценту

Допустим, агент аккуратно оформил девять черновиков и один раз отправил документ не тому адресату. Средняя успешность здесь может выглядеть прилично. Решение о расширении доступа — уже нет.

Поэтому я бы отдельно считал корректность результата, нарушения границ доступа, дубли операций и случаи, где потребовалось вмешательство. Порог для расширения прав должна определить команда с учётом последствий, а не подогнать его под получившуюся красивую цифру.

Экономику тоже лучше считать по законченной работе. Время человека включает постановку, ответы на уточнения, проверку и исправления. Расходы системы — не только один удачный вызов модели, но и повторы, инфраструктуру и сопровождение. Сравнивать это нужно с тем же процессом без агента, а не с идеальным человеком из презентации, которому никогда не нужен обед.

Ноль ошибок в небольшом тестовом наборе не доказывает готовность к любым реальным данным. Но найденная ошибка уже даёт конкретную работу: сузить полномочия, исправить инструмент, уточнить критерий или добавить недостающий тест.

Когда давать больше самостоятельности

Для начала я бы оставил агенту подготовку черновика и проверку его структуры. Следующий шаг — разрешить конкретное изменение после подтверждения человеком. Более широкие действия обсуждать уже по наблюдаемым результатам этого узкого процесса.

Это не универсальная архитектура для любых агентов. В Building Effective Agents Anthropic также предлагает начинать с простых решений и добавлять сложность по необходимости. В нашем учебном сценарии часть операций вообще может оказаться обычным скриптом. Наличие LLM в проекте не обязывает доверять ей каждое сложение.

Мне нравится идея цифрового коллеги, который после встречи закрывает задачу. Но перед выдачей доступов хочется увидеть не особенно убедительное «готово», а скучное совпадение обещанного результата с фактическим.

Красивый аватар можно согласовать потом. Сначала — кто куда записал цифры.

https://t.me/ai_on_edge