智能体跨场景复用，审批必须落到 API

从 SAP 传输变更审批，切换到五个平台上的发票异常处理，Agent 的哪些设计还能复用？作者给出的答案是：审批关卡、工具契约和网关白名单可以保留，原来的四 Agent 编排图则应该舍弃。

这篇最有用的地方，是把业务控制和平台配置分开讨论。不过，先把证据边界摆清楚：两个系列都基于虚构公司的参考方案，目前讲的是设计选择，还没有完成五个平台的实测对比。

审批能不能绕过，要由 API 决定

系列 1 在 MuleSoft 上设计 SAP 传输变更审批 Agent 时，定下一条规则：任何操作写入业务记录系统前，都由流程 API 检查审批，不能只靠提示词要求模型遵守。

系列 2 的 Part 6 原样保留了这个约束。post_invoice_adjustment 和 notify_supplier 都需要有效的 approval_id，否则流程 API 返回 APPROVAL_MISSING。

这里的关键，是模型即使选错工具、漏掉步骤，下游也会拒绝执行。提示词可以告诉 Agent 什么时候该申请审批，但真正决定请求能否通过的，是 API。

审批要求只有落实到执行入口，才能成为跨平台复用的控制。

同样被保留的还有工具边界：向 Agent 暴露流程 API，不直接暴露系统 API。前者封装业务规则，后者更接近底层系统操作。让 Agent 调用已有业务流程，可以继续利用集成团队已经写好的校验逻辑。

Part 7 又把这件事往前推了一步：在打开任何平台之前，先定义九个工具的契约，包括 schema 和面向 Agent 的描述。五个平台都必须承载或调用同一份契约，不能各做一套接口再宣称能力相同。

四 Agent 编排为什么没有继续用

系列 1 有 intake、planner、change、approval 四个 Agent，通过 broker graph 组织规则分支、循环计数和审批节点。MuleSoft 将这种方式称为 guided determinism，也就是用预先规定的路径约束 Agent 的行动。

但发票异常不是一套 21 步的变更晋级流程。系列 2 的路径更短：规则先处理，剩余异常交给一个 Agent 调查并提出建议，最后由人审批，再执行写入。照搬四个 Agent，只会让结构偏离任务。

另一个原因是平台差异。Agent Script 中的 broker graph 属于 MuleSoft 的具体实现，不能直接搬到另外四个平台。因此，作者保留平台无关的流程步骤，让每个平台自行映射。

图没有留下，图里的规则留下了：

• 「尝试两次，然后交给人」落到 Part 8：每个工具首次失败后，只允许一次纠正重试，再失败就转交处理。
• 「关卡应该是边，而不是指令」落到流程 API 的审批检查；图上的边可以补充约束，API 才负责拦截。
• 「步骤之间要校验」落到工具契约的输出 schema，用明确的数据结构承接下一步。

这也是作者最值得借鉴的取舍：复用规则，不必复用承载规则的那张图。

白名单、评测集和运维都要提前设计

系列 1 用 Omni Gateway 策略决定每个 Agent 能看到哪些工具。系列 2 把要求改成平台无关的形式：每次构建都要展示工具白名单、个人身份信息（PII）检测和 token 限制。

白名单还承担了发布控制。Part 9 用它切换不同上线阶段，Part 11 根据文档将其映射到 MuleSoft 的 MCP Global Access policy。不过，其他四个平台能否只靠配置完成同样的切换，仍要等后续构建验证。

作者还把上个系列的五条改进建议，变成了本系列的起点：

• Parts 7 和 8 先写工具描述与命名错误，再开始构建。
• Part 10 在 Build 1 前准备好 golden set，即用于反复评估 Agent 表现的基准案例集。
• 每个平台从一开始就在网关设置 token 预算。
• 缩小 Agent 职责，用一个异常处理 Agent 搭配九个工具；供应商消息相关职责放到 Parts 28–29 的独立 Agent。
• 提前安排支持方案，让可观测性、失败模式和紧急停用开关分别进入 Parts 37–39。

流程拆分也延续下来：系列 1 把 21 个步骤分给规则、Agent 或人；系列 2 的 Part 2 则对六类异常做同样的划分。先判断任务交给谁，再决定在哪个平台上搭建。

我的判断

我认同作者把审批、契约、错误和评测案例作为稳定边界。这些内容描述的是业务允许什么、工具如何交互、结果如何验收，比某个平台的编排语法更适合长期维护。

但「设计上可以迁移」和「产品里能够实现」仍有距离。Part 11 只做了文档研究，作者明确留下两个待验证点：命名错误经过 MCP Connector 后能否保持 Part 8 规定的结构；切换上线阶段能否只修改策略，无须重新部署。

原文也没有提供多 Agent 与单 Agent 的成本、准确率或延迟对照。一个 Agent 更适合当前短流程，是有理由的设计判断，还不能当成普遍规律。

与每个平台分别维护工具定义相比，共用契约更方便比较；代价是各平台必须适配同一套约束。与只在编排图里设置审批节点相比，API 检查能覆盖更多调用路径，但前提是敏感操作确实经过这个入口。

另外，产品能力依据截至 2026 年 10 月的厂商文档。作者尚未证明 Boomi、SAP、Azure、AWS 都能按同样方式落实这些要求，不能把后续构建计划读成已经完成的结果。

能拿来做什么

• 给 Node 服务接入 Agent 时，先在需要审批的操作入口校验审批凭据，并定义缺失审批时的明确错误，再编写工具调用提示词。
• 为日常 AI 编程中的工具调用先写契约，明确输入、输出、错误和重试次数。可以采用原文的限制：失败后允许一次纠正重试，仍不成功就交给人。
• 比较不同 Agent 平台时，固定工具契约和基准案例集，再观察各平台如何实现审批、白名单和错误传递，让比较有共同尺度。
• 拆分多个 Agent 前，先把流程标成规则处理、Agent 调查和人工决策三类，确认职责确实需要分开，再选择编排方式。