
MCP 2026-07-28
编写于 2026-08-22
MCPP 的协议扩展说明 与 MCP 2026-07-28 在 Peri 中对应两项独立处理:显式选择新版 server 发现握手,以及按配置建立订阅流接收变化通知。只配置协议版本不会自动启用订阅;只配置订阅也不会替换连接使用的协议版本。
这两个能力位于 MCP client 初始化之后。新版握手决定怎样取得 server 能力,订阅流决定连接建立后是否持续接收事件;普通工具调用不依赖订阅流。
新版握手如何选择
配置 protocolVersion: "2026-07-28" 后,Peri 选择新版 server/discover 路径。未配置时继续使用 legacy initialize;未知版本在配置解析时被拒绝,而不是运行中自动猜测或降级。
显式选择的目的,是让 server 和客户端使用同一套能力协商规则。配置版本不会授予额外权限,也不会绕过工具注册、资源校验或 OAuth 流程。
订阅流接收哪些变化
配置非空 subscriptions 后,连接成功会建立订阅流。server 可以通过这条流发送资源更新、资源列表变化、工具列表变化或 prompt 列表变化,Peri 按事件类型处理缓存和 session 消息。
带具体 URI 的资源更新会使对应资源缓存失效,并广播到已注册 session 的待处理消息队列;工具列表和资源列表变化主要使对应列表缓存失效,下一次请求再回源。prompt 列表没有与工具、资源相同的 Peri 持久化缓存路径。
订阅异常如何恢复
订阅流异常结束时,Peri 对连续异常按 1、2、4 秒退避,最多重试三次;收到正常通知后,连续异常计数会重置。服务端正常结束或客户端主动取消不会触发重连。
初次建立订阅失败只影响订阅能力,MCP 连接仍可能继续提供已经协商的工具和资源。订阅恢复也不等于现有 Agent 工具 bridge 立即重建;通知首先完成缓存失效和事件投递。
基于 MCP 做了什么处理
MCP 版本选择提供了新版发现和订阅接口,Peri 把它们接入已有的连接池、缓存和 session inbox。事件到达后,缓存层负责标记对应数据过期,session 层负责接收资源更新提醒,工具层在下一次列表请求时决定是否重新取得 schema。
这样处理后,新版握手、缓存和订阅各自保持独立:握手失败属于连接初始化问题,订阅失败属于连接后的可选能力问题,缓存失效属于数据新鲜度问题。三者不会被合并成一个笼统的“连接失败”。
使用边界
只有 server 明确支持新版握手时,才配置 protocolVersion;只有需要接收变化通知时,才配置 subscriptions。连接状态可以在 /mcp 面板查看,订阅是否建立以及通知是否到达,则需要结合日志和实际事件验证。
MCP 2026-07-28 不改变 Agent 的权限模型,也不替代缓存版本、TTL、OAuth 或 Skill 内容校验。它提供的是连接和事件路径,具体能力仍由 server 声明、Peri 配置和当前 middleware 装配共同决定。