MCP 官方发布新路线图：五个优先方向，HTTP 传输一统江湖（0822）
MCP 官方发布新路线图：五个优先方向，HTTP 传输一统江湖（0822）
如果你在给 Claude、Cursor 或自研 Agent 接 MCP server，昨天这条消息值得你花三分钟看完——MCP 官方更新了路线图，把接下来几个月的协议走向一次性摊开了。
先说结论：MCP 正在从「人类点确认授权」的交互工具，变成「Agent 自己干活」的云原生协议。这不是官方原话，但把五个方向摆到一起，很难得出别的结论。
五个优先方向一览
官方把路线图拆成五个优先领域，每个都配了 Core Maintainers 和 Working Group 负责：
- Agentic messaging primitives（Agent 消息原语）
- HTTP-native transport unification and hardening（HTTP-native 传输统一与加固）
- Agent identity and enterprise-ready security（Agent 身份与企业级安全）
- Improved primitives（原语改进）
- Improved SDK developer experience（SDK 开发者体验）
我挑最关键的三个展开，剩下两个是收尾打磨。
方向一：长任务不再是「一问一答」
这是路线图里我最认同的一段判断，原句直接引：
Modern agentic workloads no longer fit the standard request-and-response pattern.
翻译成人话：现在的 Agent 循环能跑很久，server 要能主动推流式结果，中途还得能「掰方向盘」改方向。MCP 已经为此引入了 Tasks、subscriptions/listen、progress notifications 三件套。
这次的重点是把它们「捏合成一套好用的东西」。具体两件事：server-initiated events（webhooks 和 channels，让 client 别再轮询等结果）；把 Tasks 扩展（SEP-2663）打磨成熟，推进正式规范。
对你的影响：如果你现在靠轮询拿长任务结果，这块改完可以直接换掉。轮询是 MCP 里最丑的补丁之一，官方终于要亲手拆了。
方向二：HTTP 一统江湖，stdio 也并入
这是我最关注的信号。官方原句：
With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload.
意思是：远程 MCP server 现在和普通 HTTP 服务没有任何区别，你能托管普通 API 的地方就能托管 MCP。这次要把它再推进一步——让本地 server 也走 Streamable HTTP over stdio。
统一到单一传输层，client 和 server 的复杂度都会掉一截。对团队来说，运维一套 MCP server 的门槛直接降到「会用 Nginx / K8s 就行」。
一个反直觉的坑：别急着把现有 stdio server 全迁走。路线图说的是「方向」，Streamable HTTP over stdio 还在做。现在迁移等于自找麻烦，等 SDK 跟上再说。
方向三：Agent 身份，告别「贴 API key」
这是五个方向里最「企业向」的一个，但我觉得它才是 MCP 能不能进生产的关键。
现状：MCP authorization 建立在「真人在浏览器里点同意」之上。原句点破问题：
more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn't present, or delegating narrower authority to sub-agents.
翻过来：越来越多调用方是「云上跑的 Agent」，有自己的身份，替一个不在场的用户干活，还会把更窄的权限委派给子 Agent。
官方给的路子不是再发明一套，而是站在现有标准上：
- 落地 DPoP（Demonstrating Proof of Possession，RFC 9449） 并推动采纳
- 通过 Workload Identity Federation 定义 Agent 身份与委派的明确路径
- 继续和 IETF OAuth、WIMSE 工作组对齐
一句话：API key 和长生命周期 token 会逐步退出 MCP 的身份舞台，被「证明持有凭证」和身份联邦取代。这是好事，贴 key 的安全模型本来就撑不起 Agent 场景。
方向四&五：原语和 SDK 的打磨
Improved primitives 解决两个具体痛点：
tools/call的返回结果能以多种形式携带同一输出，server 开发者不知道 client 会把哪种形式喂给模型 → 统一成一个明确契约- 接一个上百工具的 server，用户还没开口，模型就得为全部工具定义付 token 成本 → 做 progressive discovery，让 server 先暴露小入口，对话收窄后再逐步展开
Improved SDK developer experience 就一句话：SDK 是开发者体验 MCP 的第一触点。现在越来越多人「指着一个 Agent 去读我们的库来生成 client/server」，API 写得清不清楚、文档准不准，直接决定生成的代码能不能跑通。
对 SEP 的影响：押对方向才能过审
路线图最后给 SEP（Specification Enhancement Proposals）定了调：
Proposals outside them aren't rejected automatically, but maintainer review time is scarce and goes to the roadmap first.
落在五大方向内的 SEP 加速审、优先过；方向外的不是自动拒，但维护者精力有限，先照顾路线图。
要提 SEP 的人：先找准你的提案属于哪个优先方向，去对应的 Working Group 打磨，别裸投。
你今天可以做的事
- 检查你现在接的 MCP server 是不是还在「轮询拿结果」——是的话，留意 Tasks 和 server-initiated events 的成熟进度，准备好切换
- 如果给团队部署远程 MCP，直接按普通 HTTP 服务托管，别再为它单独搞一套部署脚本
- 有 Agent 身份需求（云上 Agent、子 Agent 委派），开始盯 DPoP 和 Workload Identity Federation，别在 API key 上继续堆补丁
FAQ
Q：这个路线图是 Anthropic 单方面定的吗？ 不是。官方明确说它由 Core Maintainers 和社区 maintainers、Working Groups 共同制定，每个方向都有 Working Group 负责，任何人都能通过 Discord 找到对应 Core Maintainer。
Q：我现在的 stdio MCP server 要马上改吗？ 不用。Streamable HTTP over stdio 还在推进中，现有 stdio server 继续能用。等 SDK 支持成熟再迁，别抢跑。
Q：progressive discovery 是什么，为什么重要？ 指 server 先给模型看一个小入口（少量工具），等对话收窄到具体意图后再展开更多工具。解决「上百个工具让模型选择变差、还提前付 token 成本」的问题。
参考来源：
