Model Context ProtocolMCP，模型上下文协议

01是什么 / 为什么#mcp-what-why

为什么是「标准」而不是「又一个模型能力」

把它想成 USB-C。在通用接口出现之前，每个设备配一根专用线，充电线、数据线、视频线各不通用；约定一个通用口之后，M 个设备加 N 类外设，各自符合标准一次就够。AI 世界原本的问题一模一样：同一个 GitHub 工具，要为 Claude 写一遍、为 Cursor 写一遍、为每个 IDE 再写一遍。

做成一个 MCP server 之后，任何支持 MCP 的客户端都能直接接上去读 issue、提 PR——工具方和应用方解耦，各做各的。生态越大，省得越多，这是它区别于「多一个模型功能」的地方。

和 Function Calling 是分工，不是替代

这是现场最容易问混的一处。两者作用在不同层：

关系是叠加：MCP 内部仍然靠模型的 function calling 做决策，它做的是把那「一次调用」标准化、跨厂商化。二者不是二选一。

治理：它不是某一家的私有协议

2024 年 11 月由 Anthropic 首次开源，2025 年被主流 AI 应用与 IDE 快速采用， 2025 年 12 月捐给 Agentic AI Foundation（AAIF）——Linux 基金会旗下的中立基金会，由 Anthropic、Block、OpenAI 等共同发起。协议变更走 SEP（Specification Enhancement Proposal，规范增强提案）公开流程。

核实 2026-07-08，来源 aaif.io 官方博客。这一条对客户的用处很直接：接入 MCP 不等于绑定某一家大模型厂商。

02什么时候不该上 MCP#boundary

三条替代路径，各自适用的场景不同：

反过来，出现下面任一条就值得上：工具要被两个以上 AI 应用接入；工具方与应用方不是同一个团队；需要让工具能力可被发现、可被集中治理和审计。

这一节是网页版在讲义之外补的：讲义把这个判断散在对练与动手做里，没有正面展开替代路径。判据本身来自讲义已有口径，未引入新的外部事实。

03协议解剖#mcp-protocol

三个角色

主机（Host）是用户面对的 AI 应用，如 Claude Desktop 或 IDE，负责权限与用户交互；客户端（Client）是 Host 内部为每个 server 建的连接器，一对一维护会话；服务端（Server）是工具与数据的提供方，声明自己能做什么。

一个 Host 可以挂多个 Client，每个 Client 专线连一个 Server。Claude Desktop 里同时接了 filesystem 和 GitHub 两个 server，它内部就起两个 client，各连一个，互不干扰。

一次连接怎么开始

经典流程三步：初始化握手（initialize）双方交换协议版本与能力清单 → 能力发现，客户端拉取 tools/list、resources/list、 prompts/list → 正常调用。握手时 server 说「我支持 tools 和 resources、不支持 prompts」，client 就只去拉这两类，能力协商避免瞎调。

三大原语：两把刀切同一件事

第一把刀按「能做什么」切：

第二把刀按「谁控制」切，决定的是责任落点——这一刀比上一刀更影响架构：

控制者决定展示方式、确认时机、权限与审计责任。选错控制面，用户体验和审计责任就会错位——比如把一个有副作用的动作做成资源，就绕过了本该有的确认环节。

口径依据官方规范 2025-11-25，核实 2026-07-12，来源 modelcontextprotocol.io 规范页。

反向能力与弃用走向

除服务端三原语外，协议还定义了反向能力：Sampling（服务端反过来请客户端的模型帮忙生成）、 Elicitation（服务端向用户追问补充信息）、Roots（客户端告知可访问的目录范围）。

真实报文：一次 tools/call 的来回

下面是一次完整往返。点任一高亮字段看它的作用与它牵到哪一节；未启用 JavaScript 时，全部字段说明以列表形式在报文下方给出。

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "query_db",
    "arguments": {
      "sql": "SELECT region, SUM(rev) FROM sales GROUP BY region"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      { "type": "text", "text": "[{\"region\":\"华东\",\"rev\":10200000}, ...]" }
    ],
    "isError": false
  }
}

整段就是标准 JSON-RPC：可读、可校验、可审计。这也是「为什么选 JSON-RPC」的答案——简单、语言无关、天然可序列化，MCP 流量因此能轻松纳入现有 API 治理。

04传输与版本演进#mcp-transport

语法相同不代表信任相同

这是这一章最值钱的一句。stdio 的边界是进程隔离，凭据走环境变量或本地文件，信任前提是「你启动的那个命令及其来源」——本地不自动等于安全。Streamable HTTP 的边界是网络策略，靠 TLS、Origin 校验、OAuth 的 audience 限定，信任前提是网络边界与授权配置。

换传输等于换一整套进程、网络、凭据边界。从 stdio 迁到 HTTP 时鉴权设计要重做，不是改个 URL。所以顺序应该是先定信任模型，再选传输形态。

口径依据官方规范 2026-07-28，核实 2026-07-30。Streamable HTTP 自 2025 年 3 月起取代旧的 HTTP+SSE（Server-Sent Events），是当前的标准传输。

五版脉络：一路在解决「企业规模化」

早期几版解决「能跑通」，后面几版全在解决「多车道、能鉴权、能规模化扩容」——协议在稳步往企业基础设施的方向走。

无状态核心：新版改动最大的一处

旧的有状态模型要先 initialize 握手拿会话 ID，整通会话认一个实例，于是需要会话粘连（sticky session）或共享会话存储，「这个会话归哪台机器」得一直记着。

无状态之后，每个请求自带协议版本与客户端信息，像每封信都写全地址，谁收都能处理。前面挂一个普通轮询负载均衡就行，任意请求打任意实例。结果是 MCP server 可以像普通无状态 Web 服务一样扩容，这是「向企业规模化倾斜」最实的一步。

三个扩展方向

加上正式弃用政策（Active → Deprecated → Removed，至少 12 个月缓冲），新版给客户两个安心点：能力可扩展、变更有节奏。

新版好在哪：五个能拿去跟客户讲的收益

下面这张表按收益组织，不按变更组织——客户关心的是「我得到什么」， 不是「协议删了哪个字段」。

还有一条不在表里但值得提：扩展框架成形——非核心能力拆成可单独版本化的扩展 （Tasks、MCP Apps 都在其中），核心保持精简、生态各自演进。对客户的意思是： 以后加能力不必等整个协议大版本。

什么场景因此变了：六个以前难做、现在能做的

怎么用这张表：客户问「升级有什么好处」，别背九项变更——先认领他属于哪一行， 再用那一行的「旧版为什么难」和他现在的痛点对上号。 对不上号的，就老实说这版对他影响不大。

口径：场景为本册按官方变更推导的落地判断，非官方清单；协议事实来源见本节末与来源页。

逐项对照：2026-07-28 相对 2025-11-25 改了什么

官方 changelog 给的是九项主变更加十二项次要变更。下表按对落地的影响排序， 每行标出对应的 SEP 编号，客户要追溯时给得出出处。

四项弃用，和一个十二个月的窗口

这一版首次带来正式的特性生命周期政策：Active → Deprecated → Removed 三态， 从弃用到最早可移除之间至少十二个月。口径要说准——这是「弃用到移除」的窗口， 不是「新版本只管十二个月」。说岔了会变成给客户的错误承诺。

迁移成本落在哪，官方说得很直白：依赖会话标识的实现受影响最大——这正是无状态改造的代价所在。 Tier 1 SDK 已扩至六个，其中 TypeScript、Python、Go、C# 都已出支持版本，包内附迁移说明。

核实 2026-07-30，来源 MCP 官方 2026-07-28 发布文与 changelog。 规范已于 2026-07-28 正式发布，本节按官方 changelog 逐项更新。本节仍是全册时效性最强的一处，下一次定点复查 2027-01-31。

05动手写 server#mcp-server

最小可运行的 server

pip install "mcp[cli]"

from mcp.server.fastmcp import FastMCP
mcp = FastMCP("demo-weather")          # 起个 server 名

@mcp.tool()
def get_weather(city: str) -> str:
    """查询某城市的当前天气（示例返回假数据）"""
    return f"{city}：晴，26°C"

if __name__ == "__main__":
    mcp.run()                          # 默认走 stdio 传输

装饰器 @mcp.tool() 会自动把函数签名、类型注解和 docstring 转成规范的工具描述——客户端在 tools/list 里看到的就是它。所以函数注释是写给模型看的，要写清什么时候用、参数是什么。这一点直接决定报文里 arguments 那一段填得对不对。

另外两个装饰器对应另外两个原语：@mcp.resource("file://readme") 暴露只读上下文， @mcp.prompt() 把一段最佳用法固化成模板。同一个 server 里三类能力可以齐活。

选栈两条硬事实：①官方 Tier 1 SDK 六种——TypeScript / Python / C# / Go / Rust / Ruby（Tier 是支持等级承诺，不是安全认证）；②面向新规范的正式版已发，不再是 beta：Python SDK v2.0.0（2026-07-28，与规范同日）把 FastMCP 更名为 MCPServer，装饰器写法不变；TypeScript SDK 前一天发 2.0.0 并拆成 @modelcontextprotocol/core / client / server 等一组包。v1 线转维护（Python 当前 v1.30.0）——上面这段 FastMCP 写法在 v1 内仍可用，暂不升级的把依赖钉上限（mcp>=1.28,<2），做迁移评估时记得新版类名已换。

SDK 版本口径核实 2026-10-20，来源 官方 SDK 页与两个 SDK 仓库的 GitHub releases。不可外推边界：Tier 1 是支持等级承诺，各语言 SDK 的正式版进度并不同步，选栈前按目标语言的仓库发布页核当日版本。

开发顺序：先单测 server，再接模型

官方调试工具 MCP Inspector 相当于电工的万用表：npx @modelcontextprotocol/inspector 连上你的 server，用图形界面查看它暴露了什么、逐个点击调用、看真实的报文往返。

先用 Inspector 把 server 单独调通，排除模型这个变量，再接进真实客户端。把「server 对不对」和「模型会不会用」拆成两件事排查，定位速度差一个数量级。

最常见的落地姿势：把现有 REST API 包一层

像给老电器配一个转接头：后端不改、业务不重写，套一层标准口就能插进所有 MCP 客户端。包装层做四件事——描述、转调、整理返回、鉴权。

已有「查订单」接口，就写一个 query_order 工具，内部转调它、把 JSON 里的关键字段挑出来返回。给客户的工作量口径：有现成 API 时，一个中等复杂度的 server 通常几人天，不是重写业务系统。

几百个接口怎么排队：别一个 API 起一个 server，也别一次全包。相关接口按业务域聚成少数几个 server，否则光是部署与目录管理就先失控；批次上先包 AI 应用真会用到的那几个——工具定义是随每条消息进上下文的（见运行期成本），包得越全，每一轮对话都在为没人调用的工具付钱。所以「全量改造」既不必要也不划算，它天然是件可以分批交付的工程。

06生产落地#mcp-production

鉴权：就是标准 OAuth，不是另起一套

本地 server 靠进程边界就安全；远程 server 暴露在网络上，必须认证「谁在调、有没有权」。 MCP 的授权底座自 2025-06-18 起是 OAuth 2.1（在 2.0 之上收紧，配合 OIDC，OpenID Connect）：客户端拿令牌访问，server 校验令牌与权限。像进写字楼——本地 server 是自家客厅，进门即信任；远程 server 是办公楼，得先在前台换访客证，刷卡才能进对应楼层。

关键话术：能直接对接客户现有的身份与访问管理（IAM，Identity and Access Management）体系。新版要求客户端校验令牌签发方、注册时声明应用类型、凭据绑定签发方——都是在堵「令牌被张冠李戴」的坑。安全评审里有一条 MUST 级红线：token 透传明令禁止——server 不得把收到的令牌原样转发给下游，RFC 8707 的 audience（受众）校验是强制项，防的正是「拿着给 A 的令牌去调 B」这类混淆代理（confused deputy）攻击。

还有容易漏的一层：MCP 层的授权只管到「这个用户能不能调这个工具」，管不到「这个用户能不能看这条数据」。工具内部访问后端时如果用的是一个通用高权限账号，前面令牌校验做得再干净，数据面仍然是所有人共用一份最高权限——越权是在这里发生的，不在协议层。所以下面验收线里的「后端二次授权」是独立的一条：后端要按调用者身份自己再判一次，而不是信任「能调进来就是有权」。

为什么要一个 MCP 网关

企业里 server 会越来越多，还有员工想接外部 server。网关在客户端与众多 server 之间做统一入口：集中认证、限流、审计、按策略放行或拦截。相当于公司的统一收发室，所有进出的流量都在这里登记、安检、留档，而不是每个工位各收各的。

有了网关才谈得上「这个部门只能用这几个 server」「所有调用留审计日志」「外部 server 先过白名单」。治理有了着落。

和已有的 API 网关是分工，不是替换——这是客户第一个会追的问题。MCP 流量本身就是标准 JSON-RPC over HTTP，TLS、限流、审计、认证这些通用治理，现有网关本来就接得住；MCP 网关补的是它看不懂的那层协议语义：按 server 与工具的粒度授权、server 的发现与白名单、连接前审查工具描述。能复用的就复用，别让客户以为要为 MCP 再买一整套治理。

去哪儿发现 server

官方 Registry 是公开 server 的元数据仓库，记录每个 server 叫什么、在哪、怎么装。它像应用商店的货架说明卡：不托管代码，也不替你做安全审查。

运行期成本：贵在上下文，不在调用2026-07-20

客户问"这东西贵不贵"，答案往往不在他以为的地方。MCP 的运行期开销主要不是每次调用的网络往返，而是工具定义常驻上下文——而且它随每一条消息进上下文，不是每会话一次，所以成本是按轮次乘的。

这三个数改变什么判断

以上三条均为 2026-07-20 联网核实，来源 Atlassian MCP Compression 与 Envoy AI Gateway 基准。成本类数字比协议条款更易过期——模型窗口、计价、客户端的延迟加载策略都在变，引用前先核日期。客户端侧已有缓解手段（工具定义超过上下文一定比例时改为按需检索加载），但各家实现与阈值不同，不写进本页口径。

上线前的五条验收线

Inspector 里调通只是联调，不是生产结论。终极判断是一句话：任意一次调用都能回放「谁、经哪个版本、调了什么、为何被允许、结果如何」。

对应到云上

只列有真实关联的环节，同一环节给多厂商代表性选项，不绑死单一供应商。各云的具体服务能力以 2026 年现状为准，属于变动最快的一类信息，引用前先核日期；完整清单见讲义第 5 章。

07安全#mcp-security

四类特有威胁

风险有多真实

核实 2026-07-08，来源 dev.to 汇总与 arXiv 2508.14925。上面第三列是这些数字的不可外推边界——带出门时必须连边界一起带，否则就成了误导。

官方指引

2026 年 6 月，NSA 与 CISA 等发布《MCP: Security Design Considerations》，从架构设计角度给出安全建议，覆盖认证授权、供应链可信、注入面防护、部署边界。客户问「你们凭什么说 MCP 能安全落地」时，可以直接引用它作背书，并对照说明方案覆盖了其中哪几条。

获取方式见本模块电子书书单第 4 条。

防护组合拳：威胁与对策一一对位

最容易被忽视也最致命的两条：无鉴权裸暴露公网，以及图省事开全自动批准。这两条几乎是事故直通车，也最容易避免。

08上手路径与排错#mcp-cheatsheet

排错三板斧

先用 Inspector 单测 server → 再接客户端分层定位 → 最后查工具描述是不是让模型误调。顺序反了会浪费大量时间：模型「不肯用」和 server「跑不通」是两类完全不同的问题。

现场高频追问

只收会改变某个决定的问题——会改变技术方案、风险判断、验收方法、对客沟通或下一步行动。每题给结论、给背后的机制或权衡、给一个可执行的下一步，并回链依据。

每题标出它加入本题库的日期：2026-07-08 的来自讲义首版对练页，2026-07-20 的是网页版新立、讲义里没有，2026-07-23 是按客户交锋场景补的四题（改造范围 / 权限越权 / 已有网关 / 上下文成本）。

09上云怎么落地#cloud

从 demo 到生产：server 放哪、谁能调、去哪找

顺着追问什么：你们打算暴露多少个工具？这个数直接乘进每一轮对话的上下文，比「支持哪些功能」更能预测账单。现有的 API 网关和 IAM 是哪一套，MCP 流量能不能直接挂上去、不另买一套治理？哪些 server 会碰内网数据——那些就是必须进自建私有目录的。

云替你做不了什么：末句改为：「官方 Registry 仍是 preview、未 GA，可能有破坏性变更，而且只是元数据货架——不托管代码、不做安全审查、不收私有 server，上面有条目不等于通过了安全审查，更不能直接当企业应用商店用。」

本节服务清单与「给客户一句话」与讲义各章的「上云怎么落地」页同源，未引入新事实；「顺着追问什么」与「云替你做不了什么」两格是网页版补的售前视角。不可外推边界：这是「哪个环节有云服务可用」的地图，不是选型结论——具体产品的地域可用性、配额、计价单位与生命周期状态会月级变动，出方案前按当期官方文档逐项复核。

10相关模块#related

同一个概念在库里只有一个主要归属，其余模块讲的是它的另一个层面。这些模块目前只有讲义。

11来源与核实#sources

本页时效性数字均经联网核实后写入，完整登记（事实 × 核实日期 × 信源）见本模块 MANIFEST。核实窗口 2026-07-08 至 2026-08-01（运行期成本三条为 2026-07-20 补核，SDK 版本口径为 2026-08-01 补核）。引用任何数字前先核日期。