同一个智能体，为什么能在五个平台跑？

选供应商之前，先把架构画出来。作者给发票异常处理智能体画完这张图后发现，大部分方框在每个平台上都一样。供应商的选择改变的是每个框怎么建，而不是有哪些框。

这张图是整条系列的地基。从第11部分的MuleSoft到第25部分的AWS，每一次构建都画在它上面。

五层结构，按请求流动的方向从上往下读

1. 渠道层：工作从哪来、人从哪回——应付账款异常队列、邮件、Teams或Slack、审批人的收件箱。这一层完全由供应商决定，而且通常已经存在。智能体应该嵌进去，而不是替换它。
2. 智能体层：发票异常智能体，之后还有供应商沟通智能体。大模型在这里推理、规划、调用工具。每个平台有自己的运行时：Agent Fabric、Agentstudio、Joule、Foundry Agent Service、AgentCore。当一个智能体需要另一个智能体、尤其是跨平台时，开放标准是A2A，目前已是稳定的1.0版本。
3. 工具层：九个工具，输入、输出和具名错误只定义一次。这里的开放标准是MCP。系列里的每个平台都能以某种形式托管或消费MCP工具，这正是公平比较得以成立的前提。
4. 流程API层：业务规则——容差、重复校验、记账规则，以及最关键的审批校验。post_invoice_adjustment会拒绝任何没有有效approval_id的调用。这一层是你自己的代码，跑在你已经在用的集成平台上。
5. 记录系统层：带发票、采购订单和收货单的ERP，供应商主数据，以及工作流引擎。它们今天就在，而且应该继续保持无聊。

横切五层的四件事

• 网关：按智能体配置工具白名单，数据进入模型前做PII检测，限制token用量。系列1里是Omni Gateway，每个平台都有对应物。
• 身份：每个智能体拥有自己的身份，按工具授予最小权限，而不是借用某个用户的身份或共享服务账号。
• 可观测性：一条trace贯穿五层，让一张发票从队列到ERP的路径可追。OpenTelemetry是显而易见的标准，但有一个前提，下面会说。
• 人工审批：审批请求走工作流，强制执行发生在第4层。这是两件不同的事，把它们混为一谈是最常见的错误。

审批校验到底住在哪

这一点值得单独说，因为它是让其余设计变安全的那一个决策。

审批校验住在流程层，不在提示词里，也不在智能体运行时里。智能体可以调用request_approval，为某个人创建一个任务。人批准后，工作流返回一个approval_id。只有到这一步，post_invoice_adjustment或notify_supplier才会成功。

如果智能体被一张奇怪的发票误导、跳过了某一步，或者干脆就是错了，记账会以APPROVAL_MISSING失败。没有任何提示词能改变这一点，因为校验根本不在提示词里。这也是系列1关于人在回路那篇文章的核心结论，原封不动地适用于全部五个平台。

它还意味着，你可以更换智能体、更换模型甚至更换平台，而不必重新验证这道控制。控制本身没有挪窝。

哪些是标准，哪些不是

开放标准这边：智能体到工具用MCP，最新规范修订版是2026-07-28；智能体到智能体用A2A 1.0，由Linux基金会治理，配有描述智能体能做什么的agent card；trace用OpenTelemetry，但有个前提——定义invoke_agent、execute_tool等span的GenAI语义约定仍处于Development状态，属性名可能随版本变化。可以用，但别建你更新不了的仪表盘。

供应商专属这边：构建和提示智能体的运行时与工作室、智能体与工具注册表、网关策略及其配置、身份集成（Entra、IAM、平台原生身份）、评估工具与仪表盘。

实际后果是：把标准层当作可复用资产来投入（工具契约、agent card、trace约定），把供应商层当作可替换件。

为什么先画图再选供应商

三个理由。它让比较保持诚实：如果每次构建都要填同样的框，就很容易看出平台在哪里原生覆盖了某个框、在哪里需要额外工作、在哪里根本帮不上忙。它让你看清自己已经拥有什么：第4、5层以及大部分渠道层在多数企业里已经存在，智能体平台的决策主要关乎第2、3层和横切关注点。它限制锁定：如果工具契约是MCP、agent card是A2A、审批校验在你的流程API里，把智能体从一个平台搬到另一个平台是工作量，但不是重写。

系列1里作者为单次MuleSoft构建画过类似的图。区别在于，现在每个框都得在五个平台上跑通。

如果后面某一篇放不进这张图，它大概本来就不属于这个系列。