2026年最新AI agent面试（03）_工具协议MCP_A2A_FC

大家好，我是浩哥，这是我输出AI agent面试专题第三章，后面还有七期。建议加入粉丝，后面粉丝可见。

*

导语：本题型是 2025-2026 Agent 面试最热考点，考察对工具调用范式与协议生态（MCP/A2A/Skill）的本质理解与选型能力。底层主线是「Function Calling 是调用语言 → MCP 把工具做成标准化服务 → Skill 把用工具完成任务的流程封装成模块 → A2A 让多个 Agent 横向协作」，四者分处不同层次、相互依赖而非竞争。面试官最爱挖的雷区有三个：把 MCP 当框架/当 Function Calling 升级版、把 Skill 当 prompt 模板、把 A2A 当 MCP 竞品。

• 2026年最新AI agent面试（01）_Agent基础与推理范式

• 2026年最新AI agent面试（02）_MultiAgent与记忆

• 2026年最新AI agent面试（03）_工具协议MCP_A2A_FC

• 2026年最新AI agent面试（04）__工具工程网关外部

• 2026年最新AI agent面试（05）_RAG基础应用

• 2026年最新AI agent面试（06）_RAG文档与检索

• 2026年最新AI agent面试（07）_大模型架构基础

• 2026年最新AI agent面试（08）_大模型训练评测

• 2026年最新AI agent面试（09）_AI编程ClaudeCode

• 2026年最新AI agent面试（10）_通信与行业动态

总目录可见 2026年最新AI agent面试（0）概述篇

Q1. 什么是 MCP？讲讲它的核心内容、组成与架构 ［来源：字节、腾讯、百度一面］

• 核心答案：MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年底推出的开放协议，目标是为「AI 应用 ↔ 外部工具/数据」建立一套统一的行业标准接口，本质是解决工具接入的碎片化、难复用、强绑定问题。在 MCP 出现前，每个工具、每个模型都是一座孤岛，接一个新工具就要单独写适配代码、处理认证、转换格式，且和具体模型强绑定；MCP 把这件事标准化——工具提供方按协议实现一个独立运行的 Server，任何支持 MCP 的 Host/Client 连上来即可自动发现并使用其中的能力，做到「实现一次、到处复用」。

• 核心答案（架构视角）：MCP 不是框架、不是 Function Calling 的升级版，而是建立在 Function Calling 之上的「工具生态层」抽象。它的价值可以类比 USB 接口标准（或 JDBC）：设备厂商只需做一次适配，所有兼容设备都能即插即用。协议本身只定义通信契约，不绑定任何特定模型、框架或编程语言，体现了「面向协议编程」的工程思想。

• 关键点 / 展开：

  1. 角色架构（三个角色）：① Host = 宿主 AI 应用（如 Claude Desktop、Cursor、Windsurf），是调度中心，负责启动/管理 Client、决定连哪些 Server；② Client = Host 内部的连接模块，一个 Client 对应一个 Server 连接，负责初始化连接、能力发现（list_tools/resources/prompts）、转发调用请求并取回结果，Host 本身不直接和 Server 说话；③ Server = 工具提供方实现的独立进程，对外暴露能力，不关心上层是哪个 Host。一个 Host 可同时连多个 Server，模型因此同时拥有多套工具能力，应用代码零改动。
  2. 能力类型（三类，职责互斥）：① Tools（工具）= 有副作用的操作（创建文件、提交代码、调 API、发消息），执行会改变外部状态、往往不可逆，通常需用户授权，对应 Function Calling 里的「函数」；② Resources（资源）= 只读数据（读日志、查数据库、取文档），无副作用，可更宽松暴露，类比「工具的资料室」；③ Prompts（提示模板）= 带参数占位符的预定义提示词模板，解决重复手写 prompt 问题，适合团队最佳实践共享。记忆口诀：Tools 改变世界、Resources 观察世界、Prompts 结构化表达。
  3. 协议层（消息格式 + 传输方式，两者解耦）：消息格式统一用 JSON-RPC 2.0（轻量 RPC，JSON 易读易调试、语言无关，定义请求/响应/通知）；传输方式支持 stdio 与 Streamable HTTP 两种（详见 Q5）。早期 2024-11-05 规范的「HTTP + SSE」双端点方案已在 2025 年 3 月规范更新中被标记 deprecated，新项目应直接用 Streamable HTTP。
  4. 与模型的关系：MCP Client 拉取 Server 的工具定义后，会将其转换为模型原生的 Function Calling 格式传给模型；模型视角完全感知不到 MCP 存在，只当自己在做普通 Function Calling。因此 MCP 底层依赖 Function Calling，模型不支持 FC 则 MCP 完全不可用。

• 常见追问：

  1. Host 和 Client 是同一个东西吗？为什么协议要拆成两个角色？（答：不同——Host 是应用整体、Client 是 Host 内每 Server 一个的连接模块，解耦后 Host 可并发管理多个 Server。）
  2. Tools 和 Resources 为什么不能合并成一个「能力」？区分的意义在哪？（答：副作用与否直接决定授权策略与暴露范围，混同会要么过度授权、要么限制能力。）

• 2026 延伸：Anthropic MCP 规范（2024-11-05 初版；2025-03 修订引入 Streamable HTTP、deprecate HTTP+SSE）；三类能力 Tools/Resources/Prompts 为协议原生定义；JSON-RPC 2.0 为底层消息格式。

Q2. 什么是 Function Calling？它的原理与完整调用流程是什么？ ［来源：鹅厂一面］

• 核心答案：Function Calling 是让 LLM 从「只会生成自然语言」升级为「能触发外部动作」的机制。开发者用 JSON Schema 把工具描述成「说明书」传给模型；模型判断需要工具时不输出自然语言，而是输出结构化的 tool_calls JSON，声明「调哪个函数、参数是什么」；宿主代码解析这段 JSON 真正执行，把结果以 role: "tool" 消息塞回对话，模型再生成最终答案。其本质是 「两轮对话 + 中间执行」的闭环，最关键的分工是：模型全程只做决策，执行一律由宿主代码完成——模型没有联网、没有直接执行代码的能力。

• 关键点 / 展开：

  1. 历史与痛点：由 OpenAI 于 2023 年推出，现 Claude / Gemini / Qwen 等主流模型均支持。此前只能靠 if/else 解析自然语言意图（如「我需要查北京天气」），极脆弱、无法标准化；FC 把「意图」固定成可解析的结构化 JSON，准确率与可对接性大幅提升。
  2. 三个角色（任务委托隐喻）：开发者 = HR，写工具 schema「职位说明书」；模型 = 经理，读说明后决策「调哪个函数、填什么参数」并下达指令；宿主代码 = 员工，真正跑函数、访问网络、查库。模型只下指令不执行。
  3. Schema 写法要点：最关键字段是 description——模型决策「要不要调、参数怎么填」唯一依赖的就是这段描述，写得含糊模型就瞎猜（如只写「获取天气」会导致城市/时间跨度误用）；参数 description、格式、示例值、限制条件都要写清。
  4. 完整调用流程：① 第一轮把 tools 列表 + 用户问题一起传给模型；② 模型若需调工具，返回 finish_reason="tool_calls"，内含函数名与参数（明确信号「还没准备好给答案」）；③ 中间执行：代码解析 tool_calls、跑函数、拿结果；④ 第二轮把结果以 tool 角色消息塞回历史再调模型，模型给出最终自然语言答案。tool_choice="auto" 让模型自判，"required" 可强制调。
  5. 并行调用：模型可对「北京和上海天气」一次性输出多个 tool_calls，宿主并行执行——这要求训练数据覆盖并行场景，否则模型只会串行。

• 常见追问：

  1. 模型输出的 tool_calls 是直接执行的吗？（答：否，必须经过宿主代码解析与校验/授权后执行，模型不触网。）
  2. tool_choice 设 required 但用户问题其实不需要工具会怎样？（答：会强制产生一次无意义调用，反而降低体验，故一般默认 auto。）

• 2026 延伸：OpenAI Function Calling（2023 首发），主流模型（GPT-4o、Claude、Gemini、Qwen）均原生支持 tool_calls 输出格式与 tool 消息回传约定。

Q3. 大模型的 Function Calling 能力是怎么训练出来的？ ［来源：快手二面］

• 核心答案：Function Calling 不是预训练自然获得的（预训练语料里几乎没有「给定 schema → 输出标准 JSON」的成对样本，它只学到「预测下一个 token」），必须靠专项微调补齐。核心分两个阶段、解决两类不同问题：SFT 教会「怎么调」（模仿正确的调用流程），RLHF 教会「什么时候调」（对齐该不该调的边界感）。一句话总结：SFT 教格式与流程，RLHF 教决策与克制。

• 关键点 / 展开：

  1. 为什么预训练学不会：即使 GPT-4，未经工具调用专项训练，遇到「北京天气」最多输出「我需要查询天气数据」（描述意图），而不会输出可被程序解析执行的结构化 JSON——这两件事有本质差距。预训练权重里没有「遇天气问题就输出固定格式 tool_calls」的统计经验。
  2. 阶段一 SFT（学会怎么调）：构造「含完整工具调用流程的对话样本」——system 注入工具定义、user 提问、assistant 输出结构化 tool_calls JSON（正确答案）、tool 返回执行结果、assistant 再基于结果给最终答案。模型通过反向传播模仿整套链路。
  3. SFT 训练数据必须覆盖的场景：① 单工具调用；② 多工具并行调用；③ 工具调用失败后的识别与重试/换路；④ 不需要调工具、直接回答（防止「遇事就调」的惯性）；⑤ 多轮对话中的工具调用（正确引用历史结果）。缺哪类就在哪类翻车。
  4. 训练数据来源：① 人工标注（质量高、成本极高，只用于核心种子数据）；② 模型自动生成（Self-Instruct / Distillation，用已具备 FC 能力的强模型如 GPT-4 批量产样本再人工抽查）。隐患是「蒸馏幻觉传递」——上游错样本会被下游学进去，故抽查不能省。
  5. 阶段二 RLHF（对齐该不该调）：SFT 样本全是「正确调用」正例，模型易偏激、遇事就调。RLHF 四步：生成多样回答 → 人类标注排序（如「1+1」直接答排第一、调计算器排末位）→ 训奖励模型 RM（专门打分裁判）→ PPO 强化学习调主模型。PPO 之所以常用，一是稳定不易崩，二是内置 KL 散度约束防止模型为讨好奖励而退化成套话怪胎。

• 常见追问：

  1. 为什么 SFT 之后还要 RLHF，不能只靠更多 SFT 样本？（答：固定正例无法覆盖「何时该直接答」的无限边界，RLHF 用人类偏好信号对齐边界感。）
  2. 蒸馏生成 FC 训练数据有什么风险，怎么缓解？（答：幻觉传递，靠人工抽查质量兜住。）

• 2026 延伸：训练范式采用 SFT + RLHF（PPO）；业界主流用 Self-Instruct / 模型蒸馏（Distillation）扩数据，参考 OpenAI GPT-4 等强模型作为种子生成器。

Q4. Function Calling 与 MCP 的区别是什么？实际场景该如何选型？ ［来源：小红书、京东三面］

• 核心答案：两者不是竞争关系、不属同一层次。Function Calling 是「调用语言」，定义模型怎么表达「我要调哪个函数、参数是什么」；MCP 是「工具生态协议」，定义工具怎么标准化打包、注册、被自动发现与跨项目复用，且底层仍靠 Function Calling 驱动（Client 把 MCP 工具定义转成 FC 格式喂模型）。类比：FC 像 HTTP 请求格式，MCP 像 REST API 设计规范 + 服务注册发现机制。选型核心问题只有一个：这个工具会不会在这个应用之外被用到？ 会，则封装成 MCP Server 更长远；只用自己、只用一次、不需复用，Function Calling 更直接。

• 关键点 / 展开：

  1. 抽象层次差异：FC 管「一次函数调用请求长什么样」，MCP 管「一堆工具怎么被组织、发现、跨项目复用」。FC 本身没有工具管理/发现/跨平台兼容概念，每次都是一次性手工对接；MCP 把工具做成独立标准化服务，谁要谁来连。
  2. Function Calling 适用场景（轻量/临时/不需复用）：① 快速原型 Demo（搭 Server 成本可能超过原型价值）；② 工具只为单一应用服务、绝不被别处用；③ 需对执行逻辑做精细控制（鉴权、参数二次处理、链路追踪，内嵌代码更方便）；④ 部署环境受限（Serverless 不允许起子进程，stdio 不可用，只能退回 FC）。
  3. MCP 适用场景（复用/规模/Agent）：① 工具需跨项目跨团队复用（同套 GitHub 工具，Claude/Cursor/CI Agent 共享，接口一变只改 Server 一处）；② 社区已有现成 MCP Server（GitHub/Slack/PostgreSQL/Puppeteer/Maps），直接配置即用、别重复造轮子；③ 工具规模上来（复杂度高、多人维护、接口常变），散落代码的维护泥潭用自动发现化解；④ 构建 Agent 系统（工具来源多、数量大，MCP 让工具模块化、核心逻辑解耦）。
  4. 选型判断顺序：① 看社区有没有现成 MCP Server（有就直接用）；② 看是否需跨项目/多人复用（需则 MCP）；③ 综合看工具数量/复杂度/团队规模/变更频率（到「散乱拐点」就上 MCP）；④ 看是正式 Agent 系统还是 Demo（正式选 MCP、Demo 用 FC）；⑤ 查部署环境限制（禁子进程则 FC）。
  5. 误区提醒：不能说「MCP 取代 FC」——FC 是 MCP 的底层驱动，缺 FC 则 MCP 翻译层失效；也不能说「两者只差写法」——抽象层次完全不同。

• 协议定位对比表（四者一览）：

• 常见追问：

  1. 既然 MCP 底层用 FC，那 MCP 相比直接在代码里写 FC 多付出了什么？（答：多一层 Host/Client/Server 进程与协议转换开销，换来复用性、自动发现与解耦。）
  2. 只有 1 个工具也值得上 MCP 吗？（答：看是否复用/社区有无现成 Server，单纯单应用单工具用 FC 更轻。）

• 2026 延伸：Anthropic MCP（2024 底）；社区现成 Server 生态（GitHub、Slack、PostgreSQL、Puppeteer、Google Maps 等官方/社区 MCP Server）；MCP 底层依赖模型原生 Function Calling。

Q5. MCP 协议通常采用什么通信方式？底层消息格式是什么？ ［来源：小米三面］

• 核心答案：MCP 的消息格式统一为 JSON-RPC 2.0（定义「调哪个方法、参数是什么、请求 ID 多少」，Server 回 result 或 error，靠 ID 匹配），传输方式只影响「怎么传」、与消息协议解耦。传输方式有两种：① stdio（标准输入输出）——本地场景，Server 作为子进程由 Client 启动，通过操作系统管道通信，不经网卡、延迟极低、无端口无网络安全问题；② Streamable HTTP——远程场景，Server 作为独立 HTTP 服务部署，单个 /mcp 端点 POST 收发，简单操作回普通 JSON、长操作升级为 SSE 流推送。早期「HTTP + SSE」双端点方案已于 2025-03 规范被标记 deprecated（保留兼容）。注意：MCP 并不用 WebSocket。

• 关键点 / 展开：

  1. 为什么选 JSON-RPC 2.0：本质是 RPC（Client 调 Server 方法、Server 回结果），JSON-RPC 轻量、JSON 易读易调试、语言无关，Python/TS 写的 Server 消息格式一致，无需额外序列化工具。
  2. stdio 详解：Client（如 Claude Desktop）启动时把 Server 当子进程拉起，经 stdin 发请求、从 stdout 读响应；管道是 OS 在内存分配的 FIFO 缓冲区，数据在 RAM 里走一趟即达，几乎零开销；Server 生命周期随 Client 自动管理；配置只需在 claude_desktop_config.json 里写 command + args。
  3. Streamable HTTP 详解：单端点 /mcp，Client POST JSON-RPC；Server 按需选择「普通 JSON 响应」或「SSE 流推送」。优点：Server 可云端部署、多 Client 共享（团队共用一个数据库 MCP Server）、支持跨机器。代价：多网络开销、需处理认证与断线重连。
  4. HTTP+SSE 为何被弃：旧方案 GET 端点开 SSE 收推送、POST 端点发请求，双通道导致状态管理复杂（POST 后断网，消息是否被处理、SSE 是否推回无从判断，排查链路长）。Streamable HTTP 合并为单端点，本质仍用 SSE（text/event-stream），只是端点从二合一，对负载均衡与 serverless 更友好。
  5. 关键设计原则：消息格式与传输方式解耦，是 MCP 灵活性的根本——换传输不影响上层语义。

• 常见追问：

  1. 远程 MCP 为什么不用 WebSocket 全双工？（答：MCP 用请求/响应 + 按需 SSE 流即可，无需常驻全双工连接，且 stdio 本地场景根本不走网络。）
  2. Streamable HTTP 和旧 HTTP+SSE 对 Serverless 的兼容性差异？（答：单端点更易在 serverless/负载均衡下部署。）

• 2026 延伸：MCP 2024-11-05 规范（HTTP+SSE 双端点）→ 2025-03 规范更新（Streamable HTTP 成为推荐远程传输，HTTP+SSE 标记 deprecated）；底层 JSON-RPC 2.0。

Q6. 为什么有些推理模型（如 o1/o3、DeepSeek-R1）早期不支持 MCP？ ［来源：拼多多一面］

• 核心答案：根因是生成范式冲突。推理模型会先一次性连续生成完整「思维链（thinking tokens）」再给答案，过程不能中途打断；而工具调用天然是多轮交互——输出调用请求后必须暂停等外部执行结果再继续。两者不兼容：没法在思考链跑到一半时暂停去等工具结果，否则推理上下文全断。而 MCP 底层完全依赖 Function Calling（翻译层需模型输出 tool_calls），推理模型若 FC 支持不好，MCP 自然用不了。后续工程解法是让工具调用发生在思考阶段结束之后（o3、Claude Extended Thinking 走此路；Claude 进一步提供 interleaved thinking 缓解「思考阶段感知不到工具结果」的局限）。

• 关键点 / 展开：

  1. 推理模型机制：o1/o3、DeepSeek-R1、Claude Extended Thinking 先在内部自言自语推演/验证/反驳，想清楚再出最终答案——这正是其复杂推理强于普通模型的根源。
  2. 工具调用本质是「中途暂停」：流程为「生成调用请求 → 强制暂停等宿主执行 → 拿结果 → 继续生成」。普通模型状态轻量可随时截断重起；推理模型思考链是依赖完整上下文的连续生成，中途打断则推理状态断掉、只能重来。
  3. 「保存状态再恢复」代价太大：中间状态（KV Cache）体积庞大，暂停期间占着 GPU 显存、工具执行几秒到几十秒这块显存不能给别人用，吞吐腰斩、延迟飙升，在线推理系统无法承受；且「思考中途接入工具结果」会引发思考状态一致性问题（前后推理可能矛盾、难融合）。
  4. 训练目标冲突：推理模型用 RL 大量奖励「思考链完整且结论正确」，倾向「一直想到底」；FC 训练恰好要求模型「在合适时机打断自己输出 JSON」，二者相反。混训常见失败模式：思考到一半乱跳 JSON 且格式错、思考链缩水变普通模型、或工具结果回来后推理断裂答非所问。故早期推理模型先放弃 FC 把推理做扎实。
  5. 真实版本差异：o1-preview（2024-09）明确不支持 FC（官方标注限制）；正式版 o1（2024-12）已加 FC；DeepSeek-R1 早期工具调用极弱。非「懒得适配」，而是结构性工程取舍。
  6. 传导关系：不支持 FC → MCP 翻译层失效（工具定义无法转 FC 格式、模型无法生成 tool_calls）→ 整条链路从中间断开，故「不支持 FC 即不支持 MCP」。

• 常见追问：

  1. 上下文窗口不够是不是主因？（答：不是，核心是中途中止与生成范式冲突，窗口够也解决不了。）
  2. interleaved thinking 解决了什么、没解决什么？（答：允许多次工具调用间穿插思考，缓解「思考阶段感知不到工具结果」，但「先查数据再深度推理」类任务仍受限。）

• 2026 延伸：OpenAI o1-preview（2024-09 不支持 FC）→ o1（2024-12 支持）；DeepSeek-R1 早期弱 FC；o3 / Claude Extended Thinking（思考后调工具）；Claude interleaved thinking（交错思考）。

Q7. 什么是 Agent Skill？它的定位、结构与加载机制是什么？ ［来源：字节一面］

• 核心答案：Agent Skill（Anthropic 2025-10 推出、2025-12 开放标准）是把「指令、脚本、模板」一体化打包成可复用能力包的机制。它不是「保存好的 prompt」，而是一个文件夹：核心是 SKILL.md（YAML frontmatter 声明名字+一句话描述，正文写执行指令与步骤），可选带上 scripts/（可执行脚本）、references/（参考文档）、assets/（模板）。关键能力有二：① Agent 能自动发现它（启动只扫 name+description）；② 按需渐进式加载（相关才加载正文，用到才取资源）。它教 Agent「拿到工具后该怎么用」，是 Agent 能自己翻阅的「操作手册 + 工具箱」。

• 关键点 / 展开：

  1. 解决什么痛点：每次新对话手动贴 prompt 导致质量不稳、团队十人贴法不一无法统一标准；共享文档靠人工维护仍会版本错乱。Skill 把反复用的指令/流程/模板打包成标准模块，Agent 自己知道何时用、怎么用。
  2. 结构：code-review/SKILL.md（必有）+ scripts/check_security.py + references/review_standards.md + assets/report_template.md。SKILL.md frontmatter 声明 name 与 description，正文用 Markdown 写步骤。比普通 prompt 强在：可带可执行脚本、可版本管理、团队统一。
  3. 渐进式加载（Progressive Disclosure）三层：① 启动只加载每个 Skill 的 name+description（约 30-50 token，像看简历）；② 任务匹配时才加载 SKILL.md 正文（像翻详细资料）；③ 执行中用到模板/脚本时才取对应资源文件。避免 20 个 Skill 全塞进 context（4 万 token 起步）淹没真正任务信息。
  4. 为什么重要：context window 是 Agent 最宝贵资源，全量加载会让注意力分散、输出质量下降；渐进式加载本质是「只在需要时获取需要的知识」，与人类的「先扫目录、用时翻章节」一致。
  5. 与 Tool/Prompt 的关系：Tool（含 MCP 工具）像配的电脑/软件/权限——让 Agent「能做事」；Skill 是操作手册/SOP——教 Agent 拿到工具后按什么步骤、标准、格式完成工作流。二者互补：Tool 提供能力，Skill 提供知识与流程。

• 常见追问：

  1. Skill 和普通 prompt 模板到底差在哪？（答：自动发现 + 渐进式加载 + 可带脚本/文档/模板 + 文件夹级版本管理。）
  2. 渐进式加载省下的 context 量级大概多少？（答：20 个 Skill 全量约 4 万 token，仅加载 frontmatter 约 1 千 token，差一个数量级。）

• 2026 延伸：Anthropic Agent Skills（2025-10 推出，2025-12 发布为开放标准，允许跨 Agent 平台兼容）；SKILL.md + YAML frontmatter 为规范核心；Progressive Disclosure 为加载机制。

Q8. MCP 与 Agent Skill 的区别是什么？两者如何配合？ ［来源：百度二面］

• 核心答案：两者不是同类概念、不竞争、互补。MCP 解决「Agent 怎么获得外部能力」（把数据库/API/文件系统标准化封装成服务，让 Agent 能查数据、调接口、读写文件，是从无到有的「手」）；Skill 解决「Agent 拿到能力后该按什么流程/标准完成任务」（把知识与流程打包成可复用模块，是「操作手册」）。粒度上 MCP 是原子操作（read_file、query_database），Skill 是完整工作流（代码审查、数据分析报告）。配合方式：Skill 做编排者（定义做什么/顺序/标准），MCP 做执行者（提供每步具体工具），即「Skill 定义流程 → 流程中调用 MCP 提供的工具」。

• 关键点 / 展开：

  1. 定位差异：MCP 让 Agent 从「只会聊天」进化成「能真正干活」（一切上层能力前提）；Skill 在已有能力之上告诉 Agent「该先做什么后做什么、关注哪些维度、用什么格式输出」。类比：MCP 配电脑装软件开权限，Skill 发操作手册。
  2. 粒度差异：MCP Tool 是单个函数、模型可见完整 schema（名字/参数/返回），精确可见性让模型准确判断「该调哪个」；Skill 是粗粒度工作流，内部可能涉及多步、调多个 MCP 工具，甚至含条件分支（如「改动涉及表结构则额外做权限合规检查」）。
  3. 配合示例（代码审查）：用户说「审查这次提交」→ Agent 扫描 Skill 列表发现 code-review 匹配 → 加载 SKILL.md 流程 → 第一步调文件系统 MCP 的 read_file 读代码；第二步跑 Skill 自带 scripts/check_security.py 做安全扫描；第三步用 assets/report_template.md 模板输出结构化报告。分工清晰：Skill 定「做什么/顺序/标准」，MCP 供「具体工具」。
  4. 自动发现对比：MCP 靠 Client 连 Server 后 list 发现 Tools/Resources/Prompts；Skill 靠 Agent 扫描 SKILL.md frontmatter 的 name+description，相关才加载——机制不同但都服务于「解耦与复用」。

• 常见追问：

  1. 能不能只用 Skill 不用 MCP？（答：Skill 只定义流程，真正「动手」仍需 MCP/工具，缺工具则空有手册。）
  2. 一个 Skill 内能否跨多个 MCP Server 调工具？（答：能，Skill 是编排层，可编排任意已连 MCP Server 的工具。）

• 2026 延伸：Anthropic MCP（Tools/Resources/Prompts 三类能力）与 Agent Skills（2025-12 开放标准）为同一生态的上下两层，常协同出现在 Agent 系统中。

Q9. 什么是 A2A 协议？它和 MCP 有什么区别？ ［来源：快手、阿里］

• 核心答案：A2A（Agent-to-Agent，Google 2025 年发布）是专门解决多个 AI Agent 之间如何互相通信协作的开放协议。与 MCP 的关系是一纵一横、各管一层：MCP 是 Agent 向下连工具和数据（纵向），A2A 是 Agent 向外连其他 Agent（横向），二者互补不冲突。A2A 让一个 Agent 把子任务委托给另一个专业 Agent，接收方按自己的 Skill 声明承接，支持异步长任务与流式推送，在复杂多 Agent 系统里通常两者同用。

• 关键点 / 展开：

  1. 为什么需要多 Agent（单 Agent 天花板）：① 工具数量上限（装 100 个工具模型易混乱）；② 上下文窗口上限（搜索结果/草稿/反思很快塞满，写 SWOT 时前面趋势已被挤出注意力）；③ 专业能力边界（一个 Agent 既做代码审查又做市场分析不如专人专 Agent）。拆给专业 Agent 并行处理 + 汇总，效果远好于单 Agent 包揽。
  2. 上下文隔离收益：调度 Agent 把「行业趋势分析」委托给市场 Agent，市场 Agent 自己搜几十网页、写草稿、迭代，中间过程都在自己 context 里；做完只回几百字摘要。调度 Agent context 只多一份摘要而非几十网页原文——把调研过程压力隔离在子 Agent 内部，调度者保持轻量。
  3. Agent Card（发现机制）：每个 A2A Agent 在约定位置发布 JSON 名片（2025 规范推荐 /.well-known/agent-card.json，早期叫 agent.json），声明名字、可做的任务（Skill 列表，带示例输入）、是否支持流式、是否支持 push notification（异步回调）。调度 Agent 先取名片再决策路由，系统可插拔——新加 Agent 发名片即可被自动发现，不改调度代码。
  4. Task（一等公民）：协作基本单位。生命周期 submitted → working → completed/failed。专为长时间任务设计：调度方提交后去干别的，通过轮询或 push notification 得知完成，再去取 artifacts（文本/文件）。调度方视角干净——只交 Task、取结果，完全黑盒（不知对方用了什么工具、调了几次 LLM）。
  5. 架构本质 = Agent 的微服务化：Agent Card 像 API 文档、Task 状态机像异步消息队列、.well-known 像注册中心一条记录。每个 A2A Agent 对外就是一个 HTTP 服务，不绑定特定框架/语言，与 MCP Server「让工具成为标准化服务」理念一脉相承。

• 常见追问：

  1. A2A 和 MCP 是竞品吗，能只选一个？（答：不是竞品，方向不同——纵向连工具、横向连 Agent，复杂系统常同用。）
  2. A2A 的 push notification 解决什么问题？（答：长任务异步回调，避免调度方同步阻塞等待。）

• 2026 延伸：Google A2A（2025 发布）；Agent Card 路径 /.well-known/agent-card.json（2025 规范）/ agent.json（早期）；Task 状态机 submitted/working/completed/failed；push notification 为异步回调机制。

Q10. 综合：Function Calling / MCP / Skill / A2A 的层级关系与整体选型框架 ［来源：鹅厂二面、面试官综合题］

• 核心答案：四者是从底到顶、由内到外的三层 + 一横架构，彼此依赖而非并列竞争：① Function Calling 是最底层「调用语言」（模型怎么调函数）；② MCP 在 FC 之上做「工具标准化」（工具怎么暴露/复用）；③ Skill 在最上层做「知识与流程封装」（拿到工具后按什么流程完成任务）；④ A2A 横向连接多个 Agent（向外协作）。完整链条：Skill（定义流程）→ MCP（提供工具）→ Function Calling（模型触发调用），每一层建立在下一层之上。选型的本质是「先判层次需求，再判复用范围与部署形态」。

• 关键点 / 展开：

  1. 层级依赖（不可跳过任一层）：无 FC（手）→ 有 MCP/菜谱也调不起函数；无 MCP（厨房）→ 有手有菜谱也无厨具可用；无 Skill（菜谱）→ 有手有厨房也不知先切后炒。做菜隐喻：FC=手、MCP=厨房、Skill=菜谱。同理 A2A 是「多个厨房之间的调度网络」。
  2. 「谁和谁通信」定位：FC = 模型↔函数（单 Agent 内部、最底层调用语言）；MCP = AI Client↔工具 Server（工具标准化封装，把 FC 管理起来）；Skill = Agent↔知识模块（扫描 frontmatter、按需加载指令/脚本/模板）；A2A = Agent↔Agent（HTTP 服务 + Agent Card + Task）。
  3. 时间线演进理解：FC（2023，解决「模型触发外部调用」）→ MCP（2024 底，解决「每应用重复对接工具」）→ Skill（2025-10，解决「有工具但不知按什么流程用」）→ A2A（2025，解决「单 Agent 天花板、需多 Agent 协作」）。每层的出现都是上一层普及后的新痛点。
  4. 完整故事串联（销售数据分析）：用户问「分析近三月销售找出下滑产品线」→ Skill 层：Agent 匹配「数据分析报告」Skill，加载流程（取数→趋势分析→按模板出报告）；MCP 层：Client 已连数据库 Server 与 Python 执行器 Server，自动可知 query_database/run_python；FC 层：模型输出 tool_calls: query_database(...)、MCP Client 路由执行、结果喂回，再调 Python 执行器，最后按 Skill 模板出报告。若任务跨专业（含市场调研），则 A2A 把子任务委托给市场 Agent。
  5. 实战选型决策树：a) 是否只需单应用内调一两个工具、临时、不需复用 → 纯 Function Calling；b) 工具需跨项目/团队复用、或社区有现成 MCP Server、或工具规模大、或在做 Agent 系统 → 上 MCP；c) Agent 面对复杂任务需统一流程/标准/可带脚本 → 叠加 Skill；d) 单 Agent 上下文/专业到天花板、需多专业并行 → 引入 A2A 做多 Agent 协作（内部仍用 MCP+FC）。
  6. 面试高频雷区：把 MCP 当框架/FC 升级版、把 Skill 当 prompt 模板、把 A2A 当 MCP 竞品、以为推理模型「只是没适配 MCP」——这些都是层次认知错误，回答时要先亮明「四者不同层、互补而非替代」的框架。

• 四类协议横向对比总表：

• 常见追问：

  1. 推理模型（o1/o3）接入这套体系时哪一层先断？（答：FC 层先断→连带 MCP 不可用；Skill/A2A 编排层仍在，但底层调工具受限，需走「思考后调工具」折中。）
  2. 一个生产级 Agent 系统通常四者怎么共存？（答：单 Agent 内 Skill 编排 + MCP 提供工具 + FC 触发；跨 Agent 用 A2A，每个子 Agent 内部又各自套 MCP+FC。）

• 2026 延伸：OpenAI Function Calling（2023）；Anthropic MCP（2024-11-05 / 2025-03 Streamable HTTP）、Agent Skills（2025-10 推出 / 2025-12 开放标准）；Google A2A（2025）。四者构成 2025-2026 Agent 工具/协议生态的主干，面试常以「层级 + 选型」综合考察。

📌 本题型速记 Checklist

• MCP 定位：Anthropic 2024 底推出的开放协议，解决工具接入碎片化/难复用/强绑定，是「AI 接工具」的 USB 标准，不是框架、不是 FC 升级版。
• MCP 三层组成：角色层（Host/Client/Server）、能力层（Tools 有副作用 / Resources 只读 / Prompts 模板）、协议层（JSON-RPC 2.0 + stdio/Streamable HTTP）。
• FC 与 MCP 关系：FC 是「调用语言」、MCP 是「工具生态协议」；MCP 底层靠 FC 驱动（Client 把工具定义转 FC 格式喂模型），缺 FC 则 MCP 翻译层失效。
• 选型金句：「只用自己、只用一次、不需复用」用 Function Calling；否则优先考虑 MCP（社区有现成 Server / 跨项目复用 / 规模大 / 做 Agent 系统）。
• MCP 通信：消息格式 JSON-RPC 2.0；本地 stdio（子进程管道、零网络），远程 Streamable HTTP（单 /mcp 端点、按需 SSE）；早期 HTTP+SSE 已于 2025-03 标记 deprecated；不用 WebSocket。
• 推理模型不支持 MCP 根因：思维链一次性连续生成不可中途打断，而工具调用需「中途暂停等结果」，生成范式冲突；且训练目标（持续推理 vs 适时打断）相反；解法=思考后调工具（o3 / Claude Extended Thinking / interleaved thinking）。
• FC 训练两阶段：SFT 教「怎么调」（覆盖单/并行/失败重试/直接答/多轮场景，数据来自人工标注+蒸馏），RLHF 教「什么时候调」（PPO + 奖励模型对齐边界感）。
• Agent Skill 本质：文件夹（SKILL.md + scripts/references/assets），自动发现 + 渐进式加载（frontmatter→正文→资源）；教 Agent「怎么用工具」，类比操作手册。
• MCP vs Skill：MCP 给 Agent「手」（原子工具），Skill 给 Agent「菜谱」（完整流程）；粒度 MCP 是函数、Skill 是工作流；配合=Skill 编排、MCP 执行。
• A2A 本质：Google 2025 协议，Agent 微服务化；Agent Card（发现）+ Task 状态机（异步长任务）+ push notification；和 MCP 一纵一横不竞争。
• 四层总关系：FC（手）→ MCP（厨房/工具）→ Skill（菜谱/流程）→ A2A（多厨房调度）；链条 Skill→MCP→FC 每层依赖下一层，缺一层则系统瘫痪。
• 面试三大雷区：把 MCP 当 FC 升级版、把 Skill 当 prompt 模板、把 A2A 当 MCP 竞品——回答先亮「不同层、互补而非替代」框架。
• 2026 规范要点：MCP 2025-03 Streamable HTTP 取代 HTTP+SSE；Agent Skills 2025-12 开放标准；A2A /.well-known/agent-card.json（早期 agent.json）；推理模型工具调用走向 interleaved thinking。