Agent 工作流里必须设计人工审批节点

先说结论。

Agent 工作流里的人工审批，不是一个通用的“确认”按钮。它应该出现在风险发生之前，让审批人看到任务上下文、模型依据、即将执行的动作和可撤回范围，并留下谁在什么条件下批准了什么。

真正需要设计的不是“要不要人”，而是哪些动作必须停、交给谁、看什么证据、多久没有响应就怎么处理。

审批节点控制的是动作，不是模型回答

模型生成一段内部草稿，和把这段文字发送给客户，不是同一种风险。前者通常可修改，后者会形成外部承诺。

因此审批应该围绕动作设计：发送、发布、删除、付款、审批、改价、修改权限、写入关键系统。模型可以在审批前整理材料、提出候选动作，但不能因为输出置信度高就自动越过动作边界。

判断一个节点是否需要审批，可以问：动作是否影响外部对象，是否难以撤回，是否涉及资金、权限、隐私或合同责任。任何一项为“是”，都应进入人工控制范围。

高风险动作要在调用工具之前停下

审批放在工具调用之后，只能做事后确认。

例如 Agent 准备给客户发送延期说明。正确顺序是：读取工单和历史沟通，生成草稿，列出引用信息，提交审批，批准后再调用邮件工具。错误顺序是先发送，再让销售点击“确认已发送”。

同样，删除知识库文档、修改成员权限、创建采购单，都要在工具获得最终执行参数后、真正调用之前暂停。审批人看到的应该是确定动作，而不是一句模糊的“允许 Agent 继续”。

审批人需要看到四类证据

一个可用的审批卡至少包含：任务目标、输入来源、模型结论、拟执行动作。

任务目标说明为什么做；输入来源让人能回到原始邮件、工单或文档；模型结论要标出假设和缺失信息；拟执行动作则列出收件人、金额、字段变化或权限范围。

如果审批人必须离开页面，自己去五个系统找材料，这个节点会变成形式主义。相反，如果页面只展示模型生成的结论，没有原始来源，审批人容易被完整流畅的文字带偏。

审批不是二选一，要支持修改和降级

现实中的决定很少只有“批准”和“拒绝”。至少还应支持修改后批准、退回补充信息、转交其他角色和降级为人工处理。

以销售邮件为例，销售可能认可建议但要改价格表述；法务可能要求删除承诺语句；负责人可能认为客户等级识别错误，需要退回重新取数。系统要记录修改差异，后续才能知道问题来自生成、规则还是数据。

如果每次修改都只能复制文字到外部工具，Agent 流程就失去了反馈闭环。

审批权限要和业务权限一致

不能因为某人能打开审批页面，就默认他能批准所有动作。

审批规则应复用业务中的角色、金额范围、区域、客户归属和数据等级。普通销售可以批准自己的跟进邮件，却不一定能批准折扣；部门主管可以批准一定范围内的资源调整，但不能修改管理员权限。

还要防止“自己申请、自己批准”。当 Agent 代表某个用户发起动作时，审批身份应独立校验，不要只相信前端传来的用户名称。

超时、重复和并发是最容易漏掉的状态

审批请求发出后，不会永远停在理想状态。

需要定义：多久提醒，多久自动过期，过期后任务是取消还是转人工；同一任务重复提交时是否合并；两位审批人同时操作时以谁为准；原始数据发生变化后，旧批准是否仍有效。

一个实用原则是“批准绑定快照”。审批人批准的是当时那份输入、输出和动作参数。任何关键字段变化，都应使旧批准失效并重新提交。

审批日志必须支持责任追溯

至少记录任务 ID、工作流版本、输入快照、模型和提示版本、工具参数、审批人、审批结果、修改内容、时间和最终执行结果。

这不是为了把责任推给某个人，而是为了复盘：为什么这个动作被批准，审批时看到了什么，执行结果是否与批准内容一致。

敏感数据不应无限期完整写入日志。可以保存哈希、字段差异或受控快照，并按业务合规要求设置访问和保留周期。

常见失败是把人工变成橡皮图章

第一种失败是审批太频繁。低风险动作也逐条确认，审批人很快形成惯性点击。

第二种失败是信息太少。只有一句“是否批准”，人无法做判断。

第三种失败是风险分级缺失。内部摘要与对外付款使用同一流程，既拖慢低风险任务，也保护不了高风险动作。

第四种失败是没有反馈用途。人工改了什么没有被记录，系统永远重复同类错误。

并非所有节点都要人工审批

只读查询、内部草稿、可丢弃的分类建议和低风险提醒，可以通过抽样复核、规则校验和事后监控控制。过度审批会让流程成本高于人工原流程。

人工也不是唯一控制手段。固定金额上限、收件人白名单、字段 schema、敏感词规则、速率限制和工具权限最小化，都应该先于审批发挥作用。

边界很清楚：规则能确定拒绝的，不必交给人猜；规则无法覆盖但风险高的，才需要人在动作前做判断。

用这份清单设计第一个审批节点

1. 列出 Agent 能调用的所有写操作。
2. 按外部影响、可逆性、资金、权限和隐私分级。
3. 为高风险动作定义审批角色，避免自批。
4. 设计审批卡，放入来源、依据和确定参数。
5. 支持批准、修改、退回、转交和降级。
6. 规定超时、数据变化和并发处理方式。
7. 记录批准快照与最终执行结果。
8. 每周检查被修改和被拒绝的原因。

下一步可以从一个真实动作开始，例如“发送客户邮件”或“写回 CRM 阶段”。把它从生成到执行的每个状态画出来，再决定审批应该卡在哪里。只画一个抽象的菱形节点，远远不够。

发生了什么、真正变化与后续观察信号

发生了什么：Agent 开始获得发送、写回等工具权限。真正变化是高风险动作从模型权限中分离出来，并形成可以追责的授权时刻。后续观察信号有三项：

1. 信号一：审批人在页面停留多久、修改了哪些字段。
2. 信号二：批准后执行失败是否能回到同一审批版本。
3. 信号三：输入数据变化后，旧批准是否自动失效。

若审批长期秒过且从不修改，不一定代表模型稳定，也可能是信息不足或审批疲劳。下一步抽查一次通过、一次修改和一次超时案例，确认每个结果都能解释“人看到了什么、系统最终执行了什么”。

我的判断是，审批节点的价值应由它改变或阻止了哪些风险动作衡量，而不是由流程里有多少个人工图标衡量。