主题
人机协同，设计成系统能力
一、人机协同，就是把“什么时候叫人”设计成系统能力
人机协同，英文常叫 Human-in-the-Loop，简称 HITL。
用一句人话讲：
不是 AI 不会了才临时喊人，而是系统提前规定好：哪些事 AI 可以自己做，哪些事必须让人看，哪些事人只需要监控，哪些事人只负责制定规则。
很多人第一次做 Agent，会写出这样的逻辑：
text
如果 AI 觉得自己不确定，就转给人工。听起来合理，但在真实系统里不够可靠。AI 最危险的时候，未必会说“我不确定”，它可能很自信地给出错误答案。所以，生产级 Agent 不能把“要不要叫人”完全交给 AI 自己判断。
text
由业务规则、风险等级、操作后果和合规要求，共同决定是否需要人工介入。更可靠的做法，是由业务规则、风险等级、操作后果和合规要求共同决定是否需要人工介入。人机协同要解决的，就是把人的判断设计成系统能力。
二、为什么需要它：不是所有事情都适合 AI 自己决定
先用一个生活场景理解。
你去医院看病，门口通常会有分诊台。分诊护士不会自己完成所有诊断，也不会把所有人都直接送进急诊。她会判断：
- 普通感冒，去普通门诊；
- 胸痛、呼吸困难，立刻走急诊；
- 症状复杂，交给专科医生；
- 情况稳定，排队等待。
这套机制的重点不是“护士会不会看病”，而是：系统要知道什么时候该让谁接手。Agent 也是一样。
一个客服 Agent 可以自动回答“怎么修改地址”；但如果用户要退款、改合同、处理大额交易、删除数据，系统就不能只靠 AI 的自信程度来决定。
比如：
text
用户：请帮我把这笔 5 万元的退款直接打回原账户。
AI：好的，已为你处理。没有审批，这可能就是一次严重事故。更稳妥的流程应该是：
text
用户提出请求
↓
Agent 理解任务并生成拟执行动作
↓
系统检查风险规则
↓
低风险：自动处理
中风险：记录并进入监控
高风险：暂停，交给人工审批
↓
审批通过后再继续执行三、人机协同在做什么：判断、暂停、交接、恢复
人机协同通常包含四个关键动作。
| 动作 | 解决的问题 | 关键要求 |
|---|---|---|
| 判断 | 这件事要不要人介入 | 依据规则、风险、权限、后果，而不是只看模型自信度 |
| 暂停 | Agent 能不能在关键节点停住 | 先审批后执行，不能事后通知 |
| 交接 | 人能不能快速做决定 | 给出摘要、原因、证据、选项、时限和追踪编号 |
| 恢复 | 人决定后系统怎么继续 | 从断点恢复，避免重复发邮件、重复扣款、重复提交 |
判断依据可以很朴素：
text
普通查询：AI 自动处理
修改收货地址：AI 自动处理，保留日志
大额退款：必须人工审批
删除用户数据：必须人工确认
异常登录封禁：高风险用户需要人工复核暂停这一步尤其重要。很多 Agent 的错误，不是因为它不会思考，而是因为它太顺滑了：理解任务、调用工具、执行操作，一路跑完。如果系统只是在执行后发通知，那就不是人机协同，而是“事后告知”。
text
Agent 准备执行高风险动作
↓
系统发现需要审批
↓
暂停当前流程并保存上下文
↓
等待人工决定交接给人工时，也不要只丢一句“AI 不确定，请人工处理”。好的交接应该像一份清晰的“决策包”：
json
{
"type": "approval_request",
"action_summary": "为用户办理 5 万元退款",
"why_escalated": "退款金额超过自动审批阈值",
"risk_level": "high",
"evidence": ["订单已支付", "用户 30 天内已有 3 次退款记录"],
"alternatives": ["批准", "拒绝", "修改金额后批准"],
"deadline_minutes": 10,
"trace_id": "refund-20260623-001"
}人做完决定后，Agent 也不应该从头重跑，而应该从暂停点恢复：
text
Agent 暂停
↓
人工审批
↓
系统记录审批结果
↓
Agent 从断点继续
↓
执行后续动作
↓
写入审计日志四、用一张图看懂基本流程
这张图的重点是：
text
人不是随机插进来的，而是被策略规则请进来的。五、三种人机关系：不是所有场景都要逐条审批
很多人一听到人机协同，就以为是“每一步都要人工确认”。这其实不现实。生产环境里，人机协同通常分成三种关系。
| 类型 | 人的角色 | 适合场景 | 举例 |
|---|---|---|---|
| 人在决策中 | 审批者、复核者 | 高风险、不可逆操作 | 大额退款、合同变更、医疗建议 |
| 人在监控中 | 监督者 | 中风险、大批量任务 | 客服质检、内容审核、异常告警 |
| 人在策略层 | 规则制定者 | 高频、规则明确任务 | 设置自动退款阈值、制定风控规则 |
一个退款系统里，这三种关系可以同时存在：小额退款自动处理，大额退款人工审批，整体退款率由运营和风控团队长期监控。
六、常见实现方式：从按钮到生产级机制
最简单的是加一个人工确认按钮：
text
AI 生成结果
↓
展示给用户
↓
用户点击确认
↓
系统执行适合 Demo 或低复杂度系统。缺点是没有风险分级、完整审计和暂停恢复机制。
更可靠的方式是“规则引擎 + 审批队列”：
text
Agent 生成拟执行动作
↓
规则引擎判断风险
↓
需要人工的任务进入审批队列
↓
人工审批后继续执行风险路由要写成明确规则，而不是让 AI 自己猜：
typescript
type RiskLevel = 'auto' | 'notify' | 'approve' | 'urgent';
function routeAction(action: Action, context: Context): RiskLevel {
if (action.type === 'delete_user_data') return 'approve';
if (action.type === 'refund' && action.amount > 10000) return 'approve';
if (context.userRiskScore > 0.8) return 'urgent';
if (context.userRiskScore > 0.4) return 'notify';
return 'auto';
}生产级系统还要能暂停、持久化、恢复、审计。因为你必须回答一个问题：
text
如果 Agent 暂停后，服务重启了怎么办？可以用伪代码表示：
typescript
async function approvalGate(state: AgentState) {
const risk = evaluateRisk(state.proposedAction, state.context);
if (risk.requiresHuman) {
const decision = await interruptAndWait({
type: 'approval_request',
summary: state.proposedAction.summary,
reason: risk.reason,
options: ['approve', 'reject', 'modify'],
traceId: state.traceId
});
return { ...state, humanDecision: decision };
}
return { ...state, humanDecision: 'auto_approved' };
}这里的关键不是 interruptAndWait 这个函数名，而是它背后的机制：保存状态、按任务 ID 恢复、从断点继续，并避免重复执行副作用。
七、完整案例：一个智能退款 Agent 应该怎么设计
下面用一个“智能退款 Agent”的案例，把人机协同串起来。不加人机协同的危险流程可能是这样：
这个流程太顺了：金额、用户风险、特殊订单、审批记录都没有进入系统边界。
加入人机协同后，可以这样设计：
风险规则可以这样拆：
| 分流 | 规则示例 | 系统动作 |
|---|---|---|
| 自动处理 | 金额小于 200 元，订单状态正常，历史退款率低 | 直接退款并记日志 |
| 进入监控 | 金额 200 到 1000 元，最近有少量退款记录 | 自动退款，进入抽检 |
| 人工审批 | 金额超过 1000 元，短时间多次退款，订单信息不完整 | 暂停并生成审批卡片 |
| 紧急升级 | 金额特别高，疑似欺诈，涉及投诉或法律风险 | 升级给高级处理人 |
给人工的审批卡片不要写成“用户申请退款，请处理”。它应该让人一眼看清发生了什么、为什么升级、证据是什么、现在要做什么决定。
json
{
"title": "退款审批请求",
"summary": "用户申请退还订单金额 5000 元",
"reason": "退款金额超过自动审批阈值，且用户 30 天内已有 3 次退款记录",
"evidence": [
"订单已支付，物流显示已签收",
"用户申请理由为商品质量问题",
"该商品近期同类投诉较多"
],
"ai_recommendation": "建议人工复核后部分退款或要求补充凭证",
"options": ["批准全额退款", "批准部分退款", "要求补充材料", "拒绝退款"],
"trace_id": "refund-20260623-001"
}审批后还要写入日志：
json
{
"trace_id": "refund-20260623-001",
"decision": "partial_refund",
"approver_id": "operator-007",
"rationale": "用户提供了部分质量问题证据，但商品已使用，批准部分退款",
"final_amount": 3000,
"model_version": "agent-policy-2026-06",
"created_at": "2026-06-23T11:03:50"
}这就是可追溯的人机协同。
八、生产级 HITL 必须注意什么
| 设计点 | 常见错误 | 更稳妥的做法 |
|---|---|---|
| 升级触发 | 如果 AI 没信心，就叫人 | 如果命中高风险规则，就叫人 |
| 执行顺序 | 先执行操作，再请求审批 | 准备执行 → 风险判断 → 暂停 → 审批 → 执行 |
| 副作用 | 恢复两次就退款两次 | 用任务 ID、幂等键和状态机控制副作用 |
| 审批质量 | 人只机械点“同意” | 高风险请求必须填理由，关键请求可二次确认 |
| 告警颗粒度 | 每个异常都通知人工 | 把相关事件合成一个链路或故事 |
比如安全系统里，不要分别推送“登录失败、异地登录、权限提升、下载大量文件”，而是合成一个事件：
text
某用户在异常地点登录失败多次，随后成功登录，并在短时间内下载大量敏感文件。人机协同不是“找个人坐在那里”。真正的人机协同，要求人能理解、干预、停止和覆盖系统决策。
九、把 HITL 做成学习闭环
很多团队把人工介入看成成本。但换个角度看，人工决策其实是高质量数据。每一次人工审批，都能告诉系统：
text
AI 的判断哪里对？
哪里错？
什么情况应该自动化？
什么情况必须升级？
哪些规则需要调整？可以把 HITL 数据分成几类。
| 数据 | 用途 |
|---|---|
| 人工批准 | 说明 AI 的建议可能是合理的 |
| 人工拒绝 | 暴露 AI 的风险判断不足 |
| 人工修改 | 说明 AI 方案方向对，但细节需要改 |
| 拒绝理由 | 可以沉淀成新规则 |
| 决策耗时 | 判断哪些升级其实没必要 |
长期至少看三个指标：
| 指标 | 计算方式 | 需要警惕什么 |
|---|---|---|
| 升级率 | 需要人工处理的任务数 / 总任务数 | 一直不降，说明 Agent 或规则没有变好 |
| 平凡升级率 | 很快被批准且没有修改的升级 / 总升级 | 太高，说明很多任务不该打扰人 |
| 关键否决率 | 人工否决 AI 建议且事后证明人工正确的比例 | 长期接近 0，可能说明人变成橡皮图章 |
人工介入不只是兜底，它还应该回流到规则、评估和训练数据里。
十、和上一篇、下一篇模式的关系
人机协同不是孤立存在的。它和“容错与恢复”关系很近：
text
容错与恢复：Agent 出错、崩溃、工具失败时，怎么恢复？
人机协同：Agent 遇到高风险、不可自动决策的情况时，怎么让人接手？两者经常一起出现。因为一旦 Agent 暂停等人工，就必须有状态保存和断点恢复能力。它和“知识检索”也有关：
text
知识检索：Agent 不知道外部知识时，怎么查资料？
人机协同：Agent 即使查了资料，也不能自己决定高风险动作时，怎么请人判断？一个常见组合是：
十一、一个实用的设计检查表
设计人机协同时，可以用下面这份清单自查。
text
1. 哪些操作 AI 可以自动执行？
2. 哪些操作必须人工审批？
3. 哪些操作只需要进入监控？
4. 哪些规则由人提前制定？
5. 升级条件是否写成明确规则？
6. 是否有结构化审批信息？
7. 是否能暂停和恢复任务？
8. 是否保存了完整审计日志？
9. 人工是否能修改、拒绝或终止任务？
10. 高风险操作是否先审批后执行？
11. 是否防止重复执行副作用？
12. 是否监控人工疲劳和橡皮图章问题？
13. 人工反馈是否回流到规则和评估系统？这份清单的核心不是“多加几个按钮”，而是确认：
text
人是否真的能在关键时刻影响系统行为。人机协同不是让 AI 不会时才喊人，而是提前把“谁能决定什么、什么时候必须暂停、人工如何接手、结果如何追溯”设计进 Agent 系统里。