题目分类
- 方向：Agent 架构 / MCP 与 A2A 协议协同设计
考察点
- 能否准确区分 MCP 与 A2A 的职责边界：MCP 连接工具、资源和提示模板，A2A 连接 Agent 与 Agent
- 能否把两者设计成分层架构，而不是把 MCP Server、工具和远程 Agent 混成一类能力
- 能否设计一个主控 Agent、专家 Agent、Agent Registry、MCP Server、权限与 Trace 组成的多 Agent 系统
- 能否讲清一次任务从用户请求、Agent 发现、任务委托、工具调用、结果回传到汇总交付的链路
- 能否识别生产风险：权限扩散、上下文泄露、工具误用、Agent 描述失真、跨 Agent 错误传播和重复副作用
- 能否提出治理策略：Agent Card 审核、最小权限、上下文裁剪、审批、幂等、超时重试、审计和评估
知识讲解
1. 两个协议解决的是不同层的问题
MCP 和 A2A 不应该被理解成竞争关系。MCP 的核心是让一个 AI 应用或 Agent 以标准方式连接外部能力，比如 tools、resources、prompts；A2A 的核心是让不同 Agent 之间能够发现彼此、理解能力、委托任务、交换消息和返回结果。
换句话说，MCP 更像“Agent 向下接工具和上下文”的协议，A2A 更像“Agent 横向找其他 Agent 协作”的协议。一个数据分析 Agent 可以通过 MCP 连接数据库、BI 系统和指标文档；同时它也可以通过 A2A 被主控 Agent 发现并委托“分析销售数据”这个任务。
面试里最关键的判断是：MCP 解决能力接入标准化，A2A 解决 Agent 协作标准化。两者组合起来，才比较像一个可扩展的多 Agent 生态。
图解 1：下面这张图展示 MCP 和 A2A 的分层关系：A2A 管 Agent 之间的协作，MCP 管每个 Agent 接入外部工具和资源。
2. 什么时候需要同时使用 MCP 和 A2A
如果系统只有一个 Agent，只是需要访问文件、数据库、浏览器或企业 API，通常 MCP 就足够了。它能把外部能力包装成标准 Server，让 Agent 或 Host 发现并调用。
如果系统有多个专业 Agent，比如数据分析 Agent、合同审核 Agent、代码审查 Agent、客服 Agent，且它们可能由不同团队、不同服务或不同运行时实现，这时就需要 A2A 来处理 Agent 发现、能力描述、任务委托、状态流转和结果交付。
同时使用两者的典型场景是复杂业务任务：用户提出一个跨系统目标，主控 Agent 需要先拆解任务，再通过 A2A 找到合适的专家 Agent；专家 Agent 接到任务后，再通过 MCP 调用自己的工具和资源完成子任务；最后把结果通过 A2A 回传给主控 Agent。
比如“分析销售数据，生成经营周报，并创建审批任务”：主控 Agent 负责规划和编排；数据分析 Agent 用 MCP 读数据库和 BI 指标；报告 Agent 用 MCP 读知识库并生成文档；审批 Agent 用 MCP 创建工单或审批流；这些专家 Agent 之间和主控 Agent 之间用 A2A 交换任务和结果。
3. 一个同时使用两者的系统架构
一个稳妥的架构可以分成五层。
第一层是 Host 和主控 Agent。Host 承接用户输入、权限体验和最终交付，主控 Agent 负责理解目标、拆分子任务、选择协作者、合并结果和控制高风险动作。
第二层是 Agent Registry。它保存或索引各个远程 Agent 的 Agent Card，包括 Agent 名称、描述、endpoint、skills、capabilities、版本和安全要求。主控 Agent 不应该靠自由聊天猜谁能做事，而应该基于 Agent Card 做候选筛选。
第三层是 A2A 协作层。主控 Agent 通过 A2A 把子任务委托给数据分析 Agent、报告 Agent、审批 Agent 等专家 Agent，并接收它们的 task state、message、artifact 或最终结果。A2A 负责的是 Agent 之间的协作协议，而不是直接连数据库或文件系统。
第四层是每个专家 Agent 自己的 MCP 能力接入层。数据分析 Agent 连接数据库 MCP Server、BI MCP Server；报告 Agent 连接文档 MCP Server、知识库 MCP Server；审批 Agent 连接工单 MCP Server、权限 MCP Server。每个 Agent 只拿自己完成任务所需的工具和资源。
第五层是治理与观测层。包括身份认证、权限隔离、上下文裁剪、敏感信息脱敏、写操作审批、幂等键、超时重试、审计 Trace、质量评估和人工接管。没有这一层，多 Agent 系统很容易从“协作”变成“错误扩散”。
图解 2：下面这张图展示一个同时使用 MCP 与 A2A 的多 Agent 系统架构。
4. 端到端任务链路怎么走
以“分析销售数据，生成经营周报，并创建审批任务”为例，链路可以这样走。
第一步，用户在 Host 中提交目标。主控 Agent 识别出任务包含数据分析、报告生成和审批创建三个子任务，并判断审批创建是高风险写操作，需要用户确认或业务审批。
第二步，主控 Agent 查询 Agent Registry，读取候选 Agent 的 Agent Card。它根据 skills、capabilities、安全要求、版本和健康状态选择数据分析 Agent、报告 Agent 和审批 Agent。
第三步，主控 Agent 通过 A2A 把子任务发给数据分析 Agent。数据分析 Agent 在自己的 Runtime 内通过 MCP 调用数据库和 BI Server，拿到指标、趋势和异常解释。它不应该把数据库账号或全量数据暴露给主控 Agent，只返回经过裁剪的分析结果、来源和必要 artifact。
第四步，主控 Agent 把分析结果通过 A2A 交给报告 Agent。报告 Agent 通过 MCP 读取报告模板、历史周报和知识库资料，生成周报草稿，并把文档 artifact 回传。
第五步，主控 Agent 准备审批动作，先生成预览和风险说明。用户确认后，审批 Agent 才通过 MCP 调用工单或审批系统。写操作要带幂等键、审批记录和审计日志，避免重试时重复创建。
第六步，主控 Agent 汇总最终结果：周报草稿、数据依据、审批任务状态和未完成风险，并把每一步的 Agent、工具、参数摘要和结果写入 Trace。
5. 关键边界和工程风险
第一个风险是把远程 Agent 当成本地工具。工具通常是明确参数和返回的能力，Agent 则有自己的状态、策略、工具、记忆和权限边界。通过 A2A 调用 Agent 时，委托的是任务，不是直接执行一个函数。
第二个风险是权限扩散。主控 Agent 如果把完整上下文、用户凭证或所有业务数据都发给下游 Agent，就会造成越权和数据泄露。正确做法是最小必要上下文：每个专家 Agent 只拿完成子任务需要的输入，并且敏感字段要脱敏。
第三个风险是能力描述失真。Agent Card 写得太泛，比如“可以处理所有业务问题”，主控 Agent 很容易路由错误。skills 应该具体描述任务边界、输入输出、限制和示例，并通过评估集验证路由效果。
第四个风险是错误传播。数据分析 Agent 给出错误指标，报告 Agent 可能继续基于错误结果生成周报，审批 Agent 又可能创建错误任务。所以跨 Agent 的 artifact 要带来源、版本、置信度和校验状态；主控 Agent 要能在关键步骤做验证、回滚或人工确认。
第五个风险是重复副作用。A2A 任务可能超时、重试或状态不一致，MCP 写操作又可能创建真实业务记录。只要涉及发邮件、创建审批、修改数据、发起支付，都必须有幂等键、审批、审计和取消或回滚策略。
6. 如何评估架构是否设计合理
评估时不能只看“任务最终有没有完成”。多 Agent 系统还要看拆解是否正确、Agent 选择是否准确、A2A 任务状态是否可追踪、MCP 工具调用是否符合权限、跨 Agent 上下文是否最小化、结果是否可解释。
常见指标包括：任务成功率、Agent 路由准确率、子任务失败率、平均协作轮数、A2A 调用延迟、MCP 工具错误率、权限拒绝率、重复写操作拦截率、人工审批率、上下文泄露事件、artifact 可追溯率和单位任务成本。
测试集也要覆盖复杂失败场景：找不到合适 Agent、Agent Card 过期、下游 Agent 超时、MCP Server 权限不足、工具结果过大、报告生成引用错误数据、审批任务重复创建、外部内容带 Prompt Injection、以及某个专家 Agent 返回低置信结果。
代码示例
下面是一个简化的 TypeScript 伪代码，展示主控 Agent 如何用 A2A 委托子任务，并让专家 Agent 在内部通过 MCP 完成工具调用。代码重点是表达边界，不绑定具体 SDK。
type AgentCard = {
name: string;
endpoint: string;
skills: string[];
version: string;
securityLevel: "internal" | "restricted";
};
type TaskResult = {
status: "completed" | "needs_approval" | "failed";
artifact?: unknown;
sources?: string[];
confidence?: number;
};
async function selectAgent(registry: AgentCard[], requiredSkill: string) {
const candidates = registry.filter((agent) => agent.skills.includes(requiredSkill));
if (candidates.length === 0) throw new Error(`No agent supports ${requiredSkill}`);
return candidates[0];
}
async function runBusinessReport(userGoal: string, registry: AgentCard[]) {
const traceId = crypto.randomUUID();
const dataAgent = await selectAgent(registry, "sales_analysis");
const reportAgent = await selectAgent(registry, "weekly_report");
const approvalAgent = await selectAgent(registry, "approval_ticket");
const analysis = await callA2A(dataAgent.endpoint, {
traceId,
task: "analyze_sales_metrics",
input: { goal: userGoal },
contextPolicy: "minimum_required",
});
assertCompleted(analysis);
const report = await callA2A(reportAgent.endpoint, {
traceId,
task: "generate_weekly_report",
input: { analysis: analysis.artifact, sources: analysis.sources },
contextPolicy: "minimum_required",
});
assertCompleted(report);
const approvalPreview = await callA2A(approvalAgent.endpoint, {
traceId,
task: "prepare_approval_ticket",
input: { report: report.artifact },
idempotencyKey: `approval:${traceId}`,
requireHumanApproval: true,
});
return { traceId, report: report.artifact, approvalPreview };
}
async function dataAnalysisAgentHandler(task: unknown): Promise<TaskResult> {
const metrics = await callMcpTool("database.query", {
sqlName: "weekly_sales_metrics",
});
const dashboard = await callMcpResource("bi.dashboard://sales-weekly");
return {
status: "completed",
artifact: summarizeMetrics(metrics, dashboard),
sources: ["database.weekly_sales_metrics", "bi.dashboard.sales-weekly"],
confidence: 0.86,
};
}
代码讲解
runBusinessReport 代表主控 Agent 的编排逻辑。它先从 Agent Registry 里按 skills 选择专家 Agent，再通过 callA2A 委托子任务。这里的 A2A 调用传的是任务、上下文策略、traceId 和必要输入，不是把所有用户上下文和系统权限都转交给下游 Agent。
dataAnalysisAgentHandler 代表专家 Agent 内部的执行逻辑。它接到 A2A 子任务后，自己通过 MCP 调用数据库工具和 BI 资源。这个边界很重要：A2A 用来 Agent 间协作，MCP 用来 Agent 接外部工具和上下文。
代码里还体现了几个生产要点：traceId 用来串起跨 Agent 和跨工具链路，contextPolicy 提醒下游只拿最小必要上下文，idempotencyKey 用来防止审批创建这类写操作重复执行，requireHumanApproval 表示高风险动作不能由 Agent 自行完成。
真实系统还要补上认证授权、Agent Card 版本校验、超时取消、重试策略、结果 schema 校验、敏感字段脱敏和失败降级。面试时不需要写完整框架，但要讲清楚协议边界和治理边界。
面试回答
我的核心判断是：MCP 和 A2A 不是二选一，MCP 解决 Agent 向下连接工具、资源和提示模板的问题，A2A 解决 Agent 之间发现、委托任务、交换状态和返回结果的问题。一个偏外部能力接入，一个偏多 Agent 协作。
如果设计一个同时使用两者的系统，我会把它分成几层。最上面是 Host 和主控 Agent，负责接收用户目标、拆任务、选协作 Agent、合并结果和处理审批。旁边有一个 Agent Registry，保存各个远程 Agent 的 Agent Card，包括 skills、endpoint、版本和安全要求。主控 Agent 根据 Agent Card 通过 A2A 把子任务委托给专家 Agent，比如数据分析 Agent、报告 Agent、审批 Agent。
每个专家 Agent 内部再通过 MCP 接自己的工具和资源。数据分析 Agent 用 MCP 连接数据库和 BI 系统，报告 Agent 用 MCP 连接文档系统和知识库，审批 Agent 用 MCP 连接工单或审批系统。这样 A2A 是 Agent 和 Agent 之间的横向协作层，MCP 是每个 Agent 向下接工具和上下文的能力层。
以“分析销售数据，生成经营周报，并创建审批任务”为例，主控 Agent 先拆成三个子任务，通过 Agent Card 找到合适的专家 Agent；数据分析 Agent 通过 MCP 查数据库和 BI，返回带来源的分析 artifact；报告 Agent 基于分析结果和模板生成周报；审批 Agent 在用户确认后通过 MCP 创建审批任务。最终主控 Agent 汇总周报、数据依据和审批状态。
生产上我会重点控制几个风险：下游 Agent 只能拿最小必要上下文，不能继承主控 Agent 的全部权限；Agent Card 要可信、可版本化、可评估，不能写得过于泛化；MCP 写操作要有审批、幂等、审计和回滚；跨 Agent 结果要带来源、置信度和 Trace，避免错误在多个 Agent 间放大。评估时看任务成功率、Agent 路由准确率、MCP 工具错误率、权限拒绝率、重复副作用拦截率和 artifact 可追溯率。
面试官追问
- 为什么不能只用 MCP 做多 Agent 协作？
- 回答方向：MCP 主要描述工具、资源和提示模板，不负责远程 Agent 的任务状态、协作语义和 Agent Card 发现。
- 为什么不能只用 A2A 调所有外部系统？
- 回答方向：外部数据库、文件、SaaS API 更适合通过 MCP 暴露为 tools/resources，而不是伪装成 Agent。
- 主控 Agent 如何选择下游 Agent？
- 回答方向：基于 Agent Card 的 skills、capabilities、版本、安全要求、健康状态和历史质量评估。
- 下游 Agent 应该拿到多少上下文？
- 回答方向：最小必要原则，只给完成子任务所需输入，敏感字段脱敏，避免权限和隐私扩散。
- 如何处理跨 Agent 任务失败？
- 回答方向：A2A 任务状态要可追踪，支持超时、取消、重试、降级、人工接管和部分结果回传。
- 写操作为什么要特别治理？
- 回答方向：跨 Agent 重试可能导致重复发信、创建工单或改数据，必须有幂等键、审批、审计和回滚。
高分回答要点
- 能明确说出 MCP 管工具/资源/提示模板接入，A2A 管 Agent 发现、委托、消息和任务状态
- 能设计分层架构：Host、主控 Agent、Agent Registry、专家 Agent、MCP Server、治理层
- 能讲清 A2A 横向协作、MCP 纵向能力接入的组合方式
- 能给出端到端链路：用户目标、Agent Card 发现、A2A 委托、MCP 调工具、结果回传、汇总交付
- 能覆盖最小上下文、权限隔离、Agent Card 治理、写操作幂等、Trace 和人工审批
- 能用路由准确率、任务成功率、工具错误率、权限拒绝率和 artifact 可追溯率评估系统
常见扣分回答
- 把 MCP 和 A2A 说成互相替代，不知道它们解决的是不同层的问题
- 把远程 Agent 当成普通工具，忽略 Agent 自身状态、能力边界和协作协议
- 让主控 Agent 把完整上下文和权限直接传给所有下游 Agent
- 只画组件图，不讲任务链路、失败处理、权限、幂等和 Trace
- 忽略 Agent Card 描述失真、版本漂移和跨 Agent 错误传播
项目结合话术
我设计这类系统时，会把 A2A 放在 Agent 协作层，把 MCP 放在能力接入层。主控 Agent 通过 Agent Registry 读取 Agent Card，选择合适的专家 Agent 并用 A2A 委托子任务；专家 Agent 只拿最小必要上下文，再通过自己的 MCP Server 访问数据库、文档、工单或知识库。全链路记录 traceId、Agent Card 版本、A2A 任务状态、MCP 工具参数摘要、权限决策、artifact 来源和审批记录，这样才能排查是路由错、Agent 能力不足、MCP 工具失败，还是跨 Agent 上下文传递出了问题。