企业AI的两大策略：Substrate式与Broker式
Salesforce和SAP在2026年采用相同的MCP协议，却做出了截然相反的战略选择：Salesforce将平台作为所有智能体可直接调用的基础层（Substrate式），而SAP要求外部智能体必须通过其第一方智能体Joule进行交互（Broker式）。这一分歧将影响整个企业软件生态的安全、定价和权力格局。
2026年4月，Salesforce在TrailblazerDX大会上发布了Headless 360，推出了六十多个MCP工具，允许任何外部智能体直接操作整个CRM系统。六个月前，SAP在其TechEd大会上推出了MCP网关，但做出了截然相反的架构决策：外部智能体应与SAP的智能体对话，而非直接调用SAP的API。两家公司使用相同的协议，却对协议用途做出了相反的判断。这一分歧是2026年企业软件领域最具战略意义的差异，而其他平台——包括Microsoft、ServiceNow、Workday、Oracle、Atlassian、Snowflake、Databricks——目前都在内部决策中，必须选择一方。
Salesforce的策略可以称为“Substrate式”：其平台成为所有智能体可调用的基础层。Headless 360将Salesforce的数据、工作流、业务逻辑和合规控制全部暴露为REST API、MCP工具或CLI命令。超过六十个新MCP工具在发布时可用，包括三十多个预配置的编码技能，并明确支持Claude Code、Cursor、Codex、Windsurf等外部编码智能体，无需浏览器即可操作平台。定价从按席位转向按消费量，这是对“智能体即用户”时代的承认。
SAP的策略则是“Broker式”：外部智能体不能直接访问平台，而是通过SAP的第一方智能体Joule进行请求。Joule在SAP的治理模型下决定是否及如何执行请求。SAP在架构指南中明确表示：“对于供应商和第三方智能体之间的外部互操作性，SAP优先采用A2A（代理间协议），而非直接暴露MCP服务器。”这意味着SAP希望成为其他智能体必须通过的中介层，其智能体Joule是持有客户关系的命名实体。
这两种策略体现了对企业智能体未来发展的三种不同预判。首先，信任的落脚点：Salesforce认为客户信任平台的数据和治理层，因此任何智能体都可调用；SAP则认为信任应集中在Joule这一已获授权的智能体上。其次，责任归属：当外部智能体通过MCP调用平台导致有害结果时，Salesforce模式可能导致平台承担连带责任，而SAP模式则试图将责任推到外部智能体一方。第三，定价权：Salesforce通过按调用量收费，鼓励智能体生态繁荣；SAP则维持基于智能体席位或运行时的定价，保持对客户关系的清晰视线。
其他企业平台尚未公开表态，但2026年至2027年间它们将不得不做出选择。Microsoft目前摇摆不定；ServiceNow趋向于Broker模式，以保护其工作流图与咨询实施经济；Workday可能采取混合策略，但偏向Broker；Snowflake和Databricks则天然倾向于Substrate模式，因为数据是它们被调用的价值所在。这一战略分歧将深刻塑造未来企业软件生态的格局。