您尚未登录账户
您的企业账号申请正在审核中
构建AI代理？A2A与MCP的简要解析
LLM代理是一种能够自主行动以实现特定目标的AI系统。在实际应用中，代理可以将用户的请求分解为多个步骤，利用知识库或API获取数据，然后整合出最终答案。这使得代理比单一的聊天机器人更为强大——它们能够通过协调多个动作来自动化复杂的工作流程（例如预订旅行、生成报告、编写代码）。
一个形象的比喻是，LLM代理就像一个拥有插件访问权限的数字助手：它可以利用其内部知识进行推理，并通过工具对外界采取行动。例如，一个规划代理可能会决定需要哪些动作，一个记忆模块可以跟踪已经完成或学到的内容，而工具（如数据库查询或API）则提供实时数据。这种模块化设计使代理能够处理单个LLM无法完成的复杂任务，因此在开发人员自动化工作流程或构建“超级”助手时非常有价值。
代理对代理（A2A）和多组件提示（MCP）是构建此类代理的两种互补框架。从概念上讲，MCP就像是代理与外部工具之间的通用连接器（或“USB-C端口”）。相比之下，A2A就像是连接多个代理以便它们可以协作的网络电缆。它提供了一种开放协议用于代理间通信：代理公布能力，通过一个通用接口发送任务给彼此并共享输出。它们都旨在扩展普通的LLM，但在不同的规模和层次上。
让我们来了解它们的工作原理并进行比较。
理解模型上下文协议
MCP是一个开放标准协议（由Anthropic推出），允许基于LLM的应用程序以统一的方式访问外部数据和工具。它将这种交互分为三个角色：主机（LLM应用程序接口）、客户端（嵌入式连接器）和一个或多个服务器（工具提供者）。例如，一个主机应用程序（如聊天UI或IDE）包含一个MCP客户端，维护与外部MCP服务器的连接。每个服务器实现一个或多个工具（功能、API或资源流）。当LLM需要采取行动时——比如查询数据库或调用Slack——客户端将该请求转发给适当的MCP服务器，服务器执行该动作并返回结果。
核心思想是抽象掉M×N集成问题。在MCP之前，开发人员必须为每个模型到API的链接编写自定义代码。使用MCP，工具自我描述其输入和输出，因此任何兼容MCP的模型都可以使用它们而无需粘合代码。在实践中，代理（LLM）接收可用工具或提示/模板的列表，指导何时使用它们。然后它可以在结构化工作流程中调用工具：
理解 → 规划 → 验证 → 精炼 → 行动
这类似于一个思维链管道：LLM计划一个策略，检查其推理，并通过工具执行最终步骤。例如，一个使用MCP的旅行规划代理可能会解析“计划在日本度过一周”并识别所需工具（航班API、酒店搜索）。然后它通过MCP服务器查询这些API，检查一致性（例如日期对齐），根据需要进行调整，最后输出预订的行程。在代码中，这可能看起来像是添加一个“Google Flights”MCP服务器和一个“Hotel Finder”MCP服务器；代理的提示将包括它们的接口，以便在需要时调用它们。
图片来源：Salesforce Devops
什么是代理对代理协议？
A2A是一个新的开放协议（由谷歌在2025年推出），允许多个AI代理相互发现、交流和协作。在A2A系统中，每个代理都是一个具有自身能力的独立服务。代理公开一个实现A2A的网络端点和一个公共“代理卡”（在/.well-known/agent.json中的JSON元数据），描述其名称、技能、端点URL和认证信息。当一个代理需要某些东西时，它可以通过获取其代理卡来发现另一个代理，然后通过HTTP/JSON-RPC发送一个“任务”请求。协议和库在后台处理安全性、长时间运行的作业和复杂的数据格式。关键的A2A概念包括：
- 代理卡：一个小的JSON文件，宣传代理的能力（例如“可以安排会议”或“分析财务”）和端点。代理定期发布或注册这些卡，以便其他人可以找到它们（例如通过目录或仅知道一个URL）。
- 客户端和服务器代理：在A2A术语中，客户端代理发起任务（请求者），而远程/服务器代理执行任务。例如，一个“招聘代理”（客户端）可能委托给一个“简历搜索代理”（远程）。
- 任务生命周期：通信通过任务进行，这些任务是具有唯一ID的JSON对象。客户端发送一个任务（通过POST /tasks/send或订阅）包含用户的请求。远程代理然后在工作时更新任务状态（“工作中”、“需要输入”等），最后返回一个工件（结果）。服务器可以使用服务器发送事件（SSE）流式传输更新，或通过webhooks将更新推送回客户端。
- 消息和部分：任务包含消息（如聊天回合）。每条消息可以包含多个具有不同内容类型（文本、图像、JSON数据等）的部分，允许丰富的协作。例如，一个数据分析代理可能会以ImagePart形式发送回一个图表，并以DataPart形式发送回一个数据表。客户端和远程协商支持的格式，因此代理可以适应各种UI。
- 能力发现与委派：代理可以宣布或搜索能力。例如，一个协调代理可以扫描可用的代理卡以选择一个专门从事“合同分析”或“推文情感”的代理。然后将选定的代理发送任务以处理该子问题。
在实践中，A2A实现了多代理团队合作。例如，想象一下自动化公司活动策划：一个代理管理整体计划，而它将场地预订委托给“场地代理”，餐饮委托给“食品代理”，营销委托给“社交媒体代理”等。它们通过HTTP安全通信：计划代理制定任务（例如“寻找主讲人”），然后通过A2A将这些任务发送给专业代理。每个代理内部可能使用自己的LLM和工具，但在外部它们遵循A2A规范，因此任何兼容A2A的客户端都可以与它们对话。这种设计本质上是模块化的：代理就像微服务。如果一个代理速度慢或宕机，协调者可以将任务路由到备份或等待（协议支持长时间运行的任务和重试）。A2A基于标准技术（HTTP+JSON-RPC，SSE）以便于集成，并且“默认安全”使用OAuth/OpenAPI风格的认证。它处理从快速查询到扩展工作流程（包括人类在环）的任务。值得注意的是，它不假设代理共享内存或内部上下文；每个代理都是自主的。所有协调都是显式的：协议管理谁进行对话以及交换什么消息。
比较：A2A与MCP
| 方面 | MCP | A2A |
|---|---|---|
| 架构 | 单代理（以LLM为中心）与工具服务器。客户端-服务器：主机+客户端（在应用中）连接到一个或多个MCP服务器以获取工具 | 多代理（对等）网络。客户端和远程角色：代理通过代理卡进行广告，然后通过HTTP/JSON进行通信 |
| 核心目的 | 为一个代理提供结构化访问外部数据和API。作为“上下文层”丰富LLM的环境 | 实现代理间协作。让代理发现彼此，委派任务，并像在一个共同团队中一样共享输出 |
| 数据流 | 代理使用工具、资源和提示模板。它读取工具描述列表并根据需要调用它们。 | 代理交换任务、消息、工件和部分。每个任务都有生命周期；消息根据需要携带内容（文本/数据） |
| 模块化 | 在工具级别模块化：每个MCP服务器是一个独立的服务。但LLM代理及其推理仍然是一个过程。 | 在代理级别模块化：每个代理可以单独开发、扩展或替换而不影响其他代理。具有新技能的新代理可以加入生态系统。 |
| 可维护性 | 需要维护一个主要代理代码库和任意数量的工具服务器端点。更改工具的接口意味着更新其服务器（尽管协议保持标准）。 | 代理是独立的微服务。您可以更新或推出新的代理，而无需重新部署其他代理。然而，协调逻辑（通常是顶级代理或协调器）可能会变得更加复杂。 |
| 性能与可扩展性 | 如果服务器是本地的或配置良好，工具调用通常具有低延迟（使用直接HTTP或SSE）。随着工具数量的增加，复杂性也会增加，但集成是标准化的。如果上下文窗口溢出或同时调用过多，可能会受到影响。 | 代理之间的HTTP网络调用开销。最适合大规模工作流程：您可以通过并行运行多个代理实例来扩展。可以处理长时间运行的任务（数小时/天）并进行流式更新。依赖于异步通信，因此吞吐量取决于网络和代理的可用性。 |
| 能力 | 擅长结构化推理：代理可以将任务分解为可预测的步骤并进行验证。执行透明（每个步骤都有记录），易于审计。非常适合编码助手、数据查找或任何需要精确工具使用的任务。 | 擅长多样化的专业知识：每个代理团队都有专长（金融、自然语言处理、视觉等）进行协作。理想用于复杂的多领域任务（企业工作流程、多步骤业务流程），单个代理无法掌握所有知识。支持丰富的媒体（文本、音频、视频）协商。 |
| 显著例子 | 用于Claude Desktop和Zed或Cursor AI等工具，以链接到GitHub、日历等。非常适合单代理场景（例如“一个连接到我所有数据库的AI副驾驶”）。 | 在跨组织设置中出现（例如，与面试调度代理合作的简历搜索代理）、复杂的业务流程和Google的Agentspace等项目中。许多贡献者（Atlassian、Cohere、LangChain等）正在构建支持A2A的代理。 |
在实践中，MCP和A2A是互补的，而不是竞争的。谷歌明确表示A2A是Anthropic的MCP的“补充”。例如，一个代理可以在内部使用MCP（链接多个工具调用），然后通过A2A将结果交给另一个代理。或者一个专门的A2A代理本身可能使用MCP来管理其内部工具使用。上表强调了这一点：MCP关注工具和数据，A2A关注代理协调。
关于安全性和复杂性，这两种协议都引入了新的关注点。MCP的开放工具调用必须仔细进行沙箱化（提示注入或工具中毒是风险）。A2A在代理之间打开了许多端点，因此身份验证（OAuth、API密钥等）和授权（RBAC、令牌）至关重要。但两者都是为企业使用而构建的：A2A默认使用HTTP认证或OAuth2.0，MCP已更新以支持服务器的OAuth2.1。
总结
那么，这让我们处于什么位置？我们已经了解了MCP和A2A如何互补——一个专注于工具和数据集成，另一个专注于代理协调。我们也看到，虽然它们扩展了代理的功能，但也引入了新的复杂性和安全层需要管理。现在，真正的问题是：
- 您如何在自己的系统中结合这些框架？
- 您的下一个代理能否使用MCP链接工具，然后通过A2A跨服务协作？
- 您的安全模型是否为这个新的、更开放的代理生态系统做好准备？
作为开发者和架构师，我们不再仅仅构建聊天机器人——我们正在设计能够计划、行动和协调的代理系统。
