MCP

MCP 全称是 Model Context Protocol（模型上下文协议）是 AI 应用与工具提供方约定的通讯协议。

解决重复对接第三方工具的问题。 举个例子：

A 公司为了让他们的 Agent 支持查询天气、路线，接入了百度地图 API。B 公司为了支持查询天气、路线也同样接入了百度地图API。那么当有 1万家公司需要接入地图API，就需要重复开发 1万次。

现在百度提供一个标准接口，跟所有公司说，我们搞了一个通用的交互协议，并提供了这个协议所有语言的实现，你们只需要引入对应的协议包，再连接上百度的 MCP 地址，就能让 Agent 拥有百度所有的开放能力。这就是 MCP 要解决的问题。

有舍有得，MCP 带来方便的同时，也带来了另一个问题：token 消耗剧增，一个 MCP Server 支持的 tool 越多，token 消耗越多。

为什么会出现这个问题呢？

因为 MCP 的工作模式是：全量加载，每次发送

为了让 AI 知道能用哪些工具，MCP 客户端会在每轮对话开始时，把所有连接的 MCP 服务器上所有工具的完整定义（名称、描述、复杂的 JSON Schema 参数）都塞进上下文里，即使你只是简单的说一句 "你好"。

这就是早期 MCP 的问题。但现在的 Agent 一般都会有智能过滤，懒加载，并不会将所有工具定义都加载到上下文中。

Skill 和 MCP 用于解决不同的问题。

如果是在本地环境，Skill 可以直接平替 MCP。但是如果非本地环境，例如云端 Agent 无法执行 Skill，只能用 MCP。

也可以这么了解，Skill 是 C/S 架构, MCP 是 B/S 架构，当提供的能力发生变更时， Skill 需要更新，MCP 不需要更新。

初始化握手：协商双方都有的能力
能力发现：Client 调用 tools/list 自动拉取完整工具 Schema
交互阶段：用户发起请求 -> Client 将所有完整的 Schema 变成 Tools（Function Calling）发给大模型 -> 大模型返回 Client 调用哪个 Tools -> Client 发送 tools/call RPC -> MCP Server 执行 -> 执行结果返回给 MCP Client -> 大模型整合数据输出回答

MCP 传输机制

为了 Agent（MCP Client）与本地的外部工具（MCP Server）交互，父进程（MCP Client）会创建子进程（MCP Server），并通过管道（pipeline）将父子进程的输入输出绑在一起。

例如父进程的 stdin 通过管道连接子进程的 stdout。

MCP 中，客户端使用独立的 HTTP POST 接口向服务端发起请求，服务端使用 SSE 推数据给客户端。

Server-Send-Event，服务器推送事件 SSE 是 W3C 标准，GET 单向长连接流水规范，HTML5 原生能力。

服务端无法单向推送消息给客户端

核心矛盾点：WebSocket 已经脱离 HTTP 生态，无法复用 HTTP 生态；需要协议升级，很多老旧网络设备不兼容 WebSocket；WebSocket 本身协议也比较重。

而 SSE 被设计出来的目标为：提供一套基于原生 HTTP 协议，无需协议升级的标准化单向推送方案。

需要声明，SSE 是特别被设计为单向传输的，所以这并不是它的弊端。

SSE 的弊端在于：

基于 HTTP Chunked 流式双向传输范式，是 Anthropic 专为 MCP 设计的底层传输层

初代 MCP 是 SSE 双端点架构，要解决 SSE 双端点架构问题，以及 SSE 本身的问题。

这里解释一下什么是双端点架构

上面的架构就带来 1 个问题，认证、超时、重连要做 2 套。