企业 AI 工作流怎么设计人工确认点？不要每一步都审批

本文目录

不少团队意识到 AI 不能毫无约束地操作业务系统，于是在每一步前都加一个“确认”。结果是流程看起来安全了，使用者却不断被弹窗打断，最后干脆回到手工处理。

人工确认点不该按模型调用次数设置，而应按动作会造成什么后果来设置。真正需要人介入的地方，通常是权限扩大、信息外发、资金变化、不可逆写入和责任转移。

先把动作分成四类

一个实用的起点，是把系统行为按后果分级。

下面是一种便于团队讨论的分类方法，不是固定标准。不同企业应根据数据敏感度、行业要求和内部授权调整。

动作类型	例子	默认处理
只读与分析	查询库存、读取制度、汇总工单	在最小权限和日志记录下自动执行
生成草稿	起草邮件、生成报价说明、填写表单	可自动生成，发送或提交前确认
可逆写入	更新内部标签、创建待办、保存草稿	限定范围后自动执行，并提供撤销和追踪
高后果动作	付款、删除数据、变更权限、对外承诺	强制人工批准，必要时采用双人审批

比起”AI 做了什么”，分类时更值得关注的是”做错后谁会受影响、能否撤销、多久能发现”。同样是写数据库，保存草稿与确认付款的风险完全不同。

确认一项计划，不等于确认每个步骤

为什么要区分这两件事？

复杂任务常包含十几次检索和工具调用。如果所有动作都逐次审批，人会失去上下文，也容易形成机械点击。

更合理的做法是先展示一份可理解的执行计划：目标是什么、要访问哪些数据、会调用哪些系统、哪些步骤会改变外部状态。用户批准计划后，系统自动完成低风险步骤，只在超出原计划或进入高后果动作时再次请求确认。

Anthropic 关于可信 Agent 的实践文章也讨论了类似设计：权限可以分为允许、需批准和禁止；计划模式则让用户先审查总体策略，而不是对每个动作逐一放行。

一个采购申请流程的拆法

用一个具体例子来看。

假设 AI 帮助处理内部采购申请：

1. 读取申请表和附件：只读，自动执行；
2. 提取金额、品类和需求部门：生成结构化结果，自动执行；
3. 查询供应商目录和预算余额：只读，自动执行；
4. 标记缺失材料或制度冲突：给出理由，由经办人修正；
5. 生成采购单草稿：可逆写入，自动保存但不提交；
6. 正式提交审批或向供应商发出文件：产生外部影响，人工确认。

这里的确认点只有两个：业务信息需要补正时，以及即将产生正式后果时。模型内部用了几次推理、查询了几张表，不必都变成用户操作。

确认界面必须说清三件事

信息要给足，但不能淹没用户。

一句”是否允许继续？”远远不够。确认界面至少要说明：

• 将要发生什么：写入哪个系统、发送给谁、涉及多少条数据；
• 依据是什么：引用的原始材料、规则和关键计算；
• 如何处理错误：能否撤销、谁会收到通知、拒绝后流程去哪里。

用户看到的是可判断的信息，而不是模型的长篇思考过程。对于批量动作，还应展示数量、异常项和影响范围，避免一键批准了用户并未理解的操作。

别忘了提示注入和外部内容

还有一道防线常被忽略。

当 Agent 能读取邮件、网页或外部文档时，这些内容本身可能夹带诱导指令。模型若把外部文本误当成系统命令，就可能越过原本的业务目标。OWASP 的 LLM 应用风险清单把提示注入和不安全输出处理列为重要风险。

因此，人工确认不能成为唯一防线。系统还需要隔离不可信内容、校验工具参数、限制可调用范围，并在执行前由确定性的业务规则检查金额、收件人、权限和数据范围。

“可接管”要做成系统能力

人工确认只是其中一环。

人工确认只是人机协作的一部分。生产工作流还要处理：

• 审批超时后自动转人工队列，而不是无限等待；
• 重试时使用幂等机制，避免重复发信或重复扣款；
• 保留输入、工具调用、审批人和结果，支持事后回放；
• 模型或外部系统不可用时，允许切回原流程；
• 当置信不足、数据缺失或动作超出授权时主动升级。

真正可靠的 AI 工作流，不是永远不犯错，而是错误发生前有边界、发生时能拦截、发生后可追溯。把人工确认放在后果边界上，才能同时保住效率和控制权。