摘要：MCP 2026-07-28删除初始化握手和协议层会话，把每次工具调用改造成可独立路由的自描述请求。对工业智能体而言，这意味着数据库、PLM、MES、CAE和设备系统接口更容易横向扩展、鉴权、审计和纳入企业API网关。
2026年7月28日，Model Context Protocol发布新一版正式规范。它在开发者社区中常被称为“MCP 2.0”，规范采用的正式版本号是2026-07-28。
这次升级的核心变化十分明确：MCP从依赖初始化握手和会话标识的双向有状态协议，转向以一次请求为基本单位的无状态协议。客户端调用工具时，不再需要先创建会话，也不再依赖Mcp-Session-Id把后续请求固定到某台服务器。每个请求携带协议版本和客户端能力，并通常附带客户端实现信息；认证凭据仍按OAuth和传输层规则另行携带。请求因此可以由负载均衡器后面的任意服务实例处理。
围绕无状态内核，新规范还同时加入能力发现、请求头路由、结果缓存、多轮交互、长任务扩展、OpenTelemetry trace context传播和OAuth安全加固，并为大部分旧功能建立至少十二个月的弃用窗口。
从工程角度看，这是MCP发布以来最重要的一次架构调整。它把一个带有明显本地进程和长连接色彩的智能体协议，推进到能够直接运行在云原生基础设施、企业API网关和大规模多租户环境中的协议形态。
MCP解决的究竟是什么问题
大语言模型能够理解文本、生成代码和制定任务计划，但模型自身不能直接读取企业数据库、调用设计软件、查询实时设备状态或创建业务工单。
要让模型执行这些操作，开发者需要为每个外部系统编写接口，并向模型描述：
- 系统提供哪些能力；
- 每个能力需要哪些输入参数；
- 返回结果采用什么结构；
- 哪些操作可以执行；
- 哪些数据可以读取；
- 什么情况下需要用户确认。
MCP提供了一套统一描述方法。在典型架构中，AI应用是Host，Host内部运行MCP Client，外部业务能力由MCP Server提供。服务器可以暴露三类主要对象：
- Tools：可以执行的工具，例如查询数据库、调用API、生成报告；
- Resources：可以读取的数据，例如文件、设备记录、知识库和数据库模式；
- Prompts：可复用的提示模板和任务范式。
MCP底层使用JSON-RPC 2.0传递消息，标准传输方式包括本地的stdio和远程的Streamable HTTP。对模型来说，不同业务系统最终被表示成一组带有清晰名称、说明和JSON Schema的工具。模型可以根据任务选择工具、填写参数，并读取结构化返回结果。
截至2026年7月，MCP官方称，其一级SDK每月下载量已接近5亿次，TypeScript和Python SDK的累计下载量均已超过10亿次。下载量可能包含自动构建和重复安装，但仍能反映协议在智能体开发生态中的扩散速度。
旧版MCP为什么需要会话
在2025-11-25等早期规范中，客户端通过HTTP调用远程MCP服务器时，需要先发送initialize请求：
1 | POST /mcp |
客户端和服务器通过这次握手确定协议版本、双方能力和实现信息。Streamable HTTP服务器可以在初始化响应中分配一个Mcp-Session-Id；一旦分配，客户端后续请求就必须携带。例如：
1868a90c-3a3f-4f5b
客户端调用工具时，需要把这个标识放进HTTP请求头：
1 | POST /mcp |
这种设计对本地工具和小规模服务比较自然。客户端初始化一次，后续在同一个逻辑会话中调用工具，服务器也可以记住客户端支持哪些能力。
进入大规模部署后，会话开始带来额外负担。
假设一个MCP服务器运行了20个实例，负载均衡器把请求随机分发给不同实例。第一次初始化发生在第3号实例，后续工具调用却可能被转发到第11号实例。第11号实例没有对应的会话数据，无法确认协议版本和客户端能力。
工程团队通常有两种解决办法。
第一种是粘性会话，让同一个Mcp-Session-Id始终访问同一台服务器。这会削弱负载均衡的灵活性。某个实例重启、扩容或被下线时，相关会话容易中断。
第二种是把会话状态放进Redis等共享存储，让所有服务器实例都能读取。这样会增加一次网络访问、一个基础设施依赖和一套会话过期机制。共享存储还要处理并发写入、故障恢复和跨区域同步。
对于只有几十个工具的MCP服务器，为保存协议版本、客户端能力和连接信息引入一套分布式会话系统，成本显得偏高。
无状态MCP怎样完成一次工具调用
在2026-07-28规范中，initialize和notifications/initialized握手被删除，Mcp-Session-Id也退出协议。每个请求需要携带完成处理所需的信息。
一次新的工具调用大致如下：
1 | POST /mcp |
这个请求可以被任意MCP服务器实例独立处理。服务器不需要查询前一次握手，也不需要根据会话标识恢复协议上下文。
新版规范要求每个请求在 _meta 中携带协议版本和客户端能力。客户端通常还会附带 clientInfo，服务器也通常在结果中给出 serverInfo，但二者属于自报的实现名称与版本，不能替代OAuth身份，也不能用于安全决策。
如果服务器不支持客户端请求的协议版本，会返回UnsupportedProtocolVersionError以及自身支持的版本。客户端可以选择一个双方兼容的版本重新发送请求。
这类设计与成熟HTTP API的思想接近：请求应尽量自描述，服务端仅依靠当前请求和明确的业务数据完成处理。
取消会话不等于取消业务状态
无状态MCP经常引出一个疑问：如果任务需要连续执行十几个步骤，没有会话还怎么工作？
答案是把业务状态从协议隐含状态改成显式对象。
例如，智能体要创建一个仿真任务，可以先调用：
1 | create_simulation(model, parameters) |
服务器返回：
1 | { |
后续调用继续传递这个标识：
1 | upload_boundary_conditions(simulation_id, file) |
购物篮可以使用basket_id，浏览器自动化可以使用browser_id，工业工单可以使用work_order_id，CAE计算可以使用job_id。
这种显式句柄有几个优势：
首先，模型能够看到状态对象。它知道某个simulation_id对应哪次仿真，可以在多个工具之间传递，也可以同时管理多个任务。
其次，权限可以绑定到具体对象。系统能够规定某个用户只能访问自己创建的job_id，并为句柄设置过期时间、租户范围和操作权限。
再次，故障恢复更清楚。服务器实例重启后，只要业务状态保存在数据库或任务系统中，新的实例便能根据句柄继续工作。
协议层保持无状态，应用层仍然可以维护复杂状态。区别在于业务状态被放回业务系统，拥有清晰的数据模型和生命周期，不再藏在传输会话里。
server/discover解决能力发现问题
取消初始化握手后，客户端如何知道服务器支持哪些功能？
新规范增加了server/discover。所有支持2026-07-28规范的服务器都必须实现该方法，客户端可以选择在执行任务前调用。
典型返回结果包含：
1 | { |
其中：
supportedVersions表示服务器支持的协议版本；
capabilities表示服务器提供工具、资源、提示模板或通知等能力；
ttlMs: 3600000表示结果可以在一小时内视为新鲜；
cacheScope: public表示允许共享缓存。
server/discover对客户端是可选操作。因为每个普通请求已经包含协议版本和客户端能力，客户端也可以直接调用工具，在收到版本错误后再调整。能力发现更适合需要提前加载工具目录、生成界面或建立路由表的Host。
多轮请求让无状态协议继续支持用户确认
智能体工具调用经常需要中途补充信息。
例如：
删除三份文件前要求用户确认；
创建云资源前展示预计费用；
提交采购申请前补充预算科目；
修改设备参数前确认设备编号和安全条件；
运行CAE仿真前要求选择材料模型；
写入生产系统前要求审批人授权。
旧版MCP允许服务器通过持续保持的双向连接，主动向客户端发送elicitation/create等请求。无状态协议取消了长期双向会话，新规范因此引入Multi Round-Trip Requests，简称MRTR。
当工具缺少用户输入时，服务器先返回：
1 | { |
客户端展示确认界面，取得用户回答后，使用新的JSON-RPC id，携带 inputResponses 和原来的 requestState 重新调用同一个工具。因为请求中已经包含恢复流程所需的信息，第二次调用可以落到另一台服务器实例。MRTR适用于 tools/call、prompts/get 和 resources/read。
resultType 在新规范中成为结果的必填字段。核心协议定义：
complete表示调用已经完成；input_required表示需要补充输入。
扩展还可以增加新的值，例如Tasks使用 task。
对工业智能体而言，这种机制尤其重要。读取设备状态可以自动完成，修改控制参数、删除数据、启动高成本任务和提交正式业务单据则需要人工确认。MRTR为“人在回路”提供了统一协议形式。
请求头路由让网关看得懂智能体操作
Streamable HTTP现在要求所有JSON-RPC请求携带 Mcp-Method。对于 tools/call、resources/read 和 prompts/get，还必须携带对应的 Mcp-Name。例如：
1 | Mcp-Method: tools/call |
API网关、WAF、负载均衡器和限流系统可以直接根据HTTP请求头判断当前操作，无需解析JSON-RPC正文。
企业可以据此建立更细的控制策略：
- tools/list允许较高访问频率；
- execute_sql每分钟限制调用次数；
- delete_record只能由指定角色访问；
- run_simulation根据GPU配额限流；
- change_setpoint必须经过强认证；
- 高风险工具转发到带人工审批的服务链路。
协议正文仍然是信息的权威来源。如果请求头中的工具名称与JSON正文不一致，服务器应拒绝请求。这样可以防止客户端在请求头中伪装成低风险工具，正文却调用高风险操作。
新版规范为此定义了HeaderMismatchError，正式错误码为-32020。MissingRequiredClientCapability和UnsupportedProtocolVersion分别使用-32021和-32022。
工具目录开始支持标准缓存
智能体Host通常会先调用tools/list获取工具目录，再把工具名称、说明和参数模式加入模型上下文。
如果服务器拥有几百个工具，每次建立连接都重新获取完整目录，会产生网络开销和Token开销。工具顺序随机变化还会改变提示词内容，降低模型Prompt Cache的命中率。
新规范要求以下结果提供 ttlMs 和 cacheScope：
server/discover；tools/list；prompts/list；resources/list；resources/templates/list；resources/read。
ttlMs 给出结果的新鲜时间，单位为毫秒，它是缓存提示而不是内容绝对不变的保证；cacheScope 分为 public 和 private，用于决定共享代理能否缓存。规范还建议服务器以确定性顺序返回工具，尽量让相同工具目录生成相同上下文。
这项变化看似细小，对大规模智能体平台的成本影响却很直接。稳定的工具目录可以减少重复请求，提高上游提示缓存命中率，也能缩短智能体开始执行任务前的准备时间。
长任务从核心协议移入扩展
工业任务经常无法在一次同步调用中完成。一次复杂有限元计算可能持续数十分钟，批量数据清洗可能运行数小时，模型训练和视频生成甚至需要更长时间。
新版MCP将Tasks从实验性核心功能移入正式扩展：
io.modelcontextprotocol/tasks
服务器可以在tools/call后返回一个任务句柄，客户端通过以下方法管理：
tasks/get：查询任务状态和结果；
tasks/update：向任务补充输入；
tasks/cancel：取消任务。
旧的阻塞式tasks/result和tasks/list被移除。特别是tasks/list，在没有会话的情况下很难安全地确定“列出谁的任务”，容易产生跨用户和跨租户泄露，因此新设计要求客户端围绕明确的任务句柄操作。
工具和资源变化通知则统一进入subscriptions/listen。客户端通过一个长时间保持的POST响应流，订阅工具列表、提示列表、资源列表或具体资源的变化。普通请求的进度通知仍在该请求自己的响应流中返回。
OAuth和企业授权得到进一步加固
MCP的典型形态是一个客户端连接多个服务器和多个授权系统，这种结构容易出现授权服务器混淆问题。
新规范建议授权服务器在授权响应中返回 iss。客户端一旦收到 iss，就必须与预先记录的发行者比较；如果服务器元数据声明支持该参数而响应中缺失，客户端也必须拒绝。通过预注册或Dynamic Client Registration获得并持久化的凭据应绑定到具体issuer，不能把一个授权服务器签发的凭据直接拿到另一个服务器使用。
对于桌面端和CLI客户端，Dynamic Client Registration需要声明正确的application_type，减少本地回调地址被误判为Web回调而遭到拒绝的问题。
长期方向上，MCP已经把Dynamic Client Registration列为弃用功能，推荐迁移到Client ID Metadata Documents。Roots、Sampling和Logging也进入弃用周期，这些功能最早可在2027年7月28日之后的规范版本中移除：
- 文件和目录通过工具参数、资源URI或服务器配置传递；
- 模型采样直接接入模型提供商API；
- 日志使用stderr或OpenTelemetry。
旧HTTP+SSE传输也应迁移到Streamable HTTP，但它采用单独的退出时间表，不能与上述功能一概表述为至少十二个月。
从mcp-explorer和Datasette看实际开发变化
新规范发布后，开发者Simon Willison基于无状态MCP推出了三个项目。
第一个是mcp-explorer。开发者可以通过一条命令查看服务器提供的工具：
1 | uvx mcp-explorer list https://example.com/mcp |
也可以检查某个工具的输入输出Schema：
1 | uvx mcp-explorer inspect https://example.com/mcp render_svg |
或者直接调用工具：
1 | uvx mcp-explorer call \ |
第二个是datasette-mcp。它为Datasette增加 /-/mcp 端点，默认暴露三个只读工具，其他插件也可以通过hook继续增加工具：
list_databases()；
get_database_schema(database_name)；
execute_sql(database_name, sql)。
其中SQL执行暂时限定为只读。接入ChatGPT、Claude或其他智能体后，模型便可以先查看数据库结构，再编写并执行查询。Willison展示的一次问答中，模型连续执行了7条SQL语句完成分析。
第三个是llm-mcp-client，用于让命令行LLM工具直接连接远程MCP服务器。
这些项目说明，无状态协议降低了轻量客户端和服务端的实现门槛。开发者可以把一个数据库查询接口包装成MCP服务器，也可以快速编写检查、调用和调试工具，无需先实现复杂的会话生命周期。
它对工业智能体平台意味着什么
工业智能体要连接的对象通常包括PLM、MES、ERP、LIMS、SCADA、设备管理系统、知识库、CAD、CAE求解器和企业文件系统。
这些系统具有三个共同特点：接口异构、权限严格、任务周期差异很大。
无状态MCP提供了一种更适合企业部署的连接方式：
1 | 智能体Host |
MCP服务实例可以通过普通负载均衡横向扩容。网关根据Mcp-Method和Mcp-Name实施鉴权、限流和审计。耗时任务返回job_id，危险操作通过MRTR要求用户确认，工具目录通过ttlMs缓存，traceparent、tracestate 和 baggage 则让调用链能够接入OpenTelemetry体系。
例如，一名工程师可以要求智能体：“调取过去三个月这台泵的振动数据，对比同型号设备，运行一次故障仿真并生成报告。”
智能体可能依次调用：
1 | find_equipment()获取设备标识； |
每个步骤都拥有明确参数、结果、权限和审计记录。底层系统无需向模型开放任意Shell或数据库写权限。
无状态协议仍然需要安全设计
MCP让工具能力比任意Shell命令更容易描述和控制，但协议本身不会自动消除提示注入、越权调用和数据泄露风险。
企业部署仍应遵守几个原则：
- 工具按最小权限设计；
- 查询和写入工具分开；
- SQL等能力优先设置为只读；
- 业务对象句柄绑定用户、租户和权限；
- 高风险操作强制人工确认；
- 工具返回内容视为不可信数据；
- 外部内容不能直接改变系统指令；
- 网关校验请求头与正文一致性；
- 全链路记录调用人、工具、参数摘要和结果状态；
- 机密数据在进入模型前进行脱敏和权限过滤。
无状态化解决的是协议复杂度和基础设施扩展问题，安全能力仍然需要身份、授权、隔离、审计和业务规则共同完成。
结语：MCP开始具备企业级协议的形态
MCP早期解决了“怎样用统一方式把工具交给模型”的问题。2026-07-28版本进一步回答了“怎样把这些工具部署到大规模企业环境中”。
握手和会话标识被移除后，一次工具调用可以由任意实例处理；显式句柄承载业务状态；MRTR支持用户确认；Tasks管理长时间任务；标准请求头支持网关路由；缓存提示降低目录重复获取成本；trace context让调用链更容易接入OpenTelemetry；OAuth调整减少多授权服务器环境中的混淆风险。
对于工业智能体，协议轻量化带来的价值尤其明显。CAD、CAE、MES、设备数据和企业知识库可以继续保留各自的数据模型和权限体系，MCP服务器负责把经过控制的能力整理成模型能够理解和调用的标准工具。
随着无状态内核、扩展框架和企业授权逐渐稳定，MCP正在从智能体开发中的接口约定，成长为智能体访问业务系统的一层通用基础设施。