2026 年 3 月，伦敦 QCon 的一个分会场里，Morgan Stanley 的工程团队站在台上，讲的不是量化交易模型，也不是风控算法——他们在讲如何用 MCP（Model Context Protocol）改造自己的 API 体系，让 AI Agent 能直接调用金融系统的核心能力。

这个画面值得停下来想一想。Morgan Stanley 不是一家喜欢追新的科技公司。它是一家成立于 1935 年、管理着数万亿美元资产的金融巨头。当这样的机构开始在顶级技术大会上分享”我们如何采用 MCP 构建 AI-Ready API”的完整旅程时，信号已经足够清晰：MCP 不再是开发者社区的新鲜玩意，它正在变成企业基础设施的必选项。

同一周，AWS 发布了 Bedrock AgentCore 与 Slack 的深度集成方案，MCP 作为工具执行层被写入架构核心。再往前一步，Salesforce 公布了 Agentic Enterprise 的八大设计原则，第八条明确写道：”优先采用开放生态和标准”，MCP 被点名列入。

这篇文章要回答一个问题：一个 Anthropic 在 2024 年底悄悄开源的协议，为什么在不到两年的时间里，从”开发者工具”跃迁为”企业集成标准”？这个跃迁意味着什么？以及——它可能在哪里失败？

先搞清楚 MCP 到底是什么

在深入案例之前，必须建立一个准确的技术认知。MCP 官方的比喻是：”AI 应用的 USB-C 接口”。这个比喻精确但不够深——它暗示了标准化，但没有说清楚标准化的是什么。

更准确的说法是：MCP 是 AI Agent 与外部世界之间的标准化通信协议。 它定义了 Agent 如何发现工具、如何理解工具的能力、如何调用工具、如何处理返回结果。在 MCP 出现之前，每个 AI 应用要接入一个外部系统，就需要写一套定制的集成代码——不同的认证方式、不同的数据格式、不同的错误处理逻辑。这就像互联网早期，每个网络协议各自为政，直到 HTTP 统一了 Web 通信。

MCP 的架构分为三个角色：Host（运行 AI 模型的应用，比如 Claude 或 ChatGPT）、Client（管理连接的中间层）和 Server（暴露工具和数据的服务端）。Server 可以暴露三种能力：工具（可执行的函数）、资源（可读取的数据）和提示词（预置的交互模板）。协议本身使用 JSON-RPC 2.0 消息格式，支持 stdio 和 HTTP 两种传输方式，版本号采用日期格式（当前版本 2025-11-25），只在不兼容变更时递增。

关键在于：这不是又一个 API 网关。传统 API 是为人类开发者设计的——有文档、有 SDK、有 Dashboard。MCP 是为 AI Agent 设计的——有模式发现、有能力描述、有运行时协商。 Agent 不读文档，它在毫秒级完成：读取描述、检查模式、查询注册表、做出选择。

这个区别决定了 MCP 不是 REST 或 GraphQL 的替代品，而是架在它们之上的一层——让 Agent 能自动发现和使用已有的 API 能力。

从 GitHub 仓库到华尔街：演化路径

MCP 的演化可以分为三个阶段，每个阶段的用户画像截然不同。

第一阶段（2024 年末—2025 年中）：开发者工具。 Anthropic 开源 MCP，Claude Desktop 率先支持。开发者用它连接本地文件系统、数据库、搜索引擎。社区开始涌现各种 MCP Server——GitHub、Slack、Notion 等等。此时的 MCP 本质上是一个”让 Claude 更好用”的开发者工具，停留在个人生产力层面。

第二阶段（2025 年中—2026 年初）：平台采纳。 转折点是多个主流 AI 平台同时支持 MCP。OpenAI 让 ChatGPT 兼容 MCP，Visual Studio Code 内置 MCP 支持，Cursor 等开发工具原生集成。GitHub 甚至专门上线了 MCP Registry。生态从”Anthropic 的协议”变成”行业的协议”。Smithery 注册表上的 MCP Server 超过数千个，npm 上的 MCP 包成为新的分发渠道。

第三阶段（2026 年初至今）：企业采纳。 这就是我们正在经历的阶段。Morgan Stanley、AWS、Salesforce 不是在试验 MCP，而是在把它写进架构原则和生产系统。这个跃迁的速度超出了大多数人的预期——通常一个开发者协议要花五到十年才能进入企业核心系统，MCP 用了不到两年。

为什么这么快？因为 AI Agent 的采纳速度本身就史无前例。企业不是在”计划未来使用 Agent”，而是已经在用——每一个用了 Agent 的企业都立刻遇到同一个问题：Agent 怎么调用我们现有的系统？ MCP 是目前唯一一个有广泛生态支持的答案。

三个案例：金融、云计算、SaaS

Morgan Stanley：当华尔街开始说 MCP

Morgan Stanley 在 QCon London 2026 的分享是一个标志性事件。他们面对的挑战非常典型：一家拥有数十年技术债务的大型金融机构，内部有成百上千个 API，分散在不同的业务线、不同的技术栈、不同的安全域中。传统方式下，每接入一个新的 AI 应用，就要为这些 API 逐一编写适配层。

Morgan Stanley 的方案是：用 MCP 作为统一的 AI 接入层，将现有 API 改造为”AI-Ready”的 MCP Server。 这不是替换现有系统，而是在现有 API 之上加一层标准化描述——让 Agent 能理解每个 API 做什么、需要什么输入、会返回什么结果、有什么权限约束。

这里的关键洞察是：对于企业来说，MCP 的价值不在于它比 REST 更好，而在于它让 Agent 能自服务。 没有 MCP，每次业务部门要让 Agent 访问一个新系统，IT 团队就要参与集成。有了 MCP，Agent 可以通过标准化的发现机制自行找到和调用工具——这把集成成本从线性降到了接近常数。

当一家管理万亿美元资产的金融机构选择在公开场合分享这个决策时，它对整个行业的示范效应是巨大的。

AWS AgentCore：MCP 作为云原生工具执行层

2026 年 3 月 23 日，AWS 发布了一篇详尽的技术博客，展示了如何将 Amazon Bedrock AgentCore 与 Slack 深度集成。在这个架构中，MCP 的角色清晰到无法忽视。

整个系统分为三层：Slack 集成基础设施（API Gateway、Lambda、SQS）、AgentCore 组件（Runtime、Gateway、Memory）和 MCP 工具执行层。当用户在 Slack 中发送消息后，请求经过验证、排队，最终到达 AgentCore Runtime。Runtime 使用 Strands Agents SDK 进行模型调用，而 工具的发现和执行完全走 MCP 协议——AgentCore Gateway 通过 MCP 获取可用工具列表，模型决定调用哪些工具，Gateway 再通过 MCP 路由工具调用到对应的 MCP Server。

这个架构的意义在于：AWS 没有发明自己的工具调用协议，而是直接采用了 MCP。 对于一个习惯自建一切的云巨头来说，这个选择本身就是对 MCP 生态地位的认可。更重要的是，AWS 用 CDK（Cloud Development Kit）将整个架构模板化——开发者可以一键部署，换掉天气查询工具，插入自己的业务 MCP Server，整个集成层完全复用。

同时，AWS 还推出了 Amazon Bedrock Knowledge Bases 的 MCP Server，提供了 13 个工具来管理企业知识库——从创建、查询到更新，全部通过 MCP 暴露。Reddit 上的 AWS 社区对此反响热烈，因为这意味着任何支持 MCP 的 Agent 都能直接操作企业知识库，无需编写任何定制集成代码。

Salesforce：把 MCP 写进架构原则

如果说 Morgan Stanley 代表了金融业的背书，AWS 代表了云厂商的站队，那么 Salesforce 代表的是企业软件巨头的理论认同。

Salesforce 在其发布的”Agentic Enterprise 八大设计原则”中，将 MCP 和开放 API 列为第八条原则”优先采用开放生态和标准”的核心内容。原文说得很直白：

“一个开放架构应该有标准化的模型接口，让更好的模型可以随时替换进来；应该有开放协议（Model Context Protocol、API、标准数据格式）来集成各个模块；应该有可移植的工作流定义，确保编排不绑定特定平台。”

这段话的权重在于说它的人是谁。Salesforce 是全球最大的 CRM 厂商，其 Agentforce 平台正在成为企业 Agent 部署的主要载体之一。当它把 MCP 写入架构原则，等于告诉整个 Salesforce 生态的合作伙伴和客户：MCP 不是可选的技术选型，而是架构合规的一部分。

Salesforce 的八大原则还揭示了一个更深层的逻辑：Agent 部署失败的根源往往不是模型不够好，而是架构不对。模块化设计、统一元数据、全链路可观测、信任治理、弹性基础设施——这些原则中的每一条，最终都指向同一个需求：标准化的系统间通信协议。MCP 是目前最接近这个需求的答案。

工具发现：MCP 生态的隐形基础设施

技术协议的价值取决于生态的丰富度，而生态的丰富度取决于工具能否被发现。这是 MCP 演化中最容易被忽视、却最关键的一环。

ICME 团队的一篇深度分析揭示了残酷的现实：MCP 注册表上已有数千个 Server，当一个 Agent 需要任务管理工具时，它会找到数十个功能重叠、名称相似的候选——create_issue、create_ticket、create_card、add_task。 研究表明，当可用工具超过 30 个且描述重叠时，Agent 的选择准确率急剧下降；超过 100 个，基本等于随机选择。

这就是为什么 GitHub 把 Copilot 的 MCP Server 从 40 个工具砍到 13 个——砍完之后，基准测试分数反而上升，延迟反而下降。另一家公司 Block 把 Linear 集成重写了三次，从 30 多个工具精简到 2 个。在 Agent 世界里，”少即是多”不是设计哲学，而是工程事实。

目前的工具发现体系已经形成了一个多层网络：

  • MCP 官方注册表（registry.modelcontextprotocol.io）：GitHub 托管的标准化注册中心，IDE 和企业治理工具首先查询这里
  • Smithery：最活跃的第三方注册表，Agent 框架如 CAMEL 原生支持运行时搜索
  • npm：实际安装发生的地方，包描述已经不只是给人看的
  • Glama：收录超过 19,000 个 MCP Server 的索引，提供机器可读的 API
  • 技能目录（如 ClawHub）：策划型发现平台，不只说”这个 Server 存在”，而是说”这个 Server 擅长这件事”

对于企业而言，工具发现不仅是技术问题，更是治理问题。你的 Agent 运行时能访问哪些工具？谁批准了这些工具的接入？工具的权限边界是什么？MCP 的工具发现机制正在从”开发者便利”演化为”企业治理入口”。

MCP vs 传统 API：本质区别在哪？

把 MCP 理解为”又一种 API 协议”是最常见的误解。两者的设计受众和使用模式完全不同：

传统 API 的消费者是人类开发者。 开发者阅读文档、理解语义、编写代码、处理错误。整个过程是离线的、一次性的——集成完成后代码就固定了。API 的设计优化点是人类可读性：清晰的文档、直觉的命名、丰富的 SDK。

MCP 的消费者是 AI Agent。 Agent 在运行时动态发现工具、理解能力描述、选择调用目标、处理返回结果。整个过程是在线的、动态的——每次任务执行时，Agent 都可能选择不同的工具组合。MCP 的设计优化点是机器可理解性：精确的 Schema、结构化的能力描述、标准化的错误码。

这意味着几个具体区别：

  1. 发现方式不同。 API 靠文档和开发者口碑传播；MCP Server 靠注册表、元数据和运行时查询被发现。
  2. 调用方式不同。 API 调用在代码编写时就确定了；MCP 工具调用由 Agent 在运行时动态决定。
  3. 组合方式不同。 API 集成需要人工编排；MCP 工具可以被 Agent 自动组合成工作流。
  4. 演化方式不同。 API 变更需要人工适配客户端代码；MCP Server 更新后，Agent 通过能力描述自动适应。

ServiceNow 的 Integration Hub 是一个有趣的对照。它通过 200 多个 Spoke 让 Agent 运行时动态调用各种企业系统——本质上实现了 MCP 试图解决的同一个问题，但用的是封闭的、平台绑定的方式。MCP 的开放性意味着同一个 MCP Server 可以被 Claude、ChatGPT、自建 Agent 框架等任何支持 MCP 的客户端调用，而 ServiceNow Spoke 只能在 ServiceNow 生态内使用。

这就是开放协议 vs 封闭平台的经典对比——而在 Agent 时代，赌注比以往任何时候都高。

第三层洞察：MCP 最大的威胁不是技术失败

MCP 的技术基础是扎实的。JSON-RPC 2.0、标准化的传输层、清晰的能力模型——这些不是会在工程上失败的设计。真正的威胁来自生态层面。

威胁一：碎片化。 每个云厂商都在用自己的方式”支持 MCP”。AWS 通过 AgentCore Gateway 包装 MCP，Google 有自己的 Agent 工具协议考量，Microsoft 在 Copilot 体系中对 MCP 的支持方式又有不同。如果每个平台都做自己的”MCP 方言”——表面兼容但实际上绑定平台特性——那 MCP 的统一价值就会被稀释，就像 Android 碎片化侵蚀了”写一次到处运行”的承诺。

威胁二：工具质量失控。 Glama 索引了超过 19,000 个 MCP Server，但研究显示 97% 的工具描述存在质量问题。描述含糊的工具不会被 Agent 正确选择，而错误选择的工具会产生错误结果——在企业场景中，这不是”体验不好”，而是”合规风险”。MCP 注册表需要从”谁都能发布”演化为某种质量门控机制，但这又与开放生态的理念存在张力。

威胁三：安全与治理空白。 MCP 协议本身定义了传输安全和能力协商，但企业级的需求远不止于此：Agent 身份认证、工具调用审计、权限细粒度控制、跨租户隔离……这些在协议层面尚未完全标准化。Salesforce 在第四条设计原则中特别强调了”可验证的 Agent 身份”和”基于任务的限时权限”——这些正是 MCP 需要补齐的企业治理能力。

对企业 IT 决策者的建议

如果你正在评估 MCP，以下是基于当前生态状态的务实建议：

立刻开始，但从内部工具入手。 不要等 MCP 生态”成熟”——它已经足够成熟用于内部场景。选择你最常被请求集成的 3-5 个内部 API，用 MCP Server 包装它们。这既降低了风险（内部工具出错影响可控），又建立了团队能力。

把 MCP 当架构原则，不是技术选型。 学 Salesforce 的做法：不是在某个项目中用 MCP，而是把”新的 AI 集成必须通过 MCP”写入架构标准。这避免了未来的集成债务。

投资工具描述质量。 你的 MCP Server 写得多好不重要，Agent 能不能理解它才重要。每个工具的描述都应该回答：它做什么、不做什么、需要什么输入、返回什么结果、有什么副作用。GitHub 砍掉 60% 工具后性能提升的案例应该成为每个团队的参考。

关注发现与治理。 在 MCP 官方注册表发布你的 Server，同时建立内部的工具目录和审批流程。Agent 的工具选择应该受到与人类 API 访问同等级别的治理约束。

不要押注单一平台的 MCP 实现。 如果你的 MCP Server 只能在某个特定云平台上运行，你就失去了协议最大的价值——可移植性。确保你的 Server 实现是标准兼容的，可以在任何 MCP 客户端上工作。

结语：协议层的窗口期

每隔一段时间，技术行业就会经历一次”协议定义时刻”——HTTP 定义了 Web，TCP/IP 定义了网络，OAuth 定义了授权。这些协议的共同特点是：一旦确立，就会成为基础设施的一部分，几十年不变。

MCP 正处于这样的窗口期。它还不完美——安全模型需要加强，治理机制需要补齐，工具质量需要提升。但在 Agent 工具协议这个赛道上，它已经获得了 Anthropic、OpenAI、AWS、Salesforce、GitHub、Microsoft 等关键玩家的支持。这种生态广度在协议早期极为罕见。

Morgan Stanley 的选择说明了一切。当一家以保守著称的金融机构愿意在公开场合分享自己的 MCP 采纳旅程，这个协议的企业化进程就已经不可逆转。

问题不再是”要不要用 MCP”，而是”怎么用好 MCP”。

本文是「AI Agent 企业落地指南」系列的第 4 篇。前三篇分别讨论了 Agent 架构选型、多 Agent 协作模式和企业安全治理框架。下一篇（第 5 篇）将聚焦 Agent 的成本优化与规模化运营。

参考资料

  1. ICME Blog, “Getting Found by Agents: A Builder’s Guide to Tool Discovery in 2026” — https://blog.icme.io/getting-found-by-agents-a-builders-guide-to-tool-discovery-in-2026/
  2. AWS Machine Learning Blog, “Integrating Amazon Bedrock AgentCore with Slack” — https://aws.amazon.com/blogs/machine-learning/integrating-amazon-bedrock-agentcore-with-slack/
  3. Salesforce, “8 Design Principles for the Agentic Enterprise” — https://www.salesforce.com/news/stories/agentic-enterprise-design-principles/
  4. Model Context Protocol Official Documentation — https://modelcontextprotocol.io/introduction
  5. MCP Specification & Versioning — https://modelcontextprotocol.io/specification
  6. Morgan Stanley, “Building AI-Ready APIs: Morgan Stanley’s Journey Adopting MCP” — QCon London 2026
  7. Smithery MCP Server Registry — https://smithery.ai/