2025年12月9日，Anthropic把Model Context Protocol捐赠给Linux Foundation旗下新成立的Agentic AI Foundation，与Block的goose和OpenAI的AGENTS.md并列三大创始项目。八个月后，2026年7月28日，MCP发布了自诞生以来最大的一次规范修订——版本号直接定为2026-07-28。维护者称其为"协议启动以来最大的修订"，这不是营销话术：整个会话模型被删除，初始化握手被移除，三项核心特性被废弃，授权机制全面重写，扩展框架正式成为一等公民。
这次修订的核心可以用一句话概括：MCP从一个有状态协议变成了完全无状态协议。这意味着每个请求自带全部上下文，任何服务器实例都能处理任何请求，不再需要粘性路由或共享会话存储。对于在负载均衡后面跑多个MCP服务器实例的团队来说，这一变化直接消灭了一整层只为绕开协议限制而存在的基础设施。
本文拆解2026-07-28规范的六个关键技术变化，从旧模型为什么撑不住讲起，到无状态核心的实现机制、Handle替代session的范式转换、OAuth 2.1安全加固、扩展框架与废弃清单，最后给出一份可以直接跑起来的迁移代码。
旧session模型为什么撑不住
要理解为什么去掉session，得先看清旧模型到底在哪里断裂。
MCP从2024年11月5日的初始规范到2025-11-25版本，一直采用有状态连接模型。客户端连接服务器时，先执行两步握手：第一步发initialize请求，交换协议版本、客户端信息和能力声明；第二步发initialized通知，确认握手完成。服务器在握手期间返回一个Mcp-Session-Id头，此后客户端的每一个请求都必须回到同一个服务器实例——因为只有那个实例认识这个session票据。
用一个具体场景说明这个模型为什么脆弱。假设你搭了一个MCP服务器叫Slotly，让AI Agent替用户预订会议室。一个进程跑了几个月没问题。然后流量上来，你把Slotly扩到三个实例放在负载均衡后面。实例A发出了session票据，但下一个请求被负载均衡路由到实例B，实例B从未见过这个票据，直接报错。对用户来说，预订流程莫名其妙失败了；对团队来说，排查这个bug要花一整个下午才能追溯到"又是session的问题"。
现有团队解决这个问题的办法有两种。第一种是粘性路由：负载均衡器记住哪个客户端绑在哪个实例上，后续请求一律送到同一个实例。第二种是共享会话存储：所有实例都能查到所有session票据，通常用Redis。两种方案都能跑，但它们都是纯粹为了绕开协议限制而搭建的额外基础设施。更麻烦的是，在API网关层做深度包检查来路由请求，不仅要解析JSON-RPC请求体找到方法名，还要维护session到实例的映射表——这些全是不应在协议层面存在的运维负担。
无状态核心三件套
2026-07-28规范用三个机制组合在一起，彻底消灭了session模型。
第一件：_meta字段。每个请求现在在JSON-RPC的_meta字段里自带协议版本、客户端信息和客户端能力声明。以前这些信息只在initialize握手中交换一次，服务器存在session上下文里。现在每个请求都携带，任何实例拿到请求就能立刻知道对方说什么版本的协议、客户端是谁、支持哪些能力。不需要握手，不需要session，不需要"记住之前聊过什么"。
第二件：Mcp-Method和Mcp-Name两个新HTTP头。客户端每次调用都带上这两个头：Mcp-Method标明JSON-RPC方法名（如tools/call），Mcp-Name标明工具或资源名称（如search）。这两个头让API网关可以不解析请求体就能路由流量，这比旧的深度包检查方案高效得多。网关读HTTP头做路由决策，是标准HTTP基础设施早就擅长的事情。
第三件：server/discover方法。旧的initialize握手被移除后，客户端需要一个新方式获取服务器能力声明。新规范提供server/discover方法：客户端按需调用，服务器返回自己的能力清单。这个调用本身也是无状态的——每次调用都返回当前能力，不依赖之前的连接历史。
| 特性 | 旧规范（2025-11-25） | 新规范（2026-07-28） |
|---|---|---|
| 连接初始化 | 两步initialize/initialized握手 | 无握手，直接发请求 |
| 会话标识 | Mcp-Session-Id头 | 已删除 |
| 协议版本传递 | 握手时交换一次 | 每请求_meta字段携带 |
| 网关路由 | 深度包检查JSON-RPC体 | 读Mcp-Method/Mcp-Name头 |
| 多实例部署 | 粘性路由或共享session存储 | 普通round-robin负载均衡 |
| 服务器能力发现 | initialize响应中返回 | 按需调用server/discover |
Handle替代session state
去掉session不意味着应用本身不能有状态。MCP服务器仍然需要记住跨调用的中间状态——比如Agent正在分步骤预订会议室，选了时间还没选餐饮。新规范的要求是：状态从协议层的隐藏管道里拿出来，变成显式的Handle。
具体做法是：工具调用返回一个显式标识符。比如Slotly的预订工具返回一个booking_id，Agent在后续调用中把这个booking_id作为普通参数传回来。服务器自己决定怎么存这些状态——Postgres、Redis、内存里都行——booking_id只是一个指针。这种模式比隐藏的session状态更强大，因为Agent能看到、能推理自己持有哪些Handle，能在不同工具之间组合传递，能在步骤之间交接。
但这也带来一个之前由协议代为处理的责任：那个booking_id必须绑定到创建它的用户，并且必须有过期机制。一个永不过期、任何人拿到字符串就能用的Handle，本质上是一个穿了马甲的永久访问令牌。新规范在授权部分专门处理了这个问题。
从实现角度仔细看这个范式转换。旧session模型下，客户端连上服务器后，服务器在内存里维护一个session对象，存着这个连接的所有中间状态——当前预订的房间、选了什么时间、有没有加餐饮、流程走到了哪一步。客户端不需要知道这些细节，它只管发请求，服务器在session上下文里找到之前的数据接着往下走。这种模式看似方便，但有个根本缺陷：Agent无法看见自己持有什么状态，也无法推理这些状态之间的关系。如果Agent同时操作两个预订——一个在选时间、一个在等确认——旧session模型下这两个流程的状态分别绑定在两个连接上，Agent无法把它们交叉组合，因为它们在不同的session管道里。
Handle模式完全改变了这个局面。每次create_booking返回的booking_id是一个Agent可以看见、可以持有、可以传递的显式标识符。Agent拿到两个booking_id后，可以自由地把一个预订的时间信息传递给另一个工具，可以在不同预订之间交叉引用。状态不再是隐藏在协议管道里的隐形线索，而是Agent可以像操作普通数据一样操作的显式输入输出。这种可见性也让审计变得简单——你只需要记录哪个Handle被传给了哪个工具，就能完整重建Agent的操作路径。session模型下要重建这种审计轨迹，你得去翻服务器的session日志，而且不同实例的session日志可能散落在不同机器上。
OAuth 2.1安全加固
旧版MCP规范的授权模型可以说是"自带令牌"——规范定义了基本框架，但把所有安全细节留给实现者自行处理，导致每个MCP服务器的授权实现都不一样。2026-07-28规范用六个SEP（Specification Enhancement Proposal）把授权从"理论上可行"拉到"照着RFC做就行"。
第一，MCP服务器正式成为OAuth 2.1资源服务器。服务器必须实现OAuth 2.0 Protected Resource Metadata（RFC 9728），暴露.well-known/oauth-protected-resource端点，让客户端自动发现正确的授权服务器。客户端必须实现Resource Indicators（RFC 8707），在令牌请求中明确指定令牌是给哪个MCP服务器用的。这直接解决了confused deputy问题：为服务器A签发的令牌无法被重放到服务器B，因为令牌里绑定了目标服务器标识。
第二，Client ID Metadata Documents（CIMD）替代Dynamic Client Registration（DCR）。DCR（RFC 7591）被废弃，只保留向后兼容。CIMD让客户端注册变成一个URL就能搞定的操作——客户端把自己的元数据文档发布到一个HTTPS URL上，授权服务器直接读取这个URL完成注册。这消除了DCR的无边界客户端注册问题，也让客户端身份可以被独立验证。
第三，发行方验证变为强制要求。客户端必须验证授权响应来自哪个授权服务器（基于RFC 9207），必须把注册凭据绑定到发行授权服务器的issuer标识。如果一个资源在授权服务器之间迁移，客户端必须重新注册。这防止了一类混合攻击：当一个客户端同时与多个MCP服务器通信时（这恰好是MCP鼓励的部署模式），令牌不能在服务器之间混用。
第四，刷新令牌处理被正式文档化（SEP-2207），step-up授权的scope累积行为也被明确（SEP-2350）。之前刷新令牌行为未定义，每个实现各做各的。第五，客户端注册时必须声明OpenID Connect的application_type（SEP-837），解决了授权服务器把桌面或CLI客户端默认当成web应用然后拒绝localhost回调的常见问题。
这六项SEP叠加起来的效果，是把MCP授权从"理论上可行，你自己接"变成"照着这些RFC做就行"。之前一个团队想给MCP服务器加企业身份认证，要从头设计令牌签发、验证、刷新逻辑，每个实现都不一样，互操作性很差。新规范直接对齐OAuth 2.1和OpenID Connect的标准实践，RFC 9728定义资源服务器元数据发现，RFC 8707定义令牌绑定到特定服务器，RFC 9207定义发行方验证，CIMD定义客户端注册。对于在Okta、Azure AD、Google Workspace后面跑MCP服务器的企业团队来说，从"未认证的MCP服务器"到"规范级安全的MCP服务器"的路径现在在规范层面就画清楚了，不再是留作练习。EMA（Enterprise-Managed Authorization）作为配套特性在7月28日发布前就已经先行落地，它让企业的身份提供商集中控制谁能访问哪些MCP服务器，不需要每个人每个服务器点一次同意——这对两百人规模以上的组织来说是刚需。
扩展框架与废弃清单
2026-07-28规范引入了正式的扩展框架。扩展获得反向DNS标识符、独立仓库、委托维护者和独立于主规范的版本号。客户端和服务器通过capabilities中的extensions映射协商扩展支持。两个扩展随发布候选一起推出。
MCP Apps让服务器直接在客户端渲染交互式HTML界面。渲染出来的UI运行在沙箱iframe里，与宿主通过标准JSON-RPC通信。这意味着UI发起的每次操作都走与普通工具调用相同的审计和同意路径。服务器可以声明工具附带一个日历选择器UI，客户端预取、缓存、审查后渲染，用户在日历里的每次点击都经过同意层。MCP Apps可能是把MCP从开发者集成层推向用户生态系统的关键原语。
Tasks为长时间运行的异步工作提供一等支持。Tasks在2025-11-25规范中是实验性核心特性，但生产使用暴露了足够多设计问题，于是被移到扩展并重新设计。服务器用tools/call返回一个task handle，客户端用tasks/get轮询结果、tasks/update发送输入、tasks/cancel停止任务。旧的tasks/list端点被移除，因为没有session它无法安全地做范围限定。任何基于旧实验性Tasks API构建的代码都需要迁移到新生命周期。
三项核心特性在此版本中被废弃：Roots被Resource URI（普通URL）替代；Sampling从核心规范中移除，可能作为扩展回归；Logging也从核心规范中移除。规范首次引入正式废弃策略——被废弃的特性会被文档化，在过渡期内继续工作，最终按明确时间线被移除。这给了实现者至少十二个月的迁移窗口。
另外两个值得注意的变化：工具输入schema现在支持完整的JSON Schema 2020-12，替代之前受限的子集——工具可以声明"接受room ID或room name"这样的oneOf结构了。错误码"Resource not found"从自定义的-32002改为标准JSON-RPC的-32602。
正式废弃策略本身也值得展开说。之前的MCP规范没有结构化的废弃流程——特性有时被默默移除，有时被改了行为但没有迁移窗口，实现者经常在升级SDK后才发现某个功能已经不工作了。2026-07-28引入的废弃策略分三个阶段：首先，被废弃的特性在规范文档中被明确标注为deprecated，附带替代方案和迁移指南；其次，在过渡期内（至少十二个月）继续正常工作，给实现者足够的时间迁移；最后，在明确的时间线到期后被正式移除。这三步让协议可以有序演化而不制造混乱。对于Roots来说，替代方案是Resource URI——就是普通URL，本来就用Roots做文件系统路径映射的团队只需要把路径改成URL格式。Sampling从核心规范移除后可能作为扩展回归，因为它在实际使用中有场景（让服务器请求客户端做模型推理），但放进核心会增加所有实现者的负担。Logging同样移出核心，因为它和JSON-RPC的日志能力有重叠，放在扩展里更合适。
完整迁移代码示例
下面是一个完整的无状态MCP服务器实现，用Python和FastAPI搭建，展示了2026-07-28规范的全部关键模式：从_meta读取协议版本、用Mcp-Method/Mcp-Name头做路由、返回显式Handle、暴露OAuth 2.1 Protected Resource Metadata端点。这个服务器可以直接跑起来，用curl测试。
#!/usr/bin/env python3
"""
无状态 MCP 服务器示例 — 符合 2026-07-28 规范
依赖: pip install fastapi uvicorn pydantic
运行: python mcp_stateless_server.py
测试: curl -X POST http://localhost:8000/mcp \
-H "MCP-Protocol-Version: 2026-07-28" \
-H "Mcp-Method: tools/call" \
-H "Mcp-Name: create_booking" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"create_booking","arguments":{"room":"A301","time":"2026-10-09T14:00"}}}'
"""
import json
import time
import uuid
from datetime import datetime, timezone, timedelta
from typing import Any
from fastapi import FastAPI, Request, Response
from fastapi.responses import JSONResponse
from pydantic import BaseModel
app = FastAPI(title="Stateless MCP Server")
# ---- Handle 存储（生产环境换成 Redis 或 Postgres） ----
# 每个 handle 绑定用户、30分钟过期，防止变成永久令牌
_HANDLES: dict[str, dict[str, Any]] = {}
HANDLE_TTL = 1800 # 30 分钟
def create_handle(user_id: str, data: dict) -> str:
"""创建显式 Handle，绑定用户，设置过期时间。"""
handle_id = f"booking_{uuid.uuid4().hex[:12]}"
_HANDLES[handle_id] = {
"user_id": user_id,
"data": data,
"expires_at": datetime.now(timezone.utc) + timedelta(seconds=HANDLE_TTL),
}
return handle_id
def resolve_handle(handle_id: str, user_id: str) -> dict | None:
"""解析 Handle，验证归属和过期。"""
record = _HANDLES.get(handle_id)
if record is None:
return None
if datetime.now(timezone.utc) > record["expires_at"]:
_HANDLES.pop(handle_id, None)
return None
if record["user_id"] != user_id:
return None # Handle 不属于此用户
return record["data"]
# ---- OAuth 2.1 Protected Resource Metadata (RFC 9728) ----
@app.get("/.well-known/oauth-protected-resource")
async def protected_resource_metadata() -> dict:
"""RFC 9728: 让客户端自动发现授权服务器。"""
return {
"resource": "https://mcp-slotly.example.com",
"authorization_servers": ["https://auth.example.com"],
"bearer_methods_supported": ["header"],
"resource_signing_alg_values_supported": ["RS256"],
}
# ---- server/discover 方法 ----
@app.get("/.well-known/mcp-server")
async def server_metadata() -> dict:
"""server/discover 的 HTTP GET 形式，返回服务器能力。"""
return {
"protocol_version": "2026-07-28",
"server_info": {"name": "slotly-mcp", "version": "1.0.0"},
"capabilities": {
"tools": {"listChanged": False},
"extensions": {
"io.github.mcp.apps": {"version": "1.0.0"},
},
},
"extensions": [
{"id": "io.github.mcp.apps", "version": "1.0.0"},
],
}
# ---- 主 MCP 端点：无状态处理 ----
@app.post("/mcp")
async def handle_mcp(request: Request) -> Response:
"""
无状态 MCP 端点。
每个请求从 _meta 和 HTTP 头读取全部上下文，
不依赖 session，任何实例都能处理任何请求。
"""
# 从 HTTP 头读取路由信息（网关也可用这些头做路由）
protocol_version = request.headers.get("MCP-Protocol-Version", "unknown")
method = request.headers.get("Mcp-Method", "")
name = request.headers.get("Mcp-Name", "")
# 从 _meta 读取客户端信息和能力（替代旧的 initialize 握手）
body = await request.json()
meta = body.get("_meta", {})
client_info = meta.get("client", {})
client_capabilities = meta.get("capabilities", {})
# 从 Authorization 头提取用户身份（OAuth 2.1 Bearer Token）
auth_header = request.headers.get("Authorization", "")
user_id = extract_user_from_token(auth_header)
if not user_id:
return JSONResponse(
status_code=401,
content={
"jsonrpc": "2.0",
"id": body.get("id"),
"error": {"code": -32602, "message": "Unauthorized"},
},
headers={"WWW-Authenticate": 'Bearer realm="mcp"'},
)
# 根据 Mcp-Method 路由（网关层也可用同样逻辑）
if method == "server/discover":
return _build_response(body, {
"protocolVersion": protocol_version,
"serverInfo": {"name": "slotly-mcp", "version": "1.0.0"},
"capabilities": {"tools": {}, "extensions": {}},
})
if method == "tools/list":
return _build_response(body, {"tools": _get_tool_list()})
if method == "tools/call":
tool_name = name or body.get("params", {}).get("name", "")
args = body.get("params", {}).get("arguments", {})
result = _dispatch_tool(tool_name, args, user_id)
return _build_response(body, result)
return _build_response(body, {
"error": {"code": -32601, "message": f"Method not found: {method}"}
})
def extract_user_from_token(auth_header: str) -> str | None:
"""从 Bearer token 提取用户标识（生产环境用 JWT 验证）。"""
if not auth_header.startswith("Bearer "):
return None
token = auth_header[7:]
# 生产环境：验证 JWT、检查 Resource Indicator (RFC 8707)
# 示例直接用 token 前缀当 user_id
return f"user_{token[:8]}" if len(token) >= 8 else None
def _get_tool_list() -> list[dict]:
return [
{
"name": "create_booking",
"description": "创建会议室预订，返回 booking handle",
"inputSchema": {
"type": "object",
"properties": {
"room": {"type": "string", "description": "会议室编号"},
"time": {"type": "string", "description": "ISO 8601 时间"},
},
"required": ["room", "time"],
},
},
{
"name": "add_catering",
"description": "为已有预订添加餐饮，需传入 booking handle",
"inputSchema": {
"type": "object",
"properties": {
"booking_id": {"type": "string", "description": "create_booking 返回的 handle"},
"menu": {"type": "string", "description": "餐单选项"},
},
"required": ["booking_id", "menu"],
},
},
{
"name": "confirm_booking",
"description": "确认预订，完成流程",
"inputSchema": {
"type": "object",
"properties": {
"booking_id": {"type": "string", "description": "booking handle"},
},
"required": ["booking_id"],
},
},
]
def _dispatch_tool(tool_name: str, args: dict, user_id: str) -> dict:
if tool_name == "create_booking":
handle = create_handle(user_id, {
"room": args.get("room"),
"time": args.get("time"),
"catering": None,
"status": "draft",
})
return {"content": [{"type": "text", "text": json.dumps({
"booking_id": handle,
"room": args.get("room"),
"time": args.get("time"),
"status": "draft",
"expires_in": HANDLE_TTL,
}, ensure_ascii=False)}]}
if tool_name == "add_catering":
booking_id = args.get("booking_id")
data = resolve_handle(booking_id, user_id)
if data is None:
return {"content": [{"type": "text", "text": "Handle 无效或已过期"}]}
data["catering"] = args.get("menu")
return {"content": [{"type": "text", "text": json.dumps({
"booking_id": booking_id, "catering": data["catering"],
}, ensure_ascii=False)}]}
if tool_name == "confirm_booking":
booking_id = args.get("booking_id")
data = resolve_handle(booking_id, user_id)
if data is None:
return {"content": [{"type": "text", "text": "Handle 无效或已过期"}]}
data["status"] = "confirmed"
return {"content": [{"type": "text", "text": json.dumps({
"booking_id": booking_id, "status": "confirmed",
"room": data["room"], "time": data["time"],
"catering": data.get("catering"),
}, ensure_ascii=False)}]}
return {"content": [{"type": "text", "text": f"未知工具: {tool_name}"}]}
def _build_response(request_body: dict, result: dict) -> Response:
return Response(
content=json.dumps({
"jsonrpc": "2.0",
"id": request_body.get("id"),
"result": result,
}, ensure_ascii=False),
media_type="application/json",
headers={
"MCP-Protocol-Version": "2026-07-28",
"Cache-Control": "public, max-age=300",
},
)
if __name__ == "__main__":
import uvicorn
print("无状态 MCP 服务器启动在 http://localhost:8000")
print("OAuth 元数据: http://localhost:8000/.well-known/oauth-protected-resource")
print("服务器发现: http://localhost:8000/.well-known/mcp-server")
print("MCP 端点: POST http://localhost:8000/mcp")
uvicorn.run(app, host="0.0.0.0", port=8000)
这段代码展示的无状态模式有几个关键点值得逐条说明。handle_mcp函数从HTTP头和_meta字段读取全部上下文，没有任何地方依赖session或全局连接状态。create_handle函数创建的每个Handle都绑定了user_id并设了30分钟过期——这就是新规范要求的"Handle不能变成永久令牌"。protected_resource_metadata端点暴露RFC 9728要求的元数据，让客户端自动发现授权服务器。tools/list响应带了Cache-Control头和max-age，客户端可以在ttlMs允许的窗口内缓存列表，减少重复请求。
用curl测试这个服务器的完整流程分三步。第一步创建预订：POST到/mcp，带Mcp-Method: tools/call和Mcp-Name: create_booking头，Authorization头带Bearer token，body里的arguments包含room和time。服务器返回一个booking_id handle。第二步添加餐饮：同样的端点，Mcp-Name改成add_catering，arguments里把第一步拿到的booking_id传回来，附上menu选项。第三步确认预订：Mcp-Name改成confirm_booking，只传booking_id。整个流程中三个请求可以打到三个不同的服务器实例——因为没有session，任何实例都能处理任何请求。
迁移检查清单
如果你的团队正在运行生产环境的MCP服务器，在迁移到2026-07-28规范时，下面这些是必须完成的工作项。
第一，拆除session初始化逻辑。initialize/initialized握手已经不存在，不需要等待它完成。从_meta字段读取协议版本、客户端信息和能力，替代从initialize响应中读取。第二，客户端侧添加Mcp-Method和Mcp-Name头到每个请求，确保负载均衡器或API网关能用这两个头做路由。第三，把任何依赖Mcp-Session-Id的状态迁移到显式Handle。找到服务器代码里所有存储或读取session绑定状态的地方，替换为工具返回的显式标识符，确保Handle绑定了正确的用户并设置了过期时间。第四，把Tasks代码从旧的阻塞模式迁移到新的轮询扩展模式。第五，审计OAuth实现：检查是否暴露了.well-known/oauth-protected-resource端点，客户端是否实现了Resource Indicators，iss字段验证是否到位。第六，在代码库中搜索字面量-32002替换为-32602。第七，在多实例部署下跑完整测试套件：部署多个服务器实例放在round-robin负载均衡后面，跑测试，任何失败的测试都指向你遗漏的隐藏session依赖。
一级SDK——Python和TypeScript——预计在7月28日最终规范发布前就具备完整支持。二级SDK包括Go、C#等会稍后跟进。DCR被废弃但保留向后兼容，所以现有基于DCR的客户端不会立刻断掉，但应该尽快迁移到CIMD。Roots、Sampling和Logging三项废弃特性至少有十二个月的过渡期，在此期间继续工作，但应该开始规划迁移。Roots变成Resource URI，就是普通URL；Sampling可能作为扩展回归；Logging移出核心规范。
这里值得单独展开说说无状态化对生产部署的实际影响。Cloudflare在2026年8月5日专门发了一篇文章，标题就叫"Scaling AI Agent Infrastructure with the MCP Stateless updates"——用Google的工程师写的这篇文章的题目就点明了核心变化：无状态化是MCP能大规模扩展的前提。之前的session模型要求sticky routing，这意味着负载均衡器要维护客户端到实例的映射表，实例重启时映射表清空，需要重新握手，期间所有请求都会失败。无状态后，任何实例都能处理任何请求，实例可以随时重启、随时扩缩容、随时被替换，不需要担心session状态丢失。这也让MCP服务器可以直接跑在Cloudflare Workers或任何普通HTTP基础设施上，不需要专门的MCP托管服务。
从更宏观的视角看，2026-07-28规范标志着MCP从一个实验性的Agent工具连接协议，转变为可以支撑企业级生产部署的基础设施。无状态核心让它能跑在标准的HTTP负载均衡基础设施上，OAuth 2.1对齐让它能接入企业身份提供商（Okta、Azure AD、Google Workspace），正式废弃策略让协议可以有序演化而不破坏现有实现。MCP加入AAIF后第一次大版本修订，就交出了一份"消除自身技术债同时加固安全模型"的答卷。对于在这个协议上构建产品的团队来说，迁移窗口已经打开，该动起来了。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/deepseek23/article/details/167274978
