返回博客首页
MCP 2026-07-28 规范发布：无状态化 + 扩展机制，远程 MCP 服务器终于好部署了
本站为独立第三方技术服务平台，提供多模型 API 聚合接入服务，与 Anthropic、OpenAI、Google 等模型提供商无任何关联、授权或合作关系。
核心要点
- MCP 2026-07-28 版规范已发布，据发布说明，这是协议诞生以来最大的一次更新。
- 协议层无状态化：远程 MCP 服务器不再需要维护会话状态，部署和扩容的自由度显著提升。
- 扩展机制成为一等公民：给协议加能力有了正式路径，首批示例包括 MCP Apps、Tasks、企业托管鉴权。
- 鉴权加固 + 正式弃用策略：协议开始有明确的版本演进纪律，长期集成的可预期性变好。
- 对开发者的实际影响：MCP 服务器可以按普通无状态 HTTP 服务的方式来运维；工具层跟模型层进一步解耦，一套工具面向多家模型复用变得更现实。
详细解读
无状态化：这次最实在的改动
在旧的设计下，跑一个远程 MCP 服务器意味着你得替客户端管住会话状态。这件事本身不难，但它把部署形态钉死了：请求必须回到持有该会话的那个进程，于是 Serverless 用不了、边缘节点用不了、负载均衡器后面横向扩容也得靠粘性会话兜着。很多团队最后只能起一台常驻实例，把它当有状态服务养起来。
新规范把状态从协议层拿掉之后，形态一下就松开了：
- 可以部署到 Serverless 与边缘基础设施，冷启动、按量伸缩这些能力才真正用得上；
- 可以放在任意负载均衡器后面横向扩容，不必要求请求粘在同一实例；
- 灰度、滚动发布、多区域多活这些常规做法，直接套用现有的无状态 HTTP 服务经验就行。
换句话说，MCP 服务器从"一个需要小心照顾的长连接服务"，变回了"一个普通的接口服务"。对运维成本的影响，可能比任何一条新特性都大。
扩展机制：不用等规范会议也能加能力
过去想给 MCP 补一块能力，路径挺尴尬——要么等主规范纳入，要么各家自己塞私有字段，互操作性随之破裂。这一版把**扩展（Extensions）**提升为一等公民，给了正式的扩展路径。发布说明里点了三个示例方向：
1. MCP Apps —— 服务端渲染的 UI，跑在沙箱化的 iframe 里。工具的返回不再只能是文本或 JSON，可以是一段可交互界面。表单填写、结果确认、数据表格这类交互，不必再硬塞进对话流。沙箱边界也让"服务端给的 UI"这件事有了安全前提。
2. Tasks —— 长时间运行与异步操作。这是实际工程里最常撞墙的一类需求：跑一次批量数据处理、等一个外部审批、调一个几分钟才出结果的流水线。以前只能自己在工具里造轮子（返回一个 job id，再让模型轮询）。现在协议层有了统一表达，客户端就能统一处理进度、取消和结果回收。
3. 企业托管鉴权（Enterprise Managed Auth） —— 通过企业自己的身份提供商集中管控 MCP 服务器的访问权限。对已有 IdP 的组织来说，这一条决定了 MCP 能不能进生产：谁能连哪个服务器、权限怎么回收、审计怎么落，都归到既有身份体系里管，而不是散在各个客户端配置里。
鉴权加固与弃用策略：不性感，但很重要
这一版还做了鉴权加固，并给出了正式的弃用策略（deprecation policy）。后者容易被忽略，但对做长期集成的团队价值很高——协议怎么废弃旧字段、给多长过渡期、如何标注，有了成文规则，你才敢把 MCP 写进核心链路，而不是每次升级都提心吊胆地做一次兼容性排查。
对开发者意味着什么
第一，MCP 服务器的部署门槛降下来了。 以前上线一个远程 MCP 服务器，你要先回答"状态放哪"；现在这题基本不用答了。个人开发者可以用 Serverless 起一个几乎零成本的服务，团队可以直接复用现有的 K8s / 边缘部署那套流程。
第二，工具层和模型层进一步解耦。 MCP 的核心价值一直是"工具写一次，多个客户端和模型都能用"。无状态化让服务端更容易横向扩，扩展机制让能力边界可以自己往外推——这两件事叠加，"一套工具接多家模型"从设计理念变成了工程上更省事的选择。
第三，异步能力值得重新评估架构。 如果你之前因为"工具调用必须几十秒内返回"而把长任务砍成了一堆碎步骤，Tasks 方向的扩展落地后，这部分设计可以推倒重来。
第四，企业落地的堵点在被逐个清理。 集中鉴权 + 明确的弃用纪律，这两条通常正是安全和架构评审最先追问的问题。
在 Code0 上如何配合使用
MCP 解决的是"模型怎么用工具"，Code0 解决的是"你怎么统一接到各家模型"——两者是互补的两层。工具侧用 MCP 抽象好之后，模型侧换谁调用，只是改一个 model 字段的事：
from openai import OpenAI
client = OpenAI(
base_url="https://hk.code0.ai/v1",
api_key="sk-你的Key", # 在 console.code0.ai 获取
)
resp = client.chat.completions.create(
model="claude-opus-4-8", # 换成 gpt-5.4 / gemini-3-pro / deepseek-v3 即可切换模型
messages=[{"role": "user", "content": "调用工具，帮我查一下本周的构建失败记录"}],
)
print(resp.choices[0].message.content)
Claude 专题场景下也可以用 Anthropic SDK 风格：
from anthropic import Anthropic
client = Anthropic(
base_url="https://hk.code0.ai",
api_key="sk-你的Key",
)
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
messages=[{"role": "user", "content": "你好"}],
)
print(resp.content[0].text)
一个思路供参考：把 MCP 服务器做成无状态的工具层，Agent 的模型调用统一走 Code0。这样工具不用为每家模型各写一份适配，模型也能按任务类型分流——重推理走 Claude Opus 系，长上下文摘要走性价比更高的型号，评测阶段横向比几家再定。具体可用模型与计费规则以 console.code0.ai 控制台为准。
Claude™ 与 Anthropic® 为 Anthropic, PBC 的商标；相关信息以其公开文档与发布说明为准。
总结
这一版 MCP 的重点不在"多了什么炫技功能"，而在把协议往工程可用的方向推了一大步：无状态化解决部署形态，扩展机制解决能力演进，鉴权加固与弃用策略解决长期维护的确定性。
建议的动作很朴素：先去读发布说明确认自己用的客户端/SDK 版本支持情况，再评估现有 MCP 服务器能不能去掉会话依赖、换成无状态部署。至于模型侧，保持一层统一接入抽象，后面无论协议还是模型怎么变，改动都能收敛在一个地方。
想动手试的话，可以从 控制台 注册获取 API Key 开始。
