Q61 · A2A 和 MCP 的区别是什么？什么时候需要多智能体？

用户对售后助手说：“订单 A123 的耳机有杂音，帮我查订单，再判断能否申请质量检测。”第一步是查一条订单记录：输入订单号，得到签收日期、商品和售后状态。第二步可能需要看故障描述、向用户追问复现条件、核对检测政策，最后给出有依据的建议。这两步表面都叫“调用外部能力”，但它们的工作单位不同：前者是一次边界清楚的查询，后者可能是需要另一个负责者持续处理的任务。

**MCP（Model Context Protocol，模型上下文协议）**主要规范助手应用怎样连接外部工具、资料和提示模板；**A2A（Agent2Agent，智能体到智能体协议）**主要规范一个独立的智能体系统怎样与另一个系统发现彼此、交换消息并协作处理任务。两者可以同时用：售后 Agent 通过 MCP 查订单，再通过 A2A 请独立的质检 Agent 处理诊断；质检 Agent 内部也可能用 MCP 调自己的检测工具。官方 A2A 对比文档用“接工具和资源”与“连接独立 Agent”划分两者的典型边界。A2A 官方对比、MCP 架构规范

本文按查阅时的 A2A 1.0.0 正式规范和 MCP 2026-07-28 正式修订版描述。版本号属于两套不同协议，不能混用；网上较早的 A2A 0.3 或 MCP 2025 教程在字段与生命周期上可能不同。本文的订单、政策和质检结论全是教学假设，不构成真实商家承诺。A2A 1.0.0 规范、MCP 2026-07-28 规范

术语与符号

术语或符号	零基础解释	A123 例子中的对应物
Agent（智能体）	能根据目标选择步骤、使用能力并产出结果的应用或服务；不等于一个模型调用	面向用户的售后助手
多智能体	多个各自有职责的 Agent 协同完成一个用户目标	售后 Agent 与独立质检 Agent 协作
MCP Host / Client / Server	Host 是助手应用；其内部 Client 连接某个提供能力的 Server	售后应用及其连接订单服务的组件
Tool（工具）	输入输出相对明确、让服务端执行一次操作的能力	按 order_id 查订单
Resource（资源）	可读取的资料，不等于可执行动作	售后政策文档
Prompt（提示模板）	可复用的消息模板；本例没有用它执行订单查询	“按政策解释申请条件”的措辞模板
A2A Client / Remote Agent	发起 A2A 请求的一方，以及接任务的远端智能体；发起方也可以是应用服务	售后 Agent 一侧 / 质检 Agent 一侧
Agent Card（智能体名片）	远端 Agent 对外声明身份、技能、访问端点和安全要求的元数据	质检 Agent 声明能做“耳机故障初筛”
Message（消息）	A2A 双方的一轮输入或回复；可包含文字、文件引用或结构化数据	“耳机左耳有间歇杂音”
Task（任务）	有编号、状态和处理过程的工作单元，适合持续或多轮工作	“对 A123 故障做初筛”
Artifact（产物）	Agent 在任务中生成、可交付的结果	带依据的初筛报告
taskId / contextId	前者标识一项任务，后者关联同一上下文里的多次消息与任务	初筛任务编号 / 本次售后咨询编号
授权范围	调用方被允许访问的数据和执行的动作	只可读 A123 所需字段，不可替用户直接批准退款
编排	决定谁先做什么、等多久、失败后怎么办	售后助手先查订单，再决定是否委托质检
order_id	本例订单查询工具的输入字段，值是订单编号	order_id="A123"
Workflow（工作流）	按预设步骤和分支执行的程序流程	固定地先查订单、再读取政策、最后回答
token	模型处理文字等内容时使用的计量单位，额外调用通常增加消耗	两个 Agent 反复传述 A123 事实会增加用量

同一张图里的两条路

从图中的售后 Agent 看，左下是 MCP：查数据，向订单工具提供明确参数后取回字段；右侧是 A2A：委托任务，把问题与必要背景交给独立的质检 Agent，它可追问、处理并交回结论。图只画两条典型路径；并不表示查订单时模型必然使用 MCP，也不表示质检 Agent 的任何工作都必须经 A2A。质检 Agent 也可用自己的工具，但它的内部流程不需要暴露给售后 Agent。A2A 与 MCP 官方对比

先比较通信对象，再比较协议功能

同一个维度	MCP 的典型情况	A2A 的典型情况
连接对象	Host 内的 MCP Client 连接提供 Tool、Resource、Prompt 的 MCP Server	A2A Client 连接一个对外提供智能体能力的远端 Agent
工作单位	读取一份资料，或以明确参数调用某个工具	发送消息；复杂工作可形成可跟踪的 Task
怎样发现能力	服务端声明 capabilities，再列出工具、资源或模板	Agent Card 声明技能、端点、能力和安全要求
输入输出	工具通常有参数结构约束，资源有标识符和内容	消息可多轮交换；结果可为 Message，也可为 Task 中的 Artifact
过程由谁掌握	Host 决定何时读资料或调用工具；MCP Server 执行所暴露的能力	远端 Agent 在自身边界内决定如何完成委托，调用方主要看任务状态和产物
长时工作	核心请求按协议处理；新版 Tasks 扩展可用于长时任务，不能说 MCP 完全不能做	Task 生命周期是 A2A 的核心概念之一，适合跨边界持续协作；简单请求也可直接回 Message
信任与权限	Host 控制共享给 Server 的数据和工具调用同意；Server 校验权限	调用方验证远端 Agent 与身份、最小化共享；远端 Agent 对任务和数据再做授权

这里的“典型情况”很重要。Agent 不一定要通过 A2A 暴露：若它只是提供一个稳定的、输入输出明确的能力，可以被包装成工具。反过来，MCP 也不限定一个应用只有一个 Agent；一个宿主应用可以让多个 Agent 使用 MCP Server。决定选哪个协议的关键，不是代码里用了几个模型，而是你是否需要与独立的任务负责者跨边界协作。A2A 1.0.0 不局限于 JSON-RPC 一种承载方式，正式规范还定义了 gRPC、HTTP+JSON/REST 等协议绑定；因此不能用“一个用 HTTP、另一个用 JSON-RPC”来区分它们。A2A 1.0.0 规范、A2A 与 MCP 对比

A123 的正常处理过程

假设用户已授权售后应用读取 A123 的必要订单信息。订单工具返回：A123 是耳机，2026 年 9 月 20 日签收，咨询时间是 9 月 25 日，用户称“左耳间歇杂音”，故障尚未被检测确认。教学用的政策 v3 规定：签收后 30 天内可申请质量问题检测，是否构成质量故障需经过检测；申请检测不等于承诺退款。下面分别看两种路线。

第一段：售后 Agent 自己查事实

售后应用先判断问题需要订单事实。它的 MCP Client 从订单 MCP Server 的工具列表中看到一个“按订单号读取售后状态”的工具；该工具要求 order_id，所以应用传入 A123。服务端验证调用方有权查看这笔订单，返回签收日期、商品与售后状态。售后应用再读取政策 v3，明确“30 天内可以申请检测”，而不是“30 天内一定可以退货”。这些动作都是边界清楚的查询，用一个售后 Agent 加工具就能完成。MCP Tools、MCP Resources

若用户只问“A123 什么时候签收？”，流程至此即可结束。再启动质检 Agent 只会增加一次远程调用、权限交接、等待与状态管理，对答案没有实质帮助。

第二段：出现独立质检任务时才委托

用户继续问：“左耳杂音能认定为质量故障吗？”售后应用不能凭文字断定故障。若组织中已有独立的质检 Agent 服务，它能处理多轮故障初筛、持有自己的检测知识和工具，售后 Agent 才有理由通过 A2A 委托。一个可复述的流程是：

1. 发现并校验接收方。售后侧从已批准的地址或目录取得质检 Agent 的 Agent Card，确认其确实声明“耳机故障初筛”、所支持的通信方式与安全要求。Agent Card 是对方的声明，不能只因卡片写着“可信”就自动放行订单数据。A2A Agent Discovery
2. 限定交接材料。售后侧只发送“耳机型号、签收日期、左耳间歇杂音、咨询目标：判断是否建议申请检测”，以及任务所需的最少订单字段；不传用户完整聊天记录、支付信息或其他订单。用户对数据共享与委托范围应知情。
3. 发出任务消息。售后侧让质检 Agent 做“故障初筛并列出尚需核实的信息”。A2A 允许远端 Agent 对简单交互直接回 Message，对需要持续处理的工作回 Task；这里假设质检 Agent 回一个任务，售后侧记录其 taskId 和关联上下文的 contextId。A2A 核心概念、A2A 任务生命周期
4. 跟踪与补充。质检 Agent 发现“杂音出现条件不清楚”，把任务标为需要输入。售后侧向用户询问“只在蓝牙连接时出现，还是有线也出现？”用户答“只在蓝牙连接时”；售后侧将答案传回同一工作上下文。处理较久时，可以按双方支持的方式查询任务、接收流式更新或使用推送通知；不应靠无限循环猜测结果。A2A 任务生命周期、A2A 核心概念
5. 验收产物并回答。质检 Agent 返回初筛结论：“还不能确认质量故障；建议用户提交复现视频并申请检测。”售后 Agent 核对该结论没有越过政策 v3，再告诉用户“处于可申请检测期限内，但故障和退款结果要以检测为准”。如果远端给出了报告，报告作为 Artifact 留存并标明来源；最终面向用户的责任仍在售后应用。

A2A 的 Task 是有状态的工作单元，可处于工作中、需要输入、已完成或失败等状态；它的 Artifact 才是要交付的内容。它不要求远端 Agent 把自己的提示词、推理过程或内部工具暴露出来。调用方要管理的是委托目标、输入、状态和验收，而不是替对方逐步操控内部执行。A2A 1.0.0 规范、A2A 任务生命周期

什么时候一个 Agent 足够，什么时候拆开有益

先问三个实际问题：目标能否用已知步骤做完？有没有独立负责该工作的人或服务？分工带来的收益能否覆盖交接成本？

情况	较合适的起点	原因
查 A123 签收日、读取政策、按固定规则说明申请条件	一个 Agent + 已授权工具/资料	输入、来源和结束条件清楚；拆成多个 Agent 只增加协调
质检部门维护独立服务，需多轮追问、内部检测、数小时后提交报告	售后 Agent 委托质检 Agent	对方有独立职责、状态和结果，调用方只需跟踪与验收
同一团队代码里有两段固定处理逻辑	普通函数或 Workflow 先行	“两个模块”不自动构成两个独立 Agent，也不需要 A2A
多方独立系统各自掌握特定权限，交接需审计	多智能体与明确协议边界可能有益	可以分清谁读了什么、谁产出结论，但仍需工程化授权和审计

多 Agent 的实际收益是职责与知识边界：质检部门可以独立维护诊断能力，售后侧不必把质检所有知识和工具塞进一个大 Agent；长任务也可以按任务编号追踪。但多 Agent 并非“模型多了就更聪明”。拆得过细会造成重复模型调用、更多 token 消耗、网络延迟、上下文转述丢失、多个 Agent 意见冲突，以及更复杂的版本和权限管理。这些是架构选择的工程推论，应通过真实任务集比较完成率、成本、耗时和错误率，而不是只看演示是否顺利。

权限、失败与回退怎么设计

**权限先于委托。**售后 Agent 对订单工具只拿读取 A123 必需字段的权限；对质检 Agent 只传完成初筛所需材料。远端 Agent 的 Agent Card 告诉你它声称会什么、如何连接，不等于替你完成身份验证和业务授权。A2A 规范要求服务端按认证与授权规则保护操作；MCP 规范也要求宿主控制分享和工具调用，服务端验证工具输入与访问权限。A2A 安全章节、MCP 安全原则

**超时不能误当失败或成功。**如果售后侧发出委托后等待超时，先用已记录的 taskId 查询状态；不要直接再建一个可能重复的质检任务。若质检任务仍在处理，可向用户说明正在等待并给出后续查询方式；若远端不可达，可保留订单与政策已经核实的部分，只说“目前符合申请检测的时间条件，故障性质暂未确认”，并转人工或稍后重试。对于有副作用的后续动作，例如创建检测单，更要避免不查状态就重试，防止重复提交。A2A 任务操作与状态

**需要输入要问清楚，失败要停止传播。**质检 Agent 若返回“需要补充复现视频”，售后侧应先征得用户同意并校验文件和隐私范围，再交给远端；用户不提供时，就说明无法完成初筛。若质检返回“可以直接退款”，但政策和订单证据只支持“可申请检测”，售后侧应拒绝把该结论当最终退款承诺，并要求复核。远端 Agent 的消息和 Artifact 都是外部输入，不应被提升为高权限系统指令。

面试时怎么回答

MCP 主要解决助手应用接入外部工具、资源和提示模板的问题，常见工作单位是一次读取或一次带参数的工具调用。A2A 主要解决独立智能体之间的协作：通过 Agent Card 了解对方能力，交换 Message，复杂工作用 Task 跟踪状态并取得 Artifact。两者能组合使用，比如售后 Agent 用 MCP 查订单，再用 A2A 委托质检 Agent 做多轮初筛。是否上多智能体，要看有没有独立职责、长时任务或跨团队边界；如果只是按固定规则查库和回答，一个 Agent 加工具更简单。多智能体增加延迟、成本和权限交接，所以要限制共享数据、跟踪任务状态、校验远端结论，并设计超时和失败回退。

如果追问“把质检 Agent 包成一个 MCP Tool 行不行？”，可以回答：可以，只要对外需求真的是一次清晰的输入输出，工具包装可能更省事；若要保留独立 Agent 的多轮协商、任务状态、异步产物和跨组织自治边界，A2A 更贴合。选择依据是交互形态，不是给某个服务贴了“Agent”标签。A2A 与 MCP 官方对比

参考资料

• A2A 1.0.0 正式规范
• A2A 官方：A2A 与 MCP 对比
• A2A 官方：核心概念、任务生命周期、智能体发现
• MCP 2026-07-28 规范、架构、工具