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

芯片人看AI · MCP协议约4000字 / 阅读约12分钟MCP 2026-07-28Agent协议MRTRTasks无状态企业AIAI4EDA网关治理OAuth授权OpenTelemetry缓存可观测说明协议变更均对照 MCP 官方规范与 Changelog企业架构和 AI4EDA 部分是基于这些变更给出的工程分析。MCP 终于开始处理那些不太性感、却真正决定系统能不能上线的问题了。上一阶段大家讨论 MCP重点通常是“模型能不能调用工具”“能不能连接数据库”“有没有足够多的 MCP Server”。到了公司内部真正部署时麻烦很快从模型侧转移到工程侧MCP Server 怎么横向扩容请求被负载均衡到另一台机器怎么办长任务断线后怎么恢复用户确认如何穿过网关安全团队怎样按工具鉴权一次超时重试会不会重复提交两份任务、占用两份 License2026 年 7 月 28 日发布的新版规范正面回答了这些问题。它把 MCP 从有状态、双向、偏本地插件的通信模型改造成无状态、可路由、可缓存的请求响应协议。官方称这是 MCP 发布以来最大的一次修订。这个说法并不夸张initialize握手、协议级 Session、Server 主动回调、SSE 续传等基础机制都被重写了。我的判断是MCP 正从“Agent 的通用插座”向“企业 AI 能力总线的线协议”靠近。但它仍然不是完整的 Agent Runtime也不会替公司解决业务权限、工具正确性和 Prompt Injection。一张表看懂这次重构维度旧版 MCPMCP 2026-07-28实际进步连接模型initialize 握手维护 Session取消握手每个请求自描述更像标准无状态 HTTP 服务状态管理依赖 Mcp-Session-Id 和特定 Server 实例使用显式 jobId/workspaceHandle 等状态句柄可扩容、可恢复、状态更透明Server→Client 交互Server 在双向流里主动回调MRTR返回 input_requiredClient 补充信息后重试不再依赖持续双向连接长任务长时间占用连接或自定义实现Tasks 扩展taskId、轮询、恢复、补充输入适合 CI、仿真、综合、PR 等长任务网关治理网关必须解析 JSON-RPC BodyHTTP 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 APod A 创建Mcp-Session-Id。下一次tools/call被负载均衡到 Pod BPod B 并不知道这个 Session。工程团队通常只有几种选择使用 Sticky Session、把 Session 状态放进共享存储、或者自己改 Transport。任何一种都会增加运维复杂度。连接中断也麻烦。Server 到 Client 的回调依赖双向流代理、WAF、Serverless 平台和移动网络未必愿意长时间保持它。长任务更尴尬一场回归仿真、一次综合或一轮 Pamp;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 适合短流程里的补充交互。综合、回归、Pamp;R、CI Pipeline 等任务还需要另一套机制因为它们不能靠重试原请求一直等下去。Tasks 从试验性核心能力移入正式扩展框架。Server 可以立即返回一个持久化taskIdClient 通过tasks/get查询状态也可以通过subscriptions/listen订阅变化。Task 有五类状态状态含义working后台任务正在执行input_required任务中途需要补充输入或审批completed执行完成结果可取回failed任务失败并返回错误信息cancelled任务进入取消状态当 Task 进入input_requiredClient 可以使用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_synthesisHeader 名称进入标准协议后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 RegistrationDCR进入弃用状态推荐使用 Client ID Metadata DocumentsCIMD或预注册机制。第四Scope 可以按操作逐步提升。只读查询先拿最小权限当工具真的需要写权限时Server 返回insufficient_scopeClient 再执行 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 和旧 HTTPSSE Transport。弃用不等于立即删除。规范给出至少 12 个月窗口旧系统可以继续工作但新项目不应再基于这些能力建设。官方建议的迁移方向很清楚被弃用能力推荐方向Roots使用 Tool 参数、Resource URI 或 Server 配置传递文件边界SamplingHost/Agent Harness 直接调用模型 ProviderLoggingSTDIO 写 stderr远程部署使用 OpenTelemetryHTTPSSE迁移到 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 Context5.管理 Tool/Resource 缓存并严格区分 Public 与 Private6.统一记录调用人、项目、输入版本、结果状态和产物位置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 第一次创建jobIdsyn-1042再次收到相同idempotencyKey时直接返回已有jobId不能再启动一份 DC、再占一份 License。3. 返回 TaskServer 持久化任务后返回{ resultType: task, task: { taskId: syn-1042, status: working, pollIntervalMs: 10000 } }4. 中途要求确认如果综合过程中发现需要改写关键 SDCTask 进入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、仿真回归和 Pamp;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、HTTPSSE - 无幂等保护的写操作。阶段二双版本试点先选择两个 Server一个只读知识查询 Server一个长任务 Server。前者验证server/discover、缓存、网关鉴权和 Trace后者验证显式 Handle、Tasks、MRTR、崩溃恢复和幂等。阶段三外置状态把工作区、Job、审批、产物和第三方授权状态从 MCP 连接中移走。建立统一的 Handle 规则、TTL、租户隔离和回收策略。阶段四接入治理在 Gateway 中落实 Tool 级别 RBAC、Scope、限流、License 配额、审计和 OpenTelemetry。为敏感缓存指定private为写操作增加幂等键和审批门禁。阶段五逐步停用旧能力新项目不再采用 Roots、Sampling、MCP Logging 和 HTTPSSE。已有系统根据至少 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 来说这条边界更重要。综合、仿真、形式验证和 Pamp;R 都有昂贵工具、长时间任务、严格输入基线与高风险副作用。最值得做的不是把dc_shell直接包装成几十个 MCP Tool而是把设计快照、任务、审批、证据与产物建模为可追踪的工程对象。新版 MCP 终于为这种做法提供了更合适的线协议。---官方资料1.MCP 官方发布The 2026-07-28 Specification2.MCP 2026-07-28 Key Changes3.MCP 版本协商与兼容机制4.Multi Round-Trip Requests 规范5.MCP Tasks 扩展6.MCP Caching 规范7.MCP Authorization 规范8.MCP Extensions Overview9.MCP Authorization Extensions· · ·关注「芯片人-晒 AI 笔记」—— 芯片人-晒 AI 笔记