A2A协议

原创已于 2026-07-18 13:30:01 修改 · 207 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

interview

大模型开发

于 2026-07-15 22:57:49 首次发布

1. A2A 协议是什么？

A2A 全称是 Agent2Agent Protocol，是一套面向 AI Agent 与 Agent 之间互通协作 的开放协议，最早由 Google 在 2025 年4月提出。
（四个词表述：角色 → Task → Agent Card → 传输与安全）
（① 角色）通过 Client Agent 与 Remote Agent 进行交互： Client Agent负责任务编排和发起、Remote Agent负责真正执行；（② Task）两边协作的基本单元是 Task，它有完整生命周期：创建、执行、状态更新，再到完成或失败。所以它不只适合一问一答，也支持长任务、流式进度，以及人机协同时的暂停等待。（③ Agent Card）Client通过Remote 的Agent Card 了解对方能力（通过Agent Card去发现、调用谁；如果角色对调，那谁当 Remote，谁就暴露自己的 Agent Card），它通常是一份 JSON，描述技能、端点、鉴权方式等。但 Remote 不用暴露内部记忆、提示词或私有工具，也能按约定协作；（④ 传输与安全）传输层常见是 HTTP/HTTPS，接口多用 JSON-RPC（也有 REST、gRPC）；HTTP 下的流式进度一般用 SSE；安全上通过 Agent Card 声明企业常见鉴权方式。

2. AgentCard 的作用是什么,？包含哪些信息？

2.1 是什么

AgentCard 可以理解成 A2A 里的「Agent 名片」。它的作用是让其他 Agent，尤其是 Client，在不了解对方内部实现的情况下，先知道这个 Remote Agent 是谁、会什么、怎么连、怎么鉴权；

2.2 包含信息

包含名称和描述name description、地址和版本url version、技能skills、鉴权要求authentication、以及能力capabilities是否支持流式等；形式一般是一份 JSON，通过约定地址发现，比如/.well-known/agent-card.json（如 Remote Agent 跑在http://127.0.0.1:5008，Client 就可以访问http://127.0.0.1:5008/.well-known/agent-card.json，拿到 JSON，就知道它叫什么、会什么、怎么调、要不要鉴权。/.well-known/ 是业界常见约定目录（类似网站放统一发现入口），A2A 用它放 Agent Card，所以大家约定“到这个路径找名片”，互操作性更好）；

2.3 解决什么问题

它解决的核心问题是能力发现与互操作：Client 先读 AgentCard，知道对方是谁、会什么、怎么连(端点是哪个，即Client 该往哪个地址发请求；端点：通常指完整的访问地址，一般是 URL，如：http://127.0.0.1:5008/tasks/send)、怎么鉴权（能力发现），再按同一协议委派 Task；双方不用共享记忆、提示词或私有工具，也能协作（互操作）；

3. Agent 之间是如何进行通信的？

整体就是：Card 声明能力 → Task 封装请求 → Client/Server 按 A2A 传输 → Network/Router/Orchestrator 做发现、路由与编排（路由是「这句话给谁」；编排是「多个任务串还是并」）；
项目中Agent 之间的通信统一走 A2A 标准化协议来实现跨服务协作；每个 Agent 以 A2AServer 对外提供服务：用 AgentCard、Skill 声明名称、地址和能力；调用方通过 A2AClient，将用户意图封装成 Message，再组装成带ID与状态的 Task 发给A2AServer，Server处理完后回写结果与状态（Server：（被调用方-提供服务）：Agent 自己（如天气、订票进程），监听端口、收Task、执行、回结果；Client：（调用方-发起调用）：主控 / 编排方，主动发请求、等响应）；

（需要智能选型时）多个Agent可注册进AgentNetwork：通过network.add(name, url)将AgentServer登记进AgentNetwork；Network再按url地址发现各端的AgentCard/Skill交给AIAgentRouter(名称、描述、示例问法等能力声明)；Router基于用户查询，对照network中各Agent的Card/Skill能力描述使用LLM做意图匹配，返回目标agent名称及置信度confidence；拿到名字后再get_agent(name) 取Client发Task（在Network 里按照name登记Agent，之后再用同一个名字把对应的调用入口（Client）取出来：get_agent(name) 取用时返回的不是Server本身，而是一个已经指向 http://127.0.0.1:5008 的 A2AClient；之后发Task，实际就会打到此ur地址上的AgentServer）（Router 只负责选型，不负责干活）；

有依赖的链路可以用串行编排，无依赖的可用并行编排；
工具调用仍用 MCP，A2A 只负责 Agent 与 Agent 之间的协作，MCP 负责 Agent 调工具。

编排：有依赖的链路可以用串行编排，无依赖的可用并行编排；编排者可以是 Orchestrator，也可以是某个 Agent：
1）Orchestrator 编排：本项目这种，主控（即Orchestrator）决定先天气再订票；或并行打两个 Agent：
2）Agent 编排：某个专家自己串行调下一个；或自己 gather 并行调多个下游 Agent；

    场景	            编排方式	        典型写法
B依赖A的结果(先awitA)    串行          r1 = await A(...); r2 = await B(...用 r1...)
A、B 互不影响            并行          await asyncio.gather(A(...), B(...))
（如「查天气 + 订票」彼此独立）

串行：await 天气任务结束 —> 从 artifacts 抽出结果 —> 拼进订票请求 —> 再 await 订票任务
两段先后执行的 send_task_async：

message = Message(content=TextContent(text=weather_query), role=MessageRole.USER)
weather_task = Task(message=message.to_dict(), id="task-" + str(uuid.uuid4()))
weather_result =  await weather_client.send_task_async(weather_task)
# ... 解析 weather_info ...：weather_result.artifacts[0]["parts"][0]["text"] 取出文本，

ticket_query = f"预订一张从北京到上海的火车票，当前天气是：{weather_info}"
ticket_message = Message(content=TextContent(text=ticket_query), role=MessageRole.USER)
ticket_task = Task(message=ticket_message.to_dict(), id="task-" + str(uuid.uuid4()))
ticket_result =  await ticket_client.send_task_async(ticket_task)

改为并行：

weather_coro = weather_client.send_task_async(weather_task)
ticket_coro = ticket_client.send_task_async(ticket_task)
weather_result, ticket_result = await asyncio.gather(weather_coro, ticket_coro)

专家侧统一契约：收 Task，写 artifacts，标 COMPLETED。例如天气 Agent：

def handle_task(self, task):
    query = (task.message or {}).get("content", {}).get("text", "")
    if "天气" in query:
        weather_result = {"温度": 30, "天气": "晴天"}
        task.artifacts = [{"parts": [{"type": "text", "text": weather_result}]}]
    ...
    task.status = TaskStatus(state=TaskState.COMPLETED)
    return task

数据流转：

用户意图（隐含在 Orchestrator 写死的流程里）
        │
        ▼
┌───────────────────┐
│  TravelOrchestrator│
└─────────┬─────────┘
          │ ① Task: "北京的天气怎么样"
          ▼
    WeatherAgent ──► artifacts: {温度:30, 天气:晴天}
          │
          │ ② Orchestrator 解析后拼新 query
          ▼
    TicketAgent ──► artifacts: 订票结果

4. A2A 和 MCP 的区别？

A2A 和 MCP 是能力互补的协议，不是二选一：MCP 解决的是 Agent 怎么连接工具和数据，扩展的是单个 Agent 能做什么，偏垂直集成；A2A 解决的是 Agent 之间怎么协作，扩展的是多个 Agent 如何一起做事，偏水平协作。
生产里两者经常叠加使用：Agent A 通过 A2A 把子任务派给 Agent B，Agent B 内部再用 MCP 去查 CRM、读知识库、调内部 API，最后把结果通过 A2A 回传给 Agent A。所以真正要判断的不是选 MCP 还是 A2A，而是这一层到底是工具集成，还是 Agent 协作。
选型上：单 Agent 或应用要稳定接入工具和数据时优先 MCP，生态也更成熟；已经有多个独立 Agent，需要跨框架、跨组织发现能力、委派任务、做异步长任务时再引入 A2A；复杂多智能体系统则两者一起用——对外用 A2A 协作，对内用 MCP 落地执行。

标签

#linux