一、云厂商的 Agent 战略

三大云服务提供商 AWS、Azure、GCP 都在积极布局 Agent 领域。AWS 推出了 Bedrock Agents，Azure 推出了 Copilot Studio 和 Semantic Kernel，GCP 推出了 Vertex AI Agent Builder。这些服务的目标是一致的：让企业能够在其云平台上轻松构建、部署和运行 Agent 应用。

然而，这些云厂商的 Agent 服务目前大多采用封闭或半封闭的模式。每个厂商都有自己的 Agent 框架、自己的Tool 定义格式、自己的认证方式。一个为 AWS Bedrock 开发的 Agent 无法直接迁移到 Azure，一个基于 Azure Semantic Kernel 构建的 Tool 不能在 GCP 上使用。这种隔离与 Agent 时代开放协作的愿景相悖。

MCP 作为统一的 Agent-Skill 交互协议，为云厂商提供了一个标准化的集成点。本章将探讨 AWS、Azure、GCP 如何拥抱 MCP，以及这种集成对企业用户意味着什么。

二、云厂商拥抱 MCP 的驱动力

云厂商有充分的理由支持 MCP。

第一，用户需求驱动。越来越多的企业用户要求跨云或多云的 Agent 部署能力。他们不希望被锁定在单一云厂商的 Agent 框架中。MCP 提供了标准化的 Skill 接口，使得 Skill 可以一次开发、跨云部署。

第二，Skill 生态的共享。如果每个云厂商都维护一个封闭的 Skill 市场，Skill 开发者需要为每个平台重复开发。这不仅浪费资源，也拖慢了创新速度。MCP 使得 Skill 可以在不同云厂商之间共享，大大扩展了 Skill 的市场空间。

第三，与现有服务的集成。云厂商拥有丰富的 API 服务，如 AWS 的 S3、Lambda、DynamoDB，Azure 的Blob Storage、Functions、Cosmos DB，GCP 的 Cloud Storage、Cloud Functions、BigQuery。将这些服务封装成 MCP Skill，可以让任何支持 MCP 的 Agent 调用，而不局限于该云厂商自己的 Agent 框架。

第四，差异化竞争的空间。虽然 Skill 接口是标准化的，但云厂商仍然可以在 Agent 编排、模型选择、运维工具、成本优化等方面进行差异化竞争。MCP 标准化的是 Skill 接口，而不是 Agent 的实现。

三、AWS 与 MCP 的集成

AWS 拥有最丰富的云服务生态，也是 Agent 领域的重要玩家。

AWS Bedrock Agents 的现状

AWS Bedrock Agents 允许开发者定义 Agent，指定其指令和一组 Action Group。每个 Action Group 对应一个Lambda 函数或 API 端点。Agent 通过自然语言理解用户意图，调用对应的 Action Group。目前，Action Group 的定义格式是 AWS 特有的。

引入 MCP 的路径

AWS 可以在 Bedrock Agents 中增加对 MCP 的原生支持。具体来说，Agent 可以配置 MCP 端点，直接调用任何符合 MCP 标准的 Skill。这意味着开发者可以使用为 MCP 生态开发的 Skill，而不需要为 Bedrock 重新封装。

同时，AWS 可以将自己的服务以 MCP Skill 的形式提供。例如，S3 Skill 提供对象存储的读写操作，Lambda Skill 提供函数调用能力，SQS Skill 提供消息队列操作，DynamoDB Skill 提供 NoSQL 数据操作。这些 Skill 可以部署在 AWS 的 MCP Gateway 上，任何支持 MCP 的 Agent 都可以调用。

AWS 作为 Skill 托管平台

AWS 还可以成为一个 Skill 托管平台。开发者可以将自己开发的 MCP Skill 部署到 AWS 上，利用 AWS 的Lambda、ECS、EKS 等服务运行 Skill 服务器。AWS 可以提供 Skill 的自动伸缩、监控、日志等运维能力。这为 Skill 开发者提供了一个可靠的托管环境。

四、Azure 与 MCP 的集成

Azure 在 Agent 领域的产品线包括 Copilot Studio 和 Semantic Kernel。

Semantic Kernel 的现状

Semantic Kernel 是一个开源的 Agent 框架，支持 C、Python 和 Java。它允许开发者定义 Plugin，每个 Plugin 包含一组 Function。Plugin 可以被 Agent 调用。目前，Plugin 的格式是 Semantic Kernel 特有的。

引入 MCP 的路径

Semantic Kernel 可以增加 MCP Plugin 适配器。开发者可以直接将 MCP Skill 作为 Plugin 导入。Semantic Kernel 的 Agent 可以调用任何 MCP Skill，就像调用原生 Plugin 一样。这大大扩展了 Semantic Kernel 的生态。

Azure AI Foundry 与 MCP

Azure AI Foundry 是 Azure 的统一 AI 开发平台。它可以在其中增加 MCP Skill 目录，用户可以浏览和部署来自MCP 生态的 Skill。Azure 可以提供 Skill 的托管运行环境，利用 Azure Container Apps 或 Kubernetes Service。

与 Power Platform 的集成

Power Platform 的低代码工具 Power Automate 和 Power Apps 也可以受益于 MCP。用户可以通过简单的配置调用 MCP Skill，将 AI 能力融入业务流程。MCP 使得 Power Platform 可以访问一个庞大的 Skill 生态。

五、GCP 与 MCP 的集成

GCP 在 Agent 领域的核心产品是 Vertex AI Agent Builder。

Vertex AI Agent Builder 的现状

Vertex AI Agent Builder 允许开发者使用自然语言构建 Agent。开发者可以指定 Tool，每个 Tool 对应一个 API 端点。目前，Tool 的定义格式是 GCP 特有的。

引入 MCP 的路径

GCP 可以在 Agent Builder 中增加对 MCP Tool 的支持。Agent 可以配置 MCP 端点，调用任何 MCP Skill。此外，GCP 可以将自己的服务封装为 MCP Skill，例如 BigQuery Skill 提供数据仓库查询，Cloud Storage Skill 提供对象存储操作，Cloud Run Skill 提供容器化应用调用。

与 Apigee 的集成

GCP 拥有 API 管理平台 Apigee。Apigee 可以成为 MCP 网关的企业级替代方案。企业可以在 Apigee 中配置MCP Skill 的认证、限流、分析等能力，而不需要自己部署网关。Apigee 的丰富策略可以与 MCP 集成，提供企业级的 API 治理。

与 Vertex AI 模型花园的集成

Vertex AI 的模型花园提供了丰富的开源和商用模型。Agent 需要调用模型时，可以通过一个标准的 MCP Skill 来访问这些模型。这使得模型的使用与 Agent 框架解耦。

六、跨云 Skill 部署

MCP 最激动人心的前景之一是跨云 Skill 部署。一个 Skill 可以部署在 AWS，被运行在 Azure 的 Agent 调用，而另一个 Skill 可能运行在 GCP。

场景示例

假设一家企业使用 AWS 作为主要云平台，但它的某些业务线在 Azure 上有遗留系统。企业需要构建一个 Agent 来协调两个云上的数据。Agent 可以运行在任何地方，通过 MCP 调用 AWS 上的 S3 Skill 和 Azure 上的 Blob Storage Skill。Agent 不需要关心 Skill 运行在哪里，只需要知道它们的 MCP 端点。

技术挑战

跨云 Skill 部署面临几个挑战。网络连通性，AWS 和 Azure 之间的网络延迟较高，且需要配置跨云连接。认证和授权，跨云调用需要统一的身份认证体系。数据合规，某些数据不能离开特定地理区域，需要在策略中体现。

Peta 等控制平面可以帮助解决这些挑战。Peta 支持跨云网关部署，可以聚合来自多个云的 Skill，提供统一的管理界面和策略控制。

七、MCP 对云厂商的战略意义

拥抱 MCP 对云厂商不仅是技术选择，更是战略选择。

从锁定到开放

传统的云厂商策略是通过专有 API 锁定用户。但越来越多的企业用户要求开放和可移植性。提供 MCP 支持可以降低用户对锁定的担忧，反而可能吸引更多用户。用户知道他们不会被锁定，更愿意在某个云上构建核心业务。

Skill 生态的网络效应

哪个云厂商能够吸引最多的 MCP Skill，哪个就能获得最大的生态优势。开发者会选择 Skill 市场最丰富的平台。早期拥抱 MCP 的云厂商有机会建立先发优势。

从服务到平台的升级

提供 MCP 支持将使云厂商从提供 AI 服务升级为提供 Agent 平台。用户可以自由组合来自不同来源的 Skill，而云厂商则提供托管、运维、治理等增值服务。

八、对企业的启示

对于企业用户来说，云厂商对 MCP 的支持意味着更大的灵活性和选择权。

第一，Skill 可移植性。企业开发的 Skill 可以在不同云之间迁移，不被单一厂商锁定。这意味着企业可以根据成本、性能、合规等因素随时调整部署策略。

第二，混合云和边缘场景。MCP 的标准接口使得 Agent 可以调用运行在任何地方的 Skill，包括企业内部数据中心、边缘设备、其他云。这为构建统一的 AI 治理层提供了可能。

第三，采购议价能力。企业可以要求云厂商提供 MCP 支持作为采购条件。也可以同时使用多个云厂商的 Agent 服务，根据性价比动态分配负载。

第四，自建 Skill 的价值保值。企业投资开发的 Skill 不会因为更换 Agent 框架或云厂商而失效。只要这些 Skill 提供 MCP 接口，它们就可以在任何支持 MCP 的环境中被复用。

九、小结

本章的核心结论可以总结为以下几点。

第一，三大云厂商都在积极布局 Agent 领域，但目前的服务大多是封闭的。MCP 为云厂商提供了一个标准化的集成点。

第二，云厂商拥抱 MCP 的驱动力包括用户需求、Skill 生态共享、与现有服务集成、差异化竞争。

第三，AWS 可以在 Bedrock Agents 中增加 MCP 支持，并将 S3、Lambda、SQS、DynamoDB 等服务封装为MCP Skill。

第四，Azure 可以在 Semantic Kernel 中增加 MCP 适配器，在 AI Foundry 中提供 Skill 目录，并与 Power Platform 集成。

第五，GCP 可以在 Vertex AI Agent Builder 中增加 MCP 支持，并与 Apigee 和模型花园集成。

第六，跨云 Skill 部署是 MCP 的重要前景，但面临网络、认证、合规等挑战。Peta 等控制平面可以帮助应对这些挑战。

第七，拥抱 MCP 对云厂商是战略选择，可以降低用户锁定担忧、建立 Skill 生态网络效应、从服务升级为平台。

第八，对企业用户，MCP 带来 Skill 可移植性、混合云支持、采购议价能力、自建 Skill 的价值保值。

在下一章，我们将探讨 MCP 与边缘计算的结合——在资源受限环境中部署 MCP。