MCP 新路线图：五大核心方向
The New MCP Roadmap
MCP 团队发布了最新路线图，聚焦五大优先领域：代理消息原语、HTTP 原生传输统一、代理身份与企业级安全、原语改进以及 SDK 开发者体验升级。随着现代代理工作负载日益复杂，MCP 正从简单的请求 - 响应模式转向支持长循环、流式结果和实时干预。通过引入 Tasks 扩展和订阅机制，协议将更好地支持服务器主动推送事件。同时，MCP 致力于标准化代理身份验证，利用 DPoP 和 Workload Identity Federation 替代传统的 API Key，并推动工具调用的渐进式发现以优化模型上下文效率。SDK 团队也在全力提升跨平台开发体验，确保文档清晰、API 直观。
现代代理工作负载已不再适应标准的请求 - 响应模式，循环可能运行更长时间，服务器可以推送流式结果，且在中途引导工作流的需求日益明确。
HN 评论区
20- rco8786
> 随着 2026-07-28 版本的发布，远程 MCP 服务器现在与其他任何 HTTP 工作负载已无二致。
很好。引入一个专用的新协议是 MCP 在初次发布时做的最不明智的决定之一。
- threecheese
我希望即将被移除的“采样（sampling）”功能能有更多的实际应用。BYO Inference（自带推理）在像 Claude Code 这样的封闭花园中可能非常有用，因为在那里，如果不按 Token 付费，就无法利用花园之外的推理能力。也许这个功能只是比它实际更有用更有趣罢了。
- izend
我非常好奇究竟有多少 MCP 服务器会真正实现所有这些功能：
“目前的 MCP 授权机制是围绕用户在浏览器中批准访问构建的。这对交互式客户端效果很好，但越来越多的调用方是作为云工作负载运行的代理，它们拥有自己的身份，代表不在场的用户进行操作，或将更窄的权限委托给子代理。我们希望 MCP 服务器能有一种标准化的方式来识别和信任这些代理身份，基于现有标准构建，而不是粘贴 API 密钥或使用长期令牌。
这项工作包括最终确定并推动 Demonstrating Proof of Possession (DPoP) 的采用，并通过 Workload Identity Federation、Enterprise-Managed Authorization 背后的 ID-JAG 授权以及标准令牌交换，定义一条关于代理身份和委托的明确路径。我们还将继续加强与 OAuth 标准机构的合作，包括 IETF OAuth 和 WIMSE 工作组，以帮助底层标准随着代理身份所需的构建块而演进。”
- cube00
我仍然难以理解，相比于 REST 端点和一个 skills.md 文件，MCP 端点究竟如何让代理更容易工作。
- mmaunder
我原本的愿景是 MCP 能让像我们这样的服务（网络安全领域）提供一个带有身份验证的自文档化端点，我们只需给用户一个 URL，它就能直接工作。然而从第一天起，它就变成了随着方向调整而不断变化的多重标准，一个极度依赖上下文的特性，感觉就像是一个临时拼凑的补丁。这彻底浇灭了我对 MCP 的热情，而且我在本地工具和 API 方面已经取得了巨大成功，除非有极大的理由，否则我不会再回头。
- mikeegg1
每当我看到“MCP”时，我脑海里翻译出来的还是“主控程序（Master Control Program）”。
- rglover
这个想法被过度复杂化的程度令人困惑。本可以用一些相对简单的模式，围绕 HTTP 和 WebSockets（如果绝对必要，再加上 SSE）来解决这个问题。
- vatsachak
为什么不直接给模型一个提示词（prompt）呢？
LLM 的每一次进步要么来自计算效率的提升，要么来自架构或框架（Harnesses）的改进……
其余的似乎都只是花哨的噱头。