标题：MCP 与 A2A 协同的多 Agent 架构怎么设计：纵向供能力、横向做协作、外层做治理

先给答案：MCP 和 A2A 不需要二选一，正确的做法是把它们叠起来用 ——MCP 负责 "纵向"，让每个 Agent 用统一方式接工具、资源和提示词模板；A2A 负责 "横向"，让主控 Agent 能发现别的 Agent、把子任务派出去、跟踪任务状态、收回产物。落到一套既能面试讲清、又能真正落地的架构上，就是 "一个入口网关 + 一个主控 Agent + 一张 Agent 注册表 + 一条 A2A 协作面 + 每个专家 Agent 自己的 MCP 能力面 + 外层统一的身份、策略、审批和 Trace"。举个具体例子：用户说 "把 Q3 销售分析一下，出一份经营周报，顺便把审批发起"，主控 Agent 先拆任务，用 A2A 找到数据 Agent、报告 Agent、审批 Agent 并派单；这三个 Agent 各自用 MCP 去查数据库、读知识库、建工单，结果再沿 A2A 回给主控，主控汇总后让用户确认。这套组合在 2026 年已经是主流打法：MCP 的 2026-07-28 规范把协议核心改成了无状态、更适合放在网关和负载均衡后面，A2A 的 v1.0 在 3 月发布、5 月补丁到 v1.0.1，两个协议现在都挂在 Linux Foundation 的 Agentic AI Foundation 下，属于同一套开放底座。所以面试时真正要证明的不是 "我知道两个协议"，而是 "我知道它们各在哪一层、在哪一刻交接、交接时带什么、出了事在哪查"。

一、先把边界钉死：一个管 "够得着"，一个管 "叫得动"

MCP（Model Context Protocol）管的是 Agent 和外部能力之间的连接。它用 JSON-RPC 2.0 把工具（tools）、资源（resources）、提示词（prompts）标准化，客户端用 tools/list 列能力、用 tools/call 调工具，一个 MCP Server 写一次，所有兼容的客户端都能用，本质上解决的是 "每个模型 × 每个工具都要单独写一套适配" 的 M×N 问题。2026-07-28 这版规范做了几件对架构很关键的事：协议层不再有 initialize 握手和 Mcp-Session-Id，任何请求自带版本和客户端能力，可以随便落到一台普通的轮询负载均衡实例上；新增 server/discover 让客户端先问能力；原来服务端发起的 sampling、elicitation 改成 "多轮往返请求"（MRTR），服务端返回 resultType: input_required，客户端带着答案重试；长任务从核心协议挪进 Tasks 官方扩展，用 tasks/get 轮询、tasks/update 回填；工具名和请求方法直接进 Mcp-Method、Mcp-Name 请求头，网关可以按头路由和鉴权；列表结果带 ttlMs 和 cacheScope，可以缓存工具目录。

A2A（Agent2Agent Protocol）管的是 Agent 和 Agent 之间的协作。它假定对方可能是别的团队、别的公司、用别的框架（LangGraph、CrewAI、ADK 都行）做出来的，你不该看到它内部怎么想、用什么工具，所以它主打 "不透明执行"。核心对象就四个：Agent Card（一张 JSON 能力名片，默认放在 /.well-known/agent-card.json，也可以用注册表或预先配置拿到，v1.0 里必填 name、description、version、supportedInterfaces、capabilities、默认输入输出模态和 skills，还支持 JWS + JCS 规范化签名）；Task（有完整生命周期的任务，支持提交、执行中、需补充输入、需授权、完成、失败、取消这些状态）；Message / Part（多轮对话内容，文本、文件、结构化数据都能装）；Artifact（任务产出物）。传输上给了 JSON-RPC、gRPC、HTTP+JSON 三种绑定，语义一致，还支持 SSE 流式、webhook 推送、contextId 串多轮。

一句话对比：MCP 让一个 Agent 变 "能干"，A2A 让一堆 Agent 变 "能配合"。这两件事的边界，用一张表看得最清楚。

什么时候只用 MCP 就够了：只有一个 Agent，工具数量在几十个以内，所有工具在同一个信任域里，也不需要跨团队派活。什么时候必须加 A2A：出现了真正的服务边界 —— 不同团队独立发布 Agent、要跨公司协作、要跑几十分钟的长任务、需要多轮协商而不是一次函数调用。判断信号很朴素：当你开始想让一个 Agent"替我去找另一个 Agent 办事"，就该上 A2A 了。

二、架构怎么分层：六层，各干各的

用户 / 业务系统

│

① 入口网关（鉴权、限流、租户、根 traceId）

│

② 主控 Agent（拆任务、选人、汇总、裁决冲突）

│ ⇄ ③ 注册与发现层（Agent Registry / MCP Registry）

│

④ A2A 协作面（task、contextId、artifact、流式/推送）

│

⑤ 专家 Agent 运行时（数据 Agent / 报告 Agent / 审批 Agent / 风控 Agent）

│

⑥ MCP 能力面（MCP Gateway → 数据库 / BI / 知识库 / 工单 / 权限）

│

贯穿：身份、策略、人工审批、Trace、评估

这里有个容易被忽略的细节：网关最好是一套平台、两条策略路径。A2A 侧校验的是 "这个调用方能不能调这个 Agent 的这个技能、委派深度多少、任务能跑多久、推送地址合不合法"；MCP 侧校验的是 "这个 Agent 能不能看见这个工具、参数合不合 schema、要不要人工批准、能不能出网"。把它们当成同一种流量处理，后面一定出问题。

至于两种协议怎么接，业界总结出三种模式，面试能讲清这个层次基本就过关了。

绝大多数生产系统用的是模式①，模式②只在 "这个能力本身就是无状态、一次调用就完事" 的时候用，模式③是边缘场景。不管哪种，中间那层编排逻辑都跑不掉。

三、一次任务怎么跑通：七步链路

拿 "分析 Q3 销售 → 出经营周报 → 发起审批" 举例，链路是这样的。

1. 接入：入口网关验用户身份和租户，生成根 traceId，把 "用户是谁、能看哪些数据" 写进请求上下文，但不把权限直接塞给下游。
2. 拆解：主控 Agent 把目标拆成 "分析指标"" 生成报告 ""准备审批" 三个子任务，并给每个子任务写清完成标准、截止时间、可接受的产物类型。
3. 选人：主控去注册表按 skill、版本、信任等级、健康度筛候选 Agent，先验 Agent Card 签名，再决定用哪个；这一步是 "按契约选人"，不是 "自由聊天猜谁能干"。
4. 派单：用 A2A 发 Task，带 contextId、traceId、最小必要输入、deadline、完成标准。注意别把主控的全部上下文和全部权限一起打包过去。
5. 干活：专家 Agent 接到任务后，自己用 MCP 调工具。数据 Agent 查 db.query、读 BI 资源；报告 Agent 读知识库模板；审批 Agent 走工单 MCP，写操作要幂等键和人工确认。
6. 回传：Task 状态沿 A2A 回流，中间可能停在 "需补充输入" 或 "需授权"，这时候由主控去问用户或走审批，而不是让下游自己越权。产物带来源、置信度、生成时间。
7. 收口：主控合并产物、检查冲突（比如报告里的数字和分析产物对不上就打回重做）、给出最终交付，高风险动作留给用户点确认。

一段最小可讲的代码，比十页 PPT 有用：

// 主控 Agent：只负责编排，不碰别人的工具

const report = await a2a.send({

agent: pick(registry, { skill: "weekly_business_report", minTrust: "verified" }), // 卡片已验签

task: "generate_weekly_report",

contextId: ctx.id, // A2A 的上下文，和用户会话隔开

input: { analysis: analysisArtifact, template: "经营周报v3" }, // 只给最小必要上下文

deadline: "PT10M",

traceId,

});

if (report.state === "input-required") return askUser(report.inputRequests);

// 专家 Agent：接到任务后自己用 MCP 干活

async function handle(task) {

const metrics = await mcp.call("db.query", { sql: "weekly_sales_metrics" });

const tpl = await mcp.read("kb://finance/report-template");

return { state: "completed", artifact: render(metrics, tpl), sources: [...], confidence: 0.86 };

}

四、六个最容易翻车的点，和对应的做法

还有一条隐形的：委派深度。A 派给 B、B 又派给 C、C 再派给 D，出了问题没人说得清是谁的决定。生产上一般把委派深度卡在 2 到 3 层，超过就强制回到主控重新决策。

五、面试口述版：三句话讲完，再准备四个追问

三句话版：MCP 是纵向的能力接入层，解决 Agent 怎么标准化地用工具和数据；A2A 是横向的协作层，解决 Agent 之间怎么发现、委托、跟踪长任务、交换产物。我的架构是一个入口网关加一个主控 Agent，主控通过签过名的 Agent Card 选人、用 A2A 派单，专家 Agent 各自用 MCP 干自己的活，外层用统一身份、策略、审批和 Trace 把两层串起来。关键不是协议会不会调，而是边界清不清 ——A2A 不碰别人的工具，MCP 不假装自己是 Agent。

追问一：为什么不能只用 MCP 做多 Agent 协作？ 因为 MCP 描述的是工具、资源和提示词，没有 Agent 发现、任务生命周期、多轮协商这套语义，硬做会把 "另一个 Agent" 降级成一个函数，长任务和澄清流程没法表达。

追问二：为什么不能只用 A2A 调所有外部系统？ 数据库、文件、SaaS API 更适合被 MCP 包成 tools/resources，伪装成 Agent 只会多一层壳、多一份不确定性，还丢掉 schema 校验。

追问三：主控怎么选下游 Agent？ 按 Agent Card 的 skills、版本、信任等级、健康状态和历史质量评分筛，不靠模型自由发挥。

追问四：下游该拿多少上下文？ 最小必要，只给完成这个子任务需要的输入，敏感字段脱敏，权限按任务重新签发。

六、怎么判断这套架构是活的

把这件事收口成一句话：MCP 决定一个 Agent 能伸多远，A2A 决定一群 Agent 能走多顺，真正让系统跑得住的是夹在中间那层治理 —— 身份每跳都换、上下文只给必要的、写操作有人签字、全链路一个 traceId 查到底。面试官想听的从来不是 "两个协议都重要"，而是你能不能说清它们在哪一层握手、握手时交换什么、以及握手失败时你怎么办。

【相关 FAQ】

问题 1：MCP 和 A2A 在一个多 Agent 架构里，到底谁负责什么？

回答 1：在 MCP 与 A2A 协同的多 Agent 架构里，分工是固定的：MCP 负责纵向，把数据库、API、知识库这些能力标准化地接给单个 Agent；A2A 负责横向，让这个 Agent 能被主控发现、被派任务、被跟踪状态、把产物交回去。记住一句话就不会乱：MCP 管 "这个 Agent 会用什么"，A2A 管 "这个 Agent 去找谁一起干"。

问题 2：只用 MCP，能不能撑起一个多 Agent 架构？

回答 2：勉强能跑，但撑不久。只用 MCP 的多 Agent 架构，本质上是把 "另一个 Agent" 当成一个工具来调，缺少 A2A 提供的 Agent Card 发现、Task 生命周期、多轮澄清和长任务推送，一旦出现跨团队、跨公司或者要跑十几分钟的任务，就会退化成自己写胶水代码。所以单 Agent 阶段用 MCP 足够，出现真实服务边界时就必须补上 A2A。

问题 3：那反过来，只用 A2A 能不能替代 MCP？

回答 3：不能。A2A 擅长 Agent 之间的委托和协作，但它不负责工具级的 schema 校验、资源读取和密钥注入，把数据库、文件系统这些硬包成 Agent 再走 A2A，等于在协作层做工具层的事，多一层壳、少一层校验。健康的 MCP 与 A2A 协同方式是：A2A 在边界上跑，MCP 在边界内跑，各管一段。

问题 4：MCP 和 A2A 协同的多 Agent 架构里，主控 Agent 凭什么选下游？

回答 4：凭契约，不凭感觉。主控读的是已签名的 Agent Card，按 skills、版本、信任等级、健康状态和历史质量评分做候选筛选，再用 A2A 派单；如果卡片过期、验签失败或者能力描述和实际评测对不上，就直接换候选。这样多 Agent 架构的路由才是可解释、可审计的，而不是模型随口点一个。

问题 5：MCP 2026-07-28 改成无状态之后，A2A 那边的长任务协同会受影响吗？

回答 5：不会，反而更顺。MCP 去掉协议层会话后，每个请求自带版本和能力，MCP Server 可以像普通 HTTP 服务一样横向扩容，长任务交给 Tasks 扩展轮询；A2A 这边本来就用 Task 管生命周期，支持流式、webhook 推送和 contextId 串多轮。两边一起用，正好是 "MCP 侧无状态好扩容、A2A 侧有状态管长任务"，职责不打架。

问题 6：小团队要不要一上来就搭 MCP + A2A 的多 Agent 架构？

回答 6：不用。先上 MCP，把工具接入收干净，一个 Agent 跑通一到两条真实业务；等到出现 "不同团队独立发布 Agent"" 任务要跨系统跑很久 ""需要多轮协商" 这些信号，再引入 A2A。多 Agent 架构的成本不在协议调用，而在注册表、身份、审批、Trace 这些治理件，早搭等于早背包袱。

【参考资料】

[2026-11-14]（2026AI 面试题：MCP 协议和 A2A 协议如何协同工作？请设计一个同时使用两者的多 Agent 系统架构）阿里云开发者社区

[2026-10-30]（Introduction – agentgateway：MCP 与 A2A 流量的统一网关）agentgateway 官方文档

[2026-10-27]（Third-party agents can now interoperate with SAP Agents via the Agent Gateway）SAP Architecture Center

[2026-10-26]（A2A 协议规范 – Agent2Agent 协议）Agent2Agent Protocol 社区

[2026-10-25]（A2A Agent Card：结构、发现与签名）Agent2Agent Protocol 社区

[2026-10-20]（A2A and MCP：横向协作与纵向接入的分工）A2A Protocol 官网

[2026-08-27]（A New Chapter for A2A: Joining the Agentic AI Foundation）A2A Protocol Blog

[2026-08-22]（The New MCP Roadmap）Model Context Protocol Blog

[2026-08-21]（How to Combine MCP and A2A in One Enterprise Agent Architecture）Digital Thought Disruption

[2026-07-28]（The 2026-07-28 Specification：无状态核心、MRTR 与 Tasks 扩展）Model Context Protocol Blog

[2026-07-06]（Multi-agent patterns：MCP 与 A2A 的适用边界）Microsoft Learn

[2026-04-09]（A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year）Linux Foundation

阿里云开发者社区A2A ProtocolModel Context ProtocolLinux FoundationMicrosoft LearnAgent2Agent ProtocolSAP Architecture CenterDigital Thought Disruption免责声明：本文为技术方案梳理与面试答题思路整理，不代表 Anthropic、Google、Linux Foundation 或任何厂商的官方口径；MCP 与 A2A 的字段、状态机和版本细节以官方规范最新发布为准，文中架构为通用设计示例，落地前需结合企业自身的身份体系、数据分级、审批流程和合规要求做二次评估；生态数据与版本信息截至 2026-11-14，后续变化请以官方公告为据。