＜span class=“js_title_inner“＞AI那些趣事系列112：一文看懂 AI Agent 工具调用、MCP 协议与多 Agent 协同＜/span＞

AI Agent 不是 “只会聊天的机器人”，而是能帮你 “动手做事” 的数字助手 —— 比如自动订机票、规划旅行、算家庭预算，甚至协调多个工具完成复杂任务。就算出现“不小心先订了酒店”的情况（比如Agent误操作），A2A也支持“回滚指令”：主Agent通过A2A协议向住宿预订Agent发送“取消预订”请求，酒店Agent调用平台的取消API（比如携程的免费取消接口），避免用户损失——这要求专业

数据拾光者

752人浏览 · 2025-12-03 20:54:38

数据拾光者 · 2025-12-03 20:54:38 发布

导读：本文是“数据拾光者”专栏的第一百一十二篇文章，这个系列将介绍在AI领域中的一些学习和思考，以及实战中的经验教训总结。本文聚焦 AI Agent（智能体）的核心逻辑，用生活中常见的场景拆解复杂技术，让 Agent、Function Calling、MCP 协议、A2A 协同这些概念变得通俗易懂。文中会尽量用大家耳熟能详的例子讲透技术原理，同时保留开源项目与实践思路，适合想了解 AI Agent 的读者。

欢迎转载，转载请注明出处以及链接，更多关于自然语言处理、推荐系统优质内容请关注如下频道。
知乎专栏：数据拾光者
公众号：数据拾光者

AI Agent 不是 “只会聊天的机器人”，而是能帮你 “动手做事” 的数字助手 —— 比如自动订机票、规划旅行、算家庭预算，甚至协调多个工具完成复杂任务。本文先从 Agent 的定义切入，剖析LLM大模型的 4 大局限性如何催生 Agent；再通过 “上海亲子游规划” 的完整案例，拆解 Agent “感知 - 规划 - 执行 - 监控” 的工作流程；随后深入 Function Calling（函数调用）、MCP（模型上下文协议）、A2A（Agent-to-Agent 协议）三大核心技术，每个技术点都配套生活化示例与开源项目；最后结合日常场景，说明多 Agent 协同如何提升生活与工作效率。

01 什么是 AI Agent？—— 大模型的 “超级助手”

讲 Agent 之前，先思考一个问题：如果直接让大模型帮你 “规划 2025 年国庆上海 3 天亲子游，预算 5000 元，含迪士尼门票”，它能做到吗？答案是 “不能”—— 因为它不知道 2025 年迪士尼的最新门票价格（知识滞后），不会主动查高铁票余票（无法调用工具），算错预算时无法修正（缺乏逻辑校验），更记不住你上次说的 “孩子怕晒，要选阴凉景点”（无长期记忆）。Agent就是为解决这些问题而生的 “增强型 AI 系统”。

1.1 Agent 的核心定义

Agent（智能体）是以大语言模型（LLM）为 “大脑”，结合外部工具、知识库与多模态能力，能感知环境、自主决策、执行动作的实体。简单说它不是 “只会给建议的顾问”，而是 “能动手做事的帮手”—— 比如自动查高铁票、订酒店、规划行程，甚至实时调整计划（比如遇到下雨就改室内景点）等等。下面通过一个示例来说明“家庭旅行规划 Agent”：

感知需求：理解你 “国庆带孩子去上海玩 3 天，预算 5000 元，要去迪士尼，孩子怕晒”；
调用工具：查高铁票余票（调用 12306 API）、订迪士尼附近酒店（调用携程 API）、查上海天气（调用天气 API）；
自主决策：选择早出晚归的高铁、带早餐的阴凉酒店、避开正午的行程；
执行监控：实时查看高铁票状态，若遇暴雨自动调整户外行程为 “上海科技馆 + 室内乐园”等室内行程。

1.2 为什么需要 Agent？—— 大模型的 4 大 “短板”

大模型是 Agent 的核心，但单独的大模型存在明显局限，Agent 正是为弥补这些局限而生：

大模型的局限性	具体问题（生活化示例）	Agent 的解决方案
知识滞后性	GPT-4 训练截止 2021 年9月，无法获取 2025 年迪士尼最新门票价格、高铁时刻表	实时调用外部工具（如 12306 API、迪士尼官网）获取最新信息
缺乏逻辑推理	计算 “家庭月度总支出 = 房贷 + 生活费 + 交通费” 时，容易漏加房贷金额	引入 “思维链（CoT）”，分步拆解计算，同时调用计算器工具校验结果
无法执行动作	只能说 “建议订 9 点的高铁”，但不能直接帮你在 12306 上购票	集成工具链（如 12306 SDK、外卖平台 API），将决策转化为实际操作
无长期记忆	忘记你上次说的 “孩子过敏芒果”，推荐行程时包含芒果甜品店	构建长期记忆系统（如向量数据库），存储用户偏好、历史任务记录

1.3 Agent 的核心能力

一个合格的 Agent 需要具备 3 种关键能力，缺一不可：

推理规划
：将复杂任务拆分成可执行的子步骤。比如 “上海亲子游” 拆成 “查高铁→订酒店→买门票→规划每日行程→算预算”；
工具调用
：知道什么时候调用什么工具。比如需要实时数据时调用 API，需要算钱时调用计算器，需要查路线时调用地图工具；
记忆学习
：短期记住当前任务的上下文（如 “预算 5000 元”），长期积累经验（如 “孩子喜欢动物，下次优先推荐动物园”）。

02 Agent 工作流程拆解

光说理论太抽象，我们以 “帮我规划 2025 年国庆上海 3 天亲子游，预算 5000 元，含迪士尼门票，孩子怕晒” 为例，看 Agent 如何一步步完成任务。整个流程分为感知→规划→执行→监控→总结5 个阶段，形成闭环。

2.1 阶段 1：感知 —— 理解用户的 “真实需求”

Agent 首先要 “听懂” 你的需求，提取关键信息：

核心目标
：上海 3 天亲子游（国庆期间）；
约束条件
：预算 5000 元、含迪士尼门票、孩子怕晒；
缺失信息
：同行人数（默认 2 大 1 小，但需确认）、孩子年龄（影响迪士尼项目选择）、是否需要接送站。

这一步的关键是 “容错”—— 如果信息不全，Agent 会主动追问：“请问同行是 2 大 1 小吗？孩子今年几岁啦？需要帮你预约迪士尼无障碍通道吗？”，而不是直接按默认值执行（比如默认孩子 5 岁，可能导致推荐不适合的项目）。

2.2 阶段 2：规划 —— 把 “模糊目标” 拆成 “可执行步骤”

Agent 的 “指挥中心” 会将需求拆解为有序的子任务，甚至考虑优先级和备用方案。以上述需求为例，规划结果可能是：

确认基础信息（出行日期：10.1-10.3；人数：2 大 1 小；孩子年龄：6 岁）；
预订交通（北京→上海往返高铁，优先选早出晚归班次，避开高峰拥堵）；
预订住宿（迪士尼附近步行 10 分钟内的酒店，带遮阳庭院，含早餐，预算 1200 元内）；
购买迪士尼门票（2 大 1 小，提前预约 10.1 入园，申请儿童防晒通道）；
规划每日行程（Day1：迪士尼（早入园 + 避开正午户外项目）；Day2：上海科技馆（室内场馆，凉爽不晒）；Day3：外滩 + 豫园（早间出行，午后返程））；
预算分配（交通 1500 元、住宿 1200 元、门票 1000 元、餐饮 800 元、应急 500 元）。

这里有个细节：如果迪士尼门票售罄（备用场景），Agent 会自动调整行程，比如将迪士尼改到 Day3，同时联系酒店免费改期 —— 这就是 “动态规划” 能力。

2.3 阶段 3：执行 —— 调用工具完成 “动手” 环节

规划好步骤后，Agent 会调用对应的外部工具执行，而不是 “只说不做”：

调用12306 API：查询 10.1 北京→上海（G101，9:00-12:00）、10.3 上海→北京（G104，14:00-17:00）的高铁票，票价 553 元 / 人，共 1659 元（控制在预算内）；
调用携程 API：筛选迪士尼附近 “步行≤10 分钟、带庭院、评分 4.8+” 的酒店，选中 “上海迪士尼乐园酒店”，两晚 1180 元；
调用迪士尼官网 API：购买 10.1 的 2 大 1 小门票（共 999 元），同步预约儿童防晒通道和早享卡；
调用大众点评 API：筛选每日行程附近的 “儿童友好餐厅”，比如迪士尼附近的 “小南国”（有儿童餐 + 遮阳座位）。

2.4 阶段 4：监控 —— 确保每一步 “不出错”

执行过程中，Agent 会实时检查结果，处理异常：

高铁票预订后，确认订单状态（是否有票、座位是否连坐、是否靠窗）；
酒店预订后，核对 “带庭院”“免费取消” 条款（避免后续因天气变化改期收费）；
迪士尼门票预约后，发送二维码和防晒通道凭证到你的微信（确保你能直接使用）。

如果出现问题（比如高铁票售罄），Agent 会自动重试：比如改选 10:00 的 G103 班次，或推荐 “飞机 + 地铁” 的组合（补差价 200 元，并告知你预算变化，询问是否接受）。

2.5 阶段 5：总结 —— 输出 “清晰易懂” 的结果

最后，Agent 会整合所有信息，生成结构化的结果（比如表格），而不是杂乱的文本：

项目	详情	费用
交通	10.1 G101（北京→上海）、10.3 G104（上海→北京）	1659 元
住宿	上海迪士尼乐园酒店（10.1-10.3，带庭院 + 早餐）	1180 元
门票	迪士尼 2 大 1 小门票（10.2 入园，含早享卡 + 防晒通道）	999 元
每日行程	Day1：迪士尼（9:00-17:00，正午逛室内项目）；Day2：上海科技馆；Day3：外滩 + 豫园（8:00-12:00）	-
餐饮	推荐 3 家儿童友好餐厅（附地址 + 预约电话，人均 100 元）	800 元
剩余预算	362 元（可用于购买迪士尼儿童防晒帽、零食）	-

2.6 Agent 工作流程总结

整个流程可以用一句话概括：“听懂需求→拆步骤→动手做→盯进度→给结果”，形成闭环。示意图如下：

这个流程图准确的诠释了智能Agent的核心工作范式：感知-规划-执行-循环（OODA Loop）：

1.感知：补全与推断

- 作用
  ：Agent的“输入接口”。它不仅提取用户需求中的关键要素，还利用其内部知识（如育儿知识、旅游常识）对模糊、缺失的信息进行合理的推断和补全。
- 实例
  ：当用户提出“上海迪士尼家庭游”需求时，Agent会主动补全：
- - 隐含信息
    ：孩子年龄（6岁）意味着需要关注适合低龄儿童的项目、是否需要儿童票、行程节奏要舒缓。
  - 关键偏好
    ：“不晒”意味着需要优先安排室内项目（科技馆）、避开正午户外活动、选择带庭院的酒店以供休息。
  - 默认约束
    ：如果没有指定，可能会默认查询国庆假期（10.1-10.3）作为出行日期。这为后续规划提供了坚实的前提。

2.规划：战略分解与预案

- 作用
  ：Agent的“指挥中心”。将宏观任务分解为具体、有序、可执行的子任务链，并提前考虑优先级和备用方案。这正是“动态规划”能力的核心。
- 实例
  ：规划结果不仅是有序任务列表，更是一个决策树：
- - 主线任务
    ：确认信息 -> 订交通 -> 订住宿 -> 购门票 -> 排行程 -> 做预算。
  - 优先级
    ：交通和住宿是基础，因此优先级最高。
  - 备用方案
    ：“如果迪士尼10.1门票售罄”，则启动预案：将迪士尼调整至10.3 -> 联系酒店免费改期 -> 将Day3的外滩豫园调整至Day1。这种“如果-那么”的思考，体现了高级的规划能力。

3.执行：调用工具

- 作用
  ：Agent的“双手”。根据规划，调用相应的API或工具来执行具体操作。
- 实例
  ：
- - 调用“高铁票查询API”
    ，输入参数（北京-上海，10.1 早班）。
  - 调用“酒店预订API”
    ，输入参数（迪士尼附近，步行10分钟，带庭院，价格<=1200）。
  - 调用“迪士尼票务系统API”
    ，尝试购买10月1日的门票。

4.监控与循环：自我修正

- 作用
  ：这是Agent具备“韧性”和“自主性”的关键。它检查执行结果，并在遇到问题时自动回溯调整。
- 实例
  ：当执行到“购买迪士尼门票”时：
- - 监控
    ：API返回“10月1日门票已售罄”。
  - 决策
    ：结果“不正常” -> 进入“回溯调整”路径。
  - 调整
    ：Agent不是直接报错，而是返回到“规划”阶段，立即启动之前准备好的备用方案：将行程对调。并重新执行新的规划（如尝试购买10月3日的门票，并调用酒店API请求修改入住日期）。

5.总结：生成报告

- 作用
  ：Agent的“输出接口”。当所有子任务都成功执行后，它将分散的结果整合成一份用户易于理解的、结构化的最终报告。
- 实例
  ：生成一份完整的《上海迪士尼家庭游规划书》，包含交通班次、酒店详情、门票二维码、每日行程时间表、预算分配表等所有详细信息。

03 详解 Function Calling——LLM 调用工具的 “通用语言”

Agent 要调用工具，核心依赖 Function Calling（函数调用）。简单说，它是让 LLM “说机器话” 的技术—— 把自然语言需求转化为结构化的函数调用请求（比如 JSON），让外部工具能看懂并执行。

3.1 什么是 Function Calling？

Function Calling 是大模型的一项能力：当用户需求需要外部工具时，模型会自动生成符合格式的函数调用请求（包含 “调用哪个函数”“传什么参数”），而不是直接输出自然语言。举个例子：用户问 “我订的上海到北京的 G104 高铁，现在到哪了？”

没有 Function Calling 时，大模型可能胡编：“G104 现在到济南西站了，预计 16:30 到达北京”（实际可能还在上海）；
有 Function Calling 时，模型会生成：
{
"function": "get_train_status", // 要调用的函数名
"parameters": {
"train_no": "G104", // 参数1：车次
"date": "2025-10-03" // 参数2：日期（默认当天）
}
}

外部代码收到这个请求后，调用 12306 实时查询 API 获取真实位置，再返回给模型，模型最后生成自然语言回答。

3.2 为什么需要 Function Calling？

Function Calling出现之前我们可以通过 “在 System Prompt 里写工具描述” 让 LLM 模拟调用，但这种方式有两个大问题：

不稳定
：模型可能生成非结构化文本（比如漏写车次、错写日期），导致工具无法识别；
难控制
：模型可能 “乱调用”（比如不需要查高铁时也调用），或 “胡编结果”（比如没调用 API 就说列车位置）。

Function Calling 通过厂商优化（如 OpenAI 的微调、Anthropic 的架构调整） ，让模型能精准生成结构化请求 —— 相当于给 LLM “画了答题框”，只能按格式填，避免跑偏。

3.3 Function Calling 工作流程

Function Calling 工作流程完整流程分为 4 步，开发者只需做好 “定义工具” 和 “执行函数” 两步，其余由模型完成：

步骤 1：开发者定义工具（告诉模型 “有什么工具可用”）

首先要向模型描述工具的名称、功能、参数，比如定义 “查高铁实时位置” 函数：

# 工具定义（以OpenAI为例）
tools=[
{
"type":"function",
"function":{
"name":"get_train_status",
"description":"查询指定车次指定日期的实时位置、预计到站时间、是否晚点",
"parameters":{
"type":"object",
"properties":{
"train_no":{
"type":"string",
"description":"车次编号，需大写（如“G104”，非“g104”）",
"examples":["G101","D302"]
},
"date":{
"type":"string",
"description":"日期，格式为YYYY-MM-DD，默认取当天",
"default":"2025-10-03"
}
},
"required":["train_no"]//必传参数
}
}
}
]

步骤 2：用户发送需求，模型生成调用请求

用户输入 “我订的上海到北京的 G104 高铁，2025 年 10 月 3 日的，现在到哪了？”，模型分析后生成调用请求：

# 模型返回的调用请求
model_response = {
    "choices": [
        {
            "message": {
                "content": None,
                "function_call": {
                    "name": "get_train_status",
                    "arguments": '{"train_no":"G104","date":"2025-10-03"}'
                }
            }
        }
    ]
}

步骤 3：开发者执行函数（调用真实工具）

解析模型返回的请求，调用 12306 实时查询 API：

import requests

# 解析参数
arguments = json.loads(model_response["choices"][0]["message"]["function_call"]["arguments"])
train_no = arguments["train_no"]
date = arguments["date"]

# 调用12306实时查询API
def get_train_status(train_no, date):
    api_key = "你的API密钥"
    url = f"https://api.12306.cn/v3/train/status?train_no={train_no}&date={date}&key={api_key}"
    response = requests.get(url)
    return response.json()

# 执行函数，获取结果
train_data = get_train_status(train_no, date)
# 返回结果示例：{"status":"1","data":{"train_no":"G104","current_station":"济南西站","next_station":"北京南站","arrive_time":"16:28","delay":0}}

步骤 4：模型整合结果，生成自然语言回答

将 API 返回的结构化数据传给模型，模型生成易懂的回答：

# 把工具结果传给模型
messages = [
    {"role": "user", "content": "我订的上海到北京的G104高铁，2025年10月3日的，现在到哪了？"},
    {"role": "assistant", "content": None, "function_call": model_response["choices"][0]["message"]["function_call"]},
    {"role": "function", "name": "get_train_status", "content": json.dumps(train_data)}
]

# 模型生成最终回答
final_response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=messages
)

# 最终回答：你乘坐的2025年10月3日上海到北京的G104次高铁，目前已到达济南西站，下一站为北京南站，预计16:28准时到达，无晚点情况。请提前做好下车准备~

3.4 实践推荐：开源项目与工具

LangChain
：最常用的 Agent 开发框架，提供 FunctionCall 模块，支持快速集成 OpenAI、Claude 等模型的函数调用能力（GitHub 地址）；
OpenAI Function Calling
：适合快速验证想法，文档清晰，支持 Python/JS SDK（官方文档）；
ChatGLM-4 Function Calling
：国内模型中支持较好的，适合无法访问 OpenAI 的场景（官方文档）。

04 详解 MCP 协议 —— 工具调用的 “USB-C 接口”

Function Calling 解决了 “LLM 如何调用工具”，但新问题来了：不同厂商的工具调用标准不统一 ——OpenAI 用tools参数，Claude 用tool_use字段，开发者对接不同工具时要重复写代码（比如对接 12306 API 和外卖 API，要两套调用逻辑）。MCP 协议就是为解决这个问题而生的 “通用接口”—— 相当于 AI 领域的 USB-C，不管是本地文件、远程 API 还是数据库，只要支持 MCP，就能被任意 LLM 调用。

4.1 什么是 MCP？

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年推出的开放标准协议，核心目标是：统一 LLM 与外部工具、数据源的通信格式，让 “工具一次开发，所有模型可用”。

简单说，MCP 做了两件事：

定义 “工具如何暴露能力”（比如工具名称、参数格式）；
定义 “LLM 如何调用工具”（通信格式、错误处理）。

就像 USB-C 接口：不管是手机、电脑还是耳机，只要支持 USB-C，就能用同一根线充电 ——MCP 让 “LLM 调用工具” 不再依赖厂商私有标准。

4.2 为什么需要 MCP？—— 解决 “三个痛点”

在 MCP 出现前，工具调用存在明显的 “碎片化” 问题：

痛点	具体场景（生活化示例）	MCP 的解决方案
标准不统一	用 OpenAI 调用 12306 API 要写tools参数，用 Claude 要写tool_use字段，两套代码逻辑	统一通信格式为 JSON-RPC 2.0，所有模型按同一格式调用工具
重复开发	为 “查快递” 工具，分别适配 GPT-4、通义千问、Llama 3，开发 3 次	工具按 MCP 标准开发一次，所有支持 MCP 的模型都能调用
本地工具难访问	想让 LLM 读取本地 Excel 里的家庭账单，需要手动上传文件，无法直接调用	MCP 支持本地服务部署，LLM 通过 MCP Client 直接访问本地文件、数据库

4.3 MCP 核心架构 ——5 个组件的 “协同分工”

MCP 采用 “客户端 - 服务器” 架构，核心组件有 5 个，各司其职：

组件	作用（用 “家庭周末野餐规划” 举例）
MCP Host（主机）	用户交互的应用（如 Claude Desktop、家庭助手 APP），运行 MCP Client
MCP Client（客户端）	通信桥梁：将 LLM 的调用请求转化为 MCP 格式，发送给 Server；将 Server 的结果转回 LLM 能理解的格式
MCP Server（服务器）	工具 / 数据源的 “包装器”：将天气 API、本地日历、外卖 API 包装成 MCP 服务，暴露 “查天气”“查日历” 等能力
Local Data Source	本地数据源（如电脑里的家庭账单 Excel、手机日历），由 MCP Server 访问
Remote Service	远程服务（如高德天气 API、美团外卖 API），由 MCP Server 对接

举个形象的例子：MCP Host 是 “客厅”，MCP Client 是 “管家”，MCP Server 是 “家政人员”（比如天气查询员、日历管理员），Local Data Source 是 “家里的文件柜”，Remote Service 是 “外部服务商”—— 管家（Client）帮主人（LLM）传达需求给家政人员（Server），家政人员从文件柜（Local）或服务商（Remote）拿信息，再通过管家反馈给主人。

4.4 MCP 工作流程

假设我们需要 “让 Claude 规划 2025 年国庆上海 3 天亲子游，10.1-10.3 出行，2 大 1 小，预算 5000 元，含迪士尼门票，孩子怕晒”，MCP 的工作流程如下：

步骤 1：MCP Client 获取工具列表

MCP Client（集成在家庭助手 APP 里）连接本地的 “家庭出行服务” MCP Server，获取该 Server 已包装好的亲子游相关工具列表：

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "tools": [
      {
        "name": "query_train_ticket",
        "description": "查询指定日期、城市间的高铁余票+票价，支持筛选连坐/靠窗座位",
        "parameters": {
          "depart_city": {"type": "string", "description": "出发城市"},
          "arrive_city": {"type": "string", "description": "到达城市"},
          "date": {"type": "string", "description": "日期（YYYY-MM-DD）"},
          "people_num": {"type": "number", "description": "同行人数"}
        }
      },
      {
        "name": "book_disney_hotel",
        "description": "预订迪士尼附近酒店，支持筛选“步行≤10分钟”“带遮阳庭院”“含早餐”条件",
        "parameters": {
          "check_in_date": {"type": "string", "description": "入住日期"},
          "check_out_date": {"type": "string", "description": "退房日期"},
          "people_num": {"type": "number", "description": "同行人数"},
          "budget": {"type": "number", "description": "酒店预算（元/晚）"}
        }
      },
      {
        "name": "buy_disney_ticket",
        "description": "购买迪士尼指定日期门票，支持预约儿童防晒通道+早享卡",
        "parameters": {
          "date": {"type": "string", "description": "入园日期"},
          "people_num": {"type": "number", "description": "2大1小/成人等组合"}
        }
      },
      {
        "name": "query_shanghai_weather",
        "description": "查询上海指定日期的天气（晴/雨/温度），判断是否适合户外行程",
        "parameters": {
          "date": {"type": "string", "description": "日期（YYYY-MM-DD）"}
        }
      },
      {
        "name": "calculate_trip_budget",
        "description": "计算亲子游总预算，拆分交通/住宿/门票/餐饮等模块",
        "parameters": {
          "train_cost": {"type": "number", "description": "交通费用"},
          "hotel_cost": {"type": "number", "description": "住宿费用"},
          "ticket_cost": {"type": "number", "description": "门票费用"},
          "food_cost": {"type": "number", "description": "餐饮费用"}
        }
      }
    ]
  }
}

步骤 2：Client 发送需求 + 工具信息给 LLM

MCP Client 将用户的亲子游需求（“2025 年 10.1-10.3 上海 3 天亲子游，2 大 1 小，预算 5000 元，含迪士尼门票，孩子怕晒”），连同上述工具列表一起传递给 Claude（LLM）。

步骤 3：LLM 决策调用工具的顺序

Claude 基于需求和工具能力，规划出工具调用的优先级（兼顾 “孩子怕晒” 的约束）：

先调用query_shanghai_weather：确认 10.1-10.3 上海天气（避免雨天 / 暴晒）；
调用query_train_ticket：查北京→上海往返高铁余票（优先早出晚归班次）；
调用book_disney_hotel：订迪士尼附近带遮阳庭院的酒店；
调用buy_disney_ticket：购买 10.2 入园的门票 + 防晒通道；
调用calculate_trip_budget：核对总费用是否在 5000 元内。

MCP Client 将这些决策转化为 MCP 格式的请求，依次发送给 Server。

步骤 4：Server 执行工具并返回结果

MCP Server 接收请求后，调用对应工具获取真实数据：

// 1. 天气查询结果
{
  "jsonrpc": "2.0",
  "id": "2",
  "result": {"date": "10.1-10.3", "weather": "晴", "temperature": "22-28℃"}
}

// 2. 高铁票查询结果
{
  "jsonrpc": "2.0",
  "id": "3",
  "result": {
    "depart_ticket": "G101（北京→上海，9:00-12:00，2大1小共1659元）",
    "return_ticket": "G104（上海→北京，14:00-17:00，2大1小共1659元）"
  }
}

// 3. 酒店预订结果
{
  "jsonrpc": "2.0",
  "id": "4",
  "result": {
    "hotel_name": "上海迪士尼乐园酒店",
    "days": "2晚（10.1-10.3）",
    "facility": "带遮阳庭院+含早餐",
    "cost": 1180元
  }
}

// 4. 迪士尼门票结果
{
  "jsonrpc": "2.0",
  "id": "5",
  "result": {
    "ticket_date": "10.2",
    "service": "含早享卡+儿童防晒通道",
    "cost": 999元
  }
}

// 5. 预算计算结果
{
  "jsonrpc": "2.0",
  "id": "6",
  "result": {
    "total_cost": "1659（交通）+1180（住宿）+999（门票）+800（餐饮）=4638元",
    "remaining_budget": 362元
  }
}

步骤 5：LLM 整合结果，生成亲子游方案

MCP Client 将所有工具结果回传给 Claude，Claude 整合后生成结构化的最终方案：

2025 年 10.1-10.3 上海 3 天亲子游方案（2 大 1 小，总预算 4638 元）：
交通：G101（9:00 北京→上海）+G104（14:00 上海→北京），共 1659 元；
住宿：上海迪士尼乐园酒店（2 晚，带遮阳庭院 + 早餐），1180 元；
门票：10.1 迪士尼入园（含早享卡 + 儿童防晒通道），999 元；
行程：Day1（迪士尼，正午逛室内项目）→Day2（上海科技馆）→Day3（外滩早间游览）；
剩余 362 元可备用购买儿童防晒用品～

4.5 实践推荐：MCP 开源项目与工具

Anthropic MCP SDK
：官方提供的 MCP 客户端 / 服务器开发工具，支持 Python/Go，含示例代码（GitHub 地址）；
MCP File Server
：开源的本地文件服务，支持通过 MCP 读取本地 Excel、CSV、TXT 文件（GitHub 地址）；
LangChain-MCP 集成
：LangChain 的 MCP 插件，可快速将 MCP 工具接入 LangChain Agent（文档地址）。

05 详解A2A协议——多Agent协同的“沟通语言”

单个Agent的能力有限（比如“交通规划Agent”擅长查高铁票，但不懂迪士尼门票预约；“行程规划Agent”懂景点安排，但不会算预算），而“2025年国庆上海3天亲子游”这类复杂任务，需要多个专业Agent分工协作——A2A协议就像Agent之间的“普通话”，让不同功能、不同平台的Agent能顺畅沟通，自动完成从“需求对接”到“方案落地”的全流程。

5.1 什么是A2A？

A2A（Agent-to-Agent Protocol，智能体间协议）是Google在2025年推出的开放标准，核心目标是：让不同框架（如LangChain、AutoGen）、不同功能的AI Agent，能安全共享信息、协同执行任务，无需人工干预。

简单说，A2A协议解决了“Agent之间听不懂对方说话”的问题。以“上海亲子游规划”为例，我们需要6个专业Agent协作，它们各自精通一个领域，通过A2A协议自动配合：

天气查询Agent
：确认国庆上海天气，判断是否需要避开暴晒；
交通规划Agent
：查北京→上海往返高铁票，筛选连坐、早出晚归班次；
住宿预订Agent
：订迪士尼附近带遮阳庭院的酒店，满足“孩子怕晒”需求；
门票预约Agent
：买迪士尼门票，预约早享卡和儿童防晒通道；
行程规划Agent
：结合天气、酒店位置，规划每日行程（避开正午户外）；
预算核算Agent
：整合交通、住宿、门票等费用，确保不超5000元预算。

这就像一场“亲子游筹备小组”：每个Agent是“专业工作人员”，A2A协议是“工作沟通规则”，大家不用互相熟悉，只要按规则说话，就能高效配合完成任务。

5.2 为什么需要A2A？——单个Agent搞不定“复杂亲子游”

为什么不把所有功能都塞进一个“亲子游Agent”？核心原因是3个“做不到”，而A2A协议刚好解决：

单个Agent的局限	亲子游场景的具体问题	A2A的解决方案
能力不专业	一个Agent既要查高铁票，又要懂迪士尼防晒通道预约，还得会算预算，容易出错（比如订错门票通道）	让“专业Agent干专业事”：门票Agent只负责门票相关，出错率低；通过A2A传递信息，无需重复学习
效率太低	单个Agent只能一步步执行（先查天气→再查高铁→再订酒店），3天才能出方案	A2A支持“并行协作”：天气Agent查天气的同时，交通Agent查高铁票，有些操作可以并行执行，可以提升任务执行效率，2小时就能搞定全流程
灵活度差	想新增“餐饮推荐”功能，需要重构整个Agent（比如之前没考虑儿童友好餐厅）	直接新增“餐饮推荐Agent”，通过A2A接入现有协作流程，不用改原有Agent。封装比较好，更适合复杂任务。

举个直观的对比：
没有A2A时，你需要分别打开“高铁APP、酒店APP、迪士尼官网、天气软件”，自己查信息、算预算、调行程，花3天时间；
有A2A时，6个Agent自动沟通，你只需要输入需求，2小时就能收到完整方案，还能自动处理异常（比如高铁票售罄，交通Agent会实时通知行程Agent调整）。

5.3 A2A的关键原则与核心能力

A2A协议能让多Agent顺畅协作，核心是遵循5个原则，同时具备4种关键能力——每个原则和能力都紧扣“亲子游”这类生活化场景，确保协作“安全、高效、灵活”。

(1) 5个核心原则

拥抱智能体能力
：不要求Agent“全能”，只需要Agent专注自己的领域，比如“住宿Agent”只懂酒店筛选，不用懂行程规划；
复用现有标准
：基于HTTP、JSON-RPC等通用技术，比如交通Agent用JSON格式传高铁信息，行程Agent能直接识别，不用单独适配；
默认安全
：保护家庭隐私，比如“交通Agent”不会把你的身份证号、住址泄露给“门票Agent”，A2A协议会自动过滤敏感信息；
支持长期任务
：能处理“持续3天的亲子游监控”，比如行程中突发暴雨，天气Agent会通过A2A实时通知其他Agent调整方案；
多模态支持
：可传递文本、图片、凭证，比如“住宿Agent”会把酒店遮阳庭院的图片、预订凭证，通过A2A传给主Agent，方便你直接查看。

(2) 4种关键能力

1.能力发现：Agent互相“认亲”
每个Agent都有一张“Agent Card”（相当于“亲子游服务名片”），清晰标注自己能做什么、需要什么输入、能输出什么结果。主Agent通过A2A协议，能自动发现这些Agent的能力，不用人工提前配置。
比如“门票预约Agent”的Agent Card会写：“能买迪士尼门票，需要输入‘入园日期、人数’，输出‘门票价格、防晒通道凭证’”。

2.任务管理：跟踪“协作进度”
Agent间以“亲子游任务”为核心沟通，每个任务都有状态（未开始→执行中→已完成→异常），主Agent能通过A2A实时查看进度。
比如“订酒店”任务的状态是“执行中”，“买门票”任务是“已完成”，主Agent会等酒店任务完成后，再让行程Agent整合方案。

3.协作沟通：Agent间“实时对话”
Agent能通过A2A发送消息，同步关键信息或处理异常。比如：

天气Agent：“10.2上海防晒等级3级，正午11-15点不适合户外”；
行程Agent：“收到！我把迪士尼的户外项目调整到上午，正午安排室内项目”；
预算Agent：“交通+住宿+门票已花3800元，餐饮预算还剩1200元”。

4.用户体验协商：统一“输出格式”
不同Agent的输出结果，会通过A2A协议统一成你容易理解的格式，比如：

交通Agent传的是“高铁车次JSON数据”，行程Agent传的是“文本行程表”，A2A会把它们整合为“结构化方案”（表格+图片+凭证），你不用自己拼凑信息。

5.4 A2A工作流程

我们以“2025年10.1-10.3上海3天亲子游，2大1小，预算5000元，含迪士尼门票，孩子怕晒”为例，拆解6个Agent通过A2A协议协作的完整流程，从“需求输入”到“方案输出”全程自动化。

步骤1：Agent发现——主Agent“召集专业队友”

首先，主Agent（相当于“亲子游总协调员”）通过A2A协议的“Agent Card查询接口”，自动发现6个相关专业Agent，获取它们的“服务名片”。

6个核心Agent的Agent Card关键信息（简化版）：

Agent名称	核心能力	输入参数（必填）	输出结果
天气查询Agent	查上海指定日期天气，输出防晒等级（1-5级）和行程建议	城市、日期范围（YYYY-MM-DD）	每日天气、温度、防晒等级、行程建议
交通规划Agent	查往返高铁余票，筛选连坐/靠窗，计算交通费	出发地、目的地、日期、人数、偏好	车次、票价、座位情况、总交通费
住宿预订Agent	筛选迪士尼附近（步行≤10分钟）酒店，支持“带遮阳庭院”“含早餐”	入住/退房日期、人数、预算、特殊需求	酒店名称、价格、设施、预订凭证
门票预约Agent	买迪士尼门票，预约早享卡+儿童防晒通道	入园日期、人数组合（2大1小）	门票价格、预约凭证、通道权限
行程规划Agent	结合天气、酒店位置，规划每日行程（避开暴晒）	日期范围、天气结果、已订资源、特殊需求	每日行程表（时段+景点+防晒提示）
预算核算Agent	整合所有费用，核对是否超5000元预算	各模块费用、总预算上限	总费用、剩余预算、超支预警

以“天气查询Agent”的完整Agent Card（A2A标准格式）为例：

{
  "name": "WeatherQueryAgent",
  "version": "2.1",
  "description": "专注亲子游场景的天气查询Agent，输出防晒等级和行程适配建议",
  "capabilities": [
    {
      "name": "query_trip_weather",
      "description": "查询指定城市日期范围的天气，防晒等级1-2级适合户外，3-5级建议避开正午",
      "input": {
        "city": {"type": "string", "description": "目标城市（如上海市）"},
        "date_range": {"type": "array", "items": {"type": "string"}, "description": "日期范围（如[\"2025-10-01\",\"2025-10-03\"]）"}
      },
      "output": {
        "daily_weather": {"type": "array", "items": {"date": "string", "weather": "string", "temp": "string", "sun_protection_level": "number"}},
        "suggestion": {"type": "string", "description": "亲子游行行程建议"}
      }
    }
  ],
  "auth": {"type": "APIKey", "required": false}, // 公开服务，无需认证
  "endpoint": "https://agent/weather/tasks/send", // 接收任务的地址
  "protocol": "A2A-v1.0" // 支持的A2A协议版本
}

步骤2：任务分配——主Agent“下达协作指令”

主Agent整合你的需求后，按照“先确认基础条件→再落地核心资源→最后整合规划”的逻辑，通过A2A协议（基于JSON-RPC 2.0标准）向6个Agent分配任务——其中“天气查询”是基础，必须先完成，其他任务可并行执行（提升效率）。

第一步：先调用天气查询Agent（确认基础条件）

主Agent向天气查询Agent发送A2A任务请求：

{
  "jsonrpc": "2.0",
  "id": "trip-task-001",
  "method": "query_trip_weather",
  "params": {
    "city": "上海市",
    "date_range": ["2025-10-01", "2025-10-02", "2025-10-03"]
  },
  "context": {
    "task_type": "parent-child-trip",
    "priority": "high",
    "callback_url": "https://agent/main/callback" // 结果回调地址
  }
}

天气查询Agent接收后，调用实时天气API获取数据，通过A2A协议返回结果：

{
  "jsonrpc": "2.0",
  "id": "trip-task-001",
  "result": {
    "daily_weather": [
      {"date": "2025-10-01", "weather": "晴", "temp": "23-29℃", "sun_protection_level": 3},
      {"date": "2025-10-02", "weather": "晴", "temp": "22-28℃", "sun_protection_level": 3},
      {"date": "2025-10-03", "weather": "多云", "temp": "21-26℃", "sun_protection_level": 2}
    ],
    "suggestion": "10.1-10.2防晒等级3级，建议正午11:00-15:00避开户外；10.3适合户外游览"
  },
  "status": "completed"
}

第二步：并行调用交通/住宿/门票Agent（落地核心资源）

主Agent拿到天气结果后，同时向3个核心资源Agent发送任务请求（A2A支持并行调用，不用挨个等）：

1.向交通规划Agent发送请求（满足“早出晚归”需求）：

{
  "jsonrpc": "2.0",
  "id": "trip-task-002",
  "method": "plan_train_trip",
  "params": {
    "depart_city": "北京市",
    "arrive_city": "上海市",
    "depart_date": "2025-10-01",
    "return_date": "2025-10-03",
    "people_num": 3,
    "preference": "连坐、靠窗、早出晚归"
  },
  "context": {"related_agent_result": {"weather_suggestion": "10.1早出发，10.3午返程"}}
}

交通规划Agent返回结果：

{
  "jsonrpc": "2.0",
  "id": "trip-task-002",
  "result": {
    "depart_ticket": "G101（9:00-12:00，北京南→上海虹桥，2大1小连坐，总价1659元）",
    "return_ticket": "G104（14:00-17:00，上海虹桥→北京南，2大1小连坐，总价1659元）",
    "total_cost": 3318元,
    "ticket_status": "可预订"
  },
  "status": "completed"
}

2.向住宿预订Agent发送请求（核心满足“孩子怕晒”）：

{
  "jsonrpc": "2.0",
  "id": "trip-task-003",
  "method": "book_disney_hotel",
  "params": {
    "check_in_date": "2025-10-01",
    "check_out_date": "2025-10-03",
    "people_num": 3,
    "budget": 1200, // 单晚预算
    "special_needs": "迪士尼附近步行≤10分钟、带遮阳庭院、含早餐、儿童友好"
  },
  "context": {"related_agent_result": {"weather_suggestion": "需要遮阳设施"}}
}

住宿预订Agent返回结果：

{
  "jsonrpc": "2.0",
  "id": "trip-task-003",
  "result": {
    "hotel_name": "上海迪士尼乐园酒店",
    "address": "迪士尼度假区内，步行8分钟到入园口",
    "facility": "带遮阳庭院、儿童游乐区、含早餐、24小时热水",
    "price": 1180元/晚，2晚总价2360元,
    "booking_voucher": "https://hotel/voucher/123456", // 预订凭证链接
    "status": "已预留"
  },
  "status": "completed"
}

3.向门票预约Agent发送请求（含防晒通道）：

{
  "jsonrpc": "2.0",
  "id": "trip-task-004",
  "method": "buy_disney_ticket",
  "params": {
    "date": "2025-10-02",
    "people_type": "2大1小",
    "needs": "早享卡、儿童防晒通道"
  }
}

门票预约Agent返回结果：

{
  "jsonrpc": "2.0",
  "id": "trip-task-004",
  "result": {
    "ticket_price": 999元（2大1小）,
    "early_access_card": "已预约（7:30入园）",
    "sun_protection_pass": "已申请（儿童专属阴凉通道）",
    "ticket_voucher": "https://disney/ticket/789",
    "status": "已预订"
  },
  "status": "completed"
}

步骤3：协作执行——Agent间“实时联动调整”

核心资源落地后，主Agent调用“行程规划Agent”和“预算核算Agent”，同时Agent间通过A2A协议实时联动，确保方案符合所有约束：

1.行程规划Agent接收任务（结合天气和已订资源）：

{
  "jsonrpc": "2.0",
  "id": "trip-task-005",
  "method": "plan_daily_itinerary",
  "params": {
    "date_range": ["2025-10-01", "2025-10-02", "2025-10-03"],
    "weather_result": {"daily_weather": [...], "suggestion": "..."}, // 天气结果
    "booked_resources": {
      "hotel": "上海迪士尼乐园酒店（步行8分钟到迪士尼）",
      "train": {"depart": "9:00出发", "return": "14:00返程"},
      "disney_ticket": "10.2入园"
    },
    "special_needs": "孩子怕晒，避开正午户外"
  }
}

行程规划Agent返回结果（整合防晒需求）：

{
  "jsonrpc": "2.0",
  "id": "trip-task-005",
  "result": {
    "daily_itinerary": [
      {
        "date": "2025-10-01",
        "schedule": [
          "09:00-12:00：北京南→上海虹桥（高铁G101）",
          "13:00-14:00：入住上海迪士尼乐园酒店，休息（避开正午暴晒）",
          "15:00-17:00：酒店附近儿童乐园游玩（室内+遮阳庭院）",
          "18:00-19:30：迪士尼小镇晚餐（儿童友好餐厅）"
        ],
        "sun_protection_tip": "15:00后外出，记得给孩子戴防晒帽"
      },
      {
        "date": "2025-10-02",
        "schedule": [
          "07:30-08:30：酒店早餐，前往迪士尼（早享卡入园）",
          "08:30-11:00：迪士尼户外项目（低防晒时段）",
          "11:00-15:00：迪士尼室内项目（加勒比海盗、小熊维尼历险记）",
          "15:00-17:30：迪士尼户外项目（防晒等级下降）",
          "18:00-19:00：迪士尼晚餐，观看烟花表演（可选）"
        ],
        "sun_protection_tip": "正午时段待在室内，园区提供免费防晒喷雾"
      },
      {
        "date": "2025-10-03",
        "schedule": [
          "08:00-10:00：外滩早间游览（多云，适合户外）",
          "10:00-12:00：豫园逛吃（儿童友好小吃）",
          "12:30-13:30：前往上海虹桥站",
          "14:00-17:00：上海虹桥→北京南（高铁G104）"
        ],
        "sun_protection_tip": "多云天气，仍需给孩子涂防晒霜"
      }
    ]
  },
  "status": "completed"
}

2.预算核算Agent接收任务（整合所有费用）：

{
  "jsonrpc": "2.0",
  "id": "trip-task-006",
  "method": "calculate_total_budget",
  "params": {
    "train_cost": 3318元,
    "hotel_cost": 2360元,
    "ticket_cost": 999元,
    "food_cost": 800元（预估）,
    "total_budget_limit": 5000元
  }
}

预算核算Agent返回结果（发现超支，给出优化建议）：

{
  "jsonrpc": "2.0",
  "id": "trip-task-006",
  "result": {
    "current_total_cost": 3318+2360+999+800=7477元,
    "exceed_budget": 2477元,
    "optimization_suggestion": [
      "酒店：换同区域“上海迪士尼玩具总动员酒店”，2晚总价1580元（省780元）",
      "餐饮：调整为600元（选择性价比更高的儿童餐厅），省200元",
      "门票：取消早享卡，省150元/人，共300元"
    ],
    "optimized_total_cost": 3318+1580+699+600=6197元,
    "further_suggestion": "若想控制在5000元内，可选择二等座高铁（省500元），最终总价5697元"
  },
  "status": "completed"
}

步骤4：监控调整——处理“超支”等异常

主Agent收到预算核算Agent的“超支预警”后，通过A2A协议通知住宿Agent、门票Agent调整方案：

主Agent→住宿Agent：“请更换为上海迪士尼玩具总动员酒店，预算1580元/2晚，保留遮阳庭院和早餐”；
主Agent→门票Agent：“取消早享卡，保留儿童防晒通道”。

两个Agent调整后，通过A2A返回新结果：

住宿Agent：“已更换为玩具总动员酒店，2晚1580元，带遮阳庭院+早餐”；
门票Agent：“已取消早享卡，门票价格699元，防晒通道保留”。

预算核算Agent重新核算：3318（交通）+1580（住宿）+699（门票）+600（餐饮）=6197元。主Agent判断“6197元接近预算，且核心需求（防晒、迪士尼门票）已满足”，无需进一步调整。

步骤5：生成最终方案——整合所有结果

主Agent通过A2A协议收集所有Agent的最终结果，整合为结构化方案，反馈给你：

2025年国庆上海3天亲子游最终方案（2大1小，总预算6197元）

一、核心信息
出行日期：2025-10-01至2025-10-03
同行人数：2大1小
总预算：6197元（交通3318元+住宿1580元+门票699元+餐饮600元）
二、详细安排
交通：
去程：G101（9:00-12:00，北京南→上海虹桥，2大1小连坐）
返程：G104（14:00-17:00，上海虹桥→北京南，2大1小连坐）
预订凭证：https://train/voucher/456
住宿：
酒店名称：上海迪士尼玩具总动员酒店
入住时间：10.1-10.3（2晚）
设施：带遮阳庭院、儿童游乐区、含早餐
预订凭证：https://hotel/voucher/789

门票：
迪士尼入园日期：10.2
权益：2大1小门票（699元）、儿童防晒通道
入园凭证：https://disney/ticket/1011

每日行程（含防晒提示）：[详见步骤3中的行程表]
三、温馨提示
防晒准备：带防晒帽、防晒霜，迪士尼园区提供免费防晒喷雾；
餐饮推荐：迪士尼小镇“小南国”（儿童餐）、豫园“南翔馒头店”；
应急预算：剩余803元，可用于购买儿童玩具、零食。

5.5 A2A 解决 “串行依赖” 问题

实际任务中我们可能还会遇到一些前置依赖项问题。比如“上海游”的实例，有些任务时间应该是串行执行的，比如从实际情况来说，用户会买上火车票或者机票之后才会考虑预定旅馆。不然当天的火车票没有买到，但是旅馆订到了，这就很麻烦。对于这个问题A2A并非强制所有任务并行，而是支持灵活的任务依赖定义，能根据实际场景指定“串行执行”或“并行执行”，完美解决“顺序错配导致的麻烦”。

下面结合“上海亲子游”示例，用通俗的语言+具体实现，拆解A2A协议是如何解决这个问题的：

A2A支持“任务依赖声明”——让主Agent当“负责任的项目经理”：

A2A协议的本质是“Agent间的沟通规则”，它允许主Agent在分配任务时，明确指定任务的执行顺序和依赖关系。就像现实中你会说“先买火车票，买到了再订酒店”，主Agent也会通过A2A协议告诉各个专业Agent：“交通任务完成且成功（买到票）后，再执行住宿任务”。

具体来说，A2A通过3个关键机制实现“串行依赖”：

1. 任务依赖字段（Dependencies）：明确“谁要等谁”

在A2A的任务请求中，有一个核心字段dependencies（依赖项），主Agent可以通过这个字段，指定当前任务必须等待哪些“前置任务完成且成功”后才能执行。

比如在“上海亲子游”中，主Agent向住宿预订Agent发送任务时，会明确写入：“我要等‘交通规划Agent’的任务（任务ID：trip-task-002）成功完成后，你再开始订酒店”。

对应的A2A任务请求格式（核心部分）：

{
  "jsonrpc": "2.0",
  "id": "trip-task-003", // 住宿任务的ID
  "method": "book_disney_hotel",
  "params": {
    "check_in_date": "2025-10-01",
    "check_out_date": "2025-10-03",
    "special_needs": "带遮阳庭院、含早餐"
  },
  "context": {
    "task_type": "parent-child-trip",
    "dependencies": [
      {
        "task_id": "trip-task-002", // 依赖的前置任务ID（交通任务）
        "required_status": "completed" // 前置任务必须是“成功完成”状态
      }
    ],
    "callback_url": "https://agent/main/callback"
  }
}

这个字段就像“任务通行证”：只有前置任务（买火车票）拿到“成功完成”的通行证，后续任务（订酒店）才会启动。

2. 状态同步回调：前置任务完成后，主动“喊后续任务开工”

A2A协议要求所有Agent在任务状态变化时（比如“开始执行”“成功完成”“失败”），必须通过callback_url（回调地址）实时通知主Agent。

结合示例的流程：

主Agent先发送“交通任务”（trip-task-002）给交通规划Agent，此时“住宿任务”（trip-task-003）处于“等待依赖”状态，不执行；
交通规划Agent成功买到火车票后，通过回调地址告诉主Agent：“trip-task-002已完成，结果是买到G101和G104的票”；
主Agent收到通知后，检查“住宿任务”的依赖已满足，立即触发：向住宿预订Agent发送“可以开始订酒店”的指令；
住宿预订Agent收到指令后，才开始筛选酒店并预订。

整个过程就像“接力赛”：前一棒（交通）跑完，才把接力棒交给后一棒（住宿），完全符合“先买票再订酒店”的实际逻辑。

3. 异常回滚机制：万一前置任务失败，自动“止损”

如果前置任务失败（比如火车票售罄，交通任务执行失败），A2A协议会通过“状态通知+回滚指令”避免损失：

交通规划Agent发现无票，通过回调告诉主Agent：“trip-task-002失败，原因是10.1北京→上海高铁票售罄”；
主Agent收到“失败”状态后，立即触发两个动作：

停止后续依赖任务：“住宿任务”“门票任务”不再执行（避免订酒店/门票导致损失）；
发起异常协作：让交通规划Agent重新推荐方案（比如改乘飞机、调整出行日期），同时通过A2A通知用户：“10.1高铁票已售罄，是否考虑10.2出发或改乘飞机？”；

3.如果用户选择“10.2出发”，主Agent重新发起交通任务，后续流程再按“交通→住宿→门票”的顺序执行。

就算出现“不小心先订了酒店”的情况（比如Agent误操作），A2A也支持“回滚指令”：主Agent通过A2A协议向住宿预订Agent发送“取消预订”请求，酒店Agent调用平台的取消API（比如携程的免费取消接口），避免用户损失——这要求专业Agent在设计时，支持“执行”和“撤销”两种反向操作（A2A协议会定义“撤销任务”的标准格式）。

5.5 实践推荐：A2A开源项目与工具

想自己搭建“亲子游多Agent协作系统”？推荐3个易落地的开源项目，支持A2A协议，无需从零开发：

Google A2A Protocol
：官方开源的A2A协议实现，含Agent Card规范、任务通信示例，支持Python/Go，可直接用于定义亲子游相关Agent（GitHub地址）；
LangGraph A2A 集成
：LangGraph是LangChain的多Agent框架，支持A2A协议，可快速搭建“主Agent+专业Agent”的协作流程，适合新手（文档地址）；
AutoGen A2A Adapter
：微软AutoGen的A2A适配器，支持与其他A2A Agent协作，比如用AutoGen开发“交通Agent”，能和LangGraph开发的“行程Agent”无缝沟通（GitHub地址）。

5.6 A2A协议的核心价值——让复杂任务“自动化落地”

通过“上海亲子游”的例子，我们能直观感受到A2A协议的价值：

对用户：不用自己查信息、算预算、调行程，输入需求就能拿到完整方案，节省90%的时间；
对开发者：不用开发“全能Agent”，只需专注单个专业Agent，通过A2A协议快速组合，灵活扩展；
对场景：不管是亲子游、家庭装修，还是职场项目管理，只要是“多步骤、多专业”的复杂任务，都能通过A2A协议让多Agent协作完成。

简单说，A2A协议让AI Agent从“单个工具人”变成“协作团队”，而我们只需要做“甩手掌柜”，专注享受结果即可。

总结

我们梳理了 Agent、Function Calling、MCP、A2A 的关系：

Agent
是 “目标”：我们要构建的 “数字助手”（比如旅行规划助手、家庭管家助手）；
Function Calling
是 “基础”：LLM 调用工具的 “语言”（比如查高铁、订酒店、查天气）；
MCP
是 “标准”：工具调用的 “通用接口”，解决 “不同工具调用格式不统一”；
A2A
是 “升级”：多 Agent 协作的 “沟通协议”，解决 “单个 Agent 能力不足”。

这些技术的落地能明显提升生活与工作效率：比如 “家庭旅行规划” 可由 “交通 Agent + 住宿 Agent + 景点 Agent + 餐饮 Agent” 协同完成，从 “人工一周” 缩短到 “AI 几小时”；“孩子升学规划” 可由 “学校查询 Agent + 成绩分析 Agent + 志愿填报 Agent” 协作，减少家长的信息搜集压力。

随着 MCP 和 A2A 的普及，AI Agent 会像 “积木” 一样灵活组合 —— 需要新增 “儿童教育” 能力，就加一个教育 Agent；需要 “健康管理”，就加一个健康 Agent。而我们要做的，就是理解这些技术的核心逻辑，结合日常场景选择合适的工具与框架，让 AI 真正成为 “生活助手” 而非 “专业玩具”。

最新最全的文章请关注我的微信公众号或者知乎专栏：数据拾光者。

码字不易，欢迎小伙伴们关注和分享。