ИИ-агенты с контролем человека: когда строить ворота одобрения (и когда нет)

Оглавление

Опубликовано в июле 2026 года.

TL;DR: Ворота одобрения имеют смысл, когда ошибка дорогостоящая, необратимая или затрагивает клиентов — и когда человек может её поймать вовремя. Нет смысла, когда объём слишком велик для проверки, ошибки дёшево исправляются или люди одобряют не читая. Я использую четыре вопроса для решения, и большинство моих 30+ производственных агентов работают полностью автоматически.

Заметка оператора: Я запускаю агентов в двух бизнесах — консалтинговый бренд и Pickleland, площадка для пиклбола в Пфлугервилле, Техас. Поначалу я везде ставил ворота одобрения, потому что это казалось «безопасным». Через несколько недель у меня был Slack-канал, заполненный уведомлениями, которые никто не читал, и агенты, технически находящиеся под наблюдением, но практически бесконтрольные. Это хуже, чем никаких ворот: иллюзия надзора без существа. Эта статья объясняет, как я сейчас думаю об этом решении.

Что такое ворота контроля человека на самом деле

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

Ворота могут быть синхронными (агент блокируется, пока кто-то не одобрит) или асинхронными (агент ставит действие в очередь, отправляет уведомление, и человек одобряет из дашборда или Slack-сообщения в своём темпе). Асинхронный вариант почти всегда лучше для всего, что не является критически важным по времени, так как синхронные ворота создают противодавление в очереди и нарушают гарантии надёжности агента.

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

Четыре вопроса, которые я задаю

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

1. Является ли действие необратимым (или дорогостоящим для отмены)?

Отправить письмо 10 000 людям нельзя отозвать. Отправить платёж нельзя легко вернуть. Удалить запись в базе данных без резервной копии — это навсегда. Необратимость — наиболее веский аргумент в пользу ворот, потому что агент не может отменить то, что сделал.

Сравните с: отметить входящий запрос категорией. Если метка неверна, исправите за два клика. Ворота не нужны.

2. Если агент ошибается, кто платит?

Внутренняя метка неверна — трачу несколько секунд на исправление. Клиентское письмо неверно — клиент платит плохим опытом, я плачу потерей доверия. Финансовая транзакция неверна — плачу реальными деньгами и потенциальным риском соответствия.

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

3. Может ли человек реально обнаружить ошибку до того, как она будет важна?

Это вопрос, который большинство людей пропускают, и он устраняет больше ворот, чем любой другой. Если агент обрабатывает 500 элементов в час и вы получаете одно Slack-уведомление на элемент, никто не прочитает все 500. Вы создаёте усталость от оповещений, а не надзор.

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

4. Читают ли люди надёжно то, что представляет агент?

Если ваша очередь одобрения заполняется и люди одобряют, не читая, ворота хуже, чем их отсутствие — создаётся ложная уверенность, что человек проверил работу.

Когда ворота явно имеют смысл

Это паттерны, где я всегда добавляю ворота, без исключений:

• Необратимые внешние коммуникации — письма, SMS, посты в соцсетях реальным людям. Агент составляет черновик; человек отправляет. В зависимости от объёма.
• Финансовые действия выше порога — всё, что перемещает деньги, получает ворота, если превышает минимум в рублях/долларах, который я устанавливаю по контексту.
• Новые паттерны, которые агент не видел раньше — если классификатор агента отмечает что-то как «неизвестное» или за пределами его обучающего распределения, это принудительная эскалация.
• Выходные данные, чувствительные к соответствию — всё, что касается HIPAA, PCI, юридических уведомлений или регулируемого финансового контента, проверяется человеком.

Когда ворота незаметно убивают продукт

Это паттерны, где ворота кажутся безопасными, но незаметно ломают принятие:

• Высокообъёмные, обратимые операции — если можно отменить за два клика и это происходит 200 раз в день, усталость от проверки победит.
• Срочные рабочие процессы — агент, отвечающий на входящие запросы клиентов за 30 секунд, не должен иметь синхронных ворот.
• Задачи, где у человека меньше контекста, чем у агента — если агент прочитал 50 страниц контекста для классификации, а рецензент получает однострочное резюме, проверка — это театр.
• Внутреннее обогащение и маркировка — теги для записей CRM, категоризация расходов, суммирование заметок встреч. Ставки не оправдывают прерывания.

Три паттерна ворот, которые я реально реализую

Когда ворота оправданы, я выбираю одну из трёх реализаций:

1. Асинхронное одобрение через Slack/почту

Агент завершает черновик, публикует сообщение в назначенный Slack-канал с предложенным действием и кнопками одобрить/отклонить, и делает паузу. Я использую Cloudflare Queues для хранения ожидающего действия и отдельный Worker, который слушает веб-хук одобрения перед возобновлением.

Хорошо работает для: черновиков писем, контента для соцсетей, важных обновлений CRM.

2. Эскалация на основе уверенности

Агент работает полностью автоматически для высокоуверенных выходных данных (скажем, ≥0,85 уверенности на структурированной схеме) и направляет низкоуверенные элементы в очередь к человеку. Человек видит только неоднозначные пограничные случаи.

Хорошо работает для: классификации, маршрутизации, триажа.

3. Проверка в дашборде с пакетным одобрением

Вместо ворот на элемент, все выходные данные агента попадают в дашборд проверки. Человек проверяет пакетами — например, каждое утро — и одобряет или исправляет группами.

Хорошо работает для: генерации контента, составления отчётов, запланированных резюме.

Ловушка усталости от оповещений

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

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

Связь с надёжностью агента

Ворота — это один слой стека надёжности, не весь стек. Мой полный стек надёжности для производственного агента:

1. Оценочная система — подтверждает правильные выходные данные перед развёртыванием.
2. Структурированные выходные данные с валидацией схемы — выходные данные агента ограничены типизированной схемой.
3. Порог уверенности — низкоуверенные выходные данные идут на проверку к человеку.
4. Журнал аудита — каждое действие агента записывается с входными данными, выходными данными и метаданными вызовов модели.
5. Ворота одобрения человека — только для действий, где вышеперечисленного недостаточно.

Моё практическое правило

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

FAQ

Как обращаться с агентом, которому нужно одобрение, но он работает с большим объёмом?

Измените архитектуру: не требуйте одобрения на элемент — требуйте одобрения на паттерн. Пусть агент работает, но пусть он представляет статистические аномалии для проверки человека.

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

Обычно это сигнал не развёртывать агента для этого действия ещё. Или используйте порог уверенности. Если вы используете Claude как слой модели, паттерны использования инструментов Anthropic SDK позволяют легко определить инструмент «эскалации», который агент может вызвать, когда ему не хватает уверенности.