Agent2Agent（谷歌）与 Model Context Protocol（MCP）：智能体互联与 API 集成的架构性进化答案

本文由葡萄牙语原文自动翻译。阅读原文

生态碎片化导致返工与不一致！

距首批生成式 AI 框架发布已有约三年。今天构建这类解决方案时，我们会发现有多种技术可以把智能体「连接」到知识库和 API：各种 RAG、GraphRAG、Function Calling 等等。发起外部调用时，可以用 Python、JavaScript、C# 等多种编程语言。然而，每个集成框架都有一套让调用生效的自有规则。很多时候，即使提示词打磨得再好，模型在生成一段连贯的集成脚本时仍会「挣扎」— 因为实现方式五花八门，取决于框架、调用类型、数据结构与要传递的上下文。这要求提示词工程随上下文、框架和外部调用工具而调整，而且许多情况下仍有明显失败。主因正是这个生态的技术碎片化。为了解决这个问题、把这摊事标准化，MCP 和谷歌的 A2A 应运而生 — 它们都是开源协议（正如大部分 AI 智能体框架）。

Model Context Protocol（MCP）是一个开放标准，用模块化、有组织、可扩展的方式来组织传递给大语言模型的_上下文_。换句话说，它定义了如何以标准化方式组织并丰富提示词，让不同的应用、智能体或工具能够以互操作的方式组合和共享上下文的各个部分。MCP 由 Anthropic 发起，如今在 GitHub 上拥有庞大的贡献者社区。

Model Context Protocol 解决了一个关键问题：向智能体提供一致的上下文，同时不暴露敏感数据（例如认证密钥）。它的架构定义了：

1. 元数据结构：描述智能体可接受的工具、权限与数据格式。

2. 安全抽象：允许智能体访问外部系统（如数据库）而无需直接共享凭证，并带有用户控制：任何操作（如访问个人数据）都需要明确同意。

3. 技术互操作性：充当中间层，在专有格式与智能体的「语言」之间转换数据。

例如，一个使用 MCP 的智能体可以收到清晰的指令：如何查询库存 API、哪些参数有效、如何处理错误 — 全程无需开发者为每个集成编写专门规则。它的架构可以分为：

1. 宿主（MCP 客户端）：Claude Desktop、ChatGPT Web 或 IDE 等发起 MCP 服务器连接的应用。

2. MCP 服务器：通过标准化协议暴露特定资源与工具的应用（经由 API）。例如 GitHub 已经创建了自己的 MCP，让模型与其 API 交互。

3. 数据源：向 MCP 服务器提供信息的本地或远程系统，如数据库、文件系统或 API。

这种模块化结构让 AI 智能体能高效地访问和操纵外部数据。这里有一张速查表帮助理解：

MCP 速查表

Agent2Agent（A2A）：谷歌的智能体协作方案

在今年 4 月的 Google Cloud Next 2025 大会上，谷歌发布了 Agent2Agent（A2A）：同样是开放协议，旨在让不同生态中的 AI 智能体安全协作，无论框架或供应商。你们会注意到，与 MCP 不同，A2A 聚焦于用户体验。

A2A 旨在促进：

1. 安全协作：让 AI 智能体安全地共享信息、协调行动。

2. 任务与状态管理：跟踪任务进度与参与智能体的状态。

3. 用户体验协商：根据用户的偏好与需求调整智能体行为。

4. 能力发现：识别并利用每个参与智能体的特定技能。

谷歌希望通过 A2A 建立一个 AI 智能体互操作的标准，促成一个更集成、更协作的生态。MCP 和 A2A 的目标都是改善互操作性。

MCP vs A2A

MCP 关注智能体如何访问和使用外部资源，A2A 则处理智能体之间如何交互与协作。两者互补，都是构建更连贯、更高效的 AI 智能体生态的基石。下图应该能更清楚地展示这两个协议各自作用于哪一层。

智能体语境中的 MCP 与 A2A

AI 智能体框架的演进一直卡在一个结构性障碍上：缺乏与外部数据源和 API 集成的通用标准。每个框架 — LangChain、Semantic Kernel、AutoGen 或其他 — 都发展出各自连接数据、工具与服务的方式，造成了一个碎片化的生态。

MCP 与 A2A 代表了 AI 系统架构的一次跃升：前者标准化了智能体与数据的关系，后者重新定义了智能体间的协作。二者合力构成一个生态：智能体不再是「孤岛」，而是自治网络中彼此集成的部分。但它们的成功将取决于技术中立与多边合作 — 为避免碎片化历史重演，这是公道的代价。说到底，MCP 和 A2A 只是开始。更深刻的革命将在智能体之间的沟通像人类语言一样流畅时到来 — 而人类语言也自有其问题。可以肯定的是，明天的问题会是新的问题：新的「沟通噪音」会是什么？🕵🏾‍♂️ 一起去发现。