摘要： 本文完整解读 Model Context Protocol（MCP）2026 路线图，重点分析 Agentic Messaging、长任务 Tasks、服务端事件、HTTP 原生传输、Agent Identity、DPoP、Workload Identity Federation、Token Exchange 与 Enterprise-Managed Authorization。最重要的结论是：MCP 正从“模型调用外部工具的连接协议”升级为“可承载长期 Agent、身份委托和企业治理的基础设施协议”，但路线图并不等于已经发布的稳定规范。企业现在应基于 2026-07-28 无状态核心、Tasks 与 EMA 扩展建设分层架构，同时把未来的 Agent 身份、渐进式发现、HTTP over stdio 和工具结果重设计封装在可替换适配层中。读完本文，你可以区分已落地能力与未来方向，并形成 Agent Runtime、MCP Gateway、身份委托、权限审批和升级回退的完整实施路线。
核心结论
MCP 2026 路线图最值得关注的不是新增多少 RPC，而是协议边界正在发生变化：从短时的 Client→Server 工具调用，扩展到长期任务、事件通知、运行中输入、Agent 工作负载身份、用户委托、子 Agent 最小权限和企业统一授权。对企业而言，MCP 将越来越像 API Gateway、任务系统和身份基础设施之间的标准连接层，而不是简单的 Function Calling 包装器。
- Agent 通信的核心是统一长期任务生命周期。 Tasks、
subscriptions/listen、Progress Notification 与未来 Webhook/Channel 必须共享状态、取消、错误和恢复语义，避免企业维护三套互不兼容的异步机制。 - 身份方向从“用户浏览器授权”转向“Agent 自身身份＋用户委托”。 路线图聚焦 DPoP、Workload Identity Federation、ID-JAG 与 RFC 8693 Token Exchange，目标是替代复制 API Key 和长期 Refresh Token。
- Enterprise-Managed Authorization 已是稳定扩展，但未来 Agent Identity 仍在演进。 EMA 解决企业 IdP 统一策略、SSO 和集中撤权；它不自动完成 Headless Agent、父子 Agent 权限衰减和人类在场证明。
2026-07-28是当前迁移基线。 已发布无状态核心、server/discover、Header 路由、缓存提示、MRTR、正式扩展框架和授权加固；企业不应等待下一版才开始兼容。- 高风险操作仍必须人工审批。 Agent 身份回答“谁在调用、代表谁”，不回答“这次付款、删除、发布或权限修改是否应获准”。审批、策略与审计必须由 Server/Gateway 强制执行。
路线图定位：方向，不是发布时间表
结论是：这份路线图足以指导架构，但不能作为采购合同、发布日期或功能承诺。MCP 官方路线图页面更新于 2026 年 8 月 22 日，描述未来 6～12 个月的优先方向，并明确说明优先级可能调整、功能可能以不同设计交付或延期。
官方列出五个 Priority Areas：
| 优先方向 | 官方目标 | 企业最直接影响 | 当前应做什么 |
|---|---|---|---|
| Agentic Messaging Primitives | 长任务、推送、流式结果、运行中干预统一 | Agent Runtime、队列、Webhook、状态机 | 使用 Tasks 扩展，抽象 Event Adapter |
| HTTP-Native Transport | 统一 HTTP/stdio 传输与缓存、错误语义 | 网关、负载均衡、WAF、可观测性 | 迁移无状态 HTTP，保留 stdio 兼容层 |
| Agent Identity & Security | 工作负载身份、用户委托、子 Agent 降权 | IdP、Token Broker、零信任、审计 | 短期 Token、Issuer/Audience/Scope 校验 |
| Improved Primitives | 统一 Tool Result，渐进发现大目录 | Tool Registry、上下文成本、结果兼容 | 内部 Canonical Result、按角色过滤目录 |
| SDK Developer Experience | 规范、SDK、示例与 Conformance 一致 | 多语言客户端、升级测试 | 锁版本并建立跨 SDK 合约测试 |
与此前的 MCP 基础教程不同，本文不再重复 Host、Client、Server 的入门定义，而从三条生产主线展开：Agent 通信与长任务、Agent 身份与委托、企业安全与治理。如果需要基础配置，可通过 AI Stack Nav 的 MCP 教程搜索补充阅读。
当前基线：2026-07-28 已经改变了什么
结论是：路线图之所以可行，是因为 2026-07-28 已经完成从有状态双向连接向无状态、可路由、可缓存请求的基础改造。企业设计必须先站在这版规范上，不能把旧 Session 模型继续扩展成长期基础设施。
无协议 Session 与无初始化握手
新规范移除 initialize/notifications/initialized 以及 Streamable HTTP 的 Mcp-Session-Id。每个请求在 _meta 中携带协议版本、客户端能力与可选客户端身份，Server 也应在结果中携带自己的信息。
这样任意请求可以落到负载均衡后的任意实例，不要求共享协议 Session。业务如果需要跨调用状态，应由 Tool 返回显式 Handle，再把 Handle 作为普通参数传回。对 Agent Runtime 来说，这意味着 Task ID、Job ID、Approval ID、Conversation Handle 都应该显式、可审计、可过期，而不是藏在 Transport Session 中。
server/discover 与能力协商
Server 必须实现 server/discover，用于公布支持的协议版本、能力和身份；Client 可以在首次操作前调用，也可以在 stdio 中作为向后兼容探测。Tasks、EMA 等扩展需要双方显式声明支持，不能只看 Server 文档就假设 Client 能消费。
Header 路由与网关治理
Streamable HTTP 请求要求 Mcp-Method 与 Mcp-Name Header，Gateway、Rate Limiter 或 WAF 可以先根据 Header 做路由、计量和授权，无需先解析整个 JSON Body。但服务端必须交叉检查 Header 与 Body，防止攻击者在 Header 写只读 Tool、Body 调用高权限 Tool。
POST /mcp HTTP/1.1
Host: mcp-gateway.YOUR_DOMAIN
Authorization: Bearer YOUR_SHORT_LIVED_TOKEN
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: deploy_preview
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": "req-1001",
"method": "tools/call",
"params": {
"name": "deploy_preview",
"arguments": {
"repository": "YOUR_ORG/YOUR_REPO",
"commit": "COMMIT_SHA"
},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "release-agent",
"version": "1.0.0"
}
}
}
}缓存与弃用策略
tools/list、prompts/list、resources/list、resources/read 等结果包含 ttlMs 与 cacheScope。Server 返回确定顺序有利于客户端缓存和上游 Prompt Cache。Dynamic Client Registration 已弃用，推荐 CIMD；Roots、Sampling、Logging 与旧 HTTP+SSE 进入弃用流程，新实现不应继续采用。
Agent 通信：从一次 RPC 到长期任务系统
结论是：MCP 的 Agent 通信并不是简单增加“Agent 给 Agent 发消息”，而是让长期任务、输入请求、进度、订阅与取消形成可组合的协议原语。
为什么 Request/Response 不够
以下任务不会在几秒内稳定完成：
- CI Pipeline、代码扫描、模型训练；
- 大批量文档解析或数据迁移；
- 等待人类审批；
- 需要外部系统回调的部署；
- 多 Agent 协作与子任务汇总；
- 移动网络或易断线环境。
如果保持一个 HTTP Connection 几十分钟，Proxy Timeout、Client Crash 和网络抖动都会破坏任务。MCP Tasks 让 Server 返回 Durable Handle，Client 之后查询状态、提交输入并取回结果。
Tasks 扩展如何工作
官方 Tasks 文档给出的流程是：
- Client 在每个请求的 Capability 中声明
io.modelcontextprotocol/tasks。 - Server 在
server/discover中声明同一 Extension。 - Server 判断请求为长任务时，返回
resultType: "task"、taskId、初始状态、TTL 与建议轮询间隔。 - Client 使用
tasks/get查询状态。 - 状态变为
input_required时，Client 读取inputRequests，通过tasks/update提交回应。 - 状态进入
completed后取得原调用的最终结果；failed返回 JSON-RPC Error。 - Client 可调用
tasks/cancel，但取消是 Cooperative，Server 可能无法立即停止底层 Job。
Task 状态包括：
| 状态 | 含义 | 是否终态 | 企业处理建议 |
|---|---|---|---|
working | 正在执行 | 否 | 记录进度、心跳与超时 |
input_required | 等待 Client/用户输入 | 否 | 展示请求并校验 Approval Context |
completed | 正常完成 | 是 | 固化 Result、审计与 Artifact |
failed | 执行失败 | 是 | 保存 Error、Retryability 与 Root Cause |
cancelled | 已取消 | 是 | 核对底层副作用是否停止 |
Task ID 必须持久化，Client Crash 或重启后才能继续。Server 在返回 Handle 前必须先 Durable Create，避免 Client 收到一个查不到的 Task。
subscriptions/listen 与 Server 事件
Polling 是 Tasks 的默认方式。若 Server 支持 Notification，可以通过 subscriptions/listen 推送 notifications/tasks，其中携带完整 Task State，减少额外 tasks/get。
路线图进一步希望增加 Server-initiated Events，包括 Channel、Subscription 与 Webhook，让 Client 不必纯轮询。这里必须区分：
- 当前规范中的
subscriptions/listen已有明确用途； - Tasks Notification 已有扩展文档；
- 路线图中的更广泛 Webhook/Channel 组合仍在演进；
- 不要把自建 Webhook 字段宣传为标准 MCP 字段。
MRTR 与运行中输入
2026-07-28 引入 Multi Round-Trip Requests（MRTR），取代旧式 Server 主动调用 elicitation/create、sampling/createMessage 或 roots/list。Server 返回 resultType: "input_required" 和 inputRequests，Client 在重试原请求时附带 inputResponses。
Tasks 的 input_required 更适合长期 Job 中暂停；普通 MRTR 适合一次调用仍能在多轮完成。企业应在内部统一 Approval Request 结构，至少包含：
- 请求主体与 Agent 身份；
- 代表的用户；
- Tool、资源与参数摘要；
- 风险级别和预计影响；
- 幂等键；
- 过期时间；
- Approver 与证据；
- 拒绝后的处理。
Agent-to-Agent 通信应该怎样理解
结论是：路线图中的 Agent Communication 不等于已经出现一个完整的通用 A2A 协议。更准确的理解是，MCP 正在提供让 Agent 参与长期工具任务、委托、事件和输入的底层原语。
一个生产级父子 Agent 工作流可以这样建模：
- Orchestrator Agent 接受用户 Goal。
- Orchestrator 通过 Registry/Server Card 发现符合能力的 MCP Server 或 Agent Service。
- Identity Broker 为子 Agent 交换短期、受众绑定、Scope 更小的 Token。
- 父 Agent 创建 Task，并得到 Durable Task ID。
- 子 Agent 在独立 Runtime 执行，定期更新 Progress。
- 需要批准时进入
input_required，由用户或 Policy Engine 决定。 - Event 通知父 Agent完成、失败或需要 Steering。
- 父 Agent验证结果、汇总证据并结束委托。
这里的“Agent Service”仍应通过明确 API/Tool Contract 暴露能力，而不是允许父 Agent把任意 Prompt 和全部用户 Token 直接转给子 Agent。委托必须可限制：
- 允许调用的 MCP Server；
- Tool Allowlist；
- Resource/Audience；
- 数据范围和租户；
- 时间与调用次数；
- 最大委托深度；
- 是否允许再委托；
- 是否允许产生副作用。
Steering 不应变成任意 Prompt 注入
长期 Agent需要在运行中调整，例如“只处理失败测试，不重构模块”。Steering Message 必须由可信主体签名，绑定 Task ID 与版本，并通过策略检查。来自网页、日志、Email 或第三方 Tool Result 的文字不能自动升级为 Steering 指令。
Checkpoint 与恢复属于实现责任
Tasks 提供 Durable Handle 和重连基础，但协议不会自动保存你业务的完整执行状态。Server 应在关键副作用前后记录 Checkpoint：输入摘要、当前 Step、已完成 Tool Call、幂等键、Artifact、Token Subject 和 Approval。恢复时从最后一个安全 Checkpoint 继续，而不是重新执行所有写操作。
Agent Identity：为什么 API Key 模式走不远
结论是：企业 Agent 越来越像云工作负载，它需要自己的 Identity，同时可能代表某位用户或服务账户行动。把长期 API Key 复制到每个 Agent Runtime，会造成身份不清、权限过大、撤权困难和 Secret 泄露。
三种主体必须区分
| 主体 | 回答的问题 | 示例 Claim | 常见错误 |
|---|---|---|---|
| User Identity | Agent 代表谁 | sub=user-123 | 只记录邮箱，身份可变 |
| Workload Identity | 哪个 Agent Runtime 在调用 | client_id=release-agent | 多 Agent 共用同一 API Key |
| Delegation Context | 谁把什么权限委托给谁 | act/sub/scope/aud | 子 Agent 获得父 Agent 全权 |
审计日志至少要能回答：哪个 Agent、在哪次 Task、代表哪个 User、使用什么 Delegation、调用哪个 Tool、操作哪个 Resource、谁审批、结果是什么。
DPoP：降低 Bearer Token 被盗后的重放风险
DPoP（Demonstrating Proof of Possession）通过客户端密钥为 HTTP Request 生成 Proof，使 Access Token 与持钥 Client 绑定。即使 Token 被复制，攻击者没有对应私钥也难以直接重放。
路线图目标是完成 DPoP 规范化并推动采用。但 DPoP 不是万能安全层：
- 它不替代 Server Authorization；
- 私钥仍需安全保存；
- 需要防止 Proof 重放；
- Proxy/Gateway 必须正确处理目标 URI 与 Method；
- 被授权 Agent 自己恶意调用时，DPoP 不会阻止。
因此，企业现在可以在身份平台评估 PoP Token，但不要把尚未确定的 MCP 专用字段写死进业务代码。
Workload Identity Federation
Workload Identity Federation 允许 Agent 使用云平台、Kubernetes、CI 或内部 Runtime 的短期身份证明，交换访问 MCP Server 的 Token，而不是存储长期 Secret。Server 或 Authorization Server 应校验：
- Issuer；
- Audience；
- Subject/Workload；
- Expiration 与 Not-before；
- Signing Key；
- Environment、Tenant 与 Attestation Claim；
- 是否允许代表用户。
RFC 8693 Token Exchange 与子 Agent 降权
Token Exchange 可让父 Agent用自己的 Token 和用户委托，换取一个 Scope 更窄、Audience 更具体、TTL 更短的子 Agent Token。关键安全不变量是：委托后的权限不得大于委托前权限。
例如父 Agent拥有：
scope: repo:read repo:write pr:create deploy:preview
aud: mcp-gateway
ttl: 30m给测试子 Agent的 Token 应缩减为：
scope: repo:read tests:run
aud: test-mcp-server
ttl: 5m
delegate: false子 Agent不应获得 repo:write 或 deploy:preview，更不能自行再委托。以上 Claim 名称属于示意，最终字段以身份平台和未来规范为准。
Enterprise-Managed Authorization：已经稳定的企业能力
结论是：EMA 是当前最可立即采用的企业授权扩展之一，它让企业 IdP 成为 MCP Server Access 的权威决策者，解决员工逐个 Server 授权、入离职撤权和统一审计问题。
EMA 解决什么
标准用户驱动授权适合消费者，但企业会遇到：
- 员工不理解每个 MCP Server 的授权细节；
- Security Team 无法统一强制 Policy；
- 新员工需要逐个授权服务；
- 离职时要在多个 Server 中分别撤权；
- Compliance 需要集中审计。
EMA 让 Okta、Azure AD 或企业 SSO 作为中介。员工登录企业 IdP；IdP 根据 Group、Role、Conditional Access 判断是否签发 Identity Assertion JWT Authorization Grant（ID-JAG）；MCP Client 再用 ID-JAG 向 MCP Authorization Server 换取 Access Token。
EMA 流程
sequenceDiagram
participant U as User
participant C as MCP Client
participant I as Enterprise IdP
participant A as MCP Auth Server
participant S as MCP Server
U->>C: Corporate SSO
C->>I: Request ID-JAG
I-->>C: Policy-scoped ID-JAG
C->>A: Exchange ID-JAG
A-->>C: MCP Access Token
C->>S: Tool call with token
S-->>C: Authorized resultAuthorization Server 验证 IdP JWT Signature、Audience、Issuer 与 Expiration，并将 Claim 映射为 Permission。账户关联应优先使用稳定 sub，Email 只作为旧账户匹配的辅助。
EMA 的边界
EMA Extension 是 Opt-in，Client Support varies，不能默认所有 Host 都支持。企业还需要：
- IdP 和 MCP Authorization Server 的 Trust 配置；
- MCP Server Registry 与 Resource Descriptor；
- Scope/Role 到 Tool/Resource 的映射；
- Break-glass 与 Emergency Revocation；
- Token Lifetime 与 Cache Policy；
- 失败、撤权和跨 Tenant 测试。
更重要的是，EMA 主要解决 User/Enterprise Policy。未来路线图仍要补齐 Agent Workload Identity、Headless Caller、子 Agent Delegation 和 Human-presence Attestation。
企业 MCP Gateway 2.0 应该长什么样
结论是：路线图落地后，企业 MCP Gateway 不应只是反向代理，而应成为版本、身份、策略、目录、Task 与审计的统一控制面。
推荐组件
| 组件 | 作用 | 必须记录的证据 |
|---|---|---|
| Protocol Gateway | 版本、Header/Body 校验、路由、限流 | Protocol、Method、Tool、Latency |
| Identity Broker | WIF、ID-JAG、Token Exchange、DPoP | Issuer、Subject、Audience、Delegation |
| Policy Engine | Tool/Resource/参数级授权 | Policy Version、Decision、Reason |
| Tool Registry | Server Card、能力、Owner、Risk | Server Version、Schema Hash、Owner |
| Task Runtime | 状态、TTL、进度、重试、恢复 | Task ID、State、Checkpoint、Error |
| Approval Service | 高风险动作人工 Gate | Approver、Scope、Expiry、Evidence |
| Audit Pipeline | 跨 Agent 与 Tool Trace | Trace ID、User、Agent、Tool、Result |
| Compatibility Lab | Client/Server/Extension 合约测试 | Matrix、Pass/Fail、Regression |
策略示例
mcp_gateway:
protocol:
preferred: "2026-07-28"
allowed:
- "2026-07-28"
- "2025-11-25"
reject_header_body_mismatch: true
identity:
require_short_lived_tokens: true
validate:
- issuer
- audience
- subject
- expiration
- scope
max_delegation_depth: 1
child_scope_must_be_subset: true
tasks:
max_ttl_seconds: 3600
persist_task_handle: true
max_retries: 3
require_idempotency_for_writes: true
approvals:
required_for:
- payment
- delete_data
- send_external_message
- publish_content
- change_permissions
- production_database_write
audit:
record_delegation_chain: true
record_policy_decision: true
redact_secrets: true这不是 MCP 官方 Schema，而是企业实施示例。不要以 mcp_gateway 字段作为协议兼容标准。
HTTP 原生传输与安全加固
结论是：远程 MCP Server 应像普通 HTTP Workload 一样部署在负载均衡、Gateway、WAF 和 OpenTelemetry 体系中；本地 stdio 仍要保留，路线图中的 HTTP/2 over stdio 尚未稳定。
当前可做
- Remote Server 使用 Streamable HTTP；
- 验证 Origin、Authentication 与 TLS；
- Gateway 校验
MCP-Protocol-Version、Mcp-Method、Mcp-Name； - 使用
_meta传播traceparent、tracestate、baggage； - 按 Tenant、Subject、Scope、Tool Version 构建 Cache Key；
- 显式处理 Unsupported Protocol 与 Header Mismatch。
路线图方向
官方希望用 Streamable HTTP 作为单一 Binding，并通过 stdio 承载，可能采用 HTTP/2 获得 Multiplexing，同时保留子进程安全与生命周期。路线图还考虑 ETag，扩展缓存到 Tool Result。
不要根据路线图提前移除现有 stdio，也不要自行创造“标准 HTTP/2 over stdio”。最稳妥的方法是：
interface TransportAdapter {
discover(): Promise<ServerCapabilities>;
call(request: McpRequest): Promise<McpResult>;
listen?(subscriptions: string[]): AsyncIterable<McpNotification>;
}业务 Tool 不接触具体 Transport，未来只替换 Adapter。
Improved Primitives：大规模工具目录的成本与风险
结论是：当 Server 暴露数百个 Tool 时，问题不只是 Token 成本，还包括模型选错 Tool、权限面扩大和 Schema 变化难追踪。路线图计划 Tool Result 重设计与 Progressive Discovery。
Tool Result 统一
当前 tools/call 可能同时返回 content 和 structuredContent，不同 Client 选择不同内容交给模型，产生兼容差异。企业可先建立内部 Canonical Result：
{
"status": "success",
"data": {},
"human_summary": "Deployment preview created.",
"artifacts": [],
"warnings": [],
"audit": {
"tool_version": "1.4.0",
"policy_decision_id": "pd-123"
}
}由 Protocol Adapter 转换为当前规范格式，未来结果契约改变时不重写业务层。
Progressive Discovery
目标是让 Client 按需求逐步获知 Tool/Resource，而不是初始加载全部目录。现在可以通过 Gateway 按 Role、Tenant、Risk 和场景过滤 tools/list，但不要创造与未来标准冲突的 RPC。
要测量：
- Tool Schema Token；
- Tool Selection Accuracy；
- Unauthorized Tool Exposure；
- Discovery Latency；
- Cache Hit Rate；
- Schema Version Mismatch。
更多生产项目可以关联 AI Stack Nav 的 企业 MCP Gateway 与 Agent 安全内容。
SDK 与 Conformance：为什么企业必须自建兼容矩阵
结论是：协议升级不应依赖“SDK 能编译”。企业必须测试不同 Client、Server、版本和 Extension 的行为，尤其是破坏性迁移和错误路径。
路线图希望让 Specification 与人工审核的 Conformance Suite 成为 Source of Truth，实验生成 Tier 1 SDK 与 Quickstart。当前企业应建立矩阵：
| Client | Server | Protocol | Tasks | EMA | 结果 |
|---|---|---|---|---|---|
| TypeScript New | Server New | 2026-07-28 | On | On | 完整测试 |
| Python New | Server New | 2026-07-28 | On | Off | Extension Graceful Degrade |
| Old Client | New Server | 2025-11-25 | Off | Off | Compatibility Gateway |
| New Client | Old Server | Probe/Fallback | Off | Off | 明确错误或降级 |
测试至少覆盖：
server/discover与版本不匹配；- Header/Body Mismatch；
- Tasks 普通结果和 Task Result 多态；
- Task Crash/Resume、TTL、Cancel；
input_required与 Approval；- EMA Token 发行、撤权、Scope Error；
- Token Exchange 权限不扩张；
- Cache Private/Public 隔离；
content/structuredContent映射；- Trace Context 与 Audit Correlation。
企业迁移路线：现在、下一步与暂缓事项
结论是：企业不应一次性实现所有路线图目标，而应分三阶段推进。
阶段一：立即实施
- 资产盘点：Host、Client、Server、SDK、Protocol、Transport、Auth、Tool 与 Owner。
- 迁移
2026-07-28无状态核心和server/discover。 - 用显式 Handle 取代协议 Session。
- Remote Server 接入 Gateway、WAF、Rate Limit 和 OpenTelemetry。
- API Key 替换为短期 Token，校验 Issuer/Audience/Scope。
- 写操作加入幂等、审批和审计。
- 建立双版本兼容环境与回退 Adapter。
阶段二：受控试点
- 在 CI、Batch、Approval 场景试用 Tasks Extension。
- 为 Enterprise Client 评估 EMA 与 ID-JAG。
- 建立 Identity Broker 和 Delegation Chain Log。
- 用 Role/Tenant Filter 缩小 Tool Catalog。
- 跨 TypeScript、Python、Go、C# 做合约测试。
阶段三：等待标准成熟
- HTTP/2 over stdio；
- MCP 专用 DPoP 最终集成方式；
- 标准化 Agent Identity/Delegation Profile；
- 通用 Server Webhook/Channel；
- Progressive Discovery 正式机制；
- 新
tools/callResult Contract。
对这些能力可以实验，但必须放在 Feature Flag 后，不得成为无法回退的生产依赖。
风险、限制与安全注意事项
结论是：路线图最大风险不是“功能延期”，而是团队误把方向当现状、误把身份认证当授权、误把事件推送当 Exactly-once，并让 Agent 在重试中重复执行副作用。
路线图状态误判
每项能力标注 stable-core、stable-extension、experimental 或 roadmap。采购与 SLA 只承诺已稳定能力。
取消不等于无副作用
tasks/cancel 是 Cooperative。收到 Cancel 后，底层 Payment、Deployment 或 Email 可能已执行。每个写操作必须有 Idempotency Key、State Check 和 Compensation Strategy。
Event 可能重复或丢失
Webhook 与 Notification 应按 At-least-once 设计，使用 Event ID、Task Version 和幂等消费。断线后重新查询 Durable Task State，不依赖“最后一条消息”。
Delegation 权限膨胀
子 Agent Token 的 Scope、Audience、TTL 和 Delegation Depth 必须收缩。Policy Engine 拒绝权限并集，不能只相信父 Agent声明。
Prompt Injection
Tool Description、Resource、Webhook、Task Result 和外部文本都是不可信输入。不得允许它们修改 System Policy、索取 Secret 或产生新的 Token Exchange。
Cache 泄露
Private Result 不得进入 Shared Cache。Cache Key 包含 Tenant、Subject、Scope、Resource Version；撤权后要有 Invalidation Strategy。
人类审批被绕过
付款、删除数据、发送外部消息、公开发布、修改账户/权限、生产数据库操作必须在 Gateway/Server 层验证 Approval Token，不能仅依赖模型 Prompt。
故障排查
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| Client 收不到 Task | 未声明 Tasks Extension | 检查每请求 Client Capabilities 和 server/discover |
| Task 重启后丢失 | Task ID 未持久化或先响应后入库 | Durable Create 后再返回 Handle |
input_required 无法继续 | Client 未处理 inputRequests 或 Approval 过期 | 实现 tasks/update 与过期重授权 |
| Cancel 后仍产生结果 | 取消是 Cooperative | 状态标记、底层取消、幂等与 Compensation |
| EMA 登录成功但 Tool 403 | Claim→Scope 映射错误 | 检查 Issuer、Audience、Subject、Group、Scope |
| 子 Agent 权限过大 | Token Exchange 未做 Scope Subset | Gateway 强制权限衰减与委托深度 |
| 网关路由到错误 Tool | Header 与 Body 未交叉验证 | 拒绝 HeaderMismatch |
| 工具目录 Token 过高 | 全量 tools/list 暴露 | Role Filter、分域 Server、等待标准 Discovery |
| 新旧 SDK 行为不同 | Extension/Result 处理差异 | Conformance 与 Canonical Result Adapter |
| Event 重复执行写操作 | 无幂等键或 Task Version | Event 去重、State CAS、Idempotency Key |
事实依据与来源
本文核验日期为 2026 年 8 月 25 日，信息边界如下：
- 官方已确认： MCP 新路线图发布于 2026 年 8 月 22 日，覆盖未来 6～12 个月五个优先方向，并明确不是坚定交付承诺。
- 当前稳定规范：
2026-07-28已发布无状态核心、server/discover、Header 路由、缓存字段、MRTR、扩展框架与授权加固。 - 当前正式扩展： Tasks 提供 Durable Handle、
tasks/get/update/cancel、input_required与 Notification；EMA 提供企业 IdP、ID-JAG、集中 Policy 和撤权。Client Support 需要逐项核实。 - 路线图方向： 更广泛的 Server Event、HTTP over stdio、ETag、Agent Identity Profile、DPoP 推广、Token Exchange 路径、Progressive Discovery 与 Tool Result 重设计尚未全部成为稳定核心规范。
- 编辑判断： MCP 正成为 Agent Runtime、Identity 与 Gateway 的标准连接层，是基于五条路线组合关系的判断，不代表官方产品承诺。
- 实施建议： Gateway 2.0 组件、YAML、三阶段迁移、5 分钟子 Agent Token 和兼容矩阵均为示例，需要项目实测。
- 未引用第三方 Benchmark： 本文没有宣称性能提升、成本下降或工具准确率提高的固定比例。
FAQ
MCP 2026 路线图已经全部上线了吗？
没有。路线图描述未来 6～12 个月的优先方向，并明确可能调整或延期。2026-07-28 核心、Tasks 和 EMA 等已有规范或扩展；HTTP over stdio、标准 Agent Identity、Progressive Discovery 等仍在演进。
MCP Tasks 是稳定核心功能吗？
Tasks 已从实验核心移到官方 Extension io.modelcontextprotocol/tasks，但不是所有 Client 默认支持。Client 与 Server 必须显式声明 Extension，Host Support 应查 Client Matrix 并实际测试。
Tasks 和普通异步 Job API 有什么区别？
Tasks 为不同 MCP Tool 提供统一 Handle、状态、TTL、轮询、输入、取消和最终结果语义。如果底层 API 已有 Job ID，可以把它映射为 MCP Task，但仍需保证 Durable Create、状态一致性和幂等。
subscriptions/listen 会完全替代轮询吗？
不会。Tasks 默认仍可通过 tasks/get 轮询；支持 Notification 时可以减少轮询。断线或事件丢失后仍应查询 Durable Task State，而不是只依赖推送。
EMA 已稳定是否代表 Agent 身份已解决？
不代表。EMA 主要解决企业用户通过 IdP 统一授权、Policy 和撤权。Headless Agent Workload Identity、父子 Agent Delegation、DPoP 与 Human-presence Attestation 仍是路线图重点。
DPoP 能防止所有 Token 攻击吗？
不能。DPoP 降低 Bearer Token 被复制后重放的风险，但不替代 Server 授权、私钥保护、Scope、Audience、TTL、Policy 和审计，也不能阻止本来就有权限的 Agent 滥用。
企业是否应立即删除 stdio？
不应。当前本地 MCP 仍有 stdio 场景。HTTP over stdio 是路线图方向而非稳定标准，正确做法是隔离 Transport Adapter，为未来替换保留空间。
Agent 有身份后还需要人工审批吗？
需要。身份只证明调用主体与委托关系。付款、删除、发布、发信、权限变更和生产数据库写入仍应由服务端强制的人类审批和 Policy Gate 控制。
如何判断 MCP Client 是否适合企业使用？
核对 Protocol Version、server/discover、Streamable HTTP、Tasks、EMA、MRTR、缓存、错误处理、OIDC/OAuth、审计与 Client Matrix；再通过企业自己的兼容测试，而不是只看“支持 MCP”标签。
参考来源
- MCP 官方博客：The New MCP Roadmap
- Model Context Protocol 官方路线图
- MCP 官方博客：The 2026-07-28 Specification
- MCP 2026-07-28 Key Changes
- MCP Tasks Extension
- MCP Enterprise-Managed Authorization
- MCP Feature Lifecycle and Deprecation Policy
- RFC 8693：OAuth 2.0 Token Exchange
- RFC 9449：DPoP
会员充值与订阅排查资料
适合阅读会员充值、订阅购买、权益对比和支付问题类文章后继续转化。
