前言
上一篇介绍了 A2A 的基本原理。
这一篇通过一个简单旅行助手实现：
Router Agent
Weather Agent
Ticket Agent
三个 Agent 之间的协作。
最终希望实现：
用户：
帮我查询明天西安到成都的车票，
再查询一下成都天气。
系统自动完成：
识别任务
↓
查询车票
↓
查询天气
↓
汇总结果
一、项目整体架构
首先设计三个 Agent：
User
↓
Router Agent
│
┌────────┴────────┐
↓ ↓
Weather Agent Ticket Agent
↓ ↓
Weather Tool Ticket Tool
各自负责：
Router Agent
→ 判断应该调用哪个 Agent
Weather Agent
→ 处理天气相关任务
Ticket Agent
→ 处理票务相关任务
二、Weather Agent
Weather Agent 只负责：
天气相关任务
例如：
class WeatherAgent:
def get_weather(self, city: str):
"""
查询城市天气。
实际项目中可以调用真实天气 API。
"""
return {
"city": city,
"weather": "晴",
"temperature": "18℃～27℃"
}
它对外暴露的 Skill 可以描述为：
Name：
get_weather
Description：
查询指定城市天气
三、Ticket Agent
Ticket Agent 负责：
车票查询
例如：
class TicketAgent:
def search_ticket(
self,
from_city: str,
to_city: str
):
"""
查询两个城市之间的车票。
"""
return {
"from": from_city,
"to": to_city,
"train": "Gxxx",
"status": "有票"
}
Skill：
Name：
search_ticket
Description：
查询两个城市之间的车票信息
四、Router Agent
Router Agent 的作用是：
根据用户问题判断应该交给哪个 Agent。
例如：
def route(intent: str):
if intent == "weather":
return "weather_agent"
if intent == "ticket":
return "ticket_agent"
return "unknown"
实际项目中，可以让 LLM 进行意图识别。
例如：
成都天气怎么样？
↓
Weather Agent
而：
查询西安到成都的车票
↓
Ticket Agent
五、Agent 之间如何协作？
例如用户：
查询成都天气
执行：
User
↓
Router Agent
↓
识别 weather
↓
Weather Agent
↓
执行天气查询
↓
Artifact
↓
Router Agent
↓
User
如果用户：
查询西安到成都车票
则：
User
↓
Router Agent
↓
识别 ticket
↓
Ticket Agent
↓
执行票务查询
↓
Artifact
↓
User
六、Main 主流程
可以使用一个主程序组织多个 Agent：
weather_agent = WeatherAgent()
ticket_agent = TicketAgent()
def main(intent: str):
agent_name = route(intent)
if agent_name == "weather_agent":
return weather_agent.get_weather(
"成都"
)
if agent_name == "ticket_agent":
return ticket_agent.search_ticket(
"西安",
"成都"
)
return "暂时无法处理该任务"
测试：
result = main("weather")
print(result)
整个结构：
main
↓
router_agent
↓
选择 Agent
↓
执行任务
↓
返回结果
真正接入 A2A 后，Router 不需要直接调用 Python 对象，而是通过 A2A 与对应 Agent 服务通信。
七、扩展：Multi Intents
真正的用户问题通常不只有一个意图。
例如：
帮我查询明天西安到成都的车票，
再看看成都天气。
这时候可以拆成：
用户问题
↓
Intent Analysis
↓
┌──────────────┐
│ weather │
│ ticket │
└──────────────┘
↓
并行 / 顺序执行
分别交给：
Weather Agent
Ticket Agent
获得：
Weather Result
+
Ticket Result
最后由主 Agent 汇总：
Main Agent
↓
组织两个 Agent 的结果
↓
生成最终回答
整体结构：
User
↓
Main Agent
↓
Intent Router
↓
┌────────┴────────┐
↓ ↓
Weather Agent Ticket Agent
↓ ↓
Weather API Ticket API
↓ ↓
Artifact Artifact
└────────┬────────┘
↓
Main Agent
↓
Final Answer
八、为什么不直接把所有 Tool 放进一个 Agent？
当然可以。
简单项目完全可以：
一个 Agent
├── Weather Tool
├── Ticket Tool
├── Hotel Tool
└── Map Tool
没必要为了使用 A2A 强行拆 Agent。
但是当业务越来越复杂：
几十个 Tool
大量 Prompt
不同业务领域
不同模型
不同权限
不同团队维护
一个 Agent 会越来越复杂。
这时候可以拆成：
Weather Agent
Ticket Agent
Hotel Agent
Device Agent
Knowledge Agent
每个 Agent 独立负责自己的领域。
再通过 A2A 进行协作。
九、A2A + MCP
A2A 和 MCP 可以组合使用。
例如：
Main Agent
↓
A2A
↓
Weather Agent
↓
MCP
↓
Weather Server
↓
Weather API
这里：
A2A
→ Main Agent 与 Weather Agent 通信
MCP
→ Weather Agent 与天气工具通信
因此一个更加完整的 Agent 系统可能是：
User
↓
Main Agent
↓
A2A
↓
┌───────────┴───────────┐
↓ ↓
Weather Agent Ticket Agent
↓ ↓
MCP MCP
↓ ↓
Weather API Ticket Service
十、总结
本篇通过：
Router Agent
Weather Agent
Ticket Agent
展示了一个基础的多 Agent 协作结构。
核心流程：
用户任务
↓
Router
↓
任务拆分
↓
选择 Agent
↓
A2A 调用
↓
Agent 执行
↓
Artifact
↓
结果汇总
↓
最终回答
需要注意：
并不是 Agent 越多越好。
简单业务：
Agent + Tools
通常已经足够。
只有当系统存在明显的：
业务边界
专业能力边界
权限边界
独立部署需求
多个团队维护
时，再考虑拆分多个 Agent 并通过 A2A 协作。
这样才能真正发挥 Multi-Agent 和 A2A 的价值，而不是单纯增加系统复杂度。
