1. 从教务开课场景看 MCP 无状态化的真实动机MCP 无状态化这件事如果只盯着协议文档看很容易变成一次名词背诵initialize 握手没了、Mcp-Session-Id 没了、每次请求要带齐信息。但真正让我理解这套改动的是之前给一个教务系统接 MCP 的经历。需求很具体教务人员对 Agent 说一句「给张三开通物理全程班实付 6800 元」Agent 要自动完成搜索学生、搜索课程商品版本、查询权益、生成开课预览、等待人工确认、正式发放权益这一整条链路。这不是天气查询那种演示工具它会改真实数据涉及学生、课程、金额和付费权益。所以我最先想的不是「怎么把工具注册出来」而是三个问题怎么接入、怎么避免误操作、系统重启或网络重试后怎么保证不重复开课。这三个问题最后都指向同一个方向——MCP 层不要自己保存会话把状态放到真正对它负责的业务系统里。有状态 MCP 看起来更自然客户端连上服务器服务器建一个 Session后续调用都带着它服务器记住客户端是谁、协商了什么、上一轮做了什么。但往生产环境推就会冒出一堆和业务无关的问题Session 存哪、服务重启怎么办、请求被负载均衡打到另一台实例怎么办、客户端断线后旧 Session 何时清理、Agent 重试时服务器怎么判断这是同一次操作还是新操作。MCP 层记住的东西越多它和业务系统的耦合就越深。这就是无状态化要解决的原始问题。2. TaoToken 作为统一 Key/API 通道的前置准备在把 MCP 服务改成无状态之前我先把模型调用这一层收敛掉。原因是无状态 MCP 的每一次请求都要自包含如果模型通道还散落在多个 Key、多个地址上排障时会分不清是协议层的问题还是通道层的问题。TaoToken 在这里的角色就是一个统一的 Key/API 通道官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 不带 UTM。你需要提前准备的东西不多但顺序别乱第一注册后在控制台创建一个 API Key地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。这个 Key 后面会同时出现在 MCP 服务的环境变量和客户端配置里所以命名建议带上用途比如 mcp-stateless-dev方便后面按环境区分。第二Key 的管理页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 建议在这里给 Key 设置额度上限避免调试阶段因为循环重试把额度跑光。无状态化改造过程中最容易出现的就是重试逻辑写错导致请求放大这个上限是兜底。第三接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 重点看请求头格式和 base_url 拼接规则。无状态 MCP 要求每次请求带齐信息模型通道这边也一样鉴权信息每次都要带不要指望服务端记住你上一次是谁。第四如果你打算长期跑编码类 Agent可以了解 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它和本篇的无状态改造不是强绑定但如果你后面要把 MCP 接到 Claude Code 这类工具里这条通道会更省心。注意Key 只放在服务端环境变量或本地配置文件里不要写进会提交到仓库的示例代码。无状态化之后每次请求都带鉴权Key 泄露的影响面比有状态时更大。3. 可复制的 config.toml 与 settings.json 配置骨架下面这套配置是我实际用过的骨架分两部分config.toml 给 MCP 服务端settings.json 给客户端。核心思路是——服务端不保存会话客户端每次请求把协议版本、客户端信息、鉴权、业务参数全部带上。先看服务端的 config.toml# config.toml —— 无状态 MCP 服务端配置骨架 [server] name edu-mcp-stateless # 无状态模式下不启用会话存储 session_store none # 协议版本随请求携带这里只做默认值 protocol_version 2026-07-28 # 服务能力通过 server/discover 暴露不依赖 initialize 握手 discover_enabled true [transport] type http host 0.0.0.0 port 8787 # 关键不要求粘性路由任意实例都能处理请求 sticky_session false [auth] # 每次请求独立校验不缓存身份 mode per-request header Authorization # 业务侧鉴权仍由原 Agent API 负责MCP 只做透传 forward_to https://your-agent-api.internal [upstream] # 统一模型通道无状态请求每次带 Key base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY timeout_ms 30000 max_retries 2 [tools] # 只读工具可直接执行 readonly [search_student, search_course, search_sku, list_benefits, preview_open_courses] # 写入工具必须带 confirm_token write [open_courses] require_confirm_token true idempotency_header X-Idempotency-Key再看客户端的 settings.json{ mcpServers: { edu-stateless: { type: http, url: http://127.0.0.1:8787/mcp, headers: { Authorization: Bearer ${TAOTOKEN_API_KEY}, MCP-Protocol-Version: 2026-07-28, X-Client-Name: edu-agent, X-Client-Capability: tools,discover }, stateless: true, discoverOnStart: true } } }几个参数值得单独说清楚。session_store none 是无状态化的开关设成 none 之后服务端不会为任何客户端创建会话所有请求走同一条无状态路径。sticky_session false 是给负载均衡看的意味着你可以把请求打到任意实例。require_confirm_token true 是安全边界它不写在提示词里而是写在服务端配置里Agent 就算跳过预览直接调 open_courses服务端也会拒绝。提示MCP-Protocol-Version 这个头在无状态模式下必须每次带。旧客户端如果还在发 initialize服务端可以保留一个兼容响应但服务端自身不依赖它也不要求客户端始终连同一个实例。4. 一次完整的连接验证动作配置写完别急着接业务工具先用最小请求验证无状态链路是否真的通了。我习惯分三步先验证模型通道再验证 MCP 服务发现最后验证一次带业务参数的完整调用。第一步验证 TaoToken 通道。用 curl 直接打一次模型对话接口确认 Key 和 base_url 都对curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: reply with ok}], max_tokens: 16 }返回里能看到正常的 choices 结构说明通道没问题。这一步也可以用模型对话页面手动验证地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 适合不想敲命令的时候快速确认。第二步验证 MCP 服务发现。无状态模式下没有 initialize 握手服务能力通过 server/discover 获取curl -s http://127.0.0.1:8787/mcp \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H MCP-Protocol-Version: 2026-07-28 \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, id: 1, method: server/discover, params: {} }正常返回里会列出 tools 列表和协议版本。如果这里报 method not found说明服务端还在走旧的 initialize 路径检查 config.toml 里的 discover_enabled 是否为 true。第三步验证一次完整的只读工具调用。注意这次请求里没有任何 Session 标识所有信息都在请求体内curl -s http://127.0.0.1:8787/mcp \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H MCP-Protocol-Version: 2026-07-28 \ -H X-Client-Name: edu-agent \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, id: 2, method: tools/call, params: { name: search_student, arguments: { tenant_id: t-1001, keyword: 张三 } } }返回里应该能看到学生列表。到这里一次无状态请求就完整跑通了鉴权在请求里、租户在请求里、业务参数在请求里服务端处理完立即返回不依赖上一轮请求也不依赖服务器内存里的上下文。5. 本篇常见错排查改造过程中我踩过的坑基本集中在下面几类按出现频率排。第一类客户端还在发 initialize服务端已经移除握手结果连接直接失败。表现是客户端日志里卡在 initializing服务端日志里没有对应处理。解决办法是升级客户端到支持 2026-07-28 的版本或者在服务端保留一个兼容响应但服务端自身不依赖 Session。如果你用的是 Claude Code 这类工具可以参考 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里的接入说明确认版本要求。第二类请求被负载均衡打到另一台实例后报 Session not found。这是有状态残留检查 config.toml 里 session_store 是否真的设成了 none以及负载均衡是否还开着粘性会话。无状态模式下粘性会话不但没必要还会掩盖问题。第三类写入工具被重复执行。表现是 Agent 超时重试后开了两次课。根因是幂等没做在服务端只靠提示词约束。正确做法是 preview_open_courses 返回 confirm_token 和 idempotency_keyopen_courses 执行时重新计算内容指纹任何一项参数变化就让令牌失效执行成功后立即销毁令牌。第四类鉴权信息只在第一次请求带后续请求 401。无状态模式下每次请求都要带 Authorization客户端配置里不要依赖服务端缓存身份。检查 settings.json 的 headers 是否每个请求都注入。第五类server/discover 返回的能力列表和实际工具对不上。通常是 config.toml 里 readonly 和 write 两个列表没同步更新新增工具后忘了登记。建议把工具注册和配置生成放在同一个构建步骤里避免手工维护两份。注意排障时优先看服务端日志里的单次请求记录。无状态化的好处之一就是一次请求可以被单独理解、追踪和审计日志里不应该出现「依赖上一轮请求」这种跨行关联。6. 把无状态 MCP 接进长期工具链验证通过之后下一步通常是把这套无状态 MCP 接进日常用的编码或 Agent 工具链。这里有个选择如果你只是偶尔验证模型行为用模型对话页面就够了如果你要长期跑编码类 Agent建议走 Coding Plan 通道配置更稳定地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。如果你用的是 Claude Code 这类客户端接入说明在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 重点确认它是否支持无状态请求头。回到无状态化本身它真正带来的不是省掉一张 Session 表而是让失败变得普通、让重试变得安全、让扩容不再改变业务语义。服务器随时可以重启请求可以被普通负载均衡分发到任意实例身份每次独立校验重复调用由业务幂等兜底日志里的一次请求可以被单独审计。这些特性在演示项目里可能不重要但只要 MCP 开始接触订单、金额、账号、权限和真实用户数据它们就会变成刚需。我当时的做法是提前把远程 MCP 做成了无状态并不知道官方最终会怎么改。后来 2026-07-28 版本把 initialize 握手和 Mcp-Session-Id 移除协议版本、客户端信息和能力信息改为随请求携带服务能力通过 server/discover 获取这等于把同一条路写进了正式规范。严谨地说我当时采用的是「无会话、请求自包含、业务状态外置」的部署架构并不等于提前实现了全部新协议字段旧客户端需要的 initialize 我也保留了兼容响应。但架构方向是对的协议可以无状态应用仍然可以有状态状态不是不能有而是必须放在真正对它负责的地方。身份状态归鉴权系统课程状态归课程系统确认状态归开课业务幂等状态归执行记录MCP 只做协议适配不拥有业务状态。