作者: AI创业内参 | 日期: 2026-07-26 | 类型: Agent工坊

MCP协议2026-07-28版本是自发布以来最大规模的重写——核心变成无状态，initialize握手被移除，Roots/Sampling/Logging三个功能被废弃，新增MCP Apps和Tasks两大扩展。如果你在用Claude Code、Hermes Agent、Cursor或任何MCP工具——你的服务器代码必须在7月28日前完成迁移。

前言：为什么这个更新你必须关注

如果你在用AI Agent做开发、做内容创业、做自动化运营，你大概率已经在用MCP（Model Context Protocol）了。它是Anthropic制定的开放标准，让AI模型能安全地连接到外部工具和数据源——相当于AI世界的"USB-C接口"。

截止2026年7月，几乎所有主流AI Agent框架都支持MCP：Claude Code、Codex、Cursor、Hermes Agent、Windsurf、Copilot……构建在这个协议上的MCP服务器已经超过数万个，覆盖从数据库查询到浏览器操控的各类场景。

7月28日，这个协议的史上最大更新将正式发布。这不是小修小补——它重写了核心传输模型，废弃了三个你大概率在用的功能，强化了授权机制，还新增了两个重量级扩展。

一句话总结：无状态化。你的MCP服务器不再需要"记住"客户端是谁。每个请求自包含，任何实例都能处理。

这对AI创业者意味着什么？意味着MCP服务器可以真正水平扩展、可以跑在Serverless上、可以用普通负载均衡器分发流量。但也意味着，你现有的MCP代码必须改。

下面我们拆解：什么变了、什么废了、什么新增了、怎么迁移。

一、核心变化：无状态化——最根本的改变

旧模式（2025-11-25）：有状态，绑定实例

在旧版MCP中，调用一个工具需要先建立会话：

客户端 → POST /mcp {initialize, 带上protocolVersion和capabilities}
服务器 → 返回 Mcp-Session-Id: 1868a90c-3a3f-4f5b...
客户端 → POST /mcp (携带 Mcp-Session-Id Header) {tools/call, ...}

这意味着什么？客户端被绑定到了签发Session的那个服务器实例上。 如果你的MCP服务器部署了5个实例，客户端只能跟它初次握手的那个实例对话。一旦那个实例挂了，会话丢失，所有状态烟消云散。

部署层面，这要求负载均衡器支持粘性会话（sticky sessions），或者在实例之间共享session存储。无论是哪种方案，都增加了运维复杂度。

新模式（2026-07-28）：无状态，自包含请求

新的请求变成了这样：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {"q": "AI agent"},
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app", "version": "1.0"
      }
    }
  }
}

注意三个关键变化：

不再需要initialize握手。协议版本、客户端信息、能力声明全都塞进了每个请求的_meta字段。
不再有Mcp-Session-Id。任何请求可以落到任何服务器实例。
新增Mcp-Method和Mcp-Name头。负载均衡器和网关不需要解析请求体就能路由——直接读Header即可。

那需要保持状态怎么办？

协议层不再管理状态，但你的应用仍然可以保持状态。MCP维护者给出的推荐模式是显式句柄：让工具返回一个明确的标识符（比如basket_id、browser_id），然后由LLM在后续调用中自动传递这个标识符。

# 工具1: 创建购物车，返回basket_id
def create_basket():
    basket_id = uuid.uuid4().hex
    db.create_basket(basket_id)
    return {"basket_id": basket_id, "status": "created"}

# 工具2: 添加到购物车，LLM自动传入basket_id
def add_to_basket(basket_id: str, item: str):
    db.add_item(basket_id, item)
    return {"basket_id": basket_id, "items": db.get_items(basket_id)}

维护者的原话是："这个模式不仅可行，而且往往比隐藏在传输元数据里的session状态更强大——模型可以在工具间组合句柄、推理它们的关系、在工作流步骤间传递它们。"

二、三个功能被正式废弃——你可能在用的

MCP 2026-07-28废弃了三个从早期就存在的功能。注意：废弃不是删除——按照新引入的生命周期政策，废弃功能至少有12个月的缓冲期才会被真正移除。但方向已定，现在就该开始替换。

1. Roots（工作区边界）

Roots让客户端告诉服务器"我的文件系统边界在哪里"，帮助服务器做权限控制。如果你在Claude Code里配置过项目根目录，用的就是这个功能。

替代方向：通过工具参数显式传递工作路径，或通过_meta携带上下文信息。

2. Sampling（采样/生成）

Sampling允许服务器反向调用客户端的LLM——比如一个MCP服务器需要"总结这段文本"时，它可以让客户端的模型来生成。这个功能的设计很酷，但实际使用率很低。

替代方向：直接在服务器端调用模型API，或使用Tasks扩展的异步模式。

3. Logging（协议级日志）

Logging是服务器向客户端发送日志通知的协议级机制。

替代方向：使用标准化的W3C Trace Context（traceparent、tracestate），对接OpenTelemetry。2026-07-28已经在_meta中标准化了tracing key名称，SDK间可以直接串联链路。

三、两大新增扩展：MCP Apps和Tasks

MCP Apps：服务器渲染的UI界面

这是本次更新中最令人兴奋的新功能。MCP服务器不再只能返回文本——它可以返回一个完整的交互界面。

一个工具调用返回的不再是字符串，而是一个沙箱化的HTML界面。客户端在iframe中渲染它，用户可以操作表单、查看表格、使用控制面板。

这意味着什么？意味着你以前需要单独开发前端的功能——数据看板、配置页面、审批界面——现在可以直接由MCP服务器提供。一个工具调用就能弹出完整的UI。

适用场景：
- 数据库查询工具返回可视化结果表格
- 部署工具返回可操作的发布确认面板
- 数据分析工具返回交互式图表

Tasks：长运行任务的一等公民

Tasks从实验性功能升级为正式扩展。它专为那些不能在一次请求-响应内完成的操作设计：构建任务、部署任务、长时间Agent运行、批处理作业。

因为核心已经无状态化，Tasks不再依赖保持连接（以前是通过SSE流实现）。新模型是基于可恢复、可轮询的状态：任何服务器实例只要连接到共享任务存储，就能报告或推进一个Task。

# 客户端发起一个长任务
tools/call {name: "deploy", arguments: {branch: "main"}}
# 服务器返回任务句柄而不是结果
→ {"resultType": "taskCreated", "taskId": "abc-123", "status": "running"}

# 客户端轮询
tasks/get {taskId: "abc-123"}
→ {"status": "completed", "result": {...}}

四、授权和安全：OAuth/OIDC全面收紧

新版本的授权机制显著收紧，全面对齐OAuth和OpenID Connect标准：

更严格的Token验证：对issuer、audience、scope的验证更加严格
动态客户端注册优化：桌面/CLI客户端现在能正确声明application_type，避免被授权服务器误判为Web应用
Resource Indicators强制要求：客户端必须实现RFC 8707的资源指示器，防止恶意服务器获取访问令牌

如果你运行任何带认证的MCP服务器，必须测试你的token验证逻辑与RC的兼容性。

五、迁移清单：3个角色各自要做什么

如果你是MCP服务器作者

□ 1. 阅读Release Candidate全文
   → https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

□ 2. 移除initialize握手路径
   → 不再把initialize当作第一条必需消息
   → 每个请求当作自包含处理

□ 3. 外部化session状态
   → 将per-session数据移到Redis/PostgreSQL等外部存储
   → 或使用显式句柄模式让LLM自己管理状态

□ 4. 添加Mcp-Method和Mcp-Name Header解析
   → 用Header做路由，不解析body

□ 5. 工具schema升级到JSON Schema 2020-12
   → 用2020-12 validator验证所有工具schema
   → 修复之前靠validator宽松容忍的schema问题

□ 6. 废弃功能替换
   → Roots → 工具参数显式传递
   → Sampling → 服务器端直接调模型API
   → Logging → W3C Trace Context + OpenTelemetry

□ 7. 升级SDK到支持2026-07-28的版本
   → Python: mcp>=1.x（检查最新版本）
   → TypeScript: @modelcontextprotocol/sdk>=最新版

如果你是MCP客户端/Agent开发者

□ 1. 更新客户端SDK
   → 确保能发送MCP-Protocol-Version: 2026-07-28

□ 2. 在_meta中携带clientInfo
   → 每个请求都要带，不再依赖initialize

□ 3. 使用server/discover获取服务端能力
   → 替代旧initialize中返回的capabilities

□ 4. 处理InputRequiredResult
   → 替代旧的SSE流等待模式
   → 将inputResponses和requestState重新提交

□ 5. 遵守tools/list的ttlMs缓存
   → 在有效期内不重复请求

如果你是MCP工具使用者（用Claude Code/Cursor/Hermes等）

□ 1. 升级你的Agent工具到最新版本
   → Claude Code: claude update
   → Hermes Agent: hermes update
   → Cursor: 自动更新

□ 2. 检查你安装的MCP服务器
   → 去GitHub查看服务器是否已发布2026-07-28兼容版本
   → 优先升级，未更新的可能在7月28日后不兼容

□ 3. 测试关键工作流
   → 在新版本Agent上跑一遍日常任务
   → 发现异常联系服务器维护者

六、7月28日之前做什么？

硬截止日：2026年7月28日。今天距离截止日不到2周。

立即行动（本周）：
- 更新你的Agent工具（Claude Code、Hermes、Cursor等）到最新版本
- 列出所有依赖的MCP服务器，去GitHub检查兼容状态

下周：
- 如果你是服务器作者，启动迁移
- 如果你是重度用户，在测试环境验证新版本不破坏现有工作流

7月28日当天：
- 所有Tier 1 SDK将完成更新
- 检查你的工具链是否全部正常工作

总结：这次更新的本质

MCP 2026-07-28的本质就一句话：从"开发机协议"升级为"生产级协议"。

无状态化是为了水平扩展；Mcp-Method头是为了让网关和负载均衡器工作；ttlMs缓存是为了减少不必要请求；废弃的Roots/Sampling/Logging是为了精简核心，把能力放到扩展中按需加载；MCP Apps是为了让工具的能力从"返回文字"升级到"返回交互"；Tasks是为了让长任务有一个标准化的生命周期。

对于AI创业者，好消息是：迁移工作虽不轻松，但方向明确。坏消息是：时间紧迫。今天就动手。

参考资料
- MCP 2026-07-28 Release Candidate: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate
- What Breaks and How to Migrate: https://www.developersdigest.tech/blog/mcp-2026-07-28-breaking-changes
- MCP 2026 Roadmap: https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/

AI创业 #MCP协议 #Agent工坊 #一人公司 #AI工具