Human-in-the-loop: где ставить approval gates в инженерном агенте

Короткий ответ

Human-in-the-loop: где ставить approval gates в инженерном агенте — это production-задача, а не демонстрационный prompt. Практический принцип: ставить подтверждение перед необратимыми, дорогостоящими или нормативно значимыми действиями, а не после них. Ключевое решение: человек должен видеть не общий вопрос «продолжить?», а конкретный diff, аргументы tool-call, последствия и способ отката. В инженерной среде результат принимается по evidence, traceability и воспроизводимой проверке, а не по уверенности формулировки модели.

Граница системы и предмет контроля

Агентный контур отличается от обычного чата наличием цикла действий. Модель не только формирует текст, но выбирает инструмент, передаёт типизированные аргументы, получает результат, обновляет состояние и решает, требуется ли следующий шаг. Поэтому объект проектирования — не prompt как строка, а полный runtime: модель, tools, permissions, state, approvals, verifier и журнал выполнения.

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

Что должно быть определено до запуска

Артефакты и архитектурные границы

Архитектуру агента удобно раскладывать на control plane и execution plane. В control plane находятся policy, identity, лимиты, approvals и выбор маршрута; в execution plane — конкретные tools, очереди, sandbox и внешние API. Такое разделение не даёт модели самостоятельно расширять собственные полномочия и позволяет независимо версионировать orchestration и исполнительные компоненты.

Контракт tool должен быть строже естественного языка: схема аргументов, единицы, enum, обязательность полей, idempotency key, ожидаемые ошибки и postcondition. Если инструмент меняет реальный объект, ответ «200 OK» недостаточен — нужен change receipt и повторное чтение состояния либо другой независимый verifier.

Практический workflow

После tool-call проверяется не текстовый комментарий модели, а фактический результат инструмента: код возврата, схема ответа, изменённый объект и ожидаемая postcondition. Несовпадение переводит задачу в controlled exception и блокирует следующий side effect.

Инженерный сценарий

Для agent workflow удобно иметь три режима: dry-run без side effects, execute-with-approval и bounded execution. Переход между ними определяется классом риска и зрелостью eval-набора.

Что измерять

Для агента итоговая точность без анализа траектории недостаточна. Одновременно контролируют success, выбор tools, число шагов, вмешательства человека, policy violations, latency и стоимость успешной задачи.

Критерии приёмки

Failure modes и защитные меры

• автоматическое подтверждение привычных действий. Защитная мера: approval до side effect; событие сохраняется как regression/incident case.
• approval fatigue. Защитная мера: двухуровневая проверка для критических операций; событие сохраняется как regression/incident case.
• подмена параметров после подтверждения. Защитная мера: time-bound approval; событие сохраняется как regression/incident case.
• неясный объект согласования. Защитная мера: не переносить approval на изменившийся payload; событие сохраняется как regression/incident case.
• отсутствие владельца решения. Защитная мера: read-only preview; событие сохраняется как regression/incident case.

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

Пилотный агент получает один класс задач и минимальный набор tools. Сначала снимаются traces в read-only/dry-run, затем добавляются approvals для side effects. Model upgrade и изменение tool schema проходят один и тот же regression suite; несовместимый schema change блокирует rollout.

Перед выдачей write-доступа отдельно тестируют timeouts, retry, duplicate delivery, partial failure и отмену задачи. Canary-версия получает ограниченную долю трафика и budget; превышение intervention/rollback threshold автоматически возвращает стабильную версию.

Traceability и эксплуатационная запись

Минимальный trace: task ID, actor identity, model/runtime, prompt/template, список доступных tools, каждый tool-call с аргументами и результатом, policy decision, approval, state transition, verifier и final status.

Чек-лист перед production

Навигация по Wave AI R5 · часть 1 из 5