MCP 2026 Roadmap：从工具协议到 Agent 通信层
Codex 核验（2026-10-10）：MCP 2026-07-28 变更说明 已发布：以 server/discover 和每请求元数据更新连接协商，引入多请求传输；旧初始化流程与若干客户端能力发生移除或弃用，Tasks 转为独立扩展。本文六月路线图保留历史日期，不能作为当前协议接口或权限配置指南。
有意思的点
MCP 2026 Roadmap 标志着 MCP 从”工具集成协议”转向”Agent 编排层”。Anthropic 已将项目捐赠给 Agentic AI Foundation，成为共享基础设施。
四大优先领域（由独立的 Working Group 驱动）：
-
Transport Evolution — Streamable HTTP 去状态化，支持水平扩展 / 负载均衡 / 无状态部署。加
.well-known元数据端点，让 agent 能自动发现 MCP server，无需硬编码地址。 -
Agent-to-Agent Communication — 最激进的转变。MCP server 不再是被动工具提供者，而是自主 agent。SEP-1686 Tasks 原语（异步、长生命周期操作）是基础。需要补：重试语义、结果过期策略、依赖链管理。
-
Governance Maturation — Contributor Ladder + 委托 SEP 审查。Working Group 可在自己领域直接批准 SEP，不用等 core maintainer 全部 sign-off。核心维护者保留战略监督权。
-
Enterprise Readiness — 审计追踪、SSO 认证、网关标准化、配置可移植性。通过 extension 机制实现，不污染核心协议。
有意思的批评
文章里提到了一个很清醒的 counterargument：scope creep 是 MCP 的存亡风险。MCP 赢在简单——一个下午就能实现 server。加入 agent-to-agent 通信、任务生命周期、协商协议后，可能变成 SOAP/CORBA 式的臃肿协议。
治理模型的对冲：让 Working Group 专注领域内决策，避免 design-by-committee。
对我们意味着什么
Hermes 本身就是 MCP 的重度使用者（MCP servers、tools、skills）。MCP 2026 的演进方向直接影响了 Hermes 的架构决策：
- Streamable HTTP 去状态化 → Hermes 的 gateway/MCP 服务部署方式会改变
.well-known发现 → Hermes 可能用这个做 LAN 设备发现（替代现在的 pairing flow？）- Agent-to-agent communication → 与 Hermes 现有的 agent_message_bus / delegation 模式互补
- Tasks 原语 → 可能比现在的 background terminal 方案更适合长任务