## 付款批次执行前人工确认 {.case data-case-id="046"} | 字段 | 值 | | --- | --- | | 案例编号 | `046` | | 行业 / 部门 | SaaS / 财务 | | 角色 | 财务经理 | | 难度 | `复杂` | | 调用来源 | `manual`（付款批次组装后由应付会计发起一次手动调用，带入批次汇总） | 付款批次一旦放行，钱就从账上划走，错了追回的成本极高，职责不清的放行本身就是内控事故。目标：付款批次组装后由应付会计发起一次手动调用，让获授权 Agent 汇总批次（笔数、金额区间、收款方类型，明细在读取侧即脱敏），财务经理逐项确认后才通知出纳在财务系统执行支付——工作流不碰任何支付接口，只做汇总、确认与通知的编排。驳回则整批退回重新组装。路由顺序：先校验输入完整性（批次清单不完整即告警留审计、新开调用不重试），再校验取数可用性（财务系统不可达即取数失败），然后判阈值红线（单笔或批次金额超过授权阈值，无论其他检查一律强制升级更高审批人，未经更高审批人确认绝不放行），最后才走常规的财务经理逐项确认。审批人可查阅财务系统中的批次明细只读件（敏感字段在该侧同样脱敏），确认逐笔有据。职责分离是硬约束：组装（应付会计）、放行（财务经理）、更高审批人、支付（出纳）四类角色必须是不同成员，发起与审批不得同一人，运行时校验成员唯一且在岗，冲突即告警留审计；工作流绝不动钱，支付由财务系统完成。指标：放行批次 100% 有逐项确认记录与审计时间戳；超阈值批次强制升级 100%、自动放行 0 例。 - **覆盖**：手动调用汇总付款批次（笔数、金额区间、收款方类型，明细在读取侧脱敏）、输入完整性与取数可用性校验、财务经理逐项确认、超阈值强制升级更高审批人、通知出纳、驳回退回重新组装、四类角色成员唯一性校验。 - **不覆盖**：执行任何支付、接触支付接口、修改明细、自动重组批次。 - **假设**：有一个经授权能读取批次明细并在读取侧脱敏汇总的 Agent（通过 App/Extension）；授权阈值在调用时作为输入；审批人可在财务系统查阅批次明细只读件（敏感字段在该侧同样脱敏）；出纳仅在财务系统支付，工作流与其支付完全隔离。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：付款批次组装后由应付会计发起一次手动调用，让获授权的汇总 Agent 经 App/Extension 读取批次明细并汇总（笔数、总金额区间、单笔金额区间、收款方类型）。App/Extension 在读取侧即完成区间化与令牌化，Agent 只接收笔数、金额区间、收款方类型与状态等白名单字段，收款方不显户名，金额不显精确值，原始财务字段不进入工作流与日志。财务红线：单笔或批次金额超过授权阈值的，无论其他检查一律强制升级更高审批人，未经更高审批人确认绝不放行；工作流不碰任何支付接口，只做汇总、确认与通知的编排。 触发：手动发起调用，调用时带入批次汇总信息、授权阈值、财务经理、更高审批人、出纳频道与汇总 Agent。 结果分流（依次判断：先输入完整性，再取数可用性，再阈值红线，最后常规逐项确认）： 输入批次信息不完整（笔数、金额或收款方类型缺失）：告警并留审计时间戳，通知补全后新开调用，不重试、不猜缺失字段——这是第一道判断，先于其他所有路由。 取数失败（财务系统不可达、批次明细取不到、数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败升级值班频道；不当作"无待确认批次"，也不当作不完整。 超过授权阈值（单笔或批次金额任一超限）：无论其他检查，强制升级到更高审批人人工决策，未经更高审批人确认绝不放行、不自动降级、不跳过。 未超阈值：汇总呈交财务经理逐项确认（每笔的金额区间与收款方类型）；审批人可在财务系统查阅批次明细只读件（敏感字段在该侧同样脱敏），确认逐笔有据。确认后通知出纳在财务系统执行支付留时间戳——工作流只发通知，支付由出纳完成；工作流回执只带笔数、金额区间与收款方类型；驳回则整批退回重新组装留审计，不自动改批次。 无待确认批次（批次为空或已确认过）：发"本次无待确认批次"回执留时间戳，不静默结束。 审批：放行必须由财务经理逐项确认，超阈值的由更高审批人决策；审批只有确认或驳回两种结果，审批不设自动超时，无默认通过/否决，也不设自动放行；四类角色（组装人/应付会计、财务经理、更高审批人、出纳）必须是不同成员，发起与审批不得同一人，运行时校验成员唯一且在岗，冲突即告警留审计。 异常：汇总 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：放行通知、整批退回、升级、信息不完整告警、零结果回执、取数失败升级，各自留审计时间戳后结束。 ``` ![案例 046 付款批次执行前人工确认：批次组装后手动调用获授权 Agent 汇总笔数与金额区间及收款方类型（App 在读取侧即完成区间化与令牌化，Agent 只接收白名单字段）；依次判断——输入不完整告警留审计新开调用不重试，财务系统不可达按取数失败告警留审计重试升级，再判红线：单笔或批次金额超授权阈值一律强制升级更高审批人、未经更高审批人确认绝不放行，未超阈值交财务经理逐项确认（审批人可查阅财务系统批次明细只读件、敏感字段在该侧同样脱敏），确认后通知出纳在财务系统执行支付（工作流不碰支付接口，回执只带笔数、金额区间与收款方类型），驳回整批退回重新组装，无待确认批次发零结果回执，四类角色不同成员、运行时校验唯一且在岗；回传不合结构停在原等待点](../../../media/cases/fig-case-046-01-flow.svg){#fig-case-046-01 width=92%} 如上图所示，正常路径、人工决策与异常都可见： 1. **手动触发**：批次组装后由应付会计发起一次调用，带入批次汇总信息、授权阈值、财务经理、更高审批人、出纳频道与汇总 Agent。 2. **汇总批次**：获授权 Agent 经 App/Extension 读取批次明细，App/Extension 在读取侧即完成区间化与令牌化，Agent 回传白名单汇总（笔数、总金额区间、单笔金额区间、收款方类型）；回传不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **依次路由（先完整性，再可用性，再红线，最后常规确认）**： - **输入批次信息不完整**：告警、留审计时间戳，通知补全后新开调用，不重试——第一道判断，先于其他所有路由。 - **取数失败**：财务系统不可达或批次明细陈旧，告警、留时间戳，按重试上限重试，仍失败升级值班频道。 - **阈值红线**：单笔或批次金额任一超阈值，无论其他检查强制升级更高审批人，未经更高审批人确认绝不放行、不自动降级、不跳过。 - **未超阈值**：汇总呈交财务经理逐项确认；审批人可在财务系统查阅批次明细只读件（敏感字段在该侧同样脱敏），确认逐笔有据。确认后通知出纳在财务系统执行支付留时间戳，工作流只发通知不碰钱，回执只带笔数、金额区间与收款方类型；驳回则整批退回重新组装留审计。 - **无待确认批次**：发零结果回执留时间戳，不静默结束。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动调用 + 完整性/可用性校验 + 阈值红线 + 逐项人工确认"流程——它知道"汇总批次"需要一个发消息并等待回调的 Agent 环节、"先校验输入完整性与取数可用性、再判阈值红线、最后常规分流"需要一个条件路由且校验与红线优先级最高、"逐项确认与升级决策"各需一个审批环节、"通知出纳与退回"各需一个发消息环节，并加上四类角色成员唯一性的运行时校验。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **超阈值批次被放行**：最危险的内控事故。规则把"单笔或批次金额超授权阈值"设在完整性、可用性校验之后的最高优先级路由，命中即短路升级更高审批人，其他检查不能让批次绕过这道门。 - **批次明细数据源不可达、数据陈旧**：不当作"无待确认批次"或直接呈交确认，而是告警失败、留审计时间戳，按上限重试；仍失败升级值班频道。 - **输入批次信息不完整**：不猜缺失的笔数、金额或收款方类型，告警留审计、通知补全新开调用，不重试——第一道判断，先于红线。 - **财务经理驳回**：整批退回重新组装留审计，没有"自动改批次再确认"；再提交就是一次新调用。 - **角色冲突**：组装人（应付会计）、财务经理、更高审批人、出纳四类角色必须是不同成员，发起与审批不得同一人；运行时校验成员唯一且在岗，冲突即告警留审计，不放行。 - **通知发送失败**：按重试上限重试投递；超上限升级值班频道，并保留待发内容供人工补发。 - **汇总 Agent 回传不合结构**：完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态——这正是不该催的决策，宁可等。若需时限，由另一条定时 Workflow（或值班人员）扫出超时项提醒。 放行必须由财务经理逐项确认，超阈值批次由更高审批人决策，这是两条独立的审批通道。确认时审批人看到的汇总里每笔金额都是区间、收款方只显类型，同时可查阅财务系统中的批次明细只读件逐笔核对（敏感字段在该侧同样脱敏），是"有依据的逐笔决策"而非盲目拍板；工作流回执只带笔数、金额区间与收款方类型。审批只有确认或驳回两种结果，驳回整批退回重新组装；审批没有时限、不设自动放行，也没有"超时默认通过"。职责分离是硬约束：组装人（应付会计）、财务经理、更高审批人、出纳四类角色必须是不同成员，发起与审批不得同一人，运行时校验成员唯一且在岗，冲突即告警留审计；工作流只编排确认与通知，绝不动钱。 本工作流对批次明细的读取由获授权 Agent 通过 App/Extension 完成，工作流不直接调用外部系统，更不接触任何支付接口——支付由出纳在财务系统执行，工作流只发通知。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），原始财务字段在源头即被区间化/令牌化，并按 10% 抽查四层实际记录；审批人仅在财务系统查阅批次明细只读件，敏感字段在该侧同样脱敏。出纳频道、审批人作为调用输入提供；数据源凭据用 `` 占位，由 Agent 运行时引用。数据源不可达或陈旧属于取数失败，走失败回执与升级。汇总遵循最小披露：金额只显区间，收款方只显类型不显户名。 - **回放集与基准**：取最近 3 个月 40 个历史批次（含未超阈值、单笔超限、批次超限、明细缺失）回放，基准为既定判定与处置。 - **红线防线**：超阈值批次 100% 强制升级更高审批人，自动放行 0 例；阈值判定与基准一致率 ≥ 99%。 - **逐项确认**：放行批次 100% 有逐项确认记录；驳回批次 100% 整批退回留审计，0 例改批次；工作流回执 100% 只带笔数、金额区间与收款方类型。 - **职责分离**：抽查 20 次放行，组装人、财务经理、更高审批人、出纳四类角色 100% 为不同成员，冲突 100% 告警留审计。 - **最小披露**：呈交与通知按 10% 抽样，户名与精确金额 0 次出现，金额 100% 为区间。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 - **结果可见**：六类结果 100% 各有回执，不静默结束。 ### 复用与变体 - **同构迁移**：薪资发放前确认、供应商预付款确认、退款放行确认。 - **双审变体**：批次总额超更高一级阈值时加签 CFO，提示词里写明即可。 - **对账衔接**：出纳执行后由另一条 Workflow 定时对账，把执行结果与放行清单核对，差异告警。