.NET+AI | MCP | MCP 2.0 正式发布：AI 应用接入协议，开始进入「云原生时代」
目录
八、Roots、Sampling、Logging 被标记为弃用
1. 检查 HTTP Server 是否还依赖 Session
2026 年 7 月 28 日，官方 [MCP C# SDK v2.0.0 正式发布][^1] , 这次更新不是一次普通的 SDK 升级，而是 MCP 自发布以来最大的一次协议级重构：它把 MCP over HTTP 从「有会话、强连接、偏单机」的形态，推进到「无状态、可路由、可扩展、云原生」的新阶段。
如果说 MCP 1.x 解决的是「模型如何调用外部工具」，那么 MCP 2.0 要解决的就是：当 MCP 服务真正进入生产环境，跑在 API Gateway、负载均衡、Serverless、边缘节点和多实例集群之后，协议本身如何支撑稳定扩展。
这也是 MCP 2.0 最值得关注的地方：它不只是让 Agent 多了一些能力，而是让 Agent 能力开始真正进入生产基础设施。
一、最大的变化：MCP 默认走向无状态
MCP 2.0 最核心的关键词，是无状态。
在旧版本中，客户端通过 Streamable HTTP 调用 MCP Server 时，通常需要先完成 initialize 握手。服务端会返回一个 Mcp-Session-Id，后续客户端每次请求都要带上这个 Session ID。
这意味着请求会被绑定到某个服务实例。生产部署时，如果 MCP Server 有多个副本，就需要考虑粘性会话、共享 Session Store，或者额外的会话迁移机制。
这对实验项目没什么问题，但对生产系统来说，会增加不少部署和运维复杂度。
Before：有状态 HTTP MCP Server
在这种模式下，客户端和服务端之间存在一个逻辑会话。后续请求通常需要依赖前面建立的 Mcp-Session-Id。
After：无状态 HTTP MCP Server
新规范移除了 initialize / initialized 握手，也取消了 Mcp-Session-Id。协议版本、能力信息等上下文会随每次请求携带，每个请求都变成「自包含」的独立请求。
结果就是：任意服务实例都可以处理任意 MCP 请求。
这让 MCP Server 更像标准 Web API，也让它可以更自然地运行在 Kubernetes、Azure Container Apps、Serverless、边缘计算和普通负载均衡之后。
一句话总结：
Before：MCP Server 更像「长连接会话服务」，部署多副本时要考虑 Session 亲和。
After：MCP Server 更像标准 Web API，任意实例都可以处理任意请求。
二、HTTP 变得更标准：网关终于看得懂 MCP
MCP 2.0 另一个重要变化，是对 HTTP 层做了标准化。
在旧模式下，网关看到的通常只是一个 /mcp 地址。至于这次请求是 tools/list、tools/call，还是调用了哪个具体工具，都藏在 JSON body 里。
这对网关、负载均衡、限流、审计、日志和观测系统都不友好。它们要么完全不知道 MCP 请求在做什么，要么必须解析 JSON body。
MCP 2.0 引入了标准 Header，例如：
MCP-Protocol-VersionMcp-MethodMcp-NameMcp-Param-*
这样一来，API Gateway、负载均衡器、限流系统、日志系统可以不解析 JSON body，仅通过 Header 就识别请求类型、工具名称和参数信息。
Before：先初始化，再携带 Session ID
服务端返回：
后续调用工具时：
After：请求自带协议版本和路由信息
这看起来只是多了几个 Header，但对生产运维非常关键。
它意味着 MCP 流量开始具备三个重要能力：
- 可路由
：网关可以按工具、资源、方法做路由。
- 可缓存
：工具列表、资源读取等响应可以表达缓存语义。
- 可观测
：一次 MCP 调用可以进入统一链路追踪体系。
一句话总结：
Before：网关看到的只是
/mcp，真正的方法和工具名藏在 JSON body 里。
After：网关可以直接通过 Header 做路由、限流、审计和观测。
这也是 MCP 2.0 非常关键的一步：它不再像「套在 HTTP 里的私有协议」，而是更像一个真正能被云基础设施理解和治理的 Web workload。
三、多轮请求：交互式工具不再依赖长连接
MCP 2.0 引入了 Multi Round-Trip Requests，也就是多轮往返请求机制。
过去，某些工具调用如果需要用户补充信息、确认操作或完成交互，往往不好表达。工具要么直接失败，要么返回一段文字让用户重新调用，要么依赖长连接或服务端会话保存中间状态。
这和真实业务场景不太匹配。
例如：
-
一个部署工具需要用户选择区域、规格、预算上限；
-
一个审批工具需要用户确认金额、收件人和权限范围；
-
一个数据分析工具需要用户补充筛选条件；
-
一个 OAuth 授权工具需要用户先完成第三方登录。
MCP 2.0 让这些交互可以用更清晰、更可扩展的协议方式表达。
Before：参数不够，只能报错或让用户重试
这种方式的问题是：工具不能在执行过程中自然地「追问用户」。
它只能告诉模型或用户：你参数没给够，请重新来一次。
After：工具执行中主动请求用户补充信息
在这个版本中，工具不再只是一个一次性函数。它可以在执行过程中向客户端发起请求，让用户补充必要信息，然后继续完成任务。
一句话总结：
Before：AI 工具像一次性函数，参数不够就失败。
After：AI 工具可以像真实助手一样，在关键步骤追问、确认、继续执行。
这会极大提升复杂工具调用的可用性。
尤其是在企业场景中，很多动作不能一把梭执行，而是需要确认、补充、授权和审计。MCP 2.0 的多轮请求机制，正是在补齐这块能力。
四、长任务：从同步阻塞到 Tasks 扩展
MCP 2.0 还引入了 Tasks 扩展，用来处理长时间运行的任务。
这类任务在真实系统里非常常见：
-
生成一份复杂报告；
-
执行一次大规模数据分析；
-
部署一组云资源；
-
扫描一个代码仓库；
-
执行一次批量迁移；
-
跑一次长时间测试。
过去，如果这些任务直接放在一次工具调用里，客户端只能等待请求结束。请求时间越长，失败概率越高，用户体验也越差。
Before：长任务阻塞一次工具调用
这种方式的问题很明显：客户端只能等。
中间进度、取消、失败状态、后续输入请求，都不好表达。
After：启用 Tasks，让长任务后台运行
客户端可以使用 Tasks 方式调用工具：
启用 Tasks 后，工具调用可以返回「任务已创建」。客户端再通过任务状态持续跟踪进度。
一句话总结：
Before：长任务占住一次请求，用户只能等。
After：工具可以返回「任务已创建」，客户端通过任务状态持续跟踪进度。
这让 MCP 更适合处理真实世界中的长流程，而不是只适合做短平快的函数调用。
五、MCP Apps：从纯文本返回到可渲染 UI
MCP 2.0 生态里另一个非常重要的方向，是 MCP Apps。
过去，MCP 工具主要返回文本或结构化 JSON。模型可以理解这些内容，但用户看到的体验往往比较单薄。
例如，一个天气工具返回 JSON：
这对模型足够，但对用户来说不一定直观。
MCP Apps 让工具可以关联一个可由客户端渲染的 HTML UI 资源。这样，MCP 工具不只可以返回数据，还可以带出图表、表单、仪表盘、审批卡片、配置面板等交互界面。
Before：工具只返回文本或 JSON
After：工具关联可视化 UI
服务端启用 MCP Apps：
一句话总结：
Before：模型拿到的是文本，用户看到的是一段描述。
After：工具可以带出一个交互式界面，比如图表、表单、仪表盘或审批卡片。
这非常适合企业应用场景。
例如：
-
数据分析工具返回图表；
-
云资源工具返回拓扑图；
-
审批工具返回确认卡片；
-
配置工具返回表单；
-
运维工具返回监控面板。
MCP Apps 让 MCP 从「工具调用协议」进一步走向「AI 应用协议」。
六、工具 Schema：从文本约定到结构化输出
MCP 2.0 还增强了工具输入输出 Schema 的表达能力。
工具参数和返回值越清晰，模型越容易生成正确调用，客户端也越容易校验、渲染和后续编排。
过去，很多工具会返回一段文本。人能看懂，但系统很难稳定解析。
Before：工具输出主要靠文本约定
这种返回对人可读，但对后续工具编排不友好。
比如下一个工具想根据 Tier 做判断，就必须从文本里提取字段，容易出错。
After：返回结构化对象，Schema 更清晰
进一步复杂的输入也可以用类型表达：
一句话总结：
Before：模型和客户端需要「猜」文本里的结构。
After：输入输出都有明确 Schema，适合校验、编排、UI 渲染和自动化工作流。
这点在 Agent 工作流里尤其重要。
因为 Agent 不只是调用一个工具，而是经常需要把一个工具的输出传给另一个工具。结构化输出越稳定，工作流越可靠。
七、安全与授权：更接近生产级 OAuth
MCP 2.0 还强化了授权体系，使其更贴近 OAuth 和 OpenID Connect 的真实生产部署。
在 C# SDK v2.0.0 的发布内容中，可以看到多项与 OAuth、动态客户端注册、PKCE、授权状态校验相关的修复和增强。
这说明 MCP 正在面向更严肃的企业级场景：不仅要能调用工具，还要能明确：
-
谁在调用？
-
代表谁调用？
-
具备什么权限？
-
授权是否可信？
-
访问是否可审计？
对于涉及企业数据、云资源、数据库、代码仓库和内部系统的 MCP Server 来说，授权能力会成为能否上线生产的关键门槛。
可以把它理解为：
MCP 1.x 更关注「能不能连上工具」。
MCP 2.0 开始关注「能不能安全、合规、可治理地使用工具」。
八、Roots、Sampling、Logging 被标记为弃用
在 MCP 2026-07-28 规范中，Roots、Sampling 和 Logging 被标记为弃用。
这并不代表现有实现立刻失效。
弃用意味着这些能力进入迁移窗口，已有客户端和服务端仍需正确处理相关能力，但新实现不应继续依赖它们。
为什么要这么做？
因为 MCP 正在从早期探索阶段，走向更稳定、更可治理、更可长期演进的阶段。一些采用率有限、语义不够清晰，或者可以通过更明确方式替代的能力，会逐步从核心协议中移出。
这也和 MCP 2.0 的整体方向一致：
核心协议更轻，扩展机制更强，生产语义更清晰。
九、C# SDK v2.0：兼容旧代码，拥抱新协议
对 .NET 开发者来说，最值得放心的一点是：官方 C# SDK v2.0 保持向后兼容。
升级 SDK 不代表你必须立刻重写所有 MCP Server。稳定的 v1 代码仍可以继续编译和运行。
但与此同时，C# SDK v2.0 已经跟进新规范：
-
HTTP Server Transport 支持无状态模式；
-
支持新的协议版本；
-
支持标准化 Header；
-
支持 Elicitation / 多轮请求；
-
支持 Tasks 扩展；
-
支持 MCP Apps 扩展；
-
支持更完整的工具 Schema 表达；
-
改进 OAuth 和授权相关能力。
这让 .NET 成为实现生产级 MCP 服务的一个自然选择。
原因也很直接：ASP.NET Core 本来就擅长做 HTTP 服务、鉴权、中间件、日志、链路追踪、依赖注入、健康检查和云原生部署。MCP 2.0 的无状态协议设计，正好可以复用这些成熟基础设施。
十、这次发布真正意味着什么？
MCP 2.0 的意义，不只是「多了几个功能」。
它真正改变的是 MCP 的部署模型和编程模型。
过去，MCP 更像是 Agent 应用和本地工具之间的连接协议。现在，它正在变成一个可以被企业基础设施承载的 AI 能力协议。
它开始认真考虑：
-
负载均衡；
-
网关路由；
-
缓存；
-
链路追踪；
-
授权；
-
安全；
-
异步任务；
-
用户交互；
-
UI 扩展；
-
结构化输出；
-
长期演进。
这说明 MCP 的下一阶段重点已经非常清晰：
从「能接入工具」，走向「能规模化运行」。
从「开发者实验协议」，走向「生产级 AI 应用基础设施」。
给开发者的迁移建议
如果你已经在使用 MCP Server，可以优先检查下面几件事：
1. 检查 HTTP Server 是否还依赖 Session
如果你的服务部署在多个副本之后，建议优先评估无状态模式：
2. 检查工具是否依赖文本返回
如果工具结果会被后续工具继续使用，建议改成结构化对象返回：
3. 检查长任务是否还在同步阻塞
如果工具执行时间可能超过几十秒，可以考虑 Tasks 扩展，而不是让一次请求一直等待。
4. 检查复杂工具是否需要用户确认
如果工具涉及部署、删除、付款、授权、审批等高风险动作，建议使用 Elicitation / 多轮请求，而不是直接执行。
5. 检查是否需要可视化 UI
如果工具返回的是复杂表格、图表、配置项或审批信息，可以评估 MCP Apps，把用户体验从文本升级到可交互界面。
结语：MCP 2.0 是 Agent 基础设施的重要分水岭
MCP 2.0 的发布，标志着 AI Agent 生态正在进入一个新阶段。
在这个阶段，大家关注的不再只是「模型能不能调用工具」，而是工具如何被治理、如何被观测、如何被授权、如何被扩展、如何在云上稳定运行。
对于开发者，现在是重新审视 MCP Server 架构的好时机：
-
是否还依赖 Session？
-
是否能横向扩展？
-
是否有清晰的授权模型？
-
工具 Schema 是否足够严格？
-
长任务是否有标准表达？
-
交互式任务是否支持用户确认？
-
结果是否能被客户端稳定解析和渲染？
对于企业和平台团队，MCP 2.0 则提供了一个更接近生产要求的协议基础。
如果说 MCP 1.x 打开了模型连接外部世界的大门，那么 MCP 2.0 正在把这扇门修成一条真正可以承载流量、权限、运维和生态的高速公路。
这也是 MCP 2.0 最重要的信号：
Agent 不再只是 Demo。
Agent 正在进入生产系统。
而 MCP，正在成为连接 Agent 与生产世界的基础协议。
参考链接
-
https://github.com/modelcontextprotocol/csharp-sdk/releases/tag/v2.0.0
-
https://devblogs.microsoft.com/dotnet/announcing-v20-of-the-official-mcp-csharp-sdk/
更多推荐
0
0- 0
已为社区贡献15条内容
所有评论(0)