## 大额采购多路并行审批 {.case data-case-id="062"} | 字段 | 值 | | --- | --- | | 案例编号 | `062` | | 行业 / 部门 | 金融 / 采购 | | 角色 | 采购负责人 | | 难度 | `复杂` | | 调用来源 | `manual`（大额采购申请提交后由采购发起一次手动调用，带入申请摘要的代号化条目与审批人清单） | 大额采购申请靠邮件逐个找人签批，一人出差整单就卡住，回头还找不到是谁没批。目标：申请提交后由采购发起一次调用，同时向采购负责人、财务、法务发起确认——全部确认后才放行进入下单流程，任一驳回则整单退回；超 48 小时未响应由另一条定时编排汇总提醒。下单由人在采购系统执行，工作流不直接下单。指标：从本次调用启动到全部审批完成的中位数 ≤ 2 个工作日；任一驳回后整单 100% 退回，不出现"部分通过即放行"；超 48 小时未响应项 100% 被提醒覆盖。 - **覆盖**：手动调用带入申请摘要的代号化条目（品类、数量、金额区间、供应商代号、事由）与审批人清单、并行发起多路审批、全部通过才放行、任一驳回整单退回、48 小时未响应汇总提醒、放行后由人在系统内下单。 - **不覆盖**：自动创建或提交订单、自动比价、审批通过后自动付款、审批规则维护。 - **假设**：申请摘要（品类、数量、金额区间、供应商代号、事由）与审批人清单由采购在调用时作为输入提供；金额只给区间，供应商用代号，不带名称与报价明细。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：大额采购申请提交后，由采购发起一次手动调用，用三条并行分支分别创建独立的 `request_approval`，交给采购负责人、财务、法务三位 Human assignee 决定；金额只用区间（如 50 万至 100 万），供应商只用代号，不外带名称与报价明细。 触发：手动发起调用，调用时带入申请摘要的代号化条目（品类、数量、金额区间、供应商代号、事由）、采购负责人 / 财务 / 法务三位 Human 成员引用与采购频道；每个 `request_approval` Effect 在创建时冻结对应 assignee，后续成员目录变化不改本次审批对象。 并行审批语义：三条并行分支各创建一个独立 `request_approval`，分别冻结采购负责人、财务、法务的 Human assignee；它们是三个独立 Approval Effect，不是审批 Agent，也不等待 Agent callback 或“完成请求”。某一路由认证 Human 提交 `approved` 后只更新自己的分支结果，三路全部 `approved` 才经显式汇合节点放行进入下单流程（由人在采购系统执行下单，工作流不直接下单），放行通知附三份审批记录并留审计时间戳与操作人；任一路认证终态为 `rejected` 即整单退回，通知发起人附驳回理由并留审计时间戳，其他已确认记录保留不撤回。 超时提醒：审批不设自动超时，也不自动通过或驳回；发起后超过 48 小时仍未响应的，提醒从汇合节点的整体等待态发出，由另一条定时编排的 Workflow 汇总提醒（提醒不是审批的一部分，也不改变审批状态与各等待位）。 本期无待审批申请（查询成功但清单为空）：发一条"本期无待审批申请"汇总回执并留时间戳，不静默结束，也不当作输入不完整。 取数失败（输入清单不完整：申请摘要缺品类或金额区间、审批人清单为空或角色缺失）：不重试——同一调用的不完整输入不会因重跑补齐；告警失败、留审计时间戳，并通知调用方（采购）更正输入后新开一次调用，而不是对相同数据重试。 审批：大额采购放行必须全部审批人确认，职责分离——采购负责人看供需，财务看预算，法务看合规，任何一方无权代替其他方确认；每一路审批均为二值确认或驳回，不设自动超时，无默认通过/否决；任一驳回即整单退回。 异常：某一路收到非 `approved` / `rejected`、身份与冻结 assignee 不符或决定幂等信息不合法的 decision 时，由 approval service 拒绝该请求；该 Approval 仍保持 pending，之后可由冻结 Human assignee 提交合法决定，其他两份 Approval 的状态不受影响，也不触发全局重提。通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：放行、整单退回、零结果回执各自留审计时间戳与操作人后结束。 ``` ![案例 062 大额采购多路并行审批：采购手动调用，以三条并行分支分别创建独立 request_approval 并冻结采购负责人、财务、法务三位 Human assignee；非法 decision 由 approval service 拒绝、该 Approval 保持 pending，其他两路不受影响。三份 Approval 全部 approved 后才经汇合节点放行进入下单流程（人在采购系统执行，工作流不下单），任一路驳回即整单退回并附理由；超 48 小时未响应的提醒从汇合节点整体等待态由另一条定时编排发出；本期无待审批申请发零结果回执；输入清单不完整不重试、告警留审计新开调用](../../../media/cases/fig-case-062-01-flow.svg){#fig-case-062-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **手动触发**：大额采购申请提交后，采购发起一次调用，带入申请摘要的代号化条目（品类、数量、金额区间、供应商代号、事由）、审批人清单与采购频道。 2. **并行发起审批**：三条并行分支分别创建独立 `request_approval`，创建时冻结采购负责人、财务、法务三位 Human assignee；它们等待的是认证 Human 决定，不是 Agent callback。某一路合法 `approved` 只更新自己的分支结果；非法 decision 由 approval service 拒绝，该 Approval 保持 pending，其他两路不受影响。 3. **汇合节点分流（三个等待位全部就绪才放行、任一驳回即退回）**： - **三路全部确认**：三份独立 Approval 全部取得认证 `approved` 终态才放行进入下单流程，放行通知附全部审批记录并留审计时间戳与操作人；下单由人在采购系统执行，工作流不直接下单。 - **任一驳回**：汇合即失败，整单退回，通知发起人并附驳回理由与已确认记录（保留不撤回），留审计时间戳；重新提交要新开一次调用，没有"AI 自动改判"。 - **本期无待审批申请**：发一条零结果汇总回执并留时间戳，不静默结束，也不当作输入不完整。 4. **超 48 小时未响应**：审批本身不设自动超时；提醒从汇合节点的整体等待态发出，由另一条定时编排的 Workflow 扫出未响应项并汇总提醒；提醒不改变审批状态与各等待位，更不自动通过或驳回。 5. **输入清单不完整**：申请摘要缺品类或金额区间、审批人清单为空或角色缺失时不重试，告警失败、留审计时间戳，通知采购更正后新开一次调用。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动调用 + 并行审批 + 显式汇合"流程——它知道“同时发起多路确认”需要三条并行分支、每一路各是一个冻结 Human assignee 的独立 `request_approval`、“三份 Approval 全部 approved 才放行、任一路 rejected 即退回”需要一个显式汇合（join）节点、"放行与退回通知"各需要一个发消息环节。AI 还会在后台校验并行分支是否汇聚回 join 节点，你不必关心这些技术细节。 - **"部分通过"被误当作放行**：这是最危险的语义错误。聚合条件必须是"全部审批人确认"才放行，任一驳回即整单退回；验收时专门回放"两方确认、一方驳回"的样本，确认结果只有整单退回一种。 - **输入清单不完整**：不重试（重跑补不齐缺失输入），也不从申请事由猜金额区间或替缺失角色指派审批人，告警失败、留审计时间戳，通知采购更正后新开一次调用。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。发起后超过 48 小时未响应的，由另一条定时检查的 Workflow 汇总提醒对应审批人；提醒不改变审批状态，不自动通过或驳回。 - **驳回后的重提**：整单退回即本次失败结束，重新走审批要新开一次调用；已确认记录保留归档，不撤回也不复用。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无待审批申请（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录。 - **非法 decision 或错误身份**：approval service 拒绝非 `approved` / `rejected`、身份不匹配冻结 assignee 或决定幂等信息不合法的请求；该 Approval 仍为 pending，冻结 Human assignee 之后可提交合法决定，其他两份 Approval 的状态与既有终态不受影响。这里没有审批 Agent、callback 或“完成请求”。 大额采购放行必须全部审批人确认，这是流程的核心而非附属环节：采购负责人看供需与供应商风险，财务看预算与资金安排，法务看合同与合规，任何一方无权代替其他方确认——职责分离在流程结构里而不是在自觉里。三路各是冻结 Human assignee 的独立 `request_approval`；decision 只有 `approved` 或 `rejected`，任一合法驳回即整单退回并留审计，不设自动超时，也没有“到期视同通过”。非法 decision 仅由 approval service 拒绝并保持该 Approval pending，不改变 sibling。若金额特别巨大需加签分管负责人，在提示词里写明，AI 会在并行分支里多加一个审批环节。 本工作流不直接对接采购系统，也不创建、提交订单。申请摘要与三位 Human 成员引用作为调用输入由采购提供；每个 Approval Effect 冻结相应 assignee，审批由 approval service 认证并记录，不经 Agent 或 App callback。放行后由人在采购系统里执行下单，工作流只发出附全部确认记录的放行通知。若将来需要核对预算或合同状态，可加一个获授权 Agent 经 App/Extension 只读查询 ERP，访问凭据用 `` 占位，由 Agent 运行时从密钥引用。金额与供应商脱敏：金额只用区间，供应商只用代号，通知与审计不含报价明细。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅区间化/代号字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 - **回放集与基准**：取最近 6 个月 40 份大额采购申请（含全部通过、任一驳回、角色缺失样本）回放，人工基准为既定放行或退回结论；聚合判定与基准一致率 100%。 - **并行语义**：“两方 approved、一方 rejected”样本 100% 整单退回，0 例部分通过即放行；放行通知 100% 附三份独立 Approval 记录。 - **汇合语义**：三份独立 Approval 100% 全部取得认证 `approved` 终态才放行，0 例在任一 Approval 仍 pending 时放行；提醒 100% 从汇合节点整体等待态发出。 - **审批身份与非法输入**：三份 Approval 的 assignee 100% 在 Effect 创建时冻结；逐路回放非法枚举、错误 actor、错误决定幂等信息，approval service 100% 拒绝、目标 Approval 仍 pending，其他两路状态 100% 不变。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅区间化/代号字段，原值不进入以上任何一层），按 10% 抽查四层实际记录。 - **超时提醒**：48 小时未响应项 100% 被提醒覆盖；提醒后审批状态 0 例被自动改变。 - **输入校验**：摘要或清单缺必填项时 100% 告警留审计并要求新开调用，不出现猜测的金额或替指派的审批人。 - **脱敏口径**：通知与审计 100% 金额为区间、供应商为代号，不含报价明细，按 10% 抽样核对。 - **结果可见**：放行、整单退回、零结果、输入不完整四类结果 100% 各有可见回执；全部审批完成中位数 ≤ 2 个工作日；每次运行留审计时间戳。 ### 复用与变体 - **同构迁移**：大额合同会签、对外投资立项并行评审、重要岗位录用多轮确认。 - **分级并行**：不同金额区间路由到不同审批人组合（更高区间加签分管负责人），在提示词里写明。 - **写回采购系统**：放行后再加一个 Agent 环节，由它通过 App/Extension 把审批结论写回采购申请单留档，订单仍由人在系统内创建；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=申请单号+审批轮次），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。