人机协同，设计成系统能力

一、人机协同，就是把“什么时候叫人”设计成系统能力

人机协同，英文常叫 Human-in-the-Loop，简称 HITL。

用一句人话讲：

不是 AI 不会了才临时喊人，而是系统提前规定好：哪些事 AI 可以自己做，哪些事必须让人看，哪些事人只需要监控，哪些事人只负责制定规则。

很多人第一次做 Agent，会写出这样的逻辑：

如果 AI 觉得自己不确定，就转给人工。

听起来合理，但在真实系统里不够可靠。AI 最危险的时候，未必会说“我不确定”，它可能很自信地给出错误答案。所以，生产级 Agent 不能把“要不要叫人”完全交给 AI 自己判断。

由业务规则、风险等级、操作后果和合规要求，共同决定是否需要人工介入。

更可靠的做法，是由业务规则、风险等级、操作后果和合规要求共同决定是否需要人工介入。人机协同要解决的，就是把人的判断设计成系统能力。

二、为什么需要它：不是所有事情都适合 AI 自己决定

先用一个生活场景理解。

你去医院看病，门口通常会有分诊台。分诊护士不会自己完成所有诊断，也不会把所有人都直接送进急诊。她会判断：

  • 普通感冒，去普通门诊；
  • 胸痛、呼吸困难，立刻走急诊；
  • 症状复杂，交给专科医生；
  • 情况稳定，排队等待。

这套机制的重点不是“护士会不会看病”，而是：系统要知道什么时候该让谁接手。Agent 也是一样。

一个客服 Agent 可以自动回答“怎么修改地址”；但如果用户要退款、改合同、处理大额交易、删除数据，系统就不能只靠 AI 的自信程度来决定。

比如：

用户：请帮我把这笔 5 万元的退款直接打回原账户。
 
AI：好的，已为你处理。

没有审批，这可能就是一次严重事故。更稳妥的流程应该是：

用户提出请求
↓
Agent 理解任务并生成拟执行动作
↓
系统检查风险规则
↓
低风险：自动处理
中风险：记录并进入监控
高风险：暂停，交给人工审批
↓
审批通过后再继续执行

三、人机协同在做什么：判断、暂停、交接、恢复

人机协同通常包含四个关键动作。

动作解决的问题关键要求
判断这件事要不要人介入依据规则、风险、权限、后果，而不是只看模型自信度
暂停Agent 能不能在关键节点停住先审批后执行，不能事后通知
交接人能不能快速做决定给出摘要、原因、证据、选项、时限和追踪编号
恢复人决定后系统怎么继续从断点恢复，避免重复发邮件、重复扣款、重复提交

判断依据可以很朴素：

普通查询：AI 自动处理
修改收货地址：AI 自动处理，保留日志
大额退款：必须人工审批
删除用户数据：必须人工确认
异常登录封禁：高风险用户需要人工复核

暂停这一步尤其重要。很多 Agent 的错误，不是因为它不会思考，而是因为它太顺滑了：理解任务、调用工具、执行操作，一路跑完。如果系统只是在执行后发通知，那就不是人机协同，而是“事后告知”。

Agent 准备执行高风险动作
↓
系统发现需要审批
↓
暂停当前流程并保存上下文
↓
等待人工决定

交接给人工时，也不要只丢一句“AI 不确定，请人工处理”。好的交接应该像一份清晰的“决策包”：

{
  "type": "approval_request",
  "action_summary": "为用户办理 5 万元退款",
  "why_escalated": "退款金额超过自动审批阈值",
  "risk_level": "high",
  "evidence": ["订单已支付", "用户 30 天内已有 3 次退款记录"],
  "alternatives": ["批准", "拒绝", "修改金额后批准"],
  "deadline_minutes": 10,
  "trace_id": "refund-20260623-001"
}

人做完决定后，Agent 也不应该从头重跑，而应该从暂停点恢复：

Agent 暂停
↓
人工审批
↓
系统记录审批结果
↓
Agent 从断点继续
↓
执行后续动作
↓
写入审计日志

四、用一张图看懂基本流程

流程图画布 · 115%
Mermaid 流程图加载中...

这张图的重点是：

人不是随机插进来的，而是被策略规则请进来的。

五、三种人机关系：不是所有场景都要逐条审批

很多人一听到人机协同，就以为是“每一步都要人工确认”。这其实不现实。生产环境里，人机协同通常分成三种关系。

类型人的角色适合场景举例
人在决策中审批者、复核者高风险、不可逆操作大额退款、合同变更、医疗建议
人在监控中监督者中风险、大批量任务客服质检、内容审核、异常告警
人在策略层规则制定者高频、规则明确任务设置自动退款阈值、制定风控规则

一个退款系统里，这三种关系可以同时存在：小额退款自动处理，大额退款人工审批，整体退款率由运营和风控团队长期监控。

六、常见实现方式：从按钮到生产级机制

最简单的是加一个人工确认按钮：

AI 生成结果
↓
展示给用户
↓
用户点击确认
↓
系统执行

适合 Demo 或低复杂度系统。缺点是没有风险分级、完整审计和暂停恢复机制。

更可靠的方式是“规则引擎 + 审批队列”：

Agent 生成拟执行动作
↓
规则引擎判断风险
↓
需要人工的任务进入审批队列
↓
人工审批后继续执行

风险路由要写成明确规则，而不是让 AI 自己猜：

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';
}

生产级系统还要能暂停、持久化、恢复、审计。因为你必须回答一个问题：

如果 Agent 暂停后，服务重启了怎么办？

可以用伪代码表示：

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”的案例，把人机协同串起来。不加人机协同的危险流程可能是这样：

流程图画布 · 115%
Mermaid 流程图加载中...

这个流程太顺了：金额、用户风险、特殊订单、审批记录都没有进入系统边界。

加入人机协同后，可以这样设计：

流程图画布 · 115%
Mermaid 流程图加载中...

风险规则可以这样拆：

分流规则示例系统动作
自动处理金额小于 200 元，订单状态正常，历史退款率低直接退款并记日志
进入监控金额 200 到 1000 元，最近有少量退款记录自动退款，进入抽检
人工审批金额超过 1000 元，短时间多次退款，订单信息不完整暂停并生成审批卡片
紧急升级金额特别高，疑似欺诈，涉及投诉或法律风险升级给高级处理人

给人工的审批卡片不要写成“用户申请退款，请处理”。它应该让人一眼看清发生了什么、为什么升级、证据是什么、现在要做什么决定。

{
  "title": "退款审批请求",
  "summary": "用户申请退还订单金额 5000 元",
  "reason": "退款金额超过自动审批阈值，且用户 30 天内已有 3 次退款记录",
  "evidence": [
    "订单已支付，物流显示已签收",
    "用户申请理由为商品质量问题",
    "该商品近期同类投诉较多"
  ],
  "ai_recommendation": "建议人工复核后部分退款或要求补充凭证",
  "options": ["批准全额退款", "批准部分退款", "要求补充材料", "拒绝退款"],
  "trace_id": "refund-20260623-001"
}

审批后还要写入日志：

{
  "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、幂等键和状态机控制副作用
审批质量人只机械点“同意”高风险请求必须填理由，关键请求可二次确认
告警颗粒度每个异常都通知人工把相关事件合成一个链路或故事

比如安全系统里，不要分别推送“登录失败、异地登录、权限提升、下载大量文件”，而是合成一个事件：

某用户在异常地点登录失败多次，随后成功登录，并在短时间内下载大量敏感文件。

人机协同不是“找个人坐在那里”。真正的人机协同，要求人能理解、干预、停止和覆盖系统决策。

九、把 HITL 做成学习闭环

很多团队把人工介入看成成本。但换个角度看，人工决策其实是高质量数据。每一次人工审批，都能告诉系统：

AI 的判断哪里对？
哪里错？
什么情况应该自动化？
什么情况必须升级？
哪些规则需要调整？

可以把 HITL 数据分成几类。

数据用途
人工批准说明 AI 的建议可能是合理的
人工拒绝暴露 AI 的风险判断不足
人工修改说明 AI 方案方向对，但细节需要改
拒绝理由可以沉淀成新规则
决策耗时判断哪些升级其实没必要

长期至少看三个指标：

指标计算方式需要警惕什么
升级率需要人工处理的任务数 / 总任务数一直不降，说明 Agent 或规则没有变好
平凡升级率很快被批准且没有修改的升级 / 总升级太高，说明很多任务不该打扰人
关键否决率人工否决 AI 建议且事后证明人工正确的比例长期接近 0，可能说明人变成橡皮图章

人工介入不只是兜底，它还应该回流到规则、评估和训练数据里。

十、和上一篇、下一篇模式的关系

人机协同不是孤立存在的。它和“容错与恢复”关系很近：

容错与恢复：Agent 出错、崩溃、工具失败时，怎么恢复？
人机协同：Agent 遇到高风险、不可自动决策的情况时，怎么让人接手？

两者经常一起出现。因为一旦 Agent 暂停等人工，就必须有状态保存和断点恢复能力。它和“知识检索”也有关：

知识检索：Agent 不知道外部知识时，怎么查资料？
人机协同：Agent 即使查了资料，也不能自己决定高风险动作时，怎么请人判断？

一个常见组合是：

流程图画布 · 115%
Mermaid 流程图加载中...

十一、一个实用的设计检查表

设计人机协同时，可以用下面这份清单自查。

1. 哪些操作 AI 可以自动执行？
2. 哪些操作必须人工审批？
3. 哪些操作只需要进入监控？
4. 哪些规则由人提前制定？
5. 升级条件是否写成明确规则？
6. 是否有结构化审批信息？
7. 是否能暂停和恢复任务？
8. 是否保存了完整审计日志？
9. 人工是否能修改、拒绝或终止任务？
10. 高风险操作是否先审批后执行？
11. 是否防止重复执行副作用？
12. 是否监控人工疲劳和橡皮图章问题？
13. 人工反馈是否回流到规则和评估系统？

这份清单的核心不是“多加几个按钮”，而是确认：

人是否真的能在关键时刻影响系统行为。

人机协同不是让 AI 不会时才喊人，而是提前把“谁能决定什么、什么时候必须暂停、人工如何接手、结果如何追溯”设计进 Agent 系统里。