8 月 22 日，Model Context Protocol（MCP）核心维护者发布了 2026 年路线图。这份文档没有公布任何新工具，也没有发布新版 SDK，但它可能是 MCP 从"有趣的协议实验"转向"企业基础设施"的最关键信号。

过去半年，MCP 的叙事主要围绕"让更多工具被模型调用"。7 月 28 日的版本更新已经做了关键铺垫：去掉初始化握手、移除协议级会话，让远程 MCP 服务器可以像普通 HTTP 服务一样水平扩展。而 8 月的路线图则进一步回答了一个问题：当 agent 真的要在生产环境里长时间运行、跨系统协作、代表用户甚至代表组织执行操作时，协议还需要补什么？

答案集中在五个方向：agentic messaging、HTTP-native transport、agent identity、improved primitives，以及 SDK 开发者体验。

从"调用工具"到"运行工作负载"

MCP 最早的场景很清晰：本地 IDE 或 Claude Desktop 启动一个子进程，模型通过 stdio 调用文件系统、数据库或 API。这个模型假设调用者是人在操作、会话周期短、工具数量可控。

但过去一年的实际使用已经偏离了这个假设。Agent 开始以云工作负载的形式运行，代表不在屏幕前的用户执行任务；一个 agent 会委派给子 agent，后者需要比父 agent 更窄的权限；有些任务要跑几分钟甚至几小时，不能靠客户端轮询。

路线图里最重要的三个补丁，正是对应这三个生产场景：agent identity、long-running work 和 progressive discovery。

Agent Identity：不要再把 API Key 贴在环境变量里

路线图中身份部分的措辞很直接：MCP 现有的授权设计假设"一个人可以在浏览器里点击同意"，但越来越多的调用者是 cloud workload，或者是一个替用户行动的 agent，再或者是被委派出去的子 agent。

解决思路不是发明新协议，而是采用现有标准：DPoP（Demonstrating Proof of Possession）、Workload Identity Federation、ID-JAG assertion grant、RFC 8693 token exchange。维护者明确说会和 IETF OAuth 以及 WIMSE 工作组协调。

这对构建 MCP 服务器的团队意味着：过去那种"把长期 token 或 API key 贴在环境变量里"的做法，路线图正在明确要淘汰它。未来的正确姿势是 token 绑定到 workload 身份、支持细粒度授权和撤销、子 agent 拿到的是被缩窄的委托 token，而不是父 agent 的全权限凭证。

Long-running Work：别再轮询了

MCP 目前对"服务器还没做完"这件事有三套互相重叠的机制：Tasks、subscriptions/listen 和 progress notifications。它们分别由不同工作组推进，生命周期、取消模型和错误处理都不一致。

路线图承诺把这三套东西统一成一套 server-initiated events，支持 webhook 或 channel，让服务器在异步任务完成时主动通知客户端。同时 Tasks 扩展（SEP-2663）继续向核心协议靠拢。

这对实际架构影响很大。一旦 server-initiated events 落地，MCP 客户端就不需要为了等一个长任务而保持长连接或频繁轮询，服务器也可以更自然地集成到现有的消息队列、事件总线或工作流系统里。

一个传输层：HTTP/2 over stdio

7 月版本让远程 MCP 服务器变成普通 HTTP 负载，但本地 stdio 传输和 HTTP 传输仍然有两套协议语义，SDK 里也要维护两条路径。路线图的解决方案很彻底：统一用 Streamable HTTP 作为唯一绑定，本地服务器通过 HTTP/2 over stdin/stdout 通信。

这意味着以后本地开发和远程部署用的是同一套传输模型，HTTP 的缓存、ETag、条件请求、标准负载均衡都能直接复用。对运维来说，MCP 服务器会越来越像一个普通的微服务。

Progressive Discovery：工具太多时怎么办

当一个 MCP 服务器暴露几十个甚至上百个工具时，模型每次调用前都要消化整个工具目录，既费上下文又容易选错。路线图提出 progressive discovery：服务器先暴露一个小的入口，随着对话聚焦再逐步展开更多工具和 resource。

这对企业级工具 catalog 是刚需。没有它，MCP 在企业内部的大规模落地会被上下文成本和选择准确率卡脖子。不过路线图也承认这部分的最终协议形态还没确定，相关工作组仍在组建。

观点：MCP 正在变成 agent 的 HTTP

这份路线图最值得关注的地方不是某一项技术，而是整体姿态的转变：MCP 不再只是"让模型调用工具的协议"，而是在尝试定义 agent 与外部世界交互的通用基础设施。

它现在面对的问题——身份、异步、发现、缓存、传输统一——几乎都是互联网协议几十年前解决过的问题。MCP 选择不重新发明轮子，而是把 OAuth、HTTP/2、IETF 标准搬进来，这个选择本身说明它想做一个能被安全团队、运维团队和合规团队接受的东西，而不是只被前端开发者喜欢。

当然，路线图里所有 deliverable 都标注为"current thinking rather than firm commitments"，6-12 个月的周期内变数还很多。但对于正在基于 MCP 做产品的团队，方向已经够清楚：现在写的每一行把 API key 写死、把任务做成同步阻塞、把工具目录一次性全量返回的代码，都是在给未来的自己挖坑。

参考来源： - MCP Roadmap: https://modelcontextprotocol.io/roadmap - Invidelabs 解读： https://blog.invidelabs.com/mcp-roadmap-agent-identity-discovery - FullStackEvolved 解读： https://www.fullstackevolved.com/blog/mcp-roadmap-agent-identity-2026-08-24 - WorldProgramming 解读： https://www.worldprogramming.org/posts/the-mcp-roadmap-is-an-api-roadmap-pprmms