在很多团队里，“人工介入”仍然是被动救火机制：
- AI 出错了才找人兜底；
- 评审人不知道自己该看什么；
- 不同人标准不同，结果波动很大；
- 介入后缺少结构化反馈，问题周而复始。
这会让 AI 系统陷入一种低效循环：自动化做得越多，人工越忙。
本章目标是把 Human-in-the-Loop（HITL）升级为 2.0：
- 人工介入不是临时补丁，而是策略编排的一部分；
- 人工不是替代 AI，而是校准 AI、放大系统上限。
学习目标
完成本章后，你将能够：
- 定义“何时必须人工介入”的策略触发条件。
- 设计分层评审角色与职责边界，避免全员全看。
- 建立人工评审 SLA、升级路径与回路控制。
- 将评审结论结构化沉淀，反哺 Prompt、规则与知识库。
一、先区分三种人工介入，不要一锅端
HITL 常被误解为“有人审批就行”。实际上至少有三类：
Validation：验证 AI 输出是否符合事实与规则。Decision：在策略冲突或高风险场景下做人类决策。Intervention：当链路异常时，人类直接接管执行。
不同类型应有不同响应时限和职责人。
二、触发策略：让人工介入“可预测”
人工介入应由策略引擎触发，而非主观感觉。
2.1 典型触发信号
- 风险评分高于阈值（如
riskScore >= 0.75）。 - 模型置信度低且结果影响高。
- 命中策略冲突或合规红线。
- 连续重试失败、补偿触发。
- 新版本灰度期的抽样复核。
hitl_trigger_policy:
- when: "risk_score >= 0.75"
route: "domain_reviewer"
- when: "policy_conflict == true"
route: "security_reviewer"
- when: "canary_phase == true"
sampling: "20%"核心原则：能自动判定的，不要靠人工聊天约定。
三、角色分层：每类问题给最合适的人
很多团队让同一批人审核全部任务，效率一定崩。
3.1 建议角色模型
Domain Reviewer：看业务正确性。Policy Reviewer：看合规与权限边界。Ops Reviewer：看执行影响与回滚可行性。Final Approver：高风险动作最终放行。
3.2 RACI 简化模板
- 业务准确性：
R=Domain,A=DomainLead - 合规风险：
R=Policy,A=SecurityLead - 执行安全：
R=Ops,A=PlatformLead
RACI 明确后，扯皮会明显减少。
四、评审标准化：把“经验判断”转成“评分卡”
如果没有统一评分卡，评审质量不可复现。
4.1 评分卡示例
{
"business_correctness": 4,
"policy_compliance": 5,
"action_executability": 3,
"explanation_quality": 4,
"final_decision": "revise"
}每项评分都应附“证据引用”，避免“我觉得”。
4.2 决策输出规范
approve：可执行。revise：需修订后重提。reject：不允许执行。takeover：人工直接接管链路。
五、SLA 与升级机制：避免评审变成瓶颈
HITL 失败的常见原因是排队过长。
5.1 SLA 建议
- L1 低风险评审：15 分钟内。
- L2 中风险评审：30 分钟内。
- L3 高风险评审：60 分钟内并双签。
5.2 升级规则
escalation_policy:
- if: "pending_minutes > 20 and level == L2"
then: "escalate_to_oncall_reviewer"
- if: "pending_minutes > 45 and level == L3"
then: "escalate_to_director"升级规则必须系统化，否则依赖个人责任心。
六、人工反馈结构化：每次介入都要反哺系统
评审完成后，最容易被忽略的是“反馈沉淀”。
6.1 反馈最小字段
error_type：语义偏差/策略冲突/执行不可行/证据不足root_cause：上下文不足/规则缺失/工具契约问题/Prompt 问题fix_type：规则修订/知识补充/工具改造/提示词调整owner+due_date
这些反馈应自动进入优化 backlog，不应靠手工整理。
七、双回路机制：短回路止血，长回路提效
建议拆成两个闭环：
- 短回路（当日）：
- 修复高频失败触发器；
- 更新黑名单规则与安全拦截；
- 防止同类错误继续扩散。
- 长回路（每周）：
- 更新评测样本集；
- 优化上下文路由与能力边界；
- 调整评审抽样比例与角色配置。
短回路保稳定，长回路提上限。
八、Foundation 接口建议：将 HITL 平台化
public sealed class ReviewRequest
{
public string TaskRunId { get; init; } = string.Empty;
public string RiskLevel { get; init; } = "L1";
public string RouteToRole { get; init; } = string.Empty;
public string EvidencePackRef { get; init; } = string.Empty;
}
public sealed class ReviewDecision
{
public string Decision { get; init; } = "revise"; // approve/revise/reject/takeover
public string ReasonCode { get; init; } = string.Empty;
public string FeedbackRef { get; init; } = string.Empty;
}
public interface IHumanReviewOrchestrator
{
string Submit(ReviewRequest request);
ReviewDecision Resolve(string reviewId);
}平台化后，评审能力可以跨工作流复用。
九、落地顺序（建议 2 周）
第 1 周：策略与流程
- 定义触发策略、角色路由与 SLA。
- 上线统一评分卡和决策格式。
第 2 周：系统化与反馈闭环
- 接入升级规则与排队监控。
- 打通评审反馈到优化 backlog。
- 灰度调优抽样比例，观察效率与质量平衡。
常见坑
1) 把所有任务都送人工
会快速拖垮吞吐，且削弱自动化价值。
2) 人工只给结论不给依据
无法复盘，也无法训练策略系统。
3) 没有角色分层
专家被低风险任务占满，高风险任务反而延迟。
4) SLA 只有承诺没有升级路径
超时后没人接，系统会卡死在“待审批”。
下一章我们进入《策略即代码（Policy as Code）：让治理规则版本化、可测试、可审计》，把组织规范转成真正可执行的工程资产。