企业官网建设流程全解析

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. 常见问题与排查技巧实录

迁移过程中我踩了不少坑，这里整理成速查表，方便你对照排查。

除了表格里的，还有几个我踩过的坑值得单独说。

第一个坑：以为"无状态"就是"不传任何上下文"。这是误解。无状态指的是服务端不存储状态，不是客户端不传上下文。该传的还得传，只是传的方式从"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无法找到mcp""codex 接入 figma mcp 怎么授权"这类问题，很多都是因为教程和实际版本对不上导致的。遇到这种问题，第一件事是确认你用的协议版本，别拿旧教程硬套新版本。

7. 我个人的迁移体会

最后说点掏心窝子的。这次 MCP 重写，我第一反应是"又来折腾"，毕竟旧模型刚学熟。但真正迁移完一个工具之后，我的看法变了：这次改动方向是对的，只是过程痛苦。

旧模型的 Session 和 Sampling，本质上是想在一个协议里解决太多问题，结果把自己搞复杂了。新模型把这些复杂度推回给调用方，协议本身变简单了，但要求使用者更清楚自己在干什么。这就像从"全自动相机"换成"手动相机"——上手门槛高了，但你能拍出更可控的照片。

如果你现在还在用旧模型，我的建议是尽早迁移。不是因为旧模型马上不能用，而是因为生态会往新模型倾斜，越晚迁移，你要改的东西越多。迁移的时候，别想着一步到位，先跑通最小链路，再逐步搬功能。踩坑是必然的，但坑踩完了，你会对 MCP 的理解上一个台阶。

至于那些还在讲 Session 和 Sampling 的教程，你可以把它们当"历史资料"看，理解设计演进，但别照着写代码了。协议在往前走，学习也得跟上。