会审批但不能付款的 Agent：权限阶梯、超时与回滚演练

第一次 Demo 很漂亮。Agent 读完发票，匹配采购订单，总结差异，然后建议批准。有人顺口问：能不能也把款付了？会议室安静了一下。那一下安静，是整场演示最有价值的部分。

团队留下了 Agent，但移除了付款工具；把“Agent 说可以”改成有范围、有审批人、有审计记录的人工决定。这个案例讲他们拆开的三个决定，以及让边界真正生效的演练。

Demo 里说“可以批准”，那才是警告

审批看起来是一个动作：同意或拒绝。实际上至少包含三个不同决定：

• 准备。 读发票、找采购订单、比对金额、收集证据。
• 批准。 代表公司承诺付款，通常受授权额度约束。
• 付款。 通过银行或支付服务商真正移动资金，是不可逆的外部效果。

Demo 把三个决定压进了一句聊天回复。Agent 之所以能“批准”，是因为界面只有一个按钮，不是因为它有权限。这是设计缺陷，不是模型缺陷。

团队的第一处改动是结构：Agent 可以准备审批包，但付款工具从工具列表里删掉。第二处是流程：每笔审批必须写明发票、金额、供应商和审批人。第三处是演练：付款结果未知时怎么办？

三个决定，不是一个大按钮

工作流按职责分离重建：

阶段	Agent 可以做	人必须做	留下的证据
准备	读发票与采购订单、列出不一致、起草建议	确认供应商与业务理由	发票号、采购订单号、金额、源文件
批准	展示审批包、突出例外	在授权范围内批准、缩小或拒绝	审批人、范围、时间、决定
付款	本工作流不允许	通过财务系统放款	付款编号、金额、状态

Agent 在准备阶段仍然有用：它能减少找采购订单、核对行项目的时间。但它不能变成审批人，也不能变成付款通道。

团队还写清了审批的范围：具体发票、具体金额、具体供应商、具体时间窗。“批准这家供应商的发票”不是有效范围；“在周五前批准 INV-1042 的这笔金额”才是。

案例一：重复发票

同一张发票来了两次。两个 PDF 文件名不同、排版略有差异，但发票号、供应商、金额和日期一致。Agent 把两份都放进了待审批列表。

人工复核者因为两个审批包并排出现，发现了问题。生产流程不能依赖“刚好看到”。团队在生成审批包之前加了重复检查：

• 归一化供应商编号、发票号、金额、发票日期；
• 在未结和近期已付发票里查找匹配；
• 命中则标记“疑似重复”，要求人工决定；
• 不自动合并、不自动删除。

检查不可能完美。供应商可能换号重开，正常的周期性扣款也可能看起来一样。所以输出是标记，不是自动拒绝。复核者看到匹配记录，自己做决定。

Agent 的职责是让人在付款前看到重复；财务系统的职责是执行最终控制。两件事都不属于模型的置信度。

反例：付款超时之后

团队演练了更难的情况：付款请求超时。银行可能已经处理，也可能没有。Agent 看到错误，和许多重试循环一样，想再发一次。

盲目重试可能付两次。团队写了另一条规则：

1. 不重试付款调用。
2. 用幂等键和发票编号向支付服务商或银行查询状态。
3. 确认已付，标记完成并停止。
4. 确认未处理，才允许人工发起新的尝试。
5. 状态未知，暂停并带着轨迹交给财务。

幂等键不是万能护身符。它只在支付方支持、且工作流在重试时复用同一个键时有效。团队把键存在审批记录里，而不是存在模型的对话历史里。一个忘记键的模型无法安全重试。

演练还暴露了报表问题。Agent 的运行状态写“失败”，但付款其实成功了。看板记了一次失败，财务系统记了一次付款。团队增加了独立的外部效果状态：已确认、已拒绝、未知。只看运行状态不够。

权限阶梯

最终设计有五级。重点不是数字，而是每一级有不同的负责人和不同的证据要求。

层级	动作	谁批准	证据	可逆吗
0	读发票与采购订单	无需审批	源文件编号	是
1	起草内部建议	应付会计	差异清单与政策引用	是
2	生成审批包	应付会计	发票、采购订单、供应商、金额、重复检查	是
3	在授权内批准	审批包中具名的人	审批人、范围、时间	部分
4	放款	财务系统与授权操作员	付款编号与对账	否

Agent 停在第 2 层。第 3 层是人在财务系统里的动作。第 4 层根本不在 Agent 的工具列表里。

这比 Demo 承诺的范围窄，却是团队能审计的范围。价值不是“Agent 会批发票”，而是“Agent 缩短准备时间，并让人在签字前看到例外”。

恢复演练

团队用 30 分钟做了一次桌面演练，参加者包括应付会计、财务操作员和负责 Agent 的工程师。不需要生产权限。

1. 普通发票。 Agent 准备审批包，审批人能看到采购订单匹配并批准。
2. 重复发票。 两张同号发票，审批包被标记，审批人拒绝其中一张并记录原因。
3. 付款后超时。 付款状态未知，操作员用幂等键查询并对账。
4. 供应商银行信息变更。 供应商记录前一天刚改，审批人暂停，用已知号码回拨确认。
5. 部分批准。 发票拆分到多个成本中心，审批包必须展示拆分，审批人逐项批准。

通过条件很简单：每个参与者都能只看记录回答“下一步做什么”，不需要叫工程师读日志。如果做不到，说明证据不足，工作流还没准备好。

Agent 绝对不能做什么

团队写了一份很短、不可协商的清单：

• 放款；
• 修改供应商银行信息；
• 批准自己的建议；
• 合并重复发票；
• 绕过超过授权额度的双人规则；
• 在结果未知时重试付款；
• 因为发票“看起来正常”而隐藏差异。

清单短，才可执行。一份没人检查的长政策，不如五条写进工具列表和审批界面的禁令。

不适用边界

这个案例适合应付账款准备、发票匹配和审批包组装，前提是已经有审批人和财务系统。它不适合消费者支付、工资、税务申报，也不适合审批人看不到源文件的流程。它也修不好一个混乱的供应商主数据或缺失的授权制度。如果财务团队无法对账未知的付款结果，Agent 就不该靠近付款工具。正确设计是一个准备助手，在钱移动之前硬停下。