在 Elasticsearch 中使用 A2A 协议和 MCP 创建 LLM Agent 新闻室：第一部分

Agent Builder is available now GA. Get started with an Elastic Cloud Trial, and check out the documentation for Agent Builder here.

引言

当前由 LLM 支持的系统正在迅速发展，超越了单一模型应用，成为复杂的网络，其中专门的代理共同完成现代计算前所未有的任务。随着这些系统的复杂性不断增加，使代理通信和工具访问成为可能的基础设施成为开发的重点。为满足这些需求，出现了两种互补的方法：用于多代理协调的代理2代理（A2A）协议，以及用于标准化工具和资源访问的模型上下文协议（MCP）。

了解在什么情况下可以同时使用和不使用这两种方法，会对应用程序的可扩展性、可维护性和有效性产生重大影响。本文以数字新闻编辑室为例，探讨了A2A的概念和实现方法，在数字新闻编辑室中，专门的 LLM 代理合作研究、撰写、编辑和发布新闻文章。

我们将在文章最后的第 5 部分探讨 A2A 的具体应用实例。

准备工作

资源库由 A2A 代理的 Python 实现组成。Flask 提供了一个 API 服务器，以及一个名为 Event Hub 的自定义 Python 消息传递服务，用于路由日志和 UI 更新消息。最后，还提供了一个 React UI，用于独立使用新闻编辑室的功能。所有内容都包含在一个 Docker 镜像中，以便于实施。如果您想直接在机器上运行服务，则需要确保安装了这些技术：

语言和运行时

• Python 13.12 - 核心后端语言

• Node.js 18+ - 可选 React UI

核心框架和 SDKS：

• A2A SDK 0.3.8 - Agent 协调与通信

• Anthropic SDK--克劳德集成人工智能生成器

• Uvicorn - 用于运行代理的 ASGI 服务器

• FastMCP 2.12.5+ - MCP 服务器实施

• React 18.2 - 前端用户界面框架

数据& 搜索

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

Docker 部署（可选，但建议使用）

• Docker 28.5.1+

第 1 部分：什么是 Agent2Agent（A2A）？

定义和核心概念

Agent2Agent(A2A) 是独立 LLM 代理 之间进行交互的标准化协议。A2A 不是由一个单一的系统来处理所有任务，而是让多个专业代理进行沟通、协调和协作，以完成复杂的工作流程，而这些工作流程对于任何单一代理来说都是难以高效处理、速度缓慢或根本不可能完成的。

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

起源与进化

Agent2Agent 通信或多代理系统的概念源于几十年前的分布式系统、微服务和多代理研究。分布式人工智能的早期工作为能够进行协商、协调和协作的代理奠定了基础。这些早期系统专门用于大规模社会模拟、学术研究和电网管理。

在谷歌和更广泛的人工智能研究界的支持下，随着 LLM 的出现和运行成本的降低，多代理系统开始进入 "专业消费者 "市场。现在，A2A 协议被称为 Agent2Agent 系统，它已发展成为一个现代标准，专为多个大型语言模型协调工作和任务的时代而设计。

A2A 协议将一致的标准和原则应用于 LLM 连接和通信的交互点，从而确保代理之间的无缝通信和协调。这种标准化使来自不同开发商、使用不同底层模型的代理能够有效地协同工作。

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

主要特点

A2A 系统建立在几个基本原则之上，以确保通信顺畅。以这些原则为基础，可以确保基于不同 LLM、框架和编程语言的不同代理都能无缝互动。

以下是四项主要原则：

• 信息传递：代理通过具有明确属性和格式的结构化信息进行通信

• 协调：代理通过相互委派任务和管理依赖关系来协调复杂的工作流程，而不会阻塞其他代理

• 专业化：每个代理都专注于某一特定领域或能力，成为该领域的专家，并根据技能组合完成任务

• 分布式状态：状态和知识分布在各个代理之间，而不是集中在一起，代理之间能够相互更新任务状态和部分回报（工件）的进展情况

新闻编辑室运行范例

试想一个由人工智能代理驱动的数字新闻编辑室，每个代理都擅长新闻业的不同方面：

• 新闻主管（协调员/客户）：分配报道任务并监督工作流程

• 记者代理：根据研究和采访撰写文章

• 研究员代理：收集事实、统计数据和背景信息

• 档案代理：使用 Elasticsearch 搜索历史文章并确定趋势

• 编辑代理：对文章的质量、风格和搜索引擎优化进行审核

• 发布者代理：通过 CI/CD 将批准的文章发布到博客平台上

当新闻主管指派一篇关于可再生能源应用的报道时，记者需要研究员收集统计数据，编辑需要审阅草稿，出版商需要出版最终稿件。这种协调是通过 A2A 协议进行的。

第 2 节：了解 A2A 架构

客户代理和远程代理角色

在 A2A 架构中，代理主要扮演两种角色。客户代理负责制定任务并将任务传达给系统中的其他代理。它能识别远程代理及其能力，并利用这些信息就任务授权做出明智的决策。客户代理负责协调整个工作流程，确保任务分配得当，系统朝着目标前进。

而远程代理则负责执行客户委托的任务。它根据请求提供信息或采取具体行动，但不会独立发起行动。远程代理还可以根据需要与其他远程代理进行通信，以履行其指定职责，从而创建一个具有专业能力的协作网络。

在我们的新闻编辑室，新闻主管充当客户代理，而记者、研究员、编辑和出版商则是远程代理，负责响应请求并相互协调。

A2A 核心能力

A2A 协议定义了几种实现多代理协作的功能：

1.发现

A2A 服务器必须公布其功能，以便客户知道何时以及如何利用它们完成特定任务。这可以通过描述代理能力、输入和输出的代理卡--JSON 文档来实现。代理卡在一致的知名端点（如推荐的/.well-known/agent-card.json 端点）上提供，允许客户在启动协作之前发现并查询代理的能力。

以下是 Elastic 定制存档代理"Archie Archivist" 的代理卡示例。请注意，Elastic 等软件提供商会托管其 A2A 代理，并提供一个 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"]
}

该代理卡揭示了 Elastic 档案代理的几个重要方面。该代理将自己定位为"Archie Archivist" ，并明确说明了自己的目的：帮助在 Elasticsearch 索引中查找历史新闻文档。该卡指定了提供商（Elastic）和协议版本（0.3.0），以确保与其他 A2A 兼容代理的兼容性。最重要的是，skills 数组列举了该代理提供的具体功能，包括强大的搜索功能和智能索引探索。每种技能都定义了它所支持的输入和输出模式，使客户能够准确了解如何与该代理进行通信。该代理源于 Elastic 的代理生成器服务，它提供了一套本地 LLM 支持的工具和 API 端点，用于与数据存储对话，而不仅仅是从存储中检索。可在此处访问 Elasticsearch 中的 A2A 代理。

2.谈判

客户和代理需要就交流方式达成一致--无论互动是通过文本、表单、iframe 还是音频/视频进行，以确保适当的用户互动和数据交换。这种协商发生在代理合作的开始阶段，并确立了整个工作流程中的交互协议。例如，语音客户服务代理可能会协商通过音频流进行通信，而数据分析代理可能更喜欢结构化的 JSON。谈判过程可确保双方以适合自身能力和当前任务要求的形式有效交换信息。

上述 JSON 代码段中列出的功能都有输入和输出模式；这些模式设定了如何与其他代理交互。

3.任务和状态管理

在整个任务执行过程中，客户端和代理需要有机制来交流任务状态、变化和依赖关系。这包括管理任务从创建、分配到进度更新和状态更改的整个生命周期。典型的状态包括待处理、进行中、已完成或失败状态。系统还必须跟踪任务之间的依赖关系，以确保在依赖任务开始之前完成前提工作。错误处理和重试逻辑也是必不可少的组成部分，可让系统从容地从故障中恢复，并继续朝着主要目标前进。

任务信息示例：

{
  "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 通信的几个关键方面。

• 信息结构包括元数据，如唯一的信息标识符、发送的信息类型、发送方和接收方标识，以及用于跟踪和调试的时间戳。

• 有效载荷包含实际的任务信息，指明远程代理正在调用的功能，并提供执行该功能所需的参数。

• 上下文部分提供了更多信息，帮助接收代理了解更广泛的工作流程，包括截止日期和优先级，告知代理应如何分配资源和安排工作。

4.合作

客户端和代理必须支持动态但有条理的交互，使代理能够要求客户端、其他代理或用户提供说明、信息或子操作。这就创造了一个协作环境，代理可以在初始指令不明确时提出后续问题，要求提供更多的背景信息以做出更好的决策，将子任务委托给其他具有更合适专业知识的代理，并在继续执行完整任务之前提供中间结果以获得反馈。这种多向沟通可确保代理商不是孤立地工作，而是参与到持续的对话中，从而取得更好的成果。

分布式点对点通信

A2A 实现了分布式通信，其中代理可能由不同的组织托管，一些代理由内部维护，另一些则由第三方服务提供。这些代理可以在不同的基础设施上运行，可能跨越多个云提供商或内部数据中心。它们可能使用不同的底层 LLM，一些代理采用 GPT 模型，另一些采用 Claude 模型，还有一些采用开源替代模型。代理甚至可以跨越不同的地理区域运行，以符合数据主权要求或减少延迟。尽管存在这种多样性，但所有代理都同意使用共同的通信协议来交换信息，从而确保了互操作性，而不管实施细节如何。这种分布式架构为系统的构建和部署提供了灵活性，使企业能够根据自身的具体需求，混合和匹配最佳的代理和基础设施。

这就是新闻编辑室应用程序的最终架构：

第 3 节：模型上下文协议（MCP）

定义和目的

模型上下文协议（MCP）是 Anthropic 开发的一种标准化协议，旨在通过用户定义的工具、资源和提示，以及其他补充代码库增添的内容，来增强单个 LLM 的功能和能力。MCP 在语言模型和它们有效完成任务所需的外部资源之间提供了一个通用接口。本文通过用例、新兴趋势和 Elastic 自身的实施，概述了 MCP 的现状。

MCP 核心概念

MCP 采用客户服务器架构，由三个主要部分组成：

• 客户端：连接到 MCP 服务器以访问其功能的应用程序（如 Claude Desktop 或自定义 AI 应用程序）。

• 服务器：向语言模型提供资源、工具和提示的应用程序。每个服务器都专门提供对特定功能或数据源的访问。

  • 工具：用户定义的函数，模型可调用这些函数进行操作，如搜索数据库、调用外部应用程序接口或对数据执行转换等。

  • 资源：模型可以读取的数据源，提供动态或静态数据，并通过 URI 模式访问（类似于 REST 路由）。

  • 提示： 可重复使用的提示模板，带有变量，可指导模型完成特定任务。

请求-响应模式

MCP 采用熟悉的请求-响应交互模式，类似于 REST API。客户端（LLM）请求资源或调用工具，然后 MCP 服务器处理请求并返回结果，LLM 利用该结果继续执行任务。与点对点代理通信相比，这种带有外围服务器的集中模式提供了一种更简单的集成模式。

新闻编辑室中的 MCP

在我们的新闻编辑室示例中，各个代理使用 MCP 服务器访问他们需要的工具和数据：

• 研究员代理使用：

  • 新闻 API MCP 服务器（访问新闻数据库）

  • 事实核查 MCP 服务器（根据可信来源核查声明）

  • 学术数据库 MCP 服务器（学术文章和研究）

• 记者代理用途：

  • 风格指南 MCP 服务器（新闻编辑室写作标准）

  • 模板 MCP 服务器（文章模板和格式）

  • 图片库 MCP 服务器（图片库照片和图形）

• 编辑器代理使用：

  • 语法检查程序 MCP 服务器（语言质量工具）

  • 剽窃检测 MCP 服务器（原创性验证）

  • 搜索引擎优化分析 MCP 服务器（标题和关键词优化）

• 出版商代理使用：

  • 内容管理系统 MCP 服务器（内容管理系统 API）

  • CI/CD MCP 服务器（部署管道）

  • 分析 MCP 服务器（跟踪和监控）

第 4 部分：架构比较

何时使用 A2A

A2A 架构在需要真正多代理协作的场景中表现出色。需要协调的多步骤工作流从 A2A 中受益匪浅，尤其是当任务涉及多个连续或并行步骤、需要迭代和改进的工作流以及需要检查点和验证的流程时。在我们的新闻编辑室示例中，报道工作流程要求记者撰写，但如果对某些事实的信心不足，可能需要返回研究员，然后再返回编辑，最后返回出版商。

跨越多个领域的特定领域专业化是 A2A 的另一个强大用例。当需要不同领域的多位专家来完成一项更大的任务时，每个代理都会带来深厚的领域知识和针对不同方面的专门推理能力，A2A 提供了建立这些联系所需的协调框架。新闻编辑室完美地体现了这一点：研究员擅长信息收集，记者擅长写作，编辑擅长质量控制--每个人都有自己独特的专长。

对自主代理行为的需求使得 A2A 尤其有价值。在 A2A 架构中，能够 根据不断变化的条件做出独立决策、表现出积极主动行为并能动态适应工作流程要求的代理可茁壮成长。专业化功能的横向扩展是另一个关键优势--多个专业化代理协同工作，而不是只有一个万能代理，同一代理的多个实例可以异步处理子任务。例如，在我们的新闻编辑室报道突发新闻时，多名记者代理可能会同时从不同角度报道同一新闻。

最后，需要真正多代理协作的任务是 A2A 的理想选择。这包括法律硕士即评审团的评估机制、建立共识和投票系统，以及需要多角度达成最佳结果的协作式问题解决方法。

何时使用 MCP

模型上下文协议是扩展单一人工智能模型功能的理想选择。当单个人工智能模型需要访问多个工具和数据源时，MCP 提供了完美的解决方案，集中式推理与分布式工具和直接的工具集成相结合。在我们的新闻编辑室示例中，研究员代理（一种模式）需要访问多个数据源，包括新闻 API、事实核查服务和学术数据库--所有这些都通过标准化的 MCP 服务器访问。

当工具集成的广泛共享和可重用性变得非常重要时，标准化工具集成就成了优先事项。MCP 凭借其预构建的 MCP 服务器生态系统大放异彩，大大缩短了常见集成的开发时间。当需要简单性和可维护性时，MCP 的请求-响应模式是开发人员所熟悉的，比分布式系统更容易理解和调试，操作复杂性也更低。

最后，软件供应商通常会提供 MCP，以方便与其系统进行远程通信。这些由供应商提供的 MCP 服务器大大缩短了入网和开发时间，同时为专有系统提供了标准化接口，使集成比定制 API 开发更加简单。

何时同时使用两种方法（A2A ❤️ 的 MCP）

正如 A2A 有关 MCP 集成的文档 所指出的，许多复杂的系统都能从 A2A 和 MCP 的 结合中受益。既需要协调又需要标准化的系统是混合方法的理想选择。A2A 处理代理协调和工作流程协调，而 MCP 则为单个代理提供工具访问。在我们的新闻编辑室示例中，代理通过 A2A 进行协调；工作流程从记者到研究员，再到编辑，最后到出版商。不过，每个代理都使用 MCP 服务器来管理其专用工具，从而实现了干净利落的架构分离。

多个专门的代理，每个都使用 MCP 进行工具访问，这代表了一种常见的模式，即代理协调层由 A2A 处理，工具访问层由 MCP 管理。这种明确的分工使系统更容易理解和维护。

将这两种方法结合起来的好处是巨大的。您可以获得多代理系统的组织优势，包括专业化、自主性和并行处理，同时还可以享受 MCP 的标准化和生态系统优势，如工具集成和资源访问。代理协调（A2A）和资源访问（MCP）之间有明确的分离，而且重要的是，A2A 不需要单独用于 API 访问等较小的任务，MCP 可以高效地处理这些任务，而不需要多代理协调的开销。

常见问题：A2A 与 MCP--使用案例

结论

这是两篇文章的第一部分，内容涉及基于 A2A 的代理的实施，并通过 MCP 服务器提供支持和外部数据及工具访问。下一篇文章将探讨实际代码，以演示它们如何共同模拟在线新闻编辑室的活动。虽然这两种框架本身都具有极强的能力和灵活性，但当它们协同工作时，你就会发现它们之间的互补性有多大。