工作流智能体的审批、人工确认和超时升级怎么设计

答案摘要：工作流智能体的审批、人工确认和超时升级，应围绕动作风险、审批依据、任务版本和可恢复性设计。聚匠科技通常让 AI 负责理解资料、生成建议和准备参数，把付款、改价、外部发送、权限开通与关键业务写入放在受控审批之后；执行前再次校验对象版本，超时则提醒、转派、失效或转人工，不把“无人处理”自动解释为同意。

先按业务后果分级，不让所有节点共用一种审批

制度检索、工单分类和内部草稿可以自动生成并抽检；修改订单、库存、合同、客户状态或账号权限的动作，需要规则校验与责任人确认；付款、退款、删除数据和对外承诺还要限制审批人、有效期与执行账号。分级依据应写进流程配置和验收用例，不能只放在提示词中。

同一流程可以混合使用 AI、固定规则、人工和业务接口。节点如何分工可先参考工作流智能体与固定自动化选型，再在工作流智能体核心页中确定交付边界。

一张确认单要绑定资料版本和拟执行参数

确认页面不能只显示“是否同意智能体执行”。每次审批应形成一个不可混用的确认包，包含原始请求、AI 提取结果、引用资料、规则判断、工具名称、关键参数、影响对象、失败处理和截止时间。审批人修改参数后，系统保存修改前后差异，并生成新的待执行版本。

• 身份：发起人、审批人、代理关系及授权有效期。
• 证据：制度、合同、订单或客户记录的版本与读取时间。
• 动作：工具、参数、读写字段、对象范围和预期状态变化。
• 版本：审批版本、业务对象版本和流程配置版本。
• 回执：接口结果、外部业务单号、后续责任人与查单入口。

审批通过后若订单金额、库存、合同版本、客户状态或人员权限发生变化，执行端应使用对象版本做并发校验。条件不匹配就退回待确认，不能拿旧审批继续写入；审批只授权当时看到的参数，不是给智能体一段时间内的通用写权限。

转派和共享队列要防止两个人同时接手

超时升级常见的问题不是没有提醒，而是原审批人、主管和共享队列同时看到任务后重复处理。任务被领取时应记录处理人、领取时间和租约到期时间；转派或租约过期后，旧处理令牌失效。提交审批结论时再次校验任务版本与当前处理人，避免两份人工结论同时触发工具调用。

需要多人会签时，应明确是全部同意、任一同意还是按角色顺序审批，并分别记录各自看到的参数版本。审批过程中参数变化，应使旧签字失效并重新确认，而不是把不同版本的意见拼成一次放行。

超时不是一个状态，要区分提醒、升级、失效和终止

1. 提醒：通知原责任人，不改变审批结果和任务所有权。
2. 升级：转给主管或共享队列，原处理令牌失效，保留转派原因。
3. 失效：金额、库存、报价或权限等时效条件过期后，关闭执行入口并重新取数。
4. 业务终止：外部订单已取消、合同已变更或客户撤回请求时，结束流程而非继续催办。
5. 转人工：接口状态未知、规则冲突或无法安全补偿时，保留上下文交给指定人员。

跨 CRM、OA、ERP 或工单系统时，可在多系统协同 AI中把各系统业务单号与智能体任务关联。这样恢复处理前可以判断任务停在哪个系统、哪些动作已经发生、哪些仍允许执行。

确认之后仍要用幂等、查单和补偿守住执行结果

人工同意不等于业务已经完成。浏览器刷新、消息重投或网络超时都可能重复触发同一动作。每个写入节点使用稳定业务幂等键，保存请求摘要、审批版本、工具结果和外部单号；超时先查外部系统，再决定重试。ERP 场景中的接口级权限与幂等细节由ERP 工具权限与幂等键指南承接，本文只负责审批包、任务转派与超时恢复。

任务状态至少区分待资料、待审批、已转派、执行中、结果未知、已完成、待人工、已失效和补偿中。多系统部分成功时逐项记录已发生的写入和可用补偿，不用“整体失败”掩盖真实业务状态。

验收要覆盖版本变化和多人并发

• 正常审批后修改参数，确认系统只执行获批版本。
• 审批期间改变订单、库存或人员权限，确认旧审批不能继续执行。
• 让原责任人和共享队列同时领取，确认只有当前处理令牌可以提交。
• 测试拒绝、转派、会签、超时失效和业务终止，核对通知、状态和责任人。
• 重复点击确认并模拟接口超时，确认只产生一个业务结果且可查单。
• 执行停止新任务、处理在途任务和恢复旧版本，核对日志与人工接管。

责任人不明确、规则频繁变化、接口无法鉴权或回查、关键写入没有幂等、参数变化不会使审批失效，或出错后没有人工接管人时，不适合直接自动执行。可以先按影子运行与分级放权只生成建议和草稿，待任务版本、权限、日志与异常负责人稳定后再开放工具调用。

说明：本文为企业工作流智能体审批与异常接管的通用方法，具体权限、数据处理、审批责任和恢复范围应结合企业制度、系统能力及适用要求确认，不构成效果承诺。