Elasticsearch：使用 Agent Builder 的 A2A 实现 - 开发者的圣诞颂歌

原创于 2025-12-29 07:04:48 发布 · 940 阅读

15 ·

CC 4.0 BY-SA版权

本文为博主原创文章，未经博主允许不得转载。

文章标签：

#elasticsearch #大数据 #搜索引擎 #全文检索 #人工智能 #ai #数据库

Elastic 同时被 3 个专栏收录

2217 篇文章

订阅专栏

Elasticsearch

1482 篇文章

订阅专栏

684 篇文章

订阅专栏

作者：来自 Elastic Justin_Castilla

部署前夜……

想象一下，朋友们：你坐在壁炉旁，手里拿着热可可，正想着该如何向你的团队解释 agent-to-agent（ A2A ）协议。你的开发者懂 MCP servers，也尝试过 agentic AI，但 A2A？它仍然像圣诞树下一个神秘的礼物，被层层包裹着。

如果我告诉你，答案其实就藏在眼前，就在我们从小唱到大的那首歌里呢？

欢迎来到《 A2A 的十二天》，在这里，我们用大家最熟悉、不断重复的圣诞颂歌，来拆解 agent 编排。因为没有什么比鹧鸪、斑鸠，和 Elasticsearch 更能代表“现代分布式系统”了。

盒子里有什么？

12-days-of-a2a 项目是一个非常简单但很有力量的演示，用来展示 Google 的 Agent-to-Agent（ A2A ）协议，并使用《 Twelve Days of Christmas 》作为数据集。圣诞节的每一天都有一个专门的 agent，全部由一个主 orchestrator agent 进行协调。我们还集成了 Elastic 全新的 Agent Builder 服务，用来展示远程 agent 如何加入这场节日派对。

你可以把它看作是一个用彩带和节日气氛包裹起来的概念验证。

角色阵容

12 个 Gift Agent：每一天的礼物各一个（鹧鸪、斑鸠、金戒指等）
1 个 Orchestrator Agent：节日 agent 交响乐的指挥
1 个 Elastic Agent：运行在 Elastic Serverless 云中的远程 agent，负责搜索礼物信息

这里真正有趣的地方在于观察这些 agent 如何通过标准化协议进行通信。它们在圣诞晚餐桌上都说同一种语言——没有尴尬的冷场，没有一头雾水的叔叔，只有顺畅的 agent 间协作。

为什么你应该关心？（除了节日气氛之外）

如果你已经熟悉 MCP（ Model Context Protocol ）servers，并且一直在探索 agentic AI，那么 A2A 就是顺理成章的下一步。首先，它天然符合 “关注点分离” 的理念。每个 agent 只负责一件事，并把它做好。以《圣诞十二天》为例，第 5 天的 agent 只懂金戒指，对敲鼓的人一无所知。这就是穿上圣诞老人外衣的 UNIX 哲学。

另外还有一个会不断送礼的好处：可扩展性。想加第十三天吗？（“十三个思考的线程？”）只需要再启动一个 agent。Orchestrator 不需要关心实现细节。说到不想关心细节，Elastic agent 也不运行在你的机器上，它托管在 Elastic Cloud 上，作为一个远程服务，展示了 A2A 如何实现真正分布式的 agent 系统。只要大家都说 A2A 这门 “语言”，你的 agent 就可以和任何人的 agent 对话。这能减轻你本地机器的压力，把负担交给别人来处理。

最后是 Agent Cards（我们后面会讲）。它们就像 AI agent 的名片，用机器可读的格式描述能力，让发现和集成变成自动化。这在所有使用 A2A 的 agent 之间强制实现了标准化。

架构：一棵由 agent 组成的圣诞树

让我们来可视化一下它是如何工作的：

当你请求关于第 5 天金戒指的信息时，orchestrator 会：

找出应该询问哪个 gift agent
调用该 agent 来获取基础信息
可选地联系 Elastic agent 来获取增强数据
将所有内容组合成一个有节日气氛的响应

所有这些都是通过标准化的 A2A 消息完成的。就像在课堂上传纸条一样，只不过纸条是 JSON，而且没有人会被留校察看。

Agent Cards：A2A 世界里的礼物标签

A2A 协议中的每个 agent 都会暴露一个 “Agent Card”：一个 JSON 文档，用来描述该 agent 能做什么。你可以把它想象成餐厅里的菜单，或者一页介绍能力的简介页面，只不过这是给 AI 能力用的。

下面是第 5 天 agent 的 card 看起来的样子：

{
  "name": "Day 5 Gift Agent",
  "description": "Provides the gift for day 5 of Christmas: 5 Golden Rings",
  "url": "http://localhost:5005",
  "version": "1.0.0",
  "protocolVersion": "0.3.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false,
    "stateTransitionHistory": false
  },
  "skills": [
    {
      "id": "get_gift",
      "name": "Get Gift",
      "description": "Get the gift for day 5 of Christmas",
      "tags": ["christmas", "gift", "day5"],
      "inputModes": ["text/plain"],
      "outputModes": ["text/plain"]
    },
    {
      "id": "get_gift_with_elastic",
      "name": "Get Gift with Elastic",
      "description": "Get the gift for day 5 with information from Elastic search",
      "tags": ["christmas", "gift", "elastic", "day5"],
      "inputModes": ["text/plain"],
      "outputModes": ["text/plain"]
    }
  ]
}

这张卡片会告诉其他 agent（以及人类）他们需要知道的一切：

它做什么：处理 Day 5 的礼物
如何访问： http://localhost:5005
它有哪些技能：两个技能，一个基础技能，一个与 Elastic 集成的技能
协议版本：让 agent 知道它们说的是同一种“方言”

当 orchestrator 想和 Day 5 的 agent 对话时，它会先获取这张卡片。这就像在开会前查看某人的 LinkedIn 资料一样 —— 你需要先知道对方能做什么，再请他们去做事。

Elastic 连接：本地遇上云

有趣的地方来了。大多数礼物 agent 都是本地的 —— 它们运行在你的机器上。但 Elastic agent？它运行在 Elastic Serverless Cloud 实例上。尽管如此，它们都说同一种语言。这要归功于大家一致采用的 A2A 标准化。

Elastic Agent Builder 提供了一个托管的 AI agent，可以搜索你的 Elasticsearch 数据。设置步骤包括：

创建一个包含圣诞礼物数据的 Elasticsearch index（78 个文档，每个礼物出现一次）
配置一个 Agent Builder agent，使其能搜索该 index
为该 agent 选择工具，Elastic 提供了几种，也可以自定义
获取 A2A endpoint URL（类似 https://your-project.kb.region.elastic.cloud/api/agent_builder/a2a ）

配置完成后，本地 orchestrator 可以像与本地 agent 通信一样轻松地向远程 Elastic agent 发送 A2A 请求。协议不关心 agent 位于何处。

真实请求流程

让我们跟踪运行时会发生什么：

$ python main.py --elastic --day 5

步骤 1：Orchestrator 接收到你的请求

def search_gift_info(self, day: int) -> str:

    gift_info = GIFTS[5]  # {"gift": "Golden Rings", "quantity": 5}

    gift_name = gift_info['gift']

    # Time to call Elastic!

    elastic_info = search_gift(gift_name, day)

步骤 2：获取 Elastic agent 的 card

本地 wrapper 发起 HTTP GET 请求，以了解远程 agent 能做什么：

GET https://your-project.kb.region.elastic.cloud/api/agent_builder/a2a/12_days_agent.json

Authorization: ApiKey <your-es-api-key>

Elastic agent 回复它的 Agent Card，显示技能包括：

platform.core.search - 搜索 Elasticsearch
platform.core.get_document_by_id - 获取特定文档
platform.core.list_indices - 列出可用的索引
platform.core.execute_esql - 执行 ES|QL 查询并返回结果

步骤 3：发送 A2A 请求

POST https://your-project.kb.region.elastic.cloud/api/agent_builder/a2a/12_days_agent

Content-Type: application/json

Authorization: ApiKey your-es-api-key

以及 A2A payload：

{
  "message": {
    "role": "user",
    "content": {
      "type": "text",
      "text": "Find information about Golden Rings from the 12 Days of Christmas, day 5"
    }
  }
}

步骤 4：Elastic agent 发挥它的魔力

在 Elastic Cloud 内部：

解析查询："Golden Rings" + "day 5"
搜索 christmas-gifts index
找到 5 个符合条件的文档
使用 AI 从文档内容生成丰富的响应
将结果打包为 A2A 响应

步骤 5：响应返回

{
  "taskId": "elastic_task_67890",
  "status": {
    "state": "COMPLETED"
  },
  "artifacts": [
    {
      "parts": [
        {
          "type": "text",
          "text": "On the fifth day of Christmas, the gift is five golden rings. These rings are perfect circles that symbolize completeness and perfection. The golden material they're made from brings warmth and light during the cold winter season, making them both symbolically and visually significant in the Christmas tradition.\n\nThe five golden rings represent the first five books of the Old Testament: Genesis, Exodus, Leviticus, Numbers, and Deuteronomy, known as the Pentateuch or Torah.\n\nGold rings were among the most valuable gifts one could give, representing wealth, status, and deep affection. Their brilliance and durability made them perfect symbols of lasting love."
        }
      ]
    }
  ]
}

步骤 6：Orchestrator 合并并展示

Day 5：5 个金戒指

来自 Elastic 的信息：

On the fifth day of Christmas, the gift is five golden rings. These rings

are perfect circles that symbolize completeness and perfection...

整个往返过程 —— 从你的命令行到云端再返回 —— 都通过标准化的 A2A 消息完成。无需自定义 API，也无需一次性集成代码。只是 agent 与 agent 的对话。

三种消息类型：A2A 的经典之作

在本演示中，A2A 通信归结为三种核心模式：

1）User 到 Orchestrator

当你运行命令时，你发送的是一个简单请求：

{
  "message": {
    "role": "user",
    "content": {
      "type": "text",
      "text": "Search for information about day 5 gift with elastic"
    }
  }
}

2）Orchestrator 到 Gift Agent

Orchestrator 向专门的 agent 请求帮助：

{
  "message": {
    "role": "user",
    "content": {
      "type": "text",
      "text": "Get the gift for day 5"
    }
  }
}

Gift agent 回复：

{
  "taskId": "task_12345",
  "status": {
    "state": "COMPLETED",
    "message": "Task completed successfully"
  },
  "artifacts": [
    {
      "index": 0,
      "parts": [
        {
          "type": "text",
          "text": "5 Golden Rings"
        }
      ]
    }
  ]
}

3）Orchestrator 到远程 Elastic Agent

结构相同，目的地不同：

{
  "message": {
    "role": "user",
    "content": {
      "type": "text",
      "text": "Find information about Golden Rings from the 12 Days of Christmas, day 5"
    }
  }
}

注意，无论你是在和本地 agent 还是远程 agent 通信，消息结构都是相同的？这就是标准化的力量。Orchestrator 不需要知道 agent 位于哪里，只需要知道它能做什么。

这有什么特别之处？

是的，数据集节日气氛浓厚又有趣，但这些模式适用于任何多 agent 系统：

AI 微服务：每个礼物 agent 就像一个微服务 —— 小而专注，可独立部署。Orchestrator 就是你的 API 网关。
混合云架构：将本地 agent（快速、私有）与远程 agent（强大、可扩展）混合使用。A2A 协议让这一切无缝衔接。
可发现的 API：Agent Cards 意味着你不需要手写文档，agent 可以自我描述。
语言无关：这个项目用 Python，但 A2A 基于 HTTP。你的礼物 agent 可以用 Python，Orchestrator 用 Go，Elastic agent 用 Elastic 的语言（提示：可能是 Java）。它们不关心。

完成这个项目后，你会有几个体会：

“等等，就只是 HTTP？” —— 是的！A2A 建立在简单可靠的网络标准之上。没有奇怪的协议，也没有专有传输。
“agent 之间不互相知道？” —— 没错！Orchestrator 处理路由。礼物 agent 不知道 Elastic 的存在，Elastic 也不认识礼物 agent。松耦合获胜。
“我可以替换任意一个 agent…” —— 完全可以！不喜欢第 5 天的 agent？换掉它。只要新 agent 说 A2A 并暴露正确的技能，Orchestrator 都不会察觉。
“水平扩展可以吗？” —— 当然。让每个礼物 agent 在自己的容器中运行。扩展热门 agent（每个人都想要金戒指）。添加负载均衡器。这就是完整的 Web 架构。

我们正在进入一个 AI agent 将像 Web API 一样普及的时代。就像今天每家公司都公开 REST API，明天它们也会公开 AI agent。A2A 提供了标准化层，让这一切成为可能。

想象一下，你的 CRM agent 与客户的采购 agent 商讨合同条款。你的监控 agent 可以在出现问题时调用云服务商的事件响应 agent。你的个人助理 agent 可以通过剧院的预订 agent 预订票。