2026-06-08 MCP 协议 拷问复盘
本轮概览
- 知识点：MCP 协议
- 模块：5. AI Agent 架构
- 分数：85/100
- 是否过关：是
- 来源卡片：[[MCP 协议]]
这一轮的基础概念和边界意识是过关的。你已经能把 MCP 说成“工具接入协议层”，也能区分它和 Function Calling、Agent 的分工，说明主干是对的。主要扣分点在第 3 题：Streamable HTTP 那部分把“普通 JSON 和 SSE 流式输出方式”混在一起了，表达不够稳；另外对 initialize 握手、Host/Client/Server、Resources/Tools/Prompts 这些底层机制还没有主动带出来，所以抗追问能力还差一截。
第 1 题
题目：
你先不用讲项目，直接用面试回答的方式说清楚：MCP 到底是什么，它核心解决了什么痛点？尽量顺手讲明白它为什么经常被类比成 AI 领域的“USB-C”。
你的回答：
你回答了 MCP 是 Agent 接入外部工具的统一标准化协议，核心解决不同 Agent 接入工具实现不一致、工具碎片化、维护成本高的问题。你也提到了只要宿主支持 MCP，工具实现一次后就能在多个系统中复用。
缺失点：
整体是对的，但更严谨的说法应是“AI 应用或宿主接入外部工具的标准协议”，不必只限于 Agent。另一个缺口是“USB-C”比喻还可以再说透一点，也就是统一的是接线规范，不是统一底层业务逻辑。
推荐答案：
MCP 是 Model Context Protocol，本质上是==一套让 AI 应用和外部工具、数据源进行标准化通信的协议==。它解决的核心痛点不是模型推理，而是工具接入碎片化。以前同一个数据库查询工具、文件工具、内部 API 工具，往往要给不同宿主分别做适配；MCP 的价值是把这层接线规范统一掉，让工具方按协议暴露能力，宿主方按协议发现和调用能力，做到一次封装、多处复用。所以它常被类比成 AI 领域的 USB-C，因为统一的是接口标准和接入方式，不是具体设备内部怎么实现。
项目口径：
在苍穹外卖 AI 客服这类系统里，如果后面要继续接订单查询、地址修改、优惠券、FAQ、知识库检索、运营平台接口，协议层统一以后，工具接入和宿主编排就能解耦。这样 Agent 侧重点放在意图理解、上下文管理和工具选择，工具侧重点放在能力暴露和安全边界。
第 2 题
题目：
MCP、Function Calling、Agent，这三者分别处在什么层次？它们的边界是什么？你要是面试里把这三个混着讲，为什么会显得不专业？
你的回答：
你回答了 Function Calling 解决模型表达调用工具意图的问题，MCP 解决暴露什么工具、如何和工具提供方通信的问题，Agent 更偏整个系统的组织和编排。
缺失点：
这题答得已经比较稳了，主要缺两个加分点。第一，最好明确说出三者不是替代关系，而是上下游协作关系。第二，可以再补一句“混着讲会显得边界不清，因为一个是意图表达层，一个是能力接入层，一个是任务执行与编排层”。
推荐答案：
Function Calling 解决的是模型如何把“我想调什么工具、参数是什么”表达成结构化调用意图；MCP 解决的是这些工具如何被标准化描述、发现、接入和通信；Agent 再往上一层，解决的是任务如何分步完成，包括规划、上下文管理、工具选择、结果整合和异常处理。三者不是替代关系，而是分层协作关系。如果面试里把它们都说成“工具调用”，会让面试官觉得你没有把意图表达、协议接入和任务编排这三个层次拆开。
项目口径：
在我的项目里，我会把这三层讲清楚：模型用 Function Calling 产出结构化调用意图；工具侧如果走协议标准化接入，可以用 MCP 这一层来解耦宿主和能力提供方；真正把订单、规则、记忆、RAG 和工具结果串起来形成完整客服交互的，是 Agent 编排和 Advisor 链。
第 3 题
题目：
如果面试官继续追问：MCP 底层为什么更适合用 JSON-RPC，而不是直接说 REST？另外 stdio 和 Streamable HTTP 各适合什么场景？你把这两个点一起答。
你的回答：
你回答了 JSON-RPC 更偏完成动作，符合 Agent 调用工具的形式；REST 更偏资源操作。你也回答了 stdio 适合本地调用、没有网络时延，Streamable HTTP 适合远程调用。
缺失点：
这一题是主要扣分点。JSON-RPC vs REST 的核心语义你答到了，但还不够完整，没有提到 MCP 本身就是方法调用风格、工具调用天然更贴近 RPC。stdio vs Streamable HTTP 只答了本地和远程的区分，还缺“stdio 模式下 stdout 不能打印普通日志，否则会污染 JSON-RPC 消息流”这个高频坑点。另一个需要修正的是，不要把 Streamable HTTP 简单说成“普通 JSON 和 SSE 流式输出方式”，现在更稳的表达是它适合团队远程服务、统一鉴权、网关接入和多租户场景。
推荐答案：
MCP 更适合用 JSON-RPC，是因为它的核心语义不是“访问某个资源”，而是“调用某个方法或工具”，这和 RPC 模型更契合。REST 更偏资源导向，比如 /users/1、/orders/100；而 MCP 这种工具调用场景更像 tools/call、resources/read 这种动作型接口。至于传输方式，stdio 更适合本地工具、本地文件、个人开发，部署简单，但要注意 stdout 是协议消息通道，不能混入普通日志；Streamable HTTP 更适合远程服务、团队共享、多租户访问，因为更方便接鉴权、网关和负载均衡。
项目口径：
如果我后面把苍穹外卖 AI 客服里的更多内部能力做成可复用工具，本地开发阶段可以先走 stdio，调试快、部署轻；一旦要给团队共享、走统一权限控制和网关治理，就更适合迁到 Streamable HTTP。无论哪种方式，最终都不能信任模型传参，后端都要继续做参数校验、权限控制、审计和超时兜底。
下次复习动作
- 把第 2 题背成一句固定口径：Function Calling 是意图表达层，MCP 是能力接入层，Agent 是任务编排层。
- 二刷第 3 题时补齐
Host/Client/Server、Resources/Tools/Prompts、initialize握手和stdout 污染协议流这几个高频追问点。 - 项目口径里保留一句“协议层解决怎么接工具，Advisor/Agent 层解决怎么组织任务”，这样边界会更清楚。