作者：来自ElasticJustin Castilla

Agent Builder 现已作为技术预览版提供。开始使用 Elastic Cloud 试用版，并在此处查看 Agent Builder 的文档。

简介

当前基于 LLM 的系统正在迅速发展，超越单一模型应用，形成复杂网络，其中专业 agent 协作完成现代计算以前无法想象的任务。随着这些系统复杂性的增加，使 agent 通信和工具访问成为开发的主要关注点。为满足这些需求，出现了两种互补的方法：用于多 agent 协作的 Agent2Agent（ A2A ）协议，以及用于标准化工具和资源访问的 Model Context Protocol（ MCP ）。

理解在何时如何协调使用或不使用这两者，会显著影响应用的可扩展性、可维护性和有效性。本文探讨了 A2A 的概念及其在数字新闻室的实际示例中的实现，其中专业 LLM agent 协作进行新闻文章的研究、撰写、编辑和发布。

相关代码仓库可在此找到，本文在第 5 节接近结尾处会展示 A2A 的实际应用示例。

前提条件

该仓库包含基于 Python 的 A2A agent 实现。提供了一个基于 Flask 的 API 服务器，以及一个名为 Event Hub 的自定义 Python 消息服务，用于路由消息以进行日志记录和 UI 更新。最后，提供了一个 React UI，用于独立使用新闻室功能。所有内容都包含在 Docker 镜像中，以便更容易实现。如果你希望在本机直接运行服务，需要确保安装以下技术：

语言和运行时

• Python 13.12 - 核心后端语言
• Node.js 18+ - 可选 React UI

核心框架和 SDK

• A2A SDK 0.3.8 - agent 协作和通信
• Anthropic SDK - Claude 集成，用于 AI 生成
• Uvicorn - 运行 agent 的 ASGI 服务器
• FastMCP 2.12.5+ - MCP 服务器实现
• React 18.2 - 前端 UI 框架

数据与搜索

• Elasticsearch 9.1.1+ - 文章索引和搜索

Docker 部署（可选，但推荐）

• Docker 28.5.1+

第 1 节：什么是 Agent2Agent（A2A）？

定义和核心概念

Agent2Agent（ A2A ）是独立 LLM agent 之间交互的标准化协议。A2A 不依赖单一整体系统处理所有任务，而是让多个专业 agent 能够沟通、协调和协作，以完成复杂工作流，这些工作流对于单个 agent 来说可能难以、高耗时或根本无法高效完成。

官方规范：https://a2a-protocol.org/latest/specification/

起源与发展

Agent2Agent 通信或多 agent 系统的概念源自分布式系统、微服务以及多 agent 研究，可追溯数十年。早期分布式人工智能工作为能够协商、协调和协作的 agent 奠定了基础。这些早期系统主要用于大规模社会模拟、学术研究和电网管理。

随着 LLM 可用性提升和运行成本降低，多 agent 系统进入了 “生产者消费者” 市场，并得到 Google 及更广泛 AI 研究社区的支持。如今被称为 Agent2Agent 系统，A2A 协议的加入已发展为现代标准，专为多 LLM 协作完成任务而设计。

A2A 协议通过在 LLM 连接和通信的交互点应用一致标准和原则，确保 agent 之间的无缝通信和协调。这种标准化使来自不同开发者、使用不同底层模型的 agent 能够有效协作。

通信协议并非新事物，它们在几乎所有互联网数字交易中都有广泛应用。如果你在浏览器中输入https://www.elastic.co/search-labs来访问本文，很可能 TCP/IP、HTTP 传输和 DNS 查询协议都已执行，确保我们有一致的浏览体验。

关键特征

A2A 系统基于几个基本原则构建，以确保顺畅通信。基于这些原则，不同的 agent（基于不同 LLM、框架和编程语言）都能无缝互动。

四个主要原则如下：

• 消息传递：agent 通过具有明确定义属性和格式的结构化消息进行通信
• 协调：agent 通过相互分配任务并管理依赖关系来组织复杂工作流，同时不阻塞其他 agent
• 专业化：每个 agent 专注于特定领域或能力，成为该领域专家，并基于技能完成任务
• 分布式状态：状态和知识分布在各 agent 之间，而非集中管理，agent 能够通过任务状态和部分结果（artifact）相互更新进度

新闻室示例

想象一个由 AI agent 驱动的数字新闻室，每个 agent 专注于新闻学的不同方面：

• 新闻主管（协调者/客户端）：分配新闻并监督工作流
• 记者 agent：根据研究和采访撰写文章
• 研究员 agent：收集事实、统计数据和背景信息
• 档案 agent：使用 Elasticsearch 搜索历史文章并识别趋势
• 编辑 agent：审查文章质量、风格和 SEO 优化
• 发布 agent：通过 CI/CD 将审核通过的文章发布到博客平台

这些 agent 并非独立工作；当新闻主管分配一篇关于可再生能源采用的报道时，记者需要研究员收集统计数据，编辑审查草稿，发布 agent 发布最终文章。这种协调通过 A2A 协议实现。

第 2 节：理解 A2A 架构

客户端 agent 与远程 agent 角色

在 A2A 架构中，agent 承担两种主要角色。客户端 agent 负责制定任务并与系统中的其他 agent 进行通信。它识别远程 agent 及其能力，并利用这些信息对任务分配做出明智决策。客户端 agent 协调整体工作流，确保任务得到适当分配，系统向目标推进。

相比之下，远程 agent 执行客户端委派的任务。它根据请求提供信息或采取特定行动，但不会独立发起操作。远程 agent 还可以根据需要与其他远程 agent 通信，以完成分配的职责，从而形成一个具有专业能力的协作网络。

在我们的新闻室示例中，新闻主管充当客户端 agent，而记者、研究员、编辑和发布者则是响应请求并相互协调的远程 agent。

核心 A2A 能力

A2A 协议定义了若干能力，使多 agent 协作成为可能：

1）发现

A2A 服务器必须公布其能力，以便客户端知道何时以及如何将其用于特定任务。这通过 Agent Card 实现 —— JSON 文档描述了 agent 的能力、输入和输出。Agent Card 可在一致的、已知的端点提供（例如推荐的 /.well-known/agent-card.json 端点），允许客户端在开始协作前发现并查询 agent 的能力。

下面是 Elastic 自定义档案 agent “Archie Archivist”的示例 Agent Card。请注意，像 Elastic 这样的软件提供商托管其 A2A agent，并提供访问的 URL：

{
  "name": "Archie Archivist",
  "description": "Helps find historical news documents in the Elasticsearch Index of archived news articles and content.",
  "url": "https://xxxxxxxxxxxxx-abc123.kb.us-central1.gcp.elastic.cloud/api/agent_builder/a2a/archive-agent",
  "provider": {
    "organization": "Elastic",
    "url": "https://elastic.co"
  },
  "version": "0.1.0",
  "protocolVersion": "0.3.0",
  "preferred_transport": "JSONRPC",
  "documentationURL": "https://www.elastic.co/docs/solutions/search/agent-builder/a2a-server"
  "capabilities": {
    "streaming": false,
    "pushNotifications": false,
    "stateTransitionHistory": false
  },
  "skills": [
    {
      "id": "platform.core.search",
      "name": "platform.core.search",
      "description": "A powerful tool for searching and analyzing data within your Elasticsearch cluster.",
      "inputModes": ["text/plain", "application/json"],
      "outputModes": ["text/plain", "application/json"]
    },
    {
      "id": "platform.core.index_explorer",
      "name": "platform.core.index_explorer",
      "description": "List relevant indices, aliases and datastreams based on a natural language query.",
      "inputModes": ["text/plain", "application/json"],
      "outputModes": ["text/plain", "application/json"]
    }
  ],
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"]
}

该 Agent Card 揭示了 Elastic 档案 agent 的几个重要方面。该 agent 自我标识为 “Archie Archivist”，并清楚说明其用途：帮助在 Elasticsearch 索引中查找历史新闻文档。Card 指定了提供商（Elastic）和协议版本（0.3.0），确保与其他符合 A2A 标准的 agent 兼容。最重要的是，skills 数组列出了该 agent 提供的具体能力，包括强大的搜索功能和智能索引探索。每项技能定义了其支持的输入和输出模式，使客户端能够准确了解如何与该 agent 通信。此 agent 来源于 Elastic 的 Agent Builder 服务，该服务提供一套原生 LLM 支持的工具和 API 端点，使你能够与数据存储进行对话，而不仅仅是检索数据。Elasticsearch 中 A2A agent 的访问可在此找到。

2）协商

客户端和 agent 需要就通信方式达成一致 —— 无论是通过文本、表单、 iframes，甚至音频/视频 —— 以确保正确的用户交互和数据交换。这种协商发生在 agent 协作开始时，并建立整个工作流中管理交互的协议。例如，基于语音的客服 agent 可能协商通过音频流通信，而数据分析 agent 可能更喜欢结构化 JSON。协商过程确保双方能够以适合其能力和任务要求的格式有效交换信息。

上面 JSON 片段中列出的能力都具有输入和输出模式；这些模式设定了其他 agent 如何与该 agent 交互的预期。

3）任务与状态管理

客户端和 agent 需要机制在任务执行过程中传递任务状态、变化和依赖关系。这包括管理任务从创建、分配到进度更新和状态变化的整个生命周期。典型状态包括待处理、进行中、已完成或失败。系统还必须跟踪任务间的依赖关系，以确保先决工作完成后再开始依赖任务。错误处理和重试逻辑也是关键组成部分，使系统能够在失败后优雅恢复，并继续向主要目标推进。

任务消息示例：

{
  "message_id": "msg_789xyz",
  "message_type": "task_request",
  "sender": "news_chief",
  "receiver": "researcher_agent",
  "timestamp": "2025-09-30T10:15:00Z",
  "payload": {
    "task_id": "task_456abc",
    "capability": "fact_gathering",
    "parameters": {
      "query": "renewable energy adoption rates in Europe 2024",
      "sources": ["eurostat", "iea", "ember"],
      "depth": "comprehensive"
    },
    "context": {
      "story_id": "story_123",
      "deadline": "2025-09-30T18:00:00Z",
      "priority": "high"
    }
  }
}

该任务消息示例展示了 A2A 通信的几个关键方面。

• 消息结构包括元数据，例如唯一消息标识符、发送的消息类型、发送方和接收方标识，以及用于跟踪和调试的时间戳。
• 有效负载包含实际的任务信息，指定在远程 agent 上调用的能力，并提供执行该能力所需的参数。
• 上下文部分提供额外信息，帮助接收 agent 理解更广泛的工作流，包括截止日期和优先级，这些信息指导 agent 如何分配资源和安排工作。

4）协作

客户端和 agent 必须支持动态且结构化的交互，使 agent 能够向客户端、其他 agent 或用户请求澄清、信息或子操作。这创造了一个协作环境，使 agent 在初始指令模糊时可以提出后续问题，请求额外上下文以做出更好决策，将子任务委派给具有更合适专业知识的其他 agent，并在执行完整任务前提供中间结果以供反馈。这种多向通信确保 agent 不孤立工作，而是参与持续对话，从而产生更好的结果。

分布式点对点通信

A2A 支持分布式通信，agent 可能由不同组织托管，其中一些 agent 在内部维护，而其他 agent 由第三方服务提供。这些 agent 可以运行在不同基础设施上 —— 可能跨多个云提供商或本地数据中心。它们可能使用不同的底层 LLM，有的 agent 由 GPT 模型提供支持，有的由 Claude 提供，还有的由开源替代方案提供支持。agent 甚至可能跨不同地理区域运行，以满足数据主权要求或降低延迟。尽管存在这种多样性，所有 agent 都遵循共同的通信协议交换信息，确保无论实现细节如何都能互操作。这种分布式架构为系统的构建和部署提供了灵活性，使组织能够根据自身需求组合最优的 agent 和基础设施。

这是新闻室应用的最终架构：

第 3 节：Model Context Protocol（MCP）

定义与目的

Model Context Protocol（MCP）是由 Anthropic 开发的标准化协议，用于增强和赋能单个 LLM，使其能够使用用户定义的工具、资源和 prompts，以及其他补充代码库内容。MCP 为语言模型与完成任务所需的外部资源之间提供了通用接口。本文概述了 MCP 的现状，包括使用案例示例、新兴趋势以及 Elastic 的实现方式。

核心 MCP 概念

MCP 基于客户端-服务器架构，包含三个主要组件：

• 客户端（Clients）：连接到 MCP 服务器以访问其能力的应用程序（如 Claude Desktop 或自定义 AI 应用）
• 服务器（Servers）：向语言模型提供资源、工具和 prompts 的应用程序。每个服务器专注于提供对特定能力或数据源的访问
  • 工具（Tools）：用户定义的函数，模型可以调用以执行操作，例如搜索数据库、调用外部 API 或对数据执行转换
  • 资源（Resources）：模型可以读取的数据源，提供动态或静态数据，通过 URI 模式访问（类似 REST 路由）
  • Prompts：带变量的可复用 prompt 模板，引导模型完成特定任务

请求-响应模式

MCP 遵循类似 REST API 的请求-响应交互模式。客户端（LLM）请求资源或调用工具，然后 MCP 服务器处理请求并返回结果，LLM 利用该结果继续任务。与点对点 agent 通信相比，这种以中心化模型与外围服务器的方式提供了更简单的集成模式。

新闻室中的 MCP

在我们的新闻室示例中，各个 agent 使用 MCP 服务器访问所需的工具和数据：

• 研究员 agent 使用：
  • News API MCP 服务器（访问新闻数据库）
  • Fact-Checking MCP 服务器（根据可信来源验证信息）
  • Academic Database MCP 服务器（学术文章和研究资料）
• 记者 agent使用：
  • Style Guide MCP 服务器（新闻室写作标准）
  • Template MCP 服务器（文章模板和格式）
  • Image Library MCP 服务器（库存图片和图形）
• 编辑 agent使用：
  • Grammar Checker MCP 服务器（语言质量工具）
  • Plagiarism Detection MCP 服务器（原创性验证）
  • SEO Analysis MCP 服务器（标题和关键词优化）
• 发布 agent 使用：
  • CMS MCP 服务器（内容管理系统 API）
  • CI/CD MCP 服务器（部署管道）
  • Analytics MCP 服务器（跟踪与监控）

第 4 节：架构比较

何时使用 A2A

A2A 架构在需要真正多 agent 协作的场景中表现出色。多步骤工作流需要协调时，A2A 特别有利，尤其是任务涉及多个顺序或并行步骤、需要迭代和优化的工作流，以及包含检查点和验证需求的流程。在我们的新闻室示例中，新闻工作流要求记者撰写文章，但如果某些事实的可靠性不足，可能需要返回给研究员进行核实，然后继续交给编辑，最终由发布者发布。

跨多个领域的专业化也是 A2A 的强力用例。当完成更大任务需要多个领域的专家，每个 agent 提供深厚的领域知识和针对不同方面的专业推理能力时，A2A 提供了实现这些连接所需的协调框架。新闻室示例完美说明了这一点：研究员专注于信息收集，记者专注于写作，编辑专注于质量控制 —— 每个角色都有独特的专业能力。

自主 agent 行为的需求使 A2A 尤为有价值。能够独立决策、根据变化条件主动行动并动态适应工作流需求的 agent 在 A2A 架构中表现出色。专业功能的水平扩展也是一个关键优势 —— 与其依赖单个全能 agent，不如让多个专业 agent 协作，同一 agent 的多个实例可以异步处理子任务。例如，在新闻突发事件中，多名记者 agent 可能同时处理同一故事的不同角度。

最后，需要真正多 agent 协作的任务非常适合 A2A，包括LLM 作为陪审机制、共识构建和投票系统，以及需要多方视角来达成最佳结果的协作问题解决。

何时使用 MCP

Model Context Protocol 适合扩展单个 AI 模型的能力。当单个 AI 模型需要访问多个工具和数据源时，MCP 提供了完美解决方案，将集中推理与分布式工具以及简单的工具集成结合。在我们的新闻室示例中，研究员 agent（单个模型）需要访问多个数据源，包括 News API、事实核查服务和学术数据库 —— 这些都通过标准化 MCP 服务器访问。

当工具集成的广泛共享和可复用性很重要时，标准化工具集成变得优先。MCP 在这方面表现突出，其预构建 MCP 服务器生态系统显著减少了常用集成的开发时间。在需要简化和可维护性的情况下，MCP 的请求-响应模式对开发者熟悉，比分布式系统更容易理解和调试，并且运营复杂性较低。

最后，MCP 通常由软件提供商提供，以简化与其系统的远程通信。这些提供商的 MCP 服务器显著减少了入门和开发时间，同时提供了标准化接口，使集成比自定义 API 开发更简单。

何时同时使用（A2A ❤️ MCP）

许多复杂系统受益于 A2A 与 MCP 的结合，如 A2A 文档中关于 MCP 集成所述。需要协调与标准化的系统是混合方法的理想候选。A2A 负责 agent 协调和工作流编排，而 MCP 为单个 agent 提供工具访问。在我们的新闻室示例中，agent 通过 A2A 协调工作流，从记者到研究员，再到编辑和发布者。然而，每个 agent 使用 MCP 服务器访问其专业工具，实现了清晰的架构分离。

多个使用 MCP 访问工具的专业 agent 是常见模式：agent 协调层由 A2A 管理，工具访问层由 MCP 管理。这种明确的职责分离使系统更易理解和维护。

结合两种方法的好处显著。你可以获得多 agent 系统的组织优势，包括专业化、自主性和平行处理，同时享受 MCP 的标准化和生态系统优势，如工具集成和资源访问。agent 协调（A2A）与资源访问（MCP）清晰分离，且对于仅需 API 访问的小任务，不需要 A2A —— MCP 可高效处理，无需多 agent 编排的额外开销。

常见问题：A2A 与 MCP 的使用场景

结论

这是两部分内容中的第一部分，介绍了基于 A2A 的 agent 实现，并辅以 MCP 服务器以提供数据和工具的支持与外部访问。下一部分将展示实际代码，演示它们如何协作以模拟在线新闻室中的工作活动。虽然这两个框架各自都非常强大且灵活，但你将看到它们在协同工作时是多么互补。

原文：https://www.elastic.co/search-labs/blog/a2a-protocol-mcp-llm-agent-newsroom-elasticsearch