Пилот ИИ-агента не равен production: как проверить готовность до запуска
ИИ-агенты часто выглядят сильнее всего на демо. Один аккуратный сценарий, хорошие входные данные, понятная цель, человек рядом, ошибки быстро поправляют. На таком стенде агент кажется почти готовым сотрудником.
Проблема начинается позже. В production появляются грязные данные, неполный контекст, странные права доступа, забытые исключения, люди, которые не читают отчеты, и задачи, где ошибка стоит денег, доверия или времени команды.
Поэтому вопрос не в том, "получился ли пилот". Вопрос точнее: есть ли у пилота production-gate, через который его можно пропустить без самообмана.
Почему демо агента почти ничего не доказывает
Демо проверяет возможность. Production проверяет устойчивость.
На демо можно показать, что агент умеет разобрать письмо, заполнить таблицу, собрать отчет, найти проблему на сайте или предложить правку. Но это еще не значит, что агент готов работать с настоящими клиентскими данными, платежами, публикациями, юридическими документами, production-кодом или внутренними доступами.
Слабое место обычно не в модели. Слабое место в контуре: какие данные ей дают, какие правила она видит, какие действия разрешены, кто проверяет результат, как фиксируются ошибки и можно ли откатиться.
Что полезного дает сигнал из очереди @alexkrol
В очереди @alexkrol есть удачная формулировка: первое поколение ИИ-агентов красиво провалилось в production, а компании теперь строят "версию 2.0". В статье не нужно повторять это как статистический приговор. Полезнее взять саму боль: пилот и рабочий процесс — разные сущности.
Пилот отвечает на вопрос: "может ли агент сделать это хоть раз?" Production отвечает на другой вопрос: "может ли он делать это регулярно, на разных случаях, с понятным риском и человеческой ответственностью?"
Это хороший материал для ONFF, потому что он переводится в практическую проверку.
Что в этом подтверждает документация Codex
Документация Codex постоянно возвращает к нескольким рабочим вещам: задаче нужен контекст, ожидаемый результат, ограничения и критерий готовности. Повторяющиеся правила лучше выносить в AGENTS.md. Права, sandbox и approval policy задают техническую границу действий. Результат нужно проверять через tests, review, diff, логи и понятные evidence.
Из этого следует простая мысль: агентный пилот нельзя выпускать в production только потому, что он один раз красиво ответил. Его нужно описать как рабочий контур.
Какие семь проверок нужны перед production
Перед запуском задайте семь вопросов.
| Проверка | Что должно быть ясно |
|---|---|
| Данные | На каких реальных данных агент работает и какие данные запрещены |
| Контекст | Какие правила, документы, файлы и примеры агент видит |
| Права | Что можно читать, менять, отправлять, публиковать или удалять |
| Метрика | Как понять, что агент дал пользу, а не просто сделал действие |
| Review | Кто смотрит результат и какие evidence принимает |
| Rollback | Как отменить действие или вернуться к прошлому состоянию |
| Владелец | Кто отвечает за решение "пускать дальше" |
Если хотя бы один блок пустой, это еще не production. Это тест.
Какой артефакт попросить у Codex
Не просите Codex "оценить, готов ли агент". Это слишком общо.
Лучше дать конкретный запрос:
Разбери этот пилот ИИ-агента как production-readiness card. Проверь данные, контекст, права доступа, метрику результата, review, rollback и владельца решения. Раздели: готово, не готово, нужно уточнить, запрещено до ручного решения. Не предлагай запуск в production, если нет rollback или владельца риска.
Codex должен вернуть таблицу, а не вдохновляющее заключение.
Как проверить карту без программирования
Проверка простая. Откройте карту и ищите пустые места.
Если написано "данные есть", но не указано какие именно, это не проверка. Если права описаны как "доступ к системе", это слишком широко. Если метрика звучит как "экономия времени", но нет способа измерить время до и после, это пожелание. Если review зависит от одного занятого человека, это узкое место. Если rollback не описан, production запускать рано.
Особенно внимательно смотрите на действия, которые выходят наружу: письма клиентам, публикации, платежи, изменения в базе, удаление файлов, правки в production и обещания от имени компании. Здесь агент должен сначала возвращать предложение, а не действовать.
Практическая карточка production-gate
Перед запуском агента в реальный процесс заполните короткую карточку.
Сценарий: какую повторяющуюся работу агент делает.
Данные: какие входы разрешены и какие запрещены.
Контекст: какие правила, документы и примеры обязательны.
Доступ: что агент может читать, что менять, а что только предлагать.
Метрика: как измеряется результат.
Проверка: кто принимает evidence.
Откат: как отменить ошибочное действие.
Решение человека: кто разрешает production и на каких условиях.
Так пилот перестает быть красивым экспериментом и становится управляемым рабочим контуром. Агент может быть полезен, но право войти в production он получает только после проверки, а не после удачного демо.