Human-in-the-Loop для AI-агентов: approval, escalation и pause/resume

Короткая версия

HITL особенно нужен в четырёх случаях:

1. High-impact actions
2. Low confidence или ambiguity
3. Policy и compliance boundaries
4. Exception handling

Хороший human-in-the-loop path умеет:

• поставить workflow на pause до side effect;
• показать человеку compact approval packet;
• принять approve, reject, edit или escalate;
• продолжить workflow с сохранённым state.

Когда approval step должен стоять - до tool call или после?

1. Где HITL действительно оправдан

Не every агентный workflow требует человека. Но есть зоны, где отсутствие human gate быстро становится operational problem.

Денежные и юридически значимые действия

• refunds;
• billing changes;
• contract redlines;
• policy exceptions;
• compliance-sensitive approvals.

Действия с внешними побочными эффектами

• email send;
• CRM update;
• browser/computer use;
• ticket creation;
• code execution;
• запуск внешнего workflow.

Низкая уверенность и конфликт сигналов

Например:

• retrieval и tool output противоречат друг другу;
• agent plan выглядит plausible, но trace показывает repeated failures;
• модель предлагает risky action на неполной информации;
• policy layer и user intent расходятся.

2. Approval - не единственный режим

Практически полезно различать несколько human decisions:

Если система умеет только yes / no, она слишком быстро сталкивается с реальной операционной сложностью.

3. Как выглядит хороший approval packet

Самая частая ошибка - показать человеку либо весь trace, либо почти ничего.

Хороший approval packet обычно содержит:

• proposed action;
• affected entity;
• краткое обоснование;
• key evidence;
• risk flags;
• editable payload;
• trace link для глубокого разбора.

То есть оператору нужен не весь внутренний reasoning, а минимум контекста, достаточный для решения.

4. Pause / resume важнее approval UI

Многие команды продумывают красивую кнопку approval, но не продумывают, как workflow продолжится после решения человека.

После approve или edit система должна:

• знать, на каком step она была остановлена;
• не повторить уже завершённые действия;
• вернуть агенту точный human decision payload;
• сохранить audit trail по всей цепочке.

Именно поэтому HITL почти всегда требует:

• durable state;
• step IDs;
• явную границу proposed vs committed;
• idempotent side effects.

Без этого один approval click легко приводит к duplicated action.

5. Что отправлять в review queue

Кроме очевидных high-risk actions, в human review часто полезно отправлять:

• low-confidence final answers в high-stakes domain;
• repeated tool failures;
• policy disagreements;
• out-of-distribution запросы;
• long-running agents с нестабильной траекторией.

Это даёт не только safety, но и product signal:

• где automation boundary ещё не готова;
• какие кейсы надо покрыть eval-наборами;
• где policy слишком жёсткая или, наоборот, дырявая.

6. Что ломает human-in-the-loop

Approval fatigue

Если в очередь уходит слишком много trivial решений, операторы начинают mechanically approve almost everything.

Late review

Человек видит уже committed action и ничего не контролирует.

Нет ownership model

Непонятно, кто отвечает за итог: агент, оператор первой линии или старший reviewer.

Нет audit-grade traces

Потом невозможно понять:

• что предложил агент;
• что изменил человек;
• почему действие всё же было выполнено.

7. Какие метрики полезны

Минимальный HITL dashboard обычно включает:

• approval rate;
• reject rate;
• edit-before-approve rate;
• median time in review queue;
• post-approval incident rate;
• unnecessary-human-review rate;
• escalation rate.

Отдельно полезно смотреть automation coverage with acceptable risk, а не просто процент кейсов "без человека".

Пример approval payload

{
  "workflow_id": "wf_821",
  "step_id": "refund_proposal_3",
  "action": "issue_refund",
  "entity_id": "order_1842",
  "proposed_args": {
    "amount": 129.0,
    "reason": "duplicate_charge"
  },
  "risk_flags": ["money_movement", "policy_exception"],
  "evidence": [
    "billing tool shows duplicate transaction",
    "customer eligible under refund policy v7"
  ]
}

Минимальный pause / resume flow

def request_approval(workflow_id, step_id, payload):
    save_pending_decision(workflow_id, step_id, payload)
    return {"status": "paused", "awaiting": "human_review"}

def resume_after_human(decision):
    if decision["type"] == "reject":
        return {"status": "stopped"}
    if decision["type"] == "edit":
        return continue_workflow(with_payload=decision["edited_payload"])
    return continue_workflow(with_payload=decision["approved_payload"])

Практический совет: разделяйте plan, proposal и commit. Именно эта тройка обычно делает human decision воспроизводимым и не даёт workflow повторно прожимать already-approved side effects.