面试官把问题抛过来：“7 月 28 日发布的新版 MCP，看了吗？”
你心里一喜，这题昨晚刚看过，张口就来：“Tasks 被移到扩展，还增加了 MCP Apps 和不少安全更新……”
“停。”面试官没让你把第二页背完，“新版连 initialize 和 Mcp-Session-Id 都删了。一个协议发展快两年，为什么最大的升级反而是在删东西？”
你准备好的更新日志突然失去了用武之地。要接住这个问题，不能继续背字段，得把 MCP 快两年的路重新走一遍。
先把这里的 session 说准：并不是所有旧版 MCP Server 都必须使用它。旧版 Streamable HTTP Server 可以选择签发 Mcp-Session-Id，像保存一本“接待记录”。只有一台 Server 时，记性好是优点；扩容成多台以后，后续请求要么固定找原来的接待员，要么所有人共用一本小本本。
所以这道题真正问的是：远程 MCP 为什么曾经允许协议替应用保存会话，现在又主动关掉了这条路？答案可以压成三步：先解决怎么接，再解决怎么安全地远程接，最后解决怎么大规模地接。
一、2024：先给 Agent 做一个统一插座
“得从 2024 年讲起。”你说。
2024 年 11 月，Anthropic 开源 MCP。当时最直接的问题是：每个 AI 应用都在单独适配数据库、文件系统、GitHub 和企业工具。应用和数据源一多，连接代码就会成倍增长。
MCP 借鉴了 LSP 的思路，把交互统一成 Host、Client 和 Server，并基于 JSON-RPC 定义了 Tools、Resources、Prompts 等能力。
这时的主要场景，是桌面客户端通过 stdio 连接本地 Server。客户端先 initialize，双方交换版本和能力，再维持一段有状态的逻辑连接。这里还没有 HTTP 的 Mcp-Session-Id，但“连接记住双方协商结果”的设计很自然：进程就在本机，连接也相对稳定。
“所以第一阶段，MCP 解决的是模型怎么用同一种方式看数据、调工具。”
二、2025 上半年：从“能连”走向“敢放到线上”
面试官接着问：“本地跑通了，为什么还要改传输和授权？”
“因为远程以后，问题不再只是能不能调用。”
网络中断、用户身份、令牌滥用和危险操作都成了真实问题。2025 年 3 月，MCP 引入 OAuth 2.1，并用 Streamable HTTP 替换原来的 HTTP+SSE。远程 Server 有了统一的授权方式，客户端也能提前识别只读或破坏性工具。
到了 6 月，工具结果可以按 Schema 返回；缺少参数时，Server 可以请求客户端向用户追问；授权也进一步限制令牌能被哪个资源使用。
3 月加入的批量调用能力，6 月又被移除了。没有足够有说服力的使用场景，就不让所有实现继续背着，这也说明 MCP 并不是只加不减。
“这一阶段，工具不只要能调，还要把授权、校验和审计所需的信息补齐。”
三、2025 下半年：工具协议开始长成生态
讲到 2025 年下半年，问题又变了：一次工具调用很快，但 Agent 可能要跑几分钟甚至几小时。
11 月的稳定版中，实验性的 Tasks 开始支持长任务状态和取消；Extensions 让新能力可以独立演进。
如果什么都往核心协议里塞，MCP 迟早会像出差前的行李箱——最后得坐上去才能拉上拉链。扩展机制的价值，就是让核心保持克制。
同年 12 月，Anthropic 将 MCP 捐给 Linux Foundation 旗下的 Agentic AI Foundation，治理也开始从单一厂商走向中立生态。
但远程部署越来越大后，另一笔账也摆上了桌面。对于启用了协议 session 的 Streamable HTTP Server，水平扩容时要么把后续请求黏在某个实例上，要么额外维护共享 session 存储。网关想路由和限流，还可能需要解析请求体。
这在云原生场景下尤其棘手——无状态设计本就是基础设施的默认假设。
四、2026：为什么新版把 session 删了？
面试官终于把问题拉回来：“所以新版为什么敢把 session 删了？”
“先澄清一件事，”你说，“协议无状态，不等于业务失忆。删掉的是前台那本隐式小本本，不是把购物车和任务进度一起扔了。”
2026 年 7 月 28 日，新版 MCP 正式发布。协议级的 initialize / initialized 握手被移除，版本和客户端能力改为随每次请求携带；Streamable HTTP 中可选的 Mcp-Session-Id 也被删除。客户端如果想提前了解 Server，可以调用新的 server/discover。
对于以前启用协议 session 的远程 HTTP 实现，这意味着同一业务过程中的不同请求不必再固定落到同一个 Server 实例。只要业务状态通过参数显式传递，或者保存在实例外部，就能使用普通的轮询负载均衡。
面试官追问：“无状态以后，购物车、浏览器页面这些状态怎么办？”
你回答：“Server 可以返回 basket_id、browser_id 这类显式句柄，后续工具调用再把它作为普通参数传回来。状态还在，只是不再偷偷藏在连接里。”
服务端中途需要用户确认，也不再依赖一直挂着的连接。新版用 Multi Round-Trip Requests 返回“还需要什么输入”和一段不透明状态，客户端收集答案后重试原请求。只要重试请求携带了所需状态，其他实例也能接着处理。
同时，新版增加便于网关路由的请求头、缓存有效期和 Trace Context；Tasks 被移到正式扩展中，Roots、Sampling、Logging 则进入弃用期。注意，弃用不等于立即删除，它们至少还有一年的迁移窗口。
五、面试官追问，项目现在该怎么改？
面试官把场景推到你的项目：“如果明天开始迁移，你先改什么？”
你差点脱口而出“升级 SDK”，又把这句咽了回去。只升级版本号显然不够，可以按三步走：
先确认客户端和 Server SDK 是否支持 2026-07-28，并测试旧版本协商；再找出藏在 session 里的业务状态，把它改成资源 ID、任务句柄或外部存储；最后做跨实例测试，确认连续调用落到不同实例时仍能完成。
上线前再检查网关能否识别 Mcp-Method、Mcp-Name，以及链路追踪能不能从 Agent 串到工具后端。这部分可观测性能力直接决定了排查效率，很多团队就是在运维监控这一步补齐之后才敢全量切。
六、一分钟怎么回答？
最后只剩一分钟，你把答案收成一段：
“MCP 在 2024 年先解决 AI 应用与外部数据、工具之间缺少统一接口的问题；2025 年随着远程部署增加，它补上 Streamable HTTP、OAuth、结构化输出、用户追问和长任务能力，又通过扩展机制和基金会治理走向开放生态。
2026 年最大的变化，是删除协议级握手和 session，让协议版本、客户端能力随请求携带，让业务状态通过显式句柄传递。这样 MCP 才更容易在普通 HTTP 基础设施上路由、缓存、追踪和水平扩容。
所以 MCP 的发展，不是工具越加越多，而是核心协议越来越薄，生产能力越来越完整。”
像这样的架构演进讨论，在云栈社区的技术论坛里常常能引发更深的思考——从协议设计反推业务取舍，比单纯背更新日志有意思得多。
发表于 4 小时前
|
查看: 3|
回复: 0
