MCP 2026 路线图更新：下一步不只是更多工具，而是 Agent 身份与长任务

MCP 2026 路线图更新：下一步不只是更多工具，而是 Agent 身份与长任务

Model Context Protocol 核心维护者在 8 月 22 日发布新路线图，覆盖下一版规范。五个优先方向是 Agent 消息原语、HTTP 原生传输统一、Agent 身份与企业安全、基础能力改进，以及 SDK 开发体验。路线图表达未来方向，不等同于已发布功能或交付日期。

MCP 正从简单工具调用进入远程服务、云端 Agent 和大规模目录。请求可能运行很久，服务端需要主动通知，Agent 还会向下游委派权限；浏览器登录、长效 Token 和全量工具列表开始触到扩展与安全边界。

长任务需要事件，但协议本身继续减少状态

2026-07-28 规范已移除协议级 session 与初始化握手，远程 MCP Server 可以像普通 HTTP 服务横向扩展；客户端通过 server/discover 查询版本和能力，列表也可以缓存。应用可以有状态，传输服务却不必绑定连接。

与此同时，Agent 工作又要求 Tasks、subscriptions/listen、进度通知和服务端主动事件。路线图计划继续推进 webhook 与 channel，减少客户端轮询，并重新检查 Agents、Transports、Triggers & Events 之间如何组合。这里的难点不是多加几个事件名，而是定义断线、重复投递、确认和取消后的事实状态。

因此，MCP Server 的无状态扩展与产品会话的持久化并不冲突。MCP 负责能力调用和事件契约，DASP 可以保存用户侧 sid、历史与恢复位置。把两者硬合成一个连接状态，扩容和跨设备续写都会变得困难。

Agent 身份不能继续借用用户的长效 Token

现有 MCP 授权更适合用户在浏览器中确认，但云端 Agent 可能在用户离线时运行，还会把更窄权限委派给子 Agent。路线图提出推进 DPoP、Workload Identity Federation、ID-JAG 与标准 Token Exchange，让服务端识别调用者本身，并验证它代表谁、被允许做什么。

企业不必等规范完成才治理。每个 Agent 应有独立工作负载身份，用户授权与服务身份分开，Token 绑定受众、权限和有效期；下游不能直接接收入口 Token。高风险操作还要记录用户、Agent、委派链和审批人。

路线图还把 DPoP 和企业授权列为未来方向，具体字段和 SDK 可能变化。现在的实现应保持可替换，避免把实验性扩展写死到所有业务表与客户端。

工具发现与返回结构会影响 Token 和正确率

当 MCP Server 暴露上百个工具时，模型要读取巨大目录，选择质量反而下降。路线图准备推进渐进式发现，让服务端先给出较小入口，再随任务展开。生产系统可以提前按领域拆目录，并统计描述占用 Token 与误选率。

tools/call 的结果也可能同时出现多种表示，服务端无法确定客户端会把哪一种交给模型。路线图希望统一更清晰的返回契约。迁移期要做跨 SDK 契约测试，尤其检查结构化内容、错误、附件与流式结果，不能只在一个客户端里跑通。

AnyAIS 已提供 MCP、DASP 与统一模型调用入口。准备下一轮协议升级时，可以先把工具、身份、事件和会话四类状态分开建模，再根据正式规范更新适配层；这样不会因为路线图中的一个字段变化重写整个产品。

参考资料

• [MCP 官方博客：The New MCP Roadmap](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/)
• [MCP 2026-07-28 规范](https://modelcontextprotocol.io/specification/2026-07-28)
• [MCP Streamable HTTP 传输](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports)
• [DASP API 参考](https://www.anyais.com/dasp/reference)