面试日记 第 20 天

白板上，我把客服 Agent、订单 Agent 和退款 Agent 全接到一条 MCP 总线上。面试官看了两秒，直接把其中两条连线擦掉：“MCP 什么时候负责 Agent 之间协作了？”

我拿着笔解释：“它们都能暴露能力，也都能被调用。把订单 Agent 包成一个 MCP Server，不也能用吗？”

她没有否定，只把“退款 Agent”那张磁贴挪到白板另一边。

“能调用，不代表是同一种关系。数据库按参数返回结果；退款 Agent 会追问、维护自己的任务状态，还可能半小时后再交付结果。你准备把它们都当 Tool？”

这句话把图里的问题钉死了。

如果对方只是提供结构化能力，我关心的是它有哪些工具、参数怎么传、结果怎么收，这更接近 MCP。可如果对方是一个独立 Agent，我还要发现它、判断它会什么、委派任务，并持续接收状态与产物，这已经是 A2A 的工作范围。

我重新画了两层：横向用 A2A 连接三个 Agent，纵向让每个 Agent 通过 MCP 访问订单库、CRM 和知识库。

面试官点了点新图，终于把题目完整说出来：

A2A 协议 与 MCP 协议的关系是怎样的？

这次不能只背一句“它们互补”。真正要答清楚的是：谁在和谁通信，以及这次交互究竟是一次工具调用，还是两个独立 Agent 在协作。

回答重点

1. 先给出一句边界

MCP 解决的是一个 AI 应用如何标准化接入工具、资源和提示；A2A 解决的是多个独立 Agent 如何发现彼此、委派任务并交换状态与结果。两者位于不同层次，可以在同一套系统中协同工作。

2. 再用四个维度区分

对比维度	MCP	A2A
连接对象	AI 应用与 MCP Server	A2A Client Agent 与远端 Agent
能力表达	Tools、Resources、Prompts 等标准能力	Agent Card、Skill、Task、Message、Artifact 等协作信息
交互重点	列出能力、传入结构化参数、获得上下文或执行结果	发现能力、委派任务、追踪状态、流式接收过程和产物
常见对象	文件、数据库、API、搜索和业务系统	拥有独立身份、逻辑、状态与任务生命周期的专业 Agent

MCP 由 Anthropic 在 2024 年推出，协议消息基于 JSON-RPC 2.0。当前标准传输方式是本地 stdio 和远程 Streamable HTTP；早期的 HTTP+SSE 已被后者替代。MCP 采用 Host、Client、Server 架构，一个 Host 可以创建多个 Client，每个 Client 与一个 Server 保持独立连接。

A2A 最初由 Google 推出，如今已捐赠给 Linux Foundation，并发布 1.0 版本。它把独立 Agent 当作协作主体，通过 Agent Card 描述能力，并围绕消息、任务、状态和产物组织交互。它不负责规定一个 Agent 内部怎样调用工具，也不替代 MCP。

3. 最后落到组合架构

以自动化客服为例，客服 Agent 可以通过 A2A 把“核对账单”和“判断退款资格”分别委派给账务 Agent、退款 Agent；这些专业 Agent 再通过 MCP 访问 CRM、订单数据库和公司知识库。

面试里画图时可以记住一个简单方向：Agent 与 Agent 横向协作，Agent 与工具纵向连接。 这不是协议强制规定的画法，但很适合快速讲清二者职责。

扩展知识

别急着把所有远端能力都包装成 Agent

反常识的地方在于，多 Agent 不一定比 MCP Tool 更高级。

如果一项能力输入输出明确、执行时间短、无需自主规划，例如查询订单、读取文件或计算运费，把它做成 MCP Tool 通常更简单，也更容易控制权限、超时和重试。

只有当对方具备独立身份和能力描述，需要自行规划、向调用方追问、维护长任务状态，或者持续返回中间进度与最终产物时，才更像应该通过 A2A 协作的远端 Agent。

还有一种常被忽略的情况：几个子 Agent 都在同一个应用、同一个团队和同一个进程里运行。这时直接使用框架自带的编排能力可能就够了，没必要为了“协议齐全”强行引入 A2A。协议解决的是跨边界互操作，边界不存在时，多加一层只会增加认证、观测和故障处理成本。

所以项目设计时，先连续问三个问题：

1. 对方提供的是确定性能力，还是会自主推进任务的 Agent？
2. 我只需要一次结构化结果，还是要跟踪状态、追问和产物？
3. 双方是否跨团队、跨平台或跨部署边界，需要稳定的互操作协议？

第一类通常优先考虑 MCP，后两类越来越接近 A2A。真正完整的 Agent 架构，往往需要在正确的边界上同时使用两者。

面试官追问

追问：如果我想让多个智能体协作完成一个任务，应该怎么设计架构？

回答：一般有两种模式。第一种是 Orchestrator 模式，搞一个中央编排智能体，它通过 A2A 协议调度其他专业智能体，协调任务分配和结果汇总。第二种是 Peer-to-Peer 模式，智能体之间平等通信，每个智能体根据自己的能力决定是否接手任务。实际项目中 Orchestrator 模式更常见，因为控制流清晰、调试方便。每个被调度的智能体内部再通过 MCP 调用所需的工具和数据。

追问：MCP 和传统的 API 调用有什么本质区别？

回答：传统 API 调用是开发者写死的，代码里明确指定调哪个接口、传什么参数。MCP 是让 AI 模型自己决定调什么、怎么调。模型看到 MCP Server 暴露的 Tools 列表和描述，根据用户意图自己选择合适的工具并构造参数。相当于把调用决策权从开发者转移到了模型，灵活性大大提升。当然代价是模型可能选错或参数填错，所以需要 Schema 约束和权限控制。

追问：A2A 协议里智能体之间怎么保证消息不被篡改？

回答：A2A 支持多层安全机制。传输层用 HTTPS/TLS 加密，防止中间人攻击。认证层支持 OAuth 2.0、mTLS、签名 JWT 等，确保身份可信。消息层可以加签名，发送方用私钥签名，接收方用公钥验签，任何篡改都会导致签名校验失败。企业级部署一般会组合使用，mTLS 做双向认证加上 JWT 签名双重保障。

白板最后留下的是两种不同的连接关系，两套协议没有必要争同一个位置。

这道题容易把“能调用”误认为“会协作”。准备 Agent 岗位时，可以继续沿着 Agent Card、任务生命周期、MCP 权限边界和多 Agent 编排往下追，直到自己能把那两层架构完整画出来。