<p>作者：来自Elastic<span>Justin Castilla</span></p> 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 模板，引导模型完成特定任务
