Финал кластера 03. У агента есть память, состояния, инварианты. Но кто и когда жмёт «продолжить»? Сегодня — про передачу управления между моделью, кодом и человеком, и про то, почему «полностью автономный агент» в большинстве задач — это плохая архитектура.
В реальном продакшене агент не должен решать всё сам. Есть три «зоны»: где модель действует автономно, где требуется проверка кодом, где нужно подтверждение человека. Грамотный AI-инженер размечает каждую функцию агента на эти зоны и проектирует чёткие точки передачи управления. Это и есть human-in-the-loop, чек-листы перед действиями, ограждения на необратимом. Без этого даже «умный» агент периодически делает дорогие ошибки.
Маркетинговая картинка «AI-агента» обычно такая: «дай задачу, получи результат, никаких твоих действий между». Звучит привлекательно, но в подавляющем большинстве реальных продуктов это плохая идея.
Причина простая: модели ошибаются. Не катастрофически, не часто, но статистически — на тысяче запусков ошибётся 20-50. Если каждый запуск — отправка письма клиенту, бронирование, перевод денег — то 20-50 этих ошибок будут необратимыми. Стоимость одной такой ошибки часто перекрывает выгоду от автоматизации.
Поэтому хорошая архитектура агента — это не «полная автономия» и не «человек делает всё сам». Это гибкая раскладка контроля: где-то агент летит на автопилоте, где-то требует подтверждение, где-то останавливается и спрашивает.
AI-инженер не создаёт «автономного агента». Он проектирует, какие решения агент делает сам, а где останавливается и передаёт управление. Это и есть архитектура контроля.
Возвращаясь к Дню 14: инварианты ловят расхождения. Сегодня — следующий шаг: что делать при расхождении. И в принципе — на каких типах действий агент вообще не должен решать без подтверждения.
Любое действие агента можно отнести к одной из трёх зон. Каждая — свой уровень контроля и своя стоимость ошибки.
Действия, которые: обратимы, дёшевы, безопасны при любом исходе. Если агент ошибётся — ничего страшного, можно поправить.
Действия с ограниченным риском, но достаточно частые, чтобы каждое подтверждение пользователем было раздражающим. Тут включается программный контроль: инварианты, валидаторы, лимиты.
Сюда же — все инварианты из Дня 14. Если код видит, что действие нарушает инвариант — блокирует, не дойдя до настоящего выполнения. Пользователь не вовлекается в каждое решение, но и агент не действует «слепо».
Действия необратимые или с высокой стоимостью ошибки. Тут код не достаточно — нужен человек.
Здесь окупается даже довольно навязчивый UX: «нажмите «да», чтобы отправить письмо клиенту». Лучше один лишний клик, чем неотозванный косяк.
Распределение действий по зонам — это часть дизайна продукта, а не выбора модели. Один и тот же агент может быть «автономным» в одной компании и «требующим подтверждения» в другой, потому что разная стоимость ошибок, разная пользовательская база, разные риски.
Cursor, например, для «автоматического редактирования файлов» включает Y/N подтверждение по умолчанию — потому что разработчики не готовы доверять полностью. Для «поиска по коду» — нет, идёт автономно.
Главная критика «подтверждений на каждом шаге» — раздражающий UX. И эта критика справедлива, если делать наивно. Хороший HITL не должен превращать продукт в «нажмите ОК 50 раз». Несколько принципов:
Не «подтверди отправку email1, теперь email2, теперь email3». А «подтверди пакет из 3 писем», с возможностью просмотреть каждое. Один клик вместо трёх.
Не «подтвердите изменения в файле». А — конкретный diff: «эта строка удалена, эта добавлена». Понятно, на что соглашаешься.
Сначала подтверждения везде. Через 20 успешных запусков — пользователь видит «доверяете этому типу действий?». Постепенный переход в жёлтую зону.
«Отправить письмо коллеге за $0» и «перевести $10000» — это не одно подтверждение. Чем выше ставки — тем подробнее окно подтверждения.
В некоторых случаях лучше «действие выполнено, отменить?» с 30-секундным окном, чем «подтверждаете?». UX лучше, эффект тот же.
«Запоминать», что пользователь всегда одобряет такие действия. С возможностью отозвать настройку. Это уже территория procedural-памяти из Дня 11.
Что должно быть в окне «подтвердите действие», чтобы пользователь действительно понимал, на что соглашается:
Хорошее подтверждение — это не препятствие, это интерфейс уверенности. Пользователь должен лучше понимать, что делает агент, чем без него.
Когда строишь нового агента — где начинать на шкале зон?
Сильный практический совет: стартуй с красной. Сделай так, чтобы агент всё подтверждал. На первых 50-100 запусках смотри, что он предлагает, где ошибается, на чём ты соглашаешься без вопросов.
Те действия, на которые ты всегда отвечаешь «да» — это кандидаты на переход в жёлтую (программная проверка). Где постоянно говоришь «нет» — там нужен либо лучший промпт, либо инвариант, либо снять с агента эту способность вовсе.
Прогрессивно расширяй автономию, а не сужай. Начать с автономного — а потом понять, что надо ограничивать — это разгребать косяки прода. Начать с подтверждений — а потом отпустить — это спокойная эволюция продукта.
Подтверждение можно реализовать на разных уровнях:
tool: request_user_approval(action, reason). Когда модель вызывает этот «инструмент», твой код останавливает агента и идёт за подтверждением.Архитектурно вариант 3 — самый чистый. Подтверждения становятся частью графа агента, можно их логировать, считать метрики, тестировать. Не «спецслучай в коде», а нормальный инструмент.
«Вы уверены? [Да] [Отмена]» — пользователь жмёт «Да» не глядя через два запуска. Это не подтверждение, это галочка для совести разработчика.
Хорошее подтверждение должно заставлять прочитать. Конкретные данные («отправить $1500 на счёт XX»), а не абстрактные («подтвердить операцию»). Кнопка «да» — после показа того, на что соглашаешься.
Противоположная грабля: «пусть пользователь подтверждает каждое действие, мы предусмотрели всё». Через 5 минут он отключит подтверждения или забросит продукт. Подтверждение — это дорогой ресурс, тратить его на каждый шаг — расточительно.
Правило: подтверждения только в красной зоне. Жёлтую зону защищай кодом, не вопросами.
Пользователь сказал «нет» на твоё предложение → агент продолжает работать дальше, как будто ничего не было. На следующей итерации может предложить то же самое.
«Нет» — это сигнал. Он должен попадать в контекст агента: «пользователь не согласился отправить письмо, нужно выяснить почему». Без этого human-in-the-loop работает в одну сторону.
«В идеале агент должен работать без вопросов, но пока модель не дотягивает — будем подтверждать». Это путь к плохому продукту. Подтверждение — это не «временная мера до улучшения модели», это правильная архитектура для определённых действий, даже если модель будет идеальной.
Хирург с идеальной техникой всё равно спросит у пациента согласие на операцию. Это не недоверие к хирургу — это правильное распределение ответственности.
Контролируемые переходы — это слой над остальной архитектурой агента. Они опираются на:
waiting_for_approval.Кластер 03 — это переход от «агент работает» к «агентом можно доверить серьёзные задачи». Пять уроков, пять слоёв одного навыка:
Следующие кластеры разворачивают агент в две стороны — наружу (к данным мира) и внутрь (к точности на больших объёмах знаний):
Как агент достаёт свежие данные. Model Context Protocol — индустриальный стандарт подключения внешних возможностей. Конкретика к Дню 6.
Из большой базы — в текущий контекст. Эмбеддинги, реранкинг, цитаты, антигаллюцинации. Как сделать так, чтобы агент знал то, чего нет в его обучении.
Приватная альтернатива облачным моделям. Когда нужна, как разворачивать, какие компромиссы. Возврат к Дню 0.
Открой любой AI-инструмент, который что-то делает (Cursor, Claude в режиме computer use, ChatGPT с инструментами). Понаблюдай: где он действует автономно, где спрашивает подтверждение, где код блокирует ему действия. У Cursor «правка файла» — красная (Y/N). У Claude в чате «web_search» — зелёная. У ChatGPT с генерацией изображений — иногда жёлтая (фильтр контента).
Возьми идею AI-агента, который тебе нравится. Перечисли все его действия (минимум 10). Каждое — отметь цветом (зелёный/жёлтый/красный). Затем по красным — придумай UX подтверждения: что показывать, какие кнопки, какие данные пользователь должен видеть. По жёлтым — какие программные проверки нужны. Это и есть твоя архитектура контроля.
Посмотри на 5-10 окон подтверждения, которые видишь в течение дня (банк, доставка, корпоративные системы). Прогони их через «анатомию хорошего подтверждения» из урока. Какие из них правда дают тебе понимание, на что соглашаешься? Какие — формальные галочки? Разница огромная, и теперь ты её видишь.