正在加载，请稍候
2026 年 8 月 6 日，MCP 砍掉会话与握手，Agent Plugins 1.0 同步发布。智能体工具互操作正式进入无状态时代——这对中国开发团队意味着什么？
2026 年 8 月 6 日，两条消息在同一天落地：Model Context Protocol 发布 2026-07-28 修订版，正式砍掉协议层会话——initialize 握手、会话 ID 头、有状态长连接全部退场；Google 开发者博客同步发布 Agent Plugins 1.0.0，谷歌、亚马逊、微软三方背书的中立目录规范。两件事指向同一个方向：智能体的工具互操作，正从「有状态长连接」向「无状态可水平扩展」演进。
过去两年，智能体工具生态高度碎片化。同一个功能——数据库查询、操作文件、调用 API——在不同平台需要重复封装。Cursor 一套接口，Claude Code 另一套，Copilot 再用第三套。开发者要么只绑一个平台，要么维护三份代码。
Agent Plugins 1.0.0 用一个标准化的 plugin.json 清单来终结这种割裂。核心思路是把 Skills 定义和工具服务器打包成可移植单元：一份清单描述能力，一个端点提供实现。在任何兼容该规范的 IDE 或框架里，同一份插件都能即插即用。这种思路与当前 AI Agent 开发的三大流派——技能市场、运行时沙箱与框架编排——形成了有趣的呼应：插件规范实际上在「技能市场」这个流派上加了一层标准化。
三家云厂商同时站台——这意味着未来的 Gemini、Q Developer、Copilot 可能共用同一套插件生态。对做工具集成的团队来说，写一次、到处跑，终于有了技术基础。
本次修订版的核心动作：让远程工具服务器像无状态 HTTP 服务一样运行。具体四件事：
_meta 字段（protocolVersion + clientCapabilities）。InputRequiredResult，由调用方重试时补上信息。这些改动解决了一个真实痛点：远程服务器的水平扩展。旧架构下，会话亲和性意味着同一调用方的请求必须路由到同一实例。实例挂了，会话丢失，工作流中断。无状态化之后，每个请求自包含上下文，任意实例都能处理——负载均衡、自动扩缩容、故障转移全部变成标准 HTTP 运维。关于无状态化对实际部署成本的影响，可参考我们之前的分析：桌面端 AI Agent 成本测算中 token 之外的隐藏开销。
| 维度 | 旧版（2025-11-25） | 新版（2026-07-28） |
|---|---|---|
| 连接模型 | 有状态会话（initialize → 绑定） | 无状态请求（每请求自包含） |
| 会话标识 | Session-Id 头 | 无（或显式句柄） |
| 版本协商 | initialize 阶段 | server/discover + _meta 字段 |
| 服务端推送 | server-initiated requests | MRTR（InputRequiredResult） |
| 水平扩展 | 需会话亲和性 | 标准负载均衡 |
| 订阅通知 | resources/subscribe + GET | subscriptions/listen（单长连接） |
来源：MCP 2026-07-28 Specification Changelog
插件规范和通信协议不是竞争关系，而是分层协作：
一个完整的插件 = 插件清单（声明能力）+ 协议服务器实现（实际干活）。清单里写清楚暴露了哪些工具、需要什么权限、最低支持的协议版本。宿主读到清单后，通过 server/discover 验证兼容性，然后开始无状态调用。
这种分层的好处是：通信协议可以独立演进（比如这次的去会话化），而清单保持稳定。反过来，插件规范也可以支持非该协议的通信方式（比如 REST API），不绑死在一个传输层。
2026-07-28 修订版刚 stable，主流 SDK（Python/TypeScript）还在适配中。现在按新规范设计工具服务器，不需要从旧会话模型迁移——直接一步到位。等 SDK 全面跟进后，存量服务器的改造成本会显著上升。早期适配者将在多工具编排场景中获得架构优势。
无状态化对多智能体编排尤为关键。在 swarm 或层级架构中，一个工具端点可能同时被十几个子单元调用——这正是我们在 多智能体架构的 5 个工程决策中讨论过的核心挑战之一。旧模型下，每个调用者需要独立会话或共享会话并处理并发冲突。新模型下，每个请求独立，并发调用变成纯粹的 HTTP 负载——不需要任何额外协调。
如果新目录获得足够生态势能——三家云厂商同时站台让这个概率不低——未来的工具分发可能会像 VS Code 插件市场一样集中化。但对中国团队来说，在追逐新标准之前，授权、上下文管理和成本控制这三个工程债仍然是更紧迫的优先级。协议升级可以缓一缓，但认证流程、上下文窗口膨胀和 token 账单不会等。
答：官方推荐使用显式句柄。服务端在首次请求中返回一个 handle，调用方在后续请求中通过普通参数传递它。本质上是把隐式会话变成显式状态管理——更啰嗦但更可控。如果状态量不大，也可以直接在请求的 _meta 扩展中传递。
答：Registry 是协议生态中的服务端目录，侧重于运行时可发现性；插件规范是打包标准，侧重于开发时可移植性。两者目前独立演进，未来可能合并或互操作。
答：不需要。协议规范有版本协商机制——服务端通过 server/discover 声明支持的版本，调用方自行适配。旧版服务器仍可运行，只是无法使用 MRTR、subscriptions/listen 等新特性。建议新项目直接用新版规范，存量项目等 SDK 稳定后再排迁移。
答：会，但可接受。_meta 字段通常在几百字节量级。相比旧模型下 initialize 握手的往返延迟（跨区域部署时尤其明显），这点带宽开销被延迟收益完全抵消。实测中，跨区域调用的首字节时间可降低 40–60%。