MCP更新： 2026-07-28：从 Agent 插件协议到企业 AI 工具总线

weixin_41468466

439人浏览 · 2026-08-02 16:59:25

weixin_41468466 · 2026-08-02 16:59:25 发布

芯片人看AI · MCP协议

约4000字 / 阅读约12分钟

MCP 2026-07-28Agent协议MRTRTasks无状态企业AIAI4EDA网关治理OAuth授权OpenTelemetry缓存可观测

说明：协议变更均对照 MCP 官方规范与 Changelog；企业架构和 AI4EDA 部分是基于这些变更给出的工程分析。

MCP 终于开始处理那些不太性感、却真正决定系统能不能上线的问题了。

上一阶段，大家讨论 MCP，重点通常是“模型能不能调用工具”“能不能连接数据库”“有没有足够多的 MCP Server”。到了公司内部真正部署时，麻烦很快从模型侧转移到工程侧：MCP Server 怎么横向扩容？请求被负载均衡到另一台机器怎么办？长任务断线后怎么恢复？用户确认如何穿过网关？安全团队怎样按工具鉴权？一次超时重试，会不会重复提交两份任务、占用两份 License？

2026 年 7 月 28 日发布的新版规范，正面回答了这些问题。

它把 MCP 从有状态、双向、偏本地插件的通信模型，改造成无状态、可路由、可缓存的请求响应协议。官方称这是 MCP 发布以来最大的一次修订。这个说法并不夸张：initialize 握手、协议级 Session、Server 主动回调、SSE 续传等基础机制都被重写了。

我的判断是：MCP 正从“Agent 的通用插座”，向“企业 AI 能力总线的线协议”靠近。但它仍然不是完整的 Agent Runtime，也不会替公司解决业务权限、工具正确性和 Prompt Injection。

一张表看懂这次重构

维度	旧版 MCP	MCP 2026-07-28	实际进步
连接模型	`initialize` 握手，维护 Session	取消握手，每个请求自描述	更像标准无状态 HTTP 服务
状态管理	依赖 `Mcp-Session-Id` 和特定 Server 实例	使用显式 `jobId/workspaceHandle` 等状态句柄	可扩容、可恢复、状态更透明
Server→Client 交互	Server 在双向流里主动回调	MRTR：返回 `input_required`，Client 补充信息后重试	不再依赖持续双向连接
长任务	长时间占用连接或自定义实现	Tasks 扩展：`taskId`、轮询、恢复、补充输入	适合 CI、仿真、综合、P&R 等长任务
网关治理	网关必须解析 JSON-RPC Body	HTTP Header 增加 `Mcp-Method`、`Mcp-Name`	可按工具直接鉴权、限流、计费
缓存	Tool/Resource 列表频繁重复获取	`ttlMs`、`cacheScope`、确定性排序	减少延迟、请求量和 Prompt Cache 抖动
可观测性	MCP 自己的 Logging	标准化 OpenTelemetry 上下文传播	容易接入公司已有监控平台
扩展机制	功能不断塞进核心协议	正式 Extension Framework	核心更稳定，能力按需扩展
授权	OAuth 流程仍有混用风险	Issuer 校验、凭据绑定、CIMD	安全边界更清楚

表里九行，改的是同一件事：MCP 不再把“连接”当成状态容器，每个请求都要说明自己是谁、支持什么、要做什么。

旧 MCP 为什么难以进入生产环境

旧版 MCP 的思路与 Language Server Protocol 有明显血缘关系。Client 先发 initialize，双方协商版本和能力；Server 返回 Session ID；后续请求沿着这条会话继续。Server 还可以通过保持打开的流，反向请求 Client 提供 Roots、Sampling 或用户输入。

在一台开发机上，这套设计很自然。Client 和 Server 长时间连接，状态放在内存里，交互也足够直接。

放进公司集群后，问题变了。

假设第一次 initialize 被转发到 Pod A，Pod A 创建 Mcp-Session-Id。下一次 tools/call 被负载均衡到 Pod B，Pod B 并不知道这个 Session。工程团队通常只有几种选择：使用 Sticky Session、把 Session 状态放进共享存储、或者自己改 Transport。任何一种都会增加运维复杂度。

连接中断也麻烦。Server 到 Client 的回调依赖双向流，代理、WAF、Serverless 平台和移动网络未必愿意长时间保持它。长任务更尴尬：一场回归仿真、一次综合或一轮 P&R 可能运行几个小时，不能指望 HTTP 连接一直活着。

2026-07-28 处理的是成熟分布式系统绕不开的约束，而不是单纯追求更快的工具调用。

变化一：无握手、无协议级 Session

新版删除了：

- initialize/notifications/initialized； - Mcp-Session-Id； - 依赖连接保存的协议状态。

每次请求通过 _meta 携带协议版本和 Client 能力。Client 身份也应随请求发送；Server 身份放在返回结果的 _meta 中。Server 必须实现 server/discover，用来公布支持的版本、能力与身份，但 Client 不必先调用它。Client 也可以直接发送请求，在收到 UnsupportedProtocolVersionError 后重新选择版本。

这带来一个直接结果：任何请求都可以落到任意 Server 实例。普通轮询负载均衡就能工作，不再要求共享 MCP Session。

不过，“MCP 无状态”很容易被误解成“应用不再需要状态”。事实正相反。状态只是不能继续偷偷藏在传输层里。

例如一个综合 Agent 至少要知道：

projectId
designRevision
constraintRevision
workspaceHandle
jobId
artifactUri

这些状态应该由业务服务显式生成，再作为工具参数传递。需要跨请求持久化的内容，要落到数据库、对象存储、任务系统或可恢复的工具进程中。

这种设计会多写一些字段。好处也很实际：状态能审计，故障后能恢复，不同 Agent 可以围绕同一个 Handle 协作。

变化二：MRTR 取代 Server 主动回调

新版引入 Multi Round-Trip Requests，简称 MRTR。它解决的是一个很具体的问题：Server 处理请求时，突然需要用户确认、额外参数或 Client 侧能力，怎么办？

旧做法是 Server 沿着双向连接反向发起请求。新做法是暂停当前业务过程，把缺少的信息作为结果返回：

{
  "resultType": "input_required",
  "inputRequests": {
    "approve_cost": {
      "method": "elicitation/create",
      "params": {
        "message": "本次回归预计占用 400 CPU·h，是否继续？"
      }
    }
  },
  "requestState": "opaque-protected-state"
}

Client 向用户展示确认信息，收集答案，再携带 inputResponses 和 requestState 重试原始请求。两次请求彼此独立，可以由不同 Server 实例处理。

requestState 对 Client 是不透明的。官方规范还特别要求 Server 把它当成攻击者可控输入；一旦它会影响授权或业务逻辑，就必须使用 HMAC、AEAD 等方式保护完整性，并绑定用户、原始请求和有效期，防止篡改与重放。

MRTR 很适合公司内部的高风险操作：

- 修改 SDC、UPF 或关键配置； - 覆盖已有网表和报告； - 提交高成本仿真、综合或云资源任务； - 删除工作区； - 在真正执行前展示影响范围与审批人。

它没有替公司定义“谁能批准什么”，但给审批系统和 Agent 之间提供了标准的暂停、询问和继续机制。

变化三：Tasks 让长任务成为一等能力

MRTR 适合短流程里的补充交互。综合、回归、P&R、CI Pipeline 等任务还需要另一套机制，因为它们不能靠重试原请求一直等下去。

Tasks 从试验性核心能力移入正式扩展框架。Server 可以立即返回一个持久化 taskId，Client 通过 tasks/get 查询状态，也可以通过 subscriptions/listen 订阅变化。

Task 有五类状态：

状态	含义
`working`	后台任务正在执行
`input_required`	任务中途需要补充输入或审批
`completed`	执行完成，结果可取回
`failed`	任务失败并返回错误信息
`cancelled`	任务进入取消状态

当 Task 进入 input_required，Client 可以使用 tasks/update 补充信息。Client 即使崩溃或重启，只要保留 taskId，就可以继续追踪。

Server 必须先持久化任务，再把 taskId 返回给 Client。否则 Server 刚返回成功就宕机，Client 拿着一个不存在的 ID，所谓“可恢复”只是界面上的假象。

对 EDA 场景来说，Tasks 不是锦上添花。它补上了 MCP 与真实工程 Flow 之间最明显的时间尺度差异。

变化四：网关可以看懂“正在调用哪个工具”

过去，MCP 的方法名和工具名主要藏在 JSON-RPC Body 里。网关要做精细化策略，必须解析请求体，理解 MCP Schema，再提取工具信息。

新版要求 Streamable HTTP 请求携带：

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: run_synthesis

Header 名称进入标准协议后，API Gateway、WAF、Service Mesh 和 Rate Limiter 都可以直接工作。企业可以建立按工具分级的策略：

工具	推荐策略
`query_report`	项目成员可调用，只读审计
`run_synthesis`	项目权限 + License 配额 + 并发限制
`modify_constraint`	写权限 + MRTR 审批 + 变更留痕
`publish_netlist`	指定角色 + 双人复核
`delete_workspace`	默认禁止，临时授权

这会改变公司建设 MCP 的组织方式。以前每个业务团队可以单独做 Server；以后更合理的形态是统一入口、统一身份、统一审计，业务团队只维护自己的能力实现。

变化五：缓存开始考虑 LLM 的真实成本

新版要求 tools/list、prompts/list、resources/list、resources/read 等结果提供：

- ttlMs：结果可以保持新鲜多长时间； - cacheScope：缓存是 public 还是 private； - 确定性排序：相同工具集合尽量保持相同顺序。

确定性排序看起来是个小修正，却很懂 LLM 系统。很多 Client 会把工具描述放进模型上下文；即使工具没有变化，只要返回顺序不同，上游 Prompt Cache 就可能失效。稳定顺序能够降低无意义的 Token 处理和缓存抖动。

公司内部需要对 cacheScope 保持克制。公开产品说明可以共享缓存，项目报告、RTL 元数据、数据库 Schema 和用户权限相关的 Tool 列表通常应该使用 private。缓存键也要包含身份和项目边界，不能因为“协议允许缓存”就把不同用户的结果混在一起。

还有一条不能省：隐藏某个 Tool 不是权限控制。无论工具是否出现在缓存列表里，真正执行 tools/call 时都要重新鉴权。

变化六：可观测性回到 OpenTelemetry

新版为 _meta 中的 traceparent、tracestate 和 baggage 定义了 OpenTelemetry 传播约定。

这样可以把一条链路串起来：

用户请求
  → 模型推理
  → Agent 规划
  → MCP Gateway
  → tools/call
  → EDA Job Scheduler
  → DC/Formality/VCS
  → 报告与产物

企业真正关心的不只是“工具有没有报错”，还包括：模型为什么选择这个工具、等待时间消耗在哪一段、一次失败重试了多少次、License 排队多久、最终产物来自哪个输入版本。

MCP 只负责传播 Trace Context。Span 怎么设计、Prompt 和 Tool 参数允许记录到什么粒度、敏感信息如何脱敏，仍然是平台侧的责任。

变化七：核心协议开始做减法

2026-07-28 建立了正式 Extension Framework。Client 和 Server 通过能力字段显式声明支持哪些扩展，双方不支持时应降级，而不是让可选能力污染核心协议。

目前官方扩展方向包括：

- Tasks：长任务、轮询、恢复和中途输入； - MCP Apps：在对话中承载交互式界面； - OAuth Client Credentials：面向后台服务和 CI 的机器身份； - Enterprise-Managed Authorization：对接企业 IdP，集中管理员工访问。

扩展存在，并不等于所有 MCP Client 已经实现。官方文档明确说明，授权扩展需要 Client 显式支持，且不同 Client 的实现进度并不一致。公司选型时要测试真实的 Client/SDK 组合，不能只看协议页面上的功能清单。

变化八：OAuth 的边界被收紧

授权一直是 MCP 远程部署中最费集成时间的部分。新版主要修了几类容易出问题的边界：

第一，Client 要验证授权响应里的 Issuer，避免把一个授权服务器发出的 Code 送到另一个服务器兑换。

第二，持久化的 Client Credential 必须按 Issuer 隔离，不能在不同授权服务器之间复用。

第三，Dynamic Client Registration（DCR）进入弃用状态，推荐使用 Client ID Metadata Documents（CIMD）或预注册机制。

第四，Scope 可以按操作逐步提升。只读查询先拿最小权限；当工具真的需要写权限时，Server 返回 insufficient_scope，Client 再执行 Step-up Authorization。这样比一开始给 Agent 一张“全权限通行证”安全得多。

企业部署还可以选择两类授权扩展：后台服务和 CI 使用 OAuth Client Credentials；员工使用的 AI Client 则可以对接 Enterprise-Managed Authorization，把准入、离职撤权和条件访问统一收回公司 IdP。

但协议不会自动生成业务 RBAC。files:write、project:signoff、license:consume 等 Scope 如何映射到组织、项目和角色，需要公司自己定义。

变化九：一批旧能力开始退场

新版正式弃用 Roots、Sampling、Logging 和旧 HTTP+SSE Transport。弃用不等于立即删除。规范给出至少 12 个月窗口，旧系统可以继续工作，但新项目不应再基于这些能力建设。

官方建议的迁移方向很清楚：

被弃用能力	推荐方向
Roots	使用 Tool 参数、Resource URI 或 Server 配置传递文件边界
Sampling	Host/Agent Harness 直接调用模型 Provider
Logging	STDIO 写 `stderr`，远程部署使用 OpenTelemetry
HTTP+SSE	迁移到 Streamable HTTP

这不是简单的接口替换。它重新划分了 Host 和 Server 的职责：模型、上下文、审批与观测主要由 Host/平台掌握；MCP Server 提供边界明确的业务能力。

这也是我认为本次更新最值得关注的部分。MCP 没有继续追求“大而全”，而是在主动减少双向魔法，把自己变成更容易治理的协议层。

企业内部 AI 架构会怎么变

新版之后，一套更合理的企业架构可以分成四层：

层次	职责	不应该承担的职责
Agent Host/Harness	模型调用、规划、上下文、记忆、审批编排	不直接绕过权限操作底层系统
MCP Gateway	身份、RBAC、Scope、限流、审计、版本兼容、路由	不理解具体 EDA 算法和业务细节
Domain MCP Server	暴露稳定的业务能力和 Schema	不把会话状态藏在单个进程中
Job/Artifact Backend	长任务、状态持久化、产物、日志、恢复	不直接接受模型的无约束命令

没有必要再造一个“万能 MCP 平台”。平台层负责共性控制，业务 Server 负责能力语义。两边的边界越清楚，后续接入不同模型、IDE、Chat Client 和自动化 Agent 时，重复建设越少。

企业 MCP Gateway 应该管什么

一套能上线的 Gateway 至少需要：

1. 同时处理旧版和 2026-07-28 的版本协商；

2. 根据 Mcp-Method、Mcp-Name 和用户身份执行策略；

3. 对有副作用的工具执行审批、限流和幂等检查；

4. 传播 OpenTelemetry Trace Context；

5. 管理 Tool/Resource 缓存，并严格区分 Public 与 Private；

6. 统一记录调用人、项目、输入版本、结果状态和产物位置；

7. 对 Tool 描述、Schema 和 Server 身份建立准入流程。

最后一项经常被低估。Tool 描述本身也是模型上下文的一部分，不能因为它来自 MCP Server 就自动信任。未经审核的描述可能诱导模型选择错误工具，甚至成为 Prompt Injection 的载体。

放进 AI4EDA：一场综合任务应该怎样跑

以 run_synthesis 为例。旧式实现很容易把当前目录、设计版本、DC 进程和 License 状态全放进 MCP Session。Agent 只看到一句“继续综合”，真正依赖什么上下文并不清楚。

新版更适合把过程拆开。

1. 冻结输入快照

Agent 先调用 create_design_snapshot，得到：

{
  "projectId": "orion",
  "designRevision": "rtl-v184",
  "constraintRevision": "sdc-v37",
  "librarySet": "n6-r12",
  "snapshotId": "snap-8f23"
}

2. 提交任务

调用 run_synthesis 时携带 snapshotId、运行策略和幂等键：

{
  "snapshotId": "snap-8f23",
  "compileMode": "dct-ultra",
  "idempotencyKey": "orion-snap-8f23-dct-ultra-r1"
}

幂等的含义是：同一个请求因为超时或断线被重复提交，也只产生一次业务副作用。Server 第一次创建 jobId=syn-1042；再次收到相同 idempotencyKey 时，直接返回已有 jobId，不能再启动一份 DC、再占一份 License。

3. 返回 Task

Server 持久化任务后返回：

{
  "resultType": "task",
  "task": {
    "taskId": "syn-1042",
    "status": "working",
    "pollIntervalMs": 10000
  }
}

4. 中途要求确认

如果综合过程中发现需要改写关键 SDC，Task 进入 input_required。Client 展示差异、影响范围和审批人，用户确认后通过 tasks/update 继续。

5. 固化产物与证据

任务结束后返回结构化结果：

{
  "status": "completed",
  "netlistUri": "artifact://orion/syn-1042/netlist.v.gz",
  "reportUri": "artifact://orion/syn-1042/qor.json",
  "logUri": "artifact://orion/syn-1042/dc.log.gz",
  "inputSnapshot": "snap-8f23",
  "toolVersion": "dc-R-2025.09-SP2"
}

这样做之后，Agent 的“记忆”不再是唯一证据。输入、任务、审批、日志和产物都有可以复查的 Handle。对于 Formality、ECO、DFT、仿真回归和 P&R，同样可以沿用这个模式。

迁移时最容易踩的五个坑

1. 把“无状态”误解成“不需要状态服务”

Session 消失后，任务、工作区、第三方 Token 和产物都需要外部持久化。没有 Job Store 的所谓无状态 Server，只是把故障窗口藏得更深。

2. 忽略副作用工具的幂等性

新版移除了 SSE Stream 的恢复与消息重投。响应流断开后，Client 要用新的 Request ID 重发请求。Server 可能已经执行成功，只是结果没有送达。提交任务、创建资源、扣减配额、发送消息、修改配置等操作都要增加业务幂等键。

3. 用 Tool 可见性代替授权

Tool 列表可以缓存，也可能按用户显示不同内容，但最终权限必须在每次 tools/call 时检查。模型知道或猜到工具名，并不意味着它有权调用。

4. 认为扩展已经被所有 Client 支持

Tasks、MCP Apps、机器身份和企业授权都需要双方显式协商。协议刚刚发布，Tier 1 SDK 已跟进，但上层 Client 的实现节奏不同。生产系统应保留降级路径。

5. 一次性升级整个系统

新版属于 Breaking Revision。官方 SDK 提供新旧版本兼容能力，但不同语言的默认行为和启用方式不完全相同。先做双版本 Endpoint 和真实负载测试，比全量切换稳妥得多。

一条可执行的企业迁移路线

阶段一：盘点

找出所有依赖以下机制的实现：

- initialize 和 Mcp-Session-Id； - 内存 Session、Sticky Session； - Server 主动发起的 Sampling、Roots、Elicitation； - 长连接任务和 SSE 恢复； - Roots、Sampling、Logging、HTTP+SSE； - 无幂等保护的写操作。

阶段二：双版本试点

先选择两个 Server：一个只读知识查询 Server，一个长任务 Server。前者验证 server/discover、缓存、网关鉴权和 Trace；后者验证显式 Handle、Tasks、MRTR、崩溃恢复和幂等。

阶段三：外置状态

把工作区、Job、审批、产物和第三方授权状态从 MCP 连接中移走。建立统一的 Handle 规则、TTL、租户隔离和回收策略。

阶段四：接入治理

在 Gateway 中落实 Tool 级别 RBAC、Scope、限流、License 配额、审计和 OpenTelemetry。为敏感缓存指定 private，为写操作增加幂等键和审批门禁。

阶段五：逐步停用旧能力

新项目不再采用 Roots、Sampling、MCP Logging 和 HTTP+SSE。已有系统根据至少 12 个月的弃用窗口逐步迁移，不需要为了追版本制造新的生产风险。

MCP 仍然没有解决什么

这版协议更接近生产环境，但边界要看清。

它没有定义 Agent 如何规划，也没有提供可靠的长期记忆；没有判断 Tool 的业务语义是否正确；没有消除 Prompt Injection 和 Tool Poisoning；没有替企业定义 RBAC、审批链与数据分级；更没有保证一次工具调用生成的网表、报告或数据库修改是正确的。

MCP 解决的是“如何标准化地连接与调用能力”。Agent Harness 负责决策和上下文，Gateway 负责控制，业务系统负责真相与执行，Verifier 负责验证结果。把这些职责全塞回 MCP Server，最后仍会得到一个难以审计的黑箱。

结语

2026-07-28 不是一次让 Demo 更炫的更新。恰恰相反，它处理的是负载均衡、断线重试、长任务、权限、缓存和观测这些工程问题。

旧版 MCP 更像一条聪明的连接；新版 MCP 更像一组可以被基础设施理解的请求。Session 被拿掉，状态反而必须说清楚。Server 不能随意回调，交互却有了可恢复的 MRTR。工具名进入 Header 后，安全与运维团队终于能在不理解模型 Prompt 的情况下执行策略。

对公司内部 AI 来说，这意味着 MCP 可以成为能力接入层，但前提是公司同时建设 Gateway、显式状态、任务系统、幂等、审计和验证闭环。少了其中任何一块，协议升级都只是换了一种调用格式。

对 AI4EDA 来说，这条边界更重要。综合、仿真、形式验证和 P&R 都有昂贵工具、长时间任务、严格输入基线与高风险副作用。最值得做的不是把 dc_shell 直接包装成几十个 MCP Tool，而是把设计快照、任务、审批、证据与产物建模为可追踪的工程对象。新版 MCP 终于为这种做法提供了更合适的线协议。

---