1. 这次重写到底改了什么从有状态长连接到无状态请求MCP 这次把自己推翻重写最核心的变化就一句话Session 没了Sampling 废了整个协议从有状态长连接转向无状态请求。如果你之前跟着 2025 年的教程学过 MCP脑子里那套先 initialize 建会话、再靠 session id 维持上下文、服务端主动 sampling 回调客户端的模型现在基本要清空重来。先说清楚 MCP 是什么避免新读者一头雾水。MCP 全称 Model Context Protocol是一套让 AI 应用客户端和外部能力服务端比如工具、数据源、资源之间标准化对话的协议。你可以把它理解成AI 世界的 USB-C 接口——不管对面接的是数据库、文件系统还是某个 SaaS只要双方都按 MCP 说话就能插上就用。这个类比很关键因为这次重写的方向恰恰就是让这个接口变得更像一根普通的数据线而不是一条需要一直握手的专线。那Session 没了具体指什么在旧模型里客户端和服务端建立连接后会有一个会话Session服务端记住你是谁、你之前调用过什么、当前上下文是什么。这个设计在单机、单用户场景下很舒服但一旦要横向扩展、要做多副本部署、要接无服务器架构Session 就成了最大的绊脚石——你得做会话粘滞、得共享会话存储、得处理会话过期运维复杂度直接翻倍。新版本把 Session 拿掉意味着每一次请求都是自包含的服务端不需要记住上一次是谁在跟我说话请求里带齐所有必要信息处理完就结束。这就是热词里反复出现的Stateless无状态。再说Sampling 废了。旧版 MCP 里有个很受关注的能力叫 Sampling允许服务端反过来请求客户端去调用大模型完成一次生成。听起来很优雅——服务端说帮我总结一下这段文本客户端负责去调模型。但实际落地时问题一堆谁来控成本谁来管提示词安全客户端和服务端的责任边界模糊调试起来像踢皮球。新版本把这条路径砍掉改成更明确的单向职责划分服务端就老老实实提供工具和资源生成这件事交回给客户端自己决定。热词里的MRTR就是这次调整里冒出来的新概念它代表的是多轮请求-响应这类更显式的交互模式取代了过去那种隐式的回调式 Sampling。所以这次重写的本质是一次从聪明但难运维到笨但好扩展的取舍。旧设计想在一个协议里塞进太多智能结果把自己搞复杂了新设计把复杂度推回给调用方换来的是部署简单、水平扩展容易、调试路径清晰。你学的 2025 教程之所以停在 2025就是因为它们讲的还是那套 Session Sampling 的旧世界。2. 为什么非要推翻重写旧架构踩过的三个硬坑要理解这次重写光知道改了什么不够得知道为什么非改不可。我梳理下来旧架构有三个绕不过去的硬坑每一个都足以逼着维护者下决心重写。2.1 会话粘滞让水平扩展变成噩梦旧版 MCP 的 Session 机制最直接的后果就是会话粘滞Session Affinity。什么意思假设你把 MCP 服务端部署了三个副本做负载均衡客户端第一次请求打到了副本 A副本 A 记住了这个会话。第二次请求如果被负载均衡甩到了副本 B副本 B 一脸懵——我不认识你啊。于是你要么在负载均衡层做粘滞保证同一个会话永远打到同一个副本要么把会话状态抽出来放到 Redis 之类的共享存储里。这两种方案我都试过各有各的痛。粘滞方案的问题是某个副本挂了挂在它上面的所有会话全断用户体验直接崩而且流量分布不均热点副本压力山大。共享存储方案的问题是每次请求都要读写一次外部存储延迟上去了而且 Redis 本身又成了新的单点和运维负担。对于一个小团队来说为了跑一个 MCP 服务端还得额外维护一套会话存储性价比太低。新架构把 Session 拿掉之后这三个副本彻底对等请求打到哪个都行负载均衡随便甩副本随便扩缩容。这就是无状态带来的最直接红利——扩展性从要动脑筋变成加机器就行。2.2 Sampling 的责任边界模糊到没法调试Sampling 这个能力设计初衷是好的让服务端也能用上大模型。但落地时它制造了一个非常尴尬的局面——服务端发起的生成请求成本和风险却由客户端承担。举个具体场景你接了一个第三方的 MCP 服务端它在你调用某个工具时偷偷发起一次 Sampling让你客户端去调模型生成一段内容。这时候问题来了这次模型调用的钱谁出如果服务端在提示词里塞了诱导性内容导致模型输出了不该输出的东西责任算谁的客户端要不要对服务端的 Sampling 请求做审核审核的话审核规则谁定我踩过的坑是调试一个带 Sampling 的服务端时日志里只能看到客户端收到 sampling 请求并返回了结果但中间模型到底被喂了什么提示词、返回了什么链路是断的。出了问题根本没法定位是服务端的锅还是客户端的锅。这种模糊的责任边界在真实生产环境里就是灾难。新版本砍掉 Sampling把生成这件事明确划给客户端服务端只负责提供确定性的工具和资源。职责单一了调试路径就清晰了——出问题要么是工具本身的问题要么是客户端调模型的问题不会再有中间那层说不清道不明的回调。2.3 长连接模型和现代部署形态格格不入旧版 MCP 假设的是一条长期存活的双向连接这在本地开发、单机工具场景下没问题。但现在的部署形态是什么是无服务器函数、是边缘计算、是容器化按需拉起。这些形态的共同特点是进程随时可能被创建和销毁不保证长期存活。你想想一个无服务器函数被调用时启动处理完请求就销毁它怎么可能维持一个长连接会话旧架构在这种环境下根本跑不起来或者要付出巨大的改造成本。新架构的无状态请求模型天然适配这种用完即走的部署方式——每次请求独立、自包含函数拉起、处理、销毁干净利落。这三个坑叠加起来结论就很清楚了旧架构不是有点小毛病而是从根子上和现代基础设施的演进方向背道而驰。与其打补丁不如推翻重写。这也是为什么这次改动这么大、这么彻底。3. 无状态之后请求到底长什么样理解了为什么接下来得看改成什么样。无状态化之后一次 MCP 请求的结构发生了根本变化这里我把关键差异拆开讲方便你对照旧教程做迁移。3.1 每次请求自带完整上下文旧模型里上下文是靠 Session 在服务端累积的。你第一次 initialize 时告诉服务端我是谁、我支持哪些能力之后就不用重复说了服务端记着。新模型里这些信息必须每次请求都带上。这听起来像是退步——每次都要重复传一样的东西不是浪费吗其实不然。重复传上下文的代价换来的是请求的完全自包含。任何一个服务端副本拿到这个请求就能独立处理不需要依赖任何之前的状态。这就像你去银行办事旧模式是先开户建档之后报账号就行新模式是每次来都带齐身份证、户口本、申请表柜员当场就能办。麻烦是麻烦了点但任何一个柜台都能办不用非得回原开户行。实际迁移时你需要把原来放在 initialize 里的能力声明、客户端信息、协议版本等挪到每个请求的元数据里。这部分是迁移工作量最大的地方因为旧教程里几乎不会强调每次都要带你得自己补上。3.2 会话标识从服务端记忆变成请求参数热词里有个很有意思的搜索词叫cookie和session和token详解这其实反映了大家的困惑无状态之后怎么区分不同用户、不同对话答案是把标识从服务端记忆变成请求参数。具体做法是客户端自己生成一个对话标识可以理解成 token每次请求都带上它。服务端不存储这个标识对应的状态但如果需要做多轮对话客户端可以把历史上下文一起打包传过来。状态的归属从服务端转移到了客户端。这个转变很关键它意味着客户端要承担更多记住上下文的责任而服务端回归成一个纯粹的无状态处理器。注意这里的 token 只是对话标识和身份认证是两码事。认证该怎么做还怎么做别把两者混为一谈。3.3 MRTR 取代了隐式回调前面提到的 MRTR是这次调整里最需要重新学习的部分。旧版 Sampling 是一种服务端主动回调客户端的隐式交互新版的 MRTR 把它改成了显式的多轮请求-响应。区别在哪旧模式像服务端给客户端打了个电话说你去帮我办件事办完告诉我新模式像服务端在响应里说这件事我办不了需要你先去做另一件事做完再回来找我。后者虽然多了一次往返但每一步都是显式的、可记录的、可审计的。客户端清楚地知道服务端需要什么服务端也清楚地知道客户端做了什么中间没有黑盒。这个改动对调试体验的提升是巨大的。以前 Sampling 出问题你得在两个进程之间来回猜现在 MRTR 的每一步都在请求-响应里明明白白日志一拉就清楚。4. 迁移实操把 2025 教程里的代码改到新模型光讲概念不够我拿一个典型的旧教程代码结构演示怎么迁移到新模型。假设你之前跟着教程写过一个带 Session 和 Sampling 的 MCP 服务端现在要改。4.1 拆掉 initialize 里的状态累积旧代码通常长这样伪代码示意结构# 旧模型initialize 时建立会话服务端记住客户端能力 def handle_initialize(request): session create_session() session.client_capabilities request.capabilities session.protocol_version request.protocol_version sessions[session.id] session return {session_id: session.id, server_capabilities: [...]} def handle_tool_call(request): session sessions[request.session_id] # 依赖服务端记忆 # ... 用 session 里的信息处理迁移到新模型第一步是把sessions这个字典删掉把需要的信息从请求里取# 新模型无状态每次请求自带上下文 def handle_request(request): # 不再有 session 查找所有信息从 request 里取 client_caps request.meta.get(client_capabilities, {}) protocol_version request.meta.get(protocol_version) conversation_id request.meta.get(conversation_id) # 客户端生成的标识 # ... 直接处理处理完不保存任何状态 return {result: ...}关键改动点删掉所有sessions[...]的读写把原来从 session 里取的东西改成从request.meta里取。这一步做完你的服务端就已经是无状态的了。4.2 把 Sampling 调用改成 MRTR 显式往返旧代码里如果有 Sampling通常是服务端主动发起# 旧模型服务端主动 sampling def handle_tool_call(request): # 服务端觉得需要模型生成 result client.sample(prompt帮我总结这段文本, text...) return {result: result}新模型里服务端不能主动回调了要改成在响应里声明我需要你先做一件事# 新模型MRTR 显式往返 def handle_request(request): if needs_generation(request): # 不主动回调而是返回一个需要后续动作的响应 return { status: needs_action, action: { type: generate, prompt_template: ..., input: request.params.get(text) } } # 正常处理 return {status: ok, result: ...}客户端收到needs_action后自己决定要不要调模型、怎么调然后把结果作为新一轮请求发回来。服务端在下一轮请求里拿到生成结果继续处理。整个链路是显式的、可记录的。实操心得迁移时最容易漏的是错误处理路径。旧模型里 Sampling 失败可能是个异常新模型里它变成了一个正常的需要动作响应你的错误处理逻辑要跟着改别还用旧的 try-catch 思路。4.3 客户端侧要补的上下文管理服务端无状态了客户端就得把记住上下文的活接过来。具体来说客户端需要维护对话标识自己生成每次请求带上用于服务端区分不同对话如果服务端需要的话。历史上下文如果要做多轮对话客户端得把相关历史打包进请求。能力声明每次请求都带上自己支持的能力别指望服务端记住。这部分在旧教程里几乎不存在因为旧模型把这些都甩给了服务端。迁移时你会发现客户端代码变多了但换来的是客户端对上下文有完全的控制权——想清空就清空想裁剪就裁剪不用受服务端会话生命周期的摆布。5. 常见问题与排查技巧实录迁移过程中我踩了不少坑这里整理成速查表方便你对照排查。问题现象可能原因排查方向请求偶尔成功偶尔失败负载均衡把请求甩到了不同副本旧代码还在依赖 session检查是否还有sessions[...]读写确认服务端完全无状态多轮对话上下文丢失客户端没把历史上下文打包进请求检查客户端是否维护并传递了对话历史服务端报未知会话旧代码残留了 session 校验逻辑全局搜索 session 相关代码彻底删除Sampling 相关调用报错还在用旧的主动回调 API改成 MRTR 显式往返检查响应结构认证失败把对话标识和认证 token 搞混了确认认证逻辑独立于对话标识响应里出现 needs_action 但客户端不处理客户端没实现 MRTR 的后续动作逻辑补上客户端对 needs_action 的处理分支除了表格里的还有几个我踩过的坑值得单独说。第一个坑以为无状态就是不传任何上下文。这是误解。无状态指的是服务端不存储状态不是客户端不传上下文。该传的还得传只是传的方式从initialize 时传一次变成每次请求都传。第二个坑MRTR 的往返次数没控制好。显式往返虽然清晰但如果设计不好可能变成来回踢皮球一次请求要往返七八次。我的经验是能一次说清的需求别拆成多次。MRTR 是为了解决服务端确实需要客户端先做一件事的场景不是让你把所有逻辑都拆成往返。第三个坑忽略了协议版本兼容。新旧模型差异这么大如果你的客户端和服务端版本不匹配会出现各种诡异问题。建议在请求元数据里明确带上协议版本服务端根据版本走不同逻辑或者直接拒绝不兼容的版本。独家避坑技巧迁移时先写一个最小无状态服务端只实现一个最简单的工具跑通整条链路再逐步把旧功能搬过来。别一上来就全量迁移那样出了问题你根本不知道是哪一步引入的。6. 这次重写对生态的连锁影响MCP 这次重写不只是协议本身的事它会沿着生态链往下传导影响每一个跟 MCP 打交道的角色。我按角色拆开说。6.1 对工具开发者的影响如果你是基于 MCP 开发工具服务端的好消息是部署变简单了。以前你得考虑会话存储、会话粘滞、长连接保活现在这些统统不用管写个无状态的请求处理器就行。坏消息是你得重新理解请求模型尤其是那些依赖服务端记住上下文的设计得改成客户端传上下文。我个人的判断是对工具开发者来说这次改动长期是利好短期是阵痛。阵痛期大概就是你重写一遍现有工具的时间但重写完之后你的工具能跑在更多部署形态上运维成本也降下来了。6.2 对客户端开发者的影响客户端这边工作量是增加的。你要接管上下文管理、要实现 MRTR 的往返逻辑、要处理更多的错误分支。但换来的是对交互流程的完全掌控。以前服务端偷偷 Sampling你只能被动接受现在每一步都是显式的你想拦就拦、想改就改。热词里有个搜索词叫browser use mcp 跟 playwright mcp 有什么区别这类问题在新模型下会更容易回答因为客户端的职责边界清晰了不同客户端之间的差异也更容易对比。6.3 对教程和学习者的影响最直接的影响就是2025 年的教程大面积过时。这不是危言耸听Session 和 Sampling 是旧教程的核心章节现在这两块要么删掉、要么重写。如果你正在跟着旧教程学我的建议是先理解旧模型的设计思路为什么当初这么设计再学新模型为什么现在这么改。理解了演进逻辑你才能举一反三而不是死记 API。热词里codex无法找到mcpcodex 接入 figma mcp 怎么授权这类问题很多都是因为教程和实际版本对不上导致的。遇到这种问题第一件事是确认你用的协议版本别拿旧教程硬套新版本。7. 我个人的迁移体会最后说点掏心窝子的。这次 MCP 重写我第一反应是又来折腾毕竟旧模型刚学熟。但真正迁移完一个工具之后我的看法变了这次改动方向是对的只是过程痛苦。旧模型的 Session 和 Sampling本质上是想在一个协议里解决太多问题结果把自己搞复杂了。新模型把这些复杂度推回给调用方协议本身变简单了但要求使用者更清楚自己在干什么。这就像从全自动相机换成手动相机——上手门槛高了但你能拍出更可控的照片。如果你现在还在用旧模型我的建议是尽早迁移。不是因为旧模型马上不能用而是因为生态会往新模型倾斜越晚迁移你要改的东西越多。迁移的时候别想着一步到位先跑通最小链路再逐步搬功能。踩坑是必然的但坑踩完了你会对 MCP 的理解上一个台阶。至于那些还在讲 Session 和 Sampling 的教程你可以把它们当历史资料看理解设计演进但别照着写代码了。协议在往前走学习也得跟上。