Автономные ИИ-агенты: где справляются сами и где человек обязателен

Что это решает

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

Как устроено

Автономность удобно мерить ступенями, а не словом «да/нет».

Что технически делает агента способным работать без человека.

Явный критерий завершения. Формулировка «разберись с обращением» оставляет агента без условия остановки. Рабочая формулировка: обращение считается закрытым, когда ответ отправлен и статус переведён; если за два шага ответа не нашлось — эскалация.

Различение пустоты и ошибки. Пустой результат поиска и недоступный сервис выглядят для модели похоже. Обёртка инструмента должна возвращать разные коды, иначе агент напишет «данных нет» там, где база просто не ответила.

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

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

Журнал с обратной ссылкой. Каждое действие записано вместе с источником: какой вход его вызвал, какой шаг агента, какие аргументы ушли. Разбор инцидента без такого журнала превращается в гадание.

Стоп-кран. Флаг, который агент проверяет перед каждым пишущим вызовом, и остановка всех запусков одной командой.

Где контроль человека обязателен независимо от зрелости агента:

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

Как подключить

Автономность набирается лестницей, каждая ступень занимает не один день.

1. Теневой режим. Агент отрабатывает на реальном потоке и складывает результат в черновики. Человек делает работу как раньше и сравнивает. Расхождения собираются в список.

2. Разделение инструментов. Два набора: читающие и пишущие. Читающие доступны всегда, пишущие — через отдельный токен и отдельную настройку.

3. Подтверждение на запись. Пишущий инструмент выводит намерение полностью: кому, что, с какими значениями. Формат dry-run важнее красивого текста:

DRY-RUN send_email
  to:      client@example.com
  subject: Продление доступа
  body:    128 символов
  reason:  тариф истекает через 3 дня

4. Лимиты. Максимум действий за запуск, максимум за сутки, потолок суммы, окно тишины для клиентских коммуникаций, белый список получателей и операций.

5. Стоп-кран и его проверка. Флаг, который агент читает перед каждой записью:

echo 1 > /var/run/agent.stop   # остановить пишущие действия
rm /var/run/agent.stop         # вернуть в работу

6. Автономность на узком классе. Первым отпускают самый однотипный случай: один тип обращения, один тип документа. Остальное продолжает идти через подтверждение.

7. Расширение по данным. Класс переводится в автономный режим, когда на нём набрана статистика: доля вмешательств стабильно низкая, откатов не было, эскалации срабатывали по делу.

8. Алерты по порогам. Уведомление приходит при выходе за границу — всплеск эскалаций, рост числа действий, повторные отказы. Ежедневный отчёт «всё хорошо» перестают читать через неделю.

Полезные сценарии

• Ночной разбор ошибок: агент группирует однотипные события и заводит один тикет с примерами вместо потока уведомлений.
• Ответ первой линии по базе знаний с жёсткой эскалацией всего, чего в базе нет.
• Сверка данных между двумя системами: читает обе, сравнивает, пишет только отчёт о расхождениях.
• Напоминания об истекающем доступе: агент формирует список и черновики, отправка идёт по подтверждению.
• Маршрутизация входящих: классификация по намерению и передача в очередь с собранным контекстом.
• Мониторинг внешнего API: регулярный вызов, сравнение с эталоном, сообщение только при отклонении.

Ограничения

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

Агент не знает, чего он не знает. При нехватке данных модель по умолчанию достраивает недостающее, а не останавливается. Остановка — поведение, которое задаётся явно в промпте и подкрепляется правилом эскалации.

Внешние сервисы отказывают молча. Ответ с кодом 200 и пустым телом агент считает успехом, и цепочка едет дальше на пустоте. Обёртки инструментов должны проверять содержательность ответа, а не только код.

Смена модели меняет поведение. Тот же промпт на новой версии даёт другой стиль решений, поэтому автономность без регресс-набора после каждого обновления откатывается на ступень назад.

Ответственность не делегируется. За действие агента отвечает владелец процесса, и это определяет, какие операции остаются за человеком независимо от качества модели.

Контроль стоит времени. Если проверять каждое действие вручную, экономии нет — поэтому автономность вводят классами задач, а не сразу целиком.

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

Как проверить результат

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

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

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

Запустить один и тот же вход дважды и посмотреть на количество созданных записей. Двойка означает отсутствие ключа идемпотентности.

Включить стоп-флаг во время работы и засечь, через сколько прекратятся пишущие вызовы. Если стоп-кран не проверялся ни разу, считать, что его нет.

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