MCP协议原理#

三者的本质区别：

Function Call（函数调用）：

• 模型输出一个 JSON 结构（工具名 + 参数），由外部代码执行对应函数
• 优点：简单直接，几乎所有主流 LLM 都支持
• 缺点：工具定义和 Agent 代码耦合，不易复用和扩展

MCP（Model Context Protocol）：

• 基于 JSON-RPC 2.0 消息；标准传输层是 stdio（本地子进程）和 Streamable HTTP（远程），旧的 HTTP+SSE 传输自 2025-03-26 起废弃
• 角色：Host（LLM 应用）里的 Client 连接 Server；Server 提供三大原语：工具（Tools，给模型执行）、资源（Resources，给用户或模型用的上下文数据）、提示词模板（Prompts）
• Client 侧能力：Elicitation（Server 请求用户补充信息）；Roots、Sampling、Logging 在 2026-07-28 版被标记为废弃（仍可用，至少保留 12 个月）
• 结构化输出：工具可声明 outputSchema，结果放在 structuredContent 里，便于程序直接解析
• 授权：HTTP 传输下基于 OAuth 2.1（MCP Server 是资源服务器，必须提供 Protected Resource Metadata，Client 用 PKCE + resource 参数申请令牌）；stdio 传输不走这套，从环境变量取凭证
• 扩展：Tasks（长任务异步执行、轮询）、MCP Apps（在对话里渲染交互式 UI）等以可选扩展形式提供，双方协商后启用
• 优点：
  • 工具服务化，独立部署，独立维护
  • 支持动态注册，LLM 不需要提前知道工具列表
  • 跨语言（官方有 Python/TypeScript/Java 等多种 SDK）
• 缺点：规范迭代快，版本间有破坏性变更（见下表）；远程调用引入网络延迟

规范版本演进（面试常被问”最新版有什么变化”）：

面试重点记最新版的”无状态化”。

Skills：

• 比 Tool 更高层的抽象，封装了一个完整的业务能力（可能包含多个 Tool 调用 + 业务逻辑 + 说明文档）
• 例如：“预订机票” 是一个 Skill，它内部会调用”查询航班”、“验证信息”、“下单”三个 Tool
• Anthropic 的 Agent Skills 已作为开放标准发布：一个目录里放 SKILL.md（名称、描述、步骤）和脚本/资源，Agent 先只看描述，用到时再加载全文，节省上下文；MCP 社区也在做 Skills over MCP 扩展
• 优点：复用性更强，对 LLM 暴露的是意图而非操作细节，减少 LLM 决策负担
• 缺点：抽象层次高，实现成本高

总结： Function Call 是基础机制，MCP 是工具服务化的工程标准，Skills 是业务能力的高阶封装，三者层次递进。

MCP全称Model Context Protocol，是Anthropic 2024年底开源、现在由Linux Foundation下的Agentic AI Foundation托管的开放协议，用来解决LLM与外部工具和数据源之间的通信问题。要理解MCP，需要和Function Call、Skills放在一起看，它们是三个递进的层次。Function Call是最基础的机制，模型输出一个JSON指定工具名和参数，由外部代码执行，简单直接但工具定义和调用代码强耦合。MCP把工具服务化了，它基于JSON-RPC 2.0消息，本地用stdio、远程用Streamable HTTP传输，旧的HTTP+SSE已经废弃。Host里的Client连接MCP Server，Server提供三大原语——Tools、Resources、Prompts，Client可以动态发现和调用，实现了跨语言跨平台的即插即用，就像USB标准统一了设备接口。远程场景的授权基于OAuth 2.1。规范用日期做版本号，最新的2026-07-28版把协议改成了无状态：去掉了initialize握手和会话头，每个请求自带协议版本和能力，服务端需要补充信息时返回input_required让客户端带着答案重试，Sampling和Roots被标记废弃。Skills是更高层的抽象，封装一个完整的业务能力，内部可能包含多个Tool调用加业务逻辑。MCP的核心价值在于解耦——工具可以独立开发、独立部署、独立迭代，不同的Agent框架都能对接同一套工具生态。局限是规范迭代快、版本间有破坏性变更，远程调用会有额外延迟。结合项目时可以讲：同一套工具怎么同时服务内部Agent和外部客户端、外部暴露时做了哪几层安全校验。

追问方向：

• MCP 和 Function Calling 的本质区别是什么？ → Function Calling 是 LLM 内置的工具调用机制（工具定义写在代码里），MCP 是工具服务化协议（工具以独立服务暴露，支持动态发现和跨语言调用）；实际链路里 MCP Client 拿到工具列表后，仍是通过模型的 Function Calling 决定调哪个
• MCP Server 怎么做安全防护？工具权限怎么控制？ → 远程走 OAuth 2.1（令牌必须是发给本 Server 的，不能透传别的令牌）或 API Key；资源归属校验（如知识库 ID 必须属于当前用户）；用户身份由服务端从认证上下文注入，不允许调用方在参数里指定；外部搜索等有成本的工具加速率限制；高风险工具加人工审批。详见 MCP生产治理与安全加固
• 内部 Agent 和外部客户端怎么复用同一套工具？ → 常见做法是同一个工具实现走两个入口：内部走框架的 Function Calling（如 Spring AI 的 @Tool），外部走 MCP Server（Streamable HTTP）暴露，Schema 一次定义两处复用；内部调用时的用户上下文由服务端注入
• MCP 的动态发现机制在生产中怎么用？ → Client 通过 tools/list 获取工具列表和 Schema，新增工具只需部署 Server，Client 无需改代码；2026-07-28 版要求列表结果带 ttlMs/cacheScope 缓存提示，并建议按确定顺序返回工具以提高提示词缓存命中率
• 最新版 MCP 为什么要做成无状态？ → 常见解读（具体动机以对应 SEP 为准）：协议级会话让远程 Server 难以水平扩展（请求要粘到同一实例）；去掉握手和 Mcp-Session-Id 后每个请求自包含，负载均衡更简单；需要跨调用状态的 Server 自己签发句柄，作为普通工具参数传递

易错点：

• ❌ 混淆 MCP 和普通 HTTP API → MCP 有标准化的工具描述、动态发现和能力协商，不只是 HTTP 调用
• ❌ 忽略 MCP 的安全层 → 外部 MCP 调用需要认证（OAuth 2.1/API Key）+ 参数隔离 + 速率限制
• ❌ 认为 MCP 只能外部调用 → 同一套工具可以同时服务内部 Agent（Function Calling）和外部客户端
• ❌ “MCP 远程传输是 HTTP+SSE” → 该传输 2025-03-26 起已废弃，现在用 Streamable HTTP
• ❌ “MCP 连接要先 initialize 握手、维护会话” → 这是 2026-07-28 之前的做法，最新版已无状态化