五个平台搭同一套智能体，差异只有五行

五个平台，同一套活干完了。MuleSoft、Boomi、SAP、Azure、AWS，每个平台都托管了同样的九个工具，也都沿用了同一条审批规则。把五份构建摆到一张表上，真正不同的地方，五行就能说完。

这是一份纯文档层面的汇总，覆盖此前十五个部分的内容。2026年11月15日，我抽查了两个最可能变动的信息点——MuleSoft 的 MCP 连接器版本和 Boomi 的运行时区域，两者都没有变化。这里没有赢家，要分出高下得靠动手实测。

一、工具放在哪

• MuleSoft：在 Mule 流程里，每个工具配一个 Tool Listener，走 MCP 连接器。
• Boomi：在 API Control Plane 里把一个 API 产品暴露成 MCP 服务器，一个端点对应一个工具。
• SAP：Integration Suite 里的 MCP Gateway，这是 SAP 的 API 策略为智能体背书的路径。
• Azure：Logic Apps、Functions、API Management 三个宿主，统一藏在 API Management 这扇前门后面。
• AWS：一个 AgentCore Gateway，把所有目标合并成单个 MCP 服务器。

差别在于智能体能看到几个 MCP 服务器，以及谁掌握门前那道关。SAP 上，这个角色是 ERP 厂商；其余四家，是你的集成团队或云团队。

二、智能体怎么建

• MuleSoft：Agent Fabric 网络里的 agent broker，用 Agent Script 编写，通过 A2A 访问。
• Boomi：Agent Designer 里的低代码方式，用结构化模式做 JSON 进、JSON 出。
• SAP：Joule Studio，低代码或专业代码皆可，跑在 SAP 的托管运行时上。
• Azure：Foundry Agent Service 里的提示词智能体。
• AWS：AgentCore Runtime 里可用任意框架，每个会话一个微虚拟机。

差别在于低代码还是写代码，以及跑在谁的运行时上。构建体验本身，是唯一一个无法从文档里打分的标准。

三、护栏装在哪

• MuleSoft：Omni Gateway 策略覆盖智能体、MCP 和 LLM 流量，包括工具允许与封禁清单、PII 检测、令牌上限。
• Boomi：护栏放在智能体内部，另有 AI Gateway 管模型和工具流量。
• SAP：生成式 AI hub 里做内容过滤和数据脱敏，API 策略管智能体怎么进来。
• Azure：API Management 充当 AI 网关，按智能体配置工具允许清单，再加 Foundry 内容过滤器。
• AWS：Policy 机制，每次工具调用都在网关处校验 Cedar 规则。

差别在于护栏落在智能体里、网关里，还是厂商的访问规则里。最稳的设计，是把硬规则放在智能体代码之外。

四、审批放在哪

• MuleSoft：智能体网络没有内置审批步骤，闸门是一个 Mule 流程。
• Boomi：工具上开启 Requires Approval 会在调用前询问，财务闸门仍是流程 API。
• SAP：用 ERP 自带的灵活工作流，审批人在 My Inbox 里处理。
• Azure：Logic Apps 工作流发一张 Teams 卡片然后等待，必须异步执行，因为工具调用在 100 秒后超时。
• AWS：Step Functions 等待一个任务令牌，审批页面和审批人身份都得自己搭。

差别在于，SAP 是唯一一个审批就住在开票系统里的平台。其余四家，审批都是用零件拼出来的。

五、能看到什么

• MuleSoft：跨智能体、broker 和 MCP 服务器的 OpenTelemetry 追踪，支持导出。
• Boomi：会话追踪包含工具调用、令牌和延迟，文档未提及导出。
• SAP：网关日志、追踪和分析，跑在 SAP 监控的运行时上。
• Azure：Application Insights 里已正式可用的 OpenTelemetry 追踪。
• AWS：OpenTelemetry 加 CloudWatch 仪表盘，CloudTrail 目前只覆盖部分组件。

差别在于追踪数据能不能离开平台。这决定了运维团队能否在一个地方盯住来自多家厂商的智能体。

没变的部分反而更重要

契约没变：同样的九个工具、同样的 schema、同样的具名错误。Azure 和 AWS 都建议用扁平 schema，AWS 还会给工具名加前缀，但没有一家迫使契约本身改动。

规则先行没变：三方匹配和重复检查在智能体之前运行。闸门也没变：每个平台上，post_invoice_adjustment 都会在流程 API 里校验 approval_id，没有任何平台的内置审批能替代这道检查。

还有一个悬而未决的问题：五个平台的文档都没说清，一次失败的工具调用如何抵达智能体，以及 isError 是否会被置位。

临时平均分是 MuleSoft 3.3、Boomi 2.8、SAP 3.0、Azure 3.6、AWS 3.6。但这是文档分，上限为 4，且 SAP 参与打分的标准数量不同。差距有一部分只是各家文档写得多与少。

上面这五行差异，比平均分更有用。它们回答的是：你的审批人在哪工作、网关归谁管、运维团队是否需要一处看全所有智能体。