MCP vs A2A：Salesforce与ServiceNow的智能体互联对决

当外部AI试图调用你的企业智能体时，Salesforce AgentForce和ServiceNow给出了截然不同的答案。一个选择将智能体封装为MCP服务器上的工具，另一个则通过A2A协议开放访问。这场协议之争没有赢家，只有适配场景的差异。

两种路径：MCP服务器 vs A2A协议

据YouTube频道分析，AgentForce的做法是要求用户将智能体添加为自定义Salesforce MCP服务器上的工具。这里有两个关键限制：仅支持AgentScript构建器创建的智能体，且智能体以登录用户的身份运行。这意味着权限边界清晰，但灵活性受限于Salesforce生态。

ServiceNow则走了一条更开放的路。在AI Agent Studio中，它允许第三方通过A2A协议（版本0.3）访问ServiceNow AI智能体。A2A专为智能体间通信设计，版本号表明该协议仍在快速迭代中。

两者都支持反向调用——即企业智能体调用外部MCP工具。但ServiceNow增加了治理层：只有经AI Control Tower批准的服务器才能被调用。这反映出ServiceNow对安全与合规的侧重，尤其适合受监管行业。

AgentScript 构建器是 Salesforce 为 AgentForce 提供的低代码/声明式智能体开发环境，开发者通过脚本定义智能体的行为逻辑、可用工具与数据访问范围，而非从零编写代码。其限制在于：只有通过 AgentScript 构建器创建的智能体才能被发布为 MCP 服务器上的工具，这意味着用其他方式（如外部框架或自定义代码）搭建的智能体无法直接接入该通道，企业在迁移既有智能体资产时需评估改造成本。

AI Control Tower 是 ServiceNow 平台中面向 AI 资产的集中治理组件，负责对智能体、模型与外部工具服务器进行注册、审批与策略管控。它并非运行时防火墙，而是在调用发生前建立“白名单”式的准入机制，只有被批准的外部 MCP 服务器才允许被 ServiceNow 智能体调用。这一设计将治理责任前移到配置阶段，但也要求企业持续维护服务器清单并定期复核。

协议选择背后的设计哲学

MCP（Model Context Protocol）本质是让AI模型访问工具和数据源的标准化方式，它将智能体视为可调用的“工具”。A2A（Agent-to-Agent）则聚焦智能体之间的对等通信，更接近分布式系统中服务间协作的模型。

AgentForce选择MCP，与其平台基因一致：Salesforce的核心是数据与流程，将智能体作为工具嵌入现有MCP服务器，能最大程度复用权限体系和用户上下文。但“仅AgentScript构建器智能体”和“以登录用户身份运行”两条限制，也意味着跨组织、跨身份的复杂调用场景可能受限。

ServiceNow选择A2A，则更像在构建智能体互联网的入口。A2A 0.3版本虽未成熟，但协议层面对智能体发现、任务协商的支持，为多智能体协作留出了空间。AI Control Tower的审批机制则是对开放性的必要制衡——开放不等于无监管。

MCP（Model Context Protocol） 由 Anthropic 提出并开源，核心是把外部能力抽象为“工具（tools）”“资源（resources）”和“提示（prompts）”三类原语，由客户端（通常是 AI 应用）按需发现和调用。它解决的是“模型如何安全地访问外部世界”的问题，天然带有客户端-服务器的主从结构，因此权限往往绑定在发起调用的用户或应用身份上。

A2A（Agent-to-Agent） 则由 Google 主导推动，后交由 Linux 基金会托管，定位于智能体之间的对等协作。它定义了智能体卡片（Agent Card）用于能力发现，以及任务（Task）生命周期用于长时协作与状态同步。与 MCP 的“调用工具”语义不同，A2A 更接近“委托任务”，调用方无需了解对方内部如何实现，只需协商目标与结果格式，这也是它更适合跨组织、多厂商智能体编排的原因。

企业该如何选择

据该视频观点，“没有赢家，只有差异。选择你的外部AI所使用的协议。”这其实点明了决策逻辑：不是比较协议优劣，而是看你的外部AI生态说什么语言。

如果你的智能体主要服务于Salesforce内部流程，且外部调用方愿意适配MCP，AgentForce的路径更直接——权限继承和工具化封装降低了集成成本。但需注意AgentScript构建器的限制，以及登录用户身份运行带来的权限粒度问题。

如果企业需要与多个第三方智能体平台对接，或处于金融、医疗等强监管行业，ServiceNow的A2A+AI Control Tower组合提供了更结构化的治理框架。A2A的智能体间通信语义也更适合复杂任务编排，尽管协议版本尚早，存在演进风险。

一个容易被忽视的细节是双向能力：两者都能调用外部MCP工具，但ServiceNow的审批机制意味着企业需要维护一个受控的服务器清单。这增加了运维负担，却也换来了可审计性。

协议融合的可能与局限

MCP和A2A并非互斥。理论上，企业可以同时支持两种协议：对内用MCP封装工具，对外用A2A开放智能体。但现实中的复杂度在于身份映射、权限传递和审计追踪——当外部AI通过A2A调用智能体，该智能体再通过MCP调用工具时，调用链上的权限如何一致地传递？

AgentForce的“以登录用户身份运行”简化了这个问题，但牺牲了跨身份调用的灵活性。ServiceNow的AI Control Tower提供了审批入口，但未在视频中展开运行时权限模型。这些细节将决定协议融合的实际可行性。

当前阶段，企业更务实的选择是：明确外部AI生态的主流协议，优先适配；同时保留对另一种协议的支持路径，避免被单一厂商锁定。协议之争的终局或许不是一方胜出，而是网关层出现协议转换服务——但那又是另一个话题了。

身份映射与权限传递是协议融合中最容易被低估的工程难题。当外部 AI 通过 A2A 发起请求时，ServiceNow 侧需要将该请求关联到一个可审计的主体身份；若该智能体随后通过 MCP 调用下游工具，下游系统看到的又是另一套凭证体系。跨协议的调用链要求每一跳都能完成身份转换与权限收敛（即取交集而非并集），否则容易出现权限放大。业界目前的常见做法是引入短期令牌与调用链追踪标识，但标准化程度仍低，各厂商实现差异较大。