微软把 MCP 的「会话」拆了：C# SDK 2.0 默认无状态，Agent 工具链开始像 Web 服务一样部署

如果你搭过 MCP 服务，大概率遇到过这样的麻烦：为了让客户端和服务器保持会话，你得处理握手、粘性路由、共享会话存储；一旦服务扩到多实例，负载均衡就开始跟你作对。协议本身不难，难的是把它跑成一个可靠的线上服务。

微软最近发布的 MCP C# SDK 2.0，试图把这块复杂度直接拆掉。它全面适配 MCP 协议 2026-07-28 修订版，默认把 Streamable HTTP 服务器设为无状态，并引入多轮往返请求（MRTR）来替代原来的服务器发起请求通道。

一分钟速览

• MCP C# SDK 2.0 默认启用无状态 HTTP 模式。
• 移除 initialize 握手与 Mcp-Session-Id 请求头。
• 协议版本与能力声明随每个请求发送，任意实例都能处理。
• 新增多轮往返请求（MRTR），替代服务器主动向客户端索取输入。
• 支持 .NET 8、9、10 与 .NET Standard 2.0。

为什么要「去会话」

MCP 原本的设计更像长连接会话：客户端先初始化，服务器返回会话 ID，之后的请求都带着这个 ID，以便服务器记住上下文。单机运行时没问题，但一旦部署到容器、Serverless 或多副本集群，会话就成了负担。你要么做粘性路由，把同一客户端固定到同一实例；要么把会话状态放到 Redis 之类的共享存储里。两种方案都增加运维成本。

2.0 的做法是把状态从连接里拿出来。协议版本和能力声明现在跟着每个请求走，服务器不需要记住「你是谁」，任何实例都能独立处理请求。负载均衡器、网关可以直接根据请求头路由，不必解析请求体。对于习惯把服务做成无状态 Web 应用的团队，这套模型显然更熟悉。

兼容性也做了考虑：旧客户端仍可自动降级到传统握手；而只有状态相关配置或旧版 SSE 端点，才会触发明确的警告码 MCP9006 和 MCP9004。换句话说，升级不会一夜之间把老服务打死，但会持续提醒你该迁移了。

MRTR：无状态之后，怎么继续追问

去会话带来一个新问题：服务器在工具调用过程中，原本可以主动向客户端请求补充信息，比如「你要我查哪个城市」「这个操作需要确认」。没有会话通道，这条路断了。

MRTR（多轮往返请求）就是替代方案。工具可以抛出 InputRequest，让客户端在下一轮请求中带回用户输入。对于 2025-11-25 或更早版本的有状态客户端，SDK 会桥接到旧的服务器发起请求；对于无状态的低版本连接，则会明确报错，而不是悄悄失败。

这个设计把「交互」变成了显式的请求-响应循环，和 HTTP 的语义更一致，也更容易被网关、审计和重试机制处理。代价是客户端要配合实现多轮逻辑，不能只发一次请求就等结果。

企业级细节：OAuth、框架与破坏性变更

2.0 还收紧了安全相关行为：支持 RFC 9207 的签发者校验，强制对外声明 PKCE 支持，动态客户端注册会自动推断应用类型。这些改动看起来琐碎，却是企业采购时必查的项。

框架支持覆盖 .NET 8、9、10 和 .NET Standard 2.0，意味着老项目也能接入。稳定的 1.x API 继续可用，但 Tasks 被移到独立包，且与 1.3、1.4 的实验版本不兼容；Roots、采样和日志 API 被标记为废弃。文档还提醒，不要用服务器自报的身份信息做安全决策。

另一个容易踩的坑是超时：Streamable HTTP 现在会等第一个协议消息到达后才发送响应头，长时间静默的处理器需要主动输出进度，或者设置更长的 HTTP 超时，否则会被中间层判定为挂起。

趋势洞察：Agent 工具链正在「Web 化」

MCP 刚出现时，更像一个本地工具协议：客户端和服务器跑在同一台机器上，用 stdio 通信。但随着 Agent 走向企业，MCP 服务越来越多地部署在云端，被多个客户端共享。无状态 HTTP、标准请求头、OAuth、负载均衡，这些 Web 后端的老朋友，正在成为 Agent 基础设施的新基座。

对开发者来说，这意味着技能栈的迁移：你不再只是写一个「工具函数」，而是在设计一个可观测、可扩展、可审计的网络服务。对平台方来说，谁先把 MCP 的部署体验做顺，谁就更容易成为 Agent 生态的默认入口。

2.0 不是终点。协议还在快速修订，实验性功能会继续进进出出。但「默认无状态」这个决定，基本给 MCP 服务的部署方式定下了基调：别再依赖会话，像做 Web 服务那样做 Agent 工具。

相关链接

• MCP C# SDK GitHub
• MCP 协议官网