当 WorkBuddy 接上 Elastic：用 A2A 把一群各管一摊的 Agent 拧成一支团队

凌晨两点，Checkout 服务的延迟告警又响了。你揉着眼打开 Kibana，发现要排这个障，得同时看指标、看日志、看依赖拓扑，而这些东西分散在好几个系统里，归不同的团队管。更烦的是，你手头还有别的活，上午安全团队让你核一下上季度的云操作审计，下午文档同事又丢来一堆技术博客要你归类。三件事，三个入口，三种说话方式。

这不是个别现象。大多数公司现在的智能体不是太少，而是太多太散。运维有一个盯告警的，安全有一个翻审计日志的，文档有一个整理博客的。它们都能干活，但彼此不通气，对你来说每用一个就得换一次语境。这种切换的隐性成本很高：你得记住每个系统怎么登录、问题该怎么问、结果该去哪找，脑子里的上下文每切一次就碎一点。我见过最典型的例子，是一个人排障排到一半，为了核对是不是人为操作导致的，又得切去安全平台查审计，查完回来发现刚才那边的查询条件已经忘了，只能重来。一天里这种来回切上五六次，真正花在思考上的时间没多少，全耗在搬运上下文上了。

我们最近在 WorkBuddy 里接上了 Elastic 的 Agent Builder，靠 A2A 协议把这一摊子事理顺了。跑下来之后，体感完全变了：你只在一个界面里说话，背后一群专职的 Agent 各忙各的，结果全回到你同一条对话里。

我们到底在解决什么问题

很多团队以为上智能体的瓶颈是模型不够聪明，或者单个 Agent 装不下足够多的技能。实际用下来发现都不是。现在的 Agent 早就能通过渐进式披露，按需加载各种 skill 来解决问题，技能广度本身不是瓶颈。

真正的麻烦在上下文。一个 session 里干活，每接一个场景就要加载对应的 MCP，会话被大量填充；每调一次 skill，过程和结果又写回上下文。任务一多，session 越撑越长，而且这些任务往往互相阻塞、还要跨任务协同交互。上下文一旦乱成一锅，Agent 的实际能力会明显往下掉，不是它不会，是它看不清了。

所以问题从来不是能不能做一个全能 Agent，而是怎么让多个 Agent 各自守住一块干净的上下文，协同起来还不用把什么都塞进同一个脑子。这正是 A2A 要解决的。

A2A 到底是什么

A2A 全称 Agent-to-Agent，是一套开放协议。它和另一个你可能听过的 MCP 是一对互补的关系：MCP 管的是 Agent 怎么连工具和外部资源，比如连一个数据库、调一个 API；A2A 管的是 Agent 之间怎么对话、怎么交接任务。一个对物，一个对人，分工很清楚。你可以这么记：MCP 让 Agent 长出手脚去够外面的东西，A2A 让 Agent 之间能互相打电话。

落到工程细节上，A2A 比想象中轻。每个 Agent 对外暴露一张 Agent Card，相当于它的简历，写清楚自己叫什么、能干什么、有哪些技能、走哪个地址。调用方想用，就通过 JSON-RPC 发一条消息过去，交一个任务。任务有唯一 ID，执行过程可追踪，做完结果能凭 ID 取回。整套通信就是 HTTP 上的标准请求，不挑语言、不挑平台，谁都能实现。

为什么是协议，不是又一个接口

有人会问，这不就是调个 API 吗，为什么非得整个协议出来？区别在于规模。如果只有两个 Agent，直接写段调用代码确实更快。但当你有七个、二十个 Agent，而且它们还不断变化的时候，每接一个就写一套适配、记一套 quirks、处理一套报错，这个成本会指数级涨。

协议的价值是把第 N 次集成的成本压到第 1 次那么低。只要大家都说 A2A 这门语言，新来的 Agent 发一张 Agent Card 就能被调度层发现、被调用，不需要为它单独写胶水代码。调度层也不需要因为某个 Worker 升级了就跟着改。这跟当年 RESTful API 取代一堆私有接口是一个道理：不是某个调用变简单了，而是"再加一个"这件事变便宜了。

反过来看没有协议的日子。假设你要打通三个 Agent，就得写三套适配：第一个返回 JSON，你得解析；第二个返回纯文本，你得猜哪句是结论；第三个干脆自己定义了套字段名，文档还不全。等第四个来了，你发现之前的封装方式套不上去，又得返工。Agent 越多，这套手搓胶水越脆，任何一端动一下，调用方就可能崩。A2A 把这些不确定性收进协议里，调用方和提供方各自守约，系统才能长大。

两层架构：谁在上，谁在下

我们的架构分两层，边界很清楚。

上层是 WorkBuddy。它扮演的是协调者，也就是 Supervisor。你在 WorkBuddy 里说话，是跟一个总的助手在聊。这个助手干四件事：听懂你要什么、判断该找哪个 Agent、把任务通过 A2A 发出去、把远端回来的结果翻成人话再递给你。注意，WorkBuddy 本身不持有那些排障技能，也不直连你的 ES 集群，更不翻你的云审计日志。它只做调度和翻译，像个项目经理，手里攥着用户的意图和对话的来龙去脉，却不碰任何一块具体的业务数据。

这层为什么重要？因为用户的上下文只能待在一个地方。如果每次换 Agent 都要把背景重新讲一遍，协同就无从谈起。Supervisor 层把用户的真实诉求、前面的对话、已经拿到的结论都攒在自己这儿，往下派活时只给 Worker 当下任务需要的最小信息。用户感受到的，始终是一段连续的对话，而不是一次次重新开始。

说得更具体点，你说的帮我看看现在什么告警没消，到了 Supervisor 这里会被翻译成一次结构化的 A2A 调用：选哪个 Agent、问什么、等多久、超时怎么办，都是它替你拿主意。你不用关心 SRE 助手期望的字段叫 alert_state 还是 status，也不用管它返回的是数组还是对象。翻译这层活不算酷，但它是普通人和一堆专业系统之间最缺的那块拼图。少了它，每个用户都得变成半个集成工程师。

下层是 Elastic Agent Builder。它托管着一群专职的 Worker Agent。我们这次环境里就有七个：SRE 助手连着可观测性数据，审计助手连着腾讯云的操作审计日志，博客助手连着 Search Labs 的内容库，还有通用助手、解决方案架构师助手等等。每个 Worker 都很专，清楚自己的工具、自己的数据边界、自己的分析方法。它们不关心你是谁、你上一句在聊什么，只管接活、出结果。它们也不需要知道还有哪些别的 Agent 存在，各扫门前雪就行。

A2A 协议就横在两层之间，是唯一的通信面。WorkBuddy 不需要知道 SRE 助手内部怎么查 ES、怎么算延迟分位值，它只要发一句当前有哪些 open 的告警，等对端把结构化结论送回来。反过来，Elastic 那边的 Agent 也不需要理解 WorkBuddy 这边的对话上下文，它只处理收到的那条指令。两边都只看见协议定义的接口，看不见对方的内脏。这张 Agent Card 就是它们之间的合同，也是组合可能性的来源。

实际跑起来是什么样

光说架构有点虚，讲讲我们实际跑的流程，这趟里三种不同性格的 Worker 都见到了。

第一步是发现。WorkBuddy 发一个 discover，Elastic 那端把七张 Agent Card 列回来。你一眼就能看到有哪些同事可用，各自擅长什么。这比口头约定靠谱，因为能力是机器可读的，随时和真实状态同步。哪天某个 Agent 下线了，卡里自然就没有它。

第二步是派活和回顾。比如我们想看 SRE 助手之前都处理过什么，先走一个 history 拉清单，只回标题和时间，不把正文一股脑倒出来。挑中一条 Checkout 服务延迟分析，再走 show 凭会话 ID 把那次的最终结论取回来。这里有个细节：那个会话 ID 是上次任务就生成并存在 Elastic 那端的，跨了会话、隔了天也能凭它读回，不用重跑一遍分析。这体现的就是 Supervisor 管上下文、Worker 端的成果可持久化这个分工。

第三步是实时派活。那天我们查一条 Checkout 服务的延迟告警。WorkBuddy 的助手判断这是排障类任务，走 A2A 把问题发给 SRE 助手。SRE 助手连上可观测性数据，定位到根因是 Cart 服务连不上 Redis，导致下单交易卡了五秒，还顺手给出了下游依赖健康和处置优先级。整段过程，WorkBuddy 没碰一行 ES 查询，只做了派活和读报告。

第四步是取结果，这里有个值得说的机制。SRE 助手这类重型 Agent，每次要加载技能、查数据、多步推理，往往一两分钟才出结果。同步等的话，云端的入口代理几十秒就掐断连接了。所以我们实际跑的是异步：发出去拿个任务 ID 先返回，客户端去干别的，过一阵子凭 ID 把结果捞回来。而且即便中途网络断了，远端任务照跑不误，结果落库后随时能取。我们那次查告警，同步等了 60 秒没回、客户端断了，但过一会儿用任务 ID 去取，结论安安稳稳在那儿。这种断线不丢活的特型，对长耗时的分析任务几乎是刚需。

同样的方式，换个场景也成立。想看最近 Elastic 官方博客写了啥，叫博客助手去整理，它把十几篇文章按时间和主题分好类递回来；要核对云上操作是否合规，叫审计助手去翻日志。三种 Worker，一个分析、一个检索综述、一个审计，全在一个界面里完成，结果都回同一条对话线索。你作为用户，根本感知不到背后换了几个系统，只知道问了一句，答案就来了。这种无感，恰恰是好架构的标志。

这么做的好处，很多不在技术本身

把上面这些摊开看，Supervisor 加 Worker 这套拆法的好处是实打实的，而且不少好处是在组织层面，不是技术层面。

专业的事交给专业的人。这不是因为单个模型学不会排障或审计，而是不同领域的任务塞进同一个 session，上下文会互相污染。让每个 Worker 守着自己的一亩三分地，它的工作记忆始终聚焦在当前任务上，推理不会被八竿子打不着的上下文拖垮。能力的上限不是来自模型多大，来自上下文有多干净。

彼此解耦，各改各的。今天 SRE 助手的查询逻辑要优化，明天审计助手要加一条合规规则，变动都发生在 Elastic 端，WorkBuddy 这边一行不用动。这点在大公司尤其关键，运维、安全、文档往往是不同的组，谁也不想等谁发版。协议把边界钉死，两边就能按自己的节奏迭代，互不阻塞。

不丢上下文。每次会话都有 contextId，结果持久化在 Elastic 那端。任务跑崩了、你关电脑了、网络抖了，下次凭 ID 还能续上。这在真实工作流里比模型多聪明重要得多，因为真实任务经常跨天、跨会话，你不可能每次都从零讲起。

可审计、可追溯。每次调用都带明确的来源标识、任务 ID、执行记录。哪个客户端发的、调了哪个 Agent、问了什么、回了什么，一条线能追到底。企业环境里，这点往往是上不上这个方案的硬指标，出了事能定责，复盘有依据。

能拼装。因为大家说同一种语言，你可以把多个 Worker 串成一条流水线，而串的人不用懂每个 Worker 的内部。比如先让审计助手扫一遍异常操作，再把结论交给 SRE 助手看是不是对应的基础设施问题，全程由 Supervisor 在中间传话。这种组合能力是单体 Agent 很难便宜地获得的。

举个具体的链：某天审计助手报出一条可疑的批量删除操作，Supervisor 记下来，转头问 SRE 助手这段时间存储相关的指标有没有异常抖动。SRE 助手查出对应时段某个 Redis 节点磁盘写满，Supervisor 把这两段拼在一起，给你一句人话：这次批量删除可能是存储压力触发了连锁反应，建议先扩容再复盘权限策略。你看到的不是两份互不相干的报告，而是一条有头有尾的线索。这就是拼装的意义：价值不在单个 Agent，而在它们被串起来的那一刻。

代价也要说清楚

当然也不是没有成本。多一层协议意味着多一层延迟，简单问题也会被网络往返拖慢；Agent 之间靠文本交接，复杂任务的意图传递会有损耗，比不上把数据放在同一进程里直接算。Worker 出错时，Supervisor 未必能判断是任务本身难还是传话传歪了，排查链路变长。

所以对那种就在本地、数据不大、要求极快的场景，直接调 API 或者本地函数反而更合适。A2A 赢在跨系统、跨团队、需要专业分工的长链条任务，而不是所有场景。判断要不要上，就看你的能力是不是分散在不同系统、不同团队手里，而且还会继续长。如果是，协议化的协同早晚划算；如果不是，别为了时髦硬上。

回到那个凌晨两点

告警响了，你不用挨个系统翻。在 WorkBuddy 里说一句帮我看看现在什么告警没消，协调层去叫 SRE 助手，它查完把结论递回来。你要深挖根因，接着追问；你要对照安全策略，它再叫审计助手。你始终在同一个对话里，Agent 们在背后各忙各的。

这种配合，靠的不是某个 Agent 突然变强，而是 A2A 把找对人、问对话、拿回结果这件事标准化了。标准化之后，加一个新 Agent 就跟你招了个新同事一样，发张能力卡，就能上岗。

多 Agent 协同真正有价值的样子，大抵如此：不是一个无所不能的超级大脑，而是一支分工明确、用同一套语言沟通的团队。WorkBuddy 做那个发号施令的项目经理，Elastic 提供那一间间各有所长的工位。中间的对讲机，叫 A2A。