发票 Agent 的人工审批边界怎么定

发票 Agent 查完采购单、收货记录和供应商历史，接下来能不能直接改账、发邮件？作者给出的答案是：查询可以放开，影响资金和供应商关系的操作必须经过人工审批，而且拦截要写进业务 API，不能只靠提示词约束。

这是「One Agent, Five Platforms」系列第 6 篇。它先规定一套跨平台通用的审批规则，再要求第 11 篇起的各平台实现遵守。对程序员来说，最有用的部分是把「需要人确认」拆成了可以实现、校验和审计的接口契约。

哪些操作该停下来，哪些可以自动走

作者沿用第 2 篇的发票处理流程，划出三处决策位置，但并非每处都安排人工审批。

第一处是容差范围内的正常发票。发票与采购订单（PO）、收货记录匹配，偏差也在财务认可的范围内，就由规则自动结案，不需要 Agent 调整，也不需要人点确认。容差由财务设定和维护，修改属于受控变更，Agent 无权触碰。

理由很实际：让人反复审批大量正确发票，容易养成不看内容直接点击的习惯。审批越多，未必越安全。

第二处是写入企业资源计划系统（ERP）之前。只要 post_invoice_adjustment 要修改价格、数量或记账结果，就必须由具备相应权限的人批准具体方案。Agent 负责整理异常类型、采购订单行、收货记录、供应商历史、价格协议和拟议调整，人负责决定这一次能否执行。

第三处是联系供应商之前。notify_supplier 发送任何内容前，都要有人批准消息。作者认为，错误或措辞不当的询问可能伤害长期合作关系，因此由 Agent 起草，人确认后发送。

查询和调查不设审批关卡。Agent 可以按需读取发票、采购订单、收货记录和供应商历史。这也解释了第 2 篇为什么把只读工具设为默认入口。

提示词里的「先问我」为什么不够

作者把审批检查放在参考架构的第 4 层，也就是流程 API 所在层。

提示词中的「提交前必须询问」是一条模型需要遵守的指令。遇到异常单据、过长对话或难以理解的工具返回，模型仍可能偏离要求。流程 API 则可以直接拒绝不符合条件的调用：post_invoice_adjustment 收不到有效的 approval_id，就返回 APPROVAL_MISSING。

审批约束要由执行操作的接口强制校验。

作者在系列 1 的 SAP 变更审批讨论中也采用了这个原则，并要求它在五个平台上保持一致。平台负责怎样暂停和恢复任务，业务接口负责决定操作是否获得授权。

这里的 approval_id 不能只是一个「用户点过同意」的标记，它至少要满足四个条件：

• 绑定一张发票、一个动作和一个金额；批准后修改价格等提案内容，原审批就不能继续使用。
• 只能使用一次，不能拿去处理另一张发票。
• 必须有有效期；过期后重新申请，避免采购单、发票或会计期间变化后继续执行旧决定。
• 申请人与审批人职责分离；Agent 可以申请审批，但不能批准自己提出的操作，审批人必须是真人，且身份不能与申请者相同。

原文没有给出审批记录结构、有效期长度，也没有展示校验实现。它定义的是接口必须满足的行为。

审批发给谁，没人回复怎么办

审批路由也不能交给 Agent 临场判断。request_approval 根据异常类型和金额，按规则找到对应人员。

低风险情况，例如缺少收货记录、疑似重复发票，由应付账款（AP）团队快速审批；超出容差的价格或数量偏差，交给拥有对应金额财务权限的人；税务不匹配由税务团队判断，Agent 只提供证据；采购订单已关闭，则由采购部门决定。

审批页面至少要展示异常类型、拟议动作、金额、Agent 使用的证据，以及源单据入口。审批人可以批准或拒绝，也可以填写进入审计记录的备注。系列第 34 篇将比较各平台如何呈现这些信息，当前文章没有提供比较结果。

无人响应时，流程应先提醒，再升级给代理人或更高一级负责人。原文没有规定具体等待时长，但给出了明确的默认行为：

超时后发票继续挂起，不入账，也不发送消息。

「没有回答」不能被转换成「已经同意」。

因此，作者计划检查各平台能否创建附带提案和证据的审批任务、暂停并恢复 Agent、返回可供流程 API 验证的 approval_id，以及记录谁在何时批准了什么。这些能力对应评分表中的人工介入指标。

我的判断

我认同把审批放进执行接口，也认同按操作后果设置关卡。相比每一步都弹确认框，这套方案更有机会把人的注意力留给重要决定；相比只在提示词里写要求，它提供了明确的拒绝路径。

但这篇是虚构公司的参考设计。产品能力依据截至 2026 年 10 月的厂商文档，作者也提醒实际构建前核对最新文档。文中没有上线数据、事故率或不同审批策略的对照实验，因此「减少无效审批能改善审批质量」目前仍是设计判断，不能当作已经验证的收益。

它还依赖几个前提：财务容差已经定义清楚，人员权限能够查询，审批记录可信，业务 API 真能拦住越权操作。只有一个审批弹窗，后端仍接受任意写入，这套机制就没有成立。

另外，作者以「读取不改变数据」为理由放开调查，这在流程副作用上成立，却没有讨论读取权限和敏感信息范围。实际接入时，只读权限仍需要限定到任务所需的数据。

能拿来做什么

• 给现有 AI 工具按后果分类，把查询、财务修改和对外发送分别列清楚，再确定哪些必须停下来等待人工决定。
• 如果用 Node 封装业务工具，就在写入接口校验审批记录与当前提案是否匹配，并检查有效期和使用状态；缺少有效授权时明确拒绝调用。
• 做审批前端时，把具体动作、金额、证据和源单据放在确认按钮之前，让审批人能够核查这一次操作。
• 为等待审批设计提醒、升级和挂起状态，并验证超时路径不会触发入账或发送；选平台时同时检查暂停恢复、授权返回和审计能力。