MCP 2026-07-28：无状态协议对 B2B 智能体部署意味着什么

为什么这次发布改变了部署的算法

模型上下文协议（MCP）是一个用于将 AI 智能体连接到外部系统的开放标准。2026 年 7 月 28 日，它发布了自问世以来最大的一次修订——一个候选发布版，它使协议层变为无状态，引入了一等的扩展机制，并弃用了三个在生产中增加复杂度却名不副实的特性。

对于在 B2B 智能体系统背后部署 MCP 服务器的团队来说，实际影响是具体的：你不再需要粘性会话、共享会话存储或会话感知的负载均衡器。智能体在多次工具调用之间所需的状态变成了一个显式句柄——对模型可见、可在日志中审计、并可被中间层缓存。本文将逐一说明对 B2B 部署至关重要的变化，以及它们如何映射到我们已经交付的 MCP 模块模式。

无状态的协议层

最重磅的变化：initialize / initialized 握手和 Mcp-Session-Id 头被移除。请求现在是自包含的。协议版本、客户端信息和能力都随每次请求承载在 _meta 中，而不再存在于一个服务器必须记住的协商会话里。

在 B2B 部署中，这消除了什么：

• 粘性会话负载均衡器。 远程 MCP 服务器可以放在普通的轮询负载均衡器后面。任何服务器实例都能处理任何请求，因为解释请求不需要任何服务器端状态。
• 共享会话存储。 如果你今天做横向扩展，每个 MCP 服务器实例都需要访问同一份会话状态——通常是 Redis 或数据库。无状态协议移除了这一依赖。
• 会话重放基础设施。 当会话在工作流中途断开时，客户端必须重新初始化并重建上下文。无状态协议没有会话可断开；每个请求都携带自己所需的一切。

部署形态变得更简单：一组无状态的 MCP 服务器实例放在负载均衡器后面，它们之间没有共享状态层。这与任何无状态 HTTP API 的形态相同——久经考验、可观测、且扩展成本低廉。

有状态工作流的显式句柄模式

无状态并不意味着状态消失。跨越多次工具调用的工作流——一次 RFQ 受理、一轮报价协商、一次库存预留——仍然需要连续性。候选发布版用显式句柄模式取代了隐藏的会话状态：一个工具铸造出一个句柄（一个 order_id、一个 quote_id、一个 basket_id），模型在后续调用中把它作为普通参数传回。

对 B2B 部署而言，这是一次有意义的转变，原因有三。

状态对模型可见。 今天，会话状态存在于 LLM 从不查看的传输层元数据中。有了显式句柄，模型会在其推理过程中持有并引用该句柄。当模型调用 get_quote(quote_id="q-7f3a") 时，它知道自己正在操作哪一份报价。这提升了多步工作流中工具选择的准确度。

状态可在日志中审计。 每个请求都在请求体中携带其句柄，而不是在应用日志器会剥离的某个头里。审计追踪可以通过读取请求参数在任意时点重建完整的工作流状态——无需与会话存储日志做关联比对。

状态可被中间层缓存。 因为句柄是请求的一部分，网关或缓存层可以以它为键。列表和资源结果携带 ttlMs 和 cacheScope 字段，因此一个带稳定句柄的目录查询可以从缓存中提供服务，而无需访问上游系统。

这如何映射到一个 RFQ 工作流

设想一个跨五次工具调用运行的报价工作流：创建请求、搜索目录、生成报价、预留库存、应用定价层级。在基于会话的协议下，这五次调用共享一个服务器端会话。在显式句柄模式下：

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

每次调用都携带它所需的句柄。没有任何服务器需要在调用之间记住任何东西。如果负载均衡器把第 4 次调用路由到与第 3 次不同的实例，它仍然可以工作——句柄就在请求里。如果审计团队一周后需要重建这个工作流，请求参数中的句柄就能讲述完整的故事。

扩展：一等公民且独立版本化

候选发布版引入扩展作为一等概念。扩展获得反向 DNS 标识符（例如 com.example.workflow），拥有各自的 ext-* 仓库，有委派的维护者，并且独立于核心协议进行版本化。

前两个扩展是具体的：

• MCP Apps — 在沙盒化 iframe 中交付的服务器渲染 HTML UI。MCP 服务器可以交付一个由客户端渲染的 UI，从而在客户端无需构建自定义前端的情况下，实现人在环中的审批界面。
• Tasks — 带任务句柄的长时运行工作。工具可以立即返回一个任务句柄，客户端随后轮询完成情况，而不必让连接开启数分钟之久。

对 B2B 部署来说，MCP Apps 在需要人工审批某笔交易后智能体才能继续时至关重要——超过阈值的采购订单，或带有非标准折扣的报价。审批界面可以随 MCP 模块一起交付，而无需一个单独的前端。Tasks 则对超出单次请求超时的工作流至关重要：一份需要 90 秒生成的供应商报价，一次运行数分钟的目录同步。

弃用：Roots、Sampling、Logging

三个特性被弃用（仅做注解标记，为期 12 个月；移除需要一个单独的标准流程）：

• Roots → 由工具参数和资源 URI 取代。Roots 曾是客户端向服务器告知文件系统位置的一种方式；如今同样的意图被表达为读取文件的工具的参数。
• Sampling → 由直接的 LLM 提供方 API 集成取代。需要 LLM 调用的服务器直接向提供方发起调用，而不再请求客户端执行一次采样往返。
• Logging → 由 stderr 和 OpenTelemetry 取代。服务器日志转移到标准进程输出和分布式追踪，而不再走 MCP 日志通道。

Logging 的弃用对 B2B 部署最为相关。审计日志模式——每次工具调用都记录请求、响应、延迟和结果——如今与 OpenTelemetry 对齐，而不再依赖某个协议专有的日志通道。这意味着 MCP 服务器日志可以在无需自定义传输的情况下集成进现有的可观测性管道（Datadog、CloudWatch、Honeycomb）。

可路由、可缓存、可追踪

三项影响生产运维的新增内容：

• Mcp-Method 和 Mcp-Name 头使网关无需检查请求体即可路由。网关可以在头这一层按方法和工具名路由——路由层无需解析 JSON。
• 列表 / 资源结果上的 ttlMs 和 cacheScope 为中间层提供了标准的缓存契约。一个目录列表响应可以声明 5 分钟的 TTL，路径上的任何网关都能遵守它。
• W3C Trace Context 传播被记录在案以兼容 OpenTelemetry。由智能体客户端发起的追踪会穿过 MCP 服务器并进入上游系统调用，因此单个 RFQ 工作流会作为一条追踪出现在它触及的每一个系统中。

对于一个为 NetSuite、HubSpot 和一个供应商目录运行 MCP 服务器的 B2B 部署来说，这意味着：网关可以按工具名路由而无需解析请求体，可以按声明的 TTL 缓存目录响应，并可以在一棵 span 树中追踪单次报价请求从智能体到 ERP 再到供应商 API 的全过程。

面向一对多形态的授权加固

候选发布版为 B2B 智能体系统实际采用的部署形态改进了 OAuth 和 OpenID Connect：一个客户端（智能体）连接到多个服务器（NetSuite、HubSpot、BigCommerce、一个供应商目录）。令牌刷新、作用域管理和多服务器凭据处理在规范中得到解决，而不再留给每个集成各自独立解决。

这一点很重要，因为 B2B 智能体系统不会只连接一个系统。一个典型的 RFQ 智能体会连接到一个 ERP（NetSuite）、一个 CRM（HubSpot）、一个电商平台（BigCommerce），以及两三个供应商目录——每个都有自己的 OAuth 流程、令牌生命周期和作用域集合。协议现在提供了一个管理这种复杂度的标准模式，而不再需要每个 MCP 模块实现自己的凭据生命周期。

对现有 MCP 模块有何改变

如果你已经在交付 MCP 模块——例如那个 38 工具的 RFQ 处理器模式，其中工具通过 MCP_CONFIGURATION 注册、领域 mixin 在一个共享的 GraphQL 客户端之上组合——无状态协议改变的是部署，而不是模块代码。

模块的工具注册、输入输出 schema、速率限制和审计日志保持不变。改变的是：

• 启动时不再有会话初始化。 模块不参与 initialize 握手。它接收带有承载协议版本和能力的 _meta 的请求，并做出响应。
• 有状态工具铸造句柄。 如果某个工具今天依赖服务器端会话来跟踪一个多步工作流，它应当铸造一个显式句柄并返回它。客户端在下次调用时把它传回。对于一个 RFQ 处理器，request_id、quote_id 和 hold_id 本就是这些句柄——这一模式对该领域来说是自然而然的。
• 日志转移到 OpenTelemetry。 如果模块通过 MCP 日志通道记录日志，请迁移到 stderr 和 OpenTelemetry span。审计内容（请求、响应、延迟、结果）保持不变；改变的是传输。
• 缓存是声明式的。 列表和资源端点可以在其响应上声明 ttlMs 和 cacheScope，让中间层无需猜测即可缓存。

对 B2B 团队的结论

无状态协议减少了基于 MCP 的智能体部署所需的基础设施。你用请求参数中的显式句柄换掉了粘性会话和共享会话存储——这一交换使系统更易扩展、更易审计，并在标准工具中更具可观测性。

如果你的团队正在为一个基于 MCP 的智能体部署划定范围，7 月 28 日的候选发布版就是应当瞄准的版本。从一开始就为显式句柄而设计，可以避免日后从基于会话的状态迁移过来。

---

一个运行 NetSuite、BigCommerce 和三个供应商目录的分销商，能获得一个这样的智能体：它通过邮件或门户接收 RFQ，对照目录图谱解析产品并做替代，按客户层级定价，带有效期地预留库存，并把已接受的报价写回 NetSuite——每一步都被记录。该构建属于四步法中的第 2-3 阶段，通常在 5-8 周内上线。

申请一次限定范围的构建。 一周的探索。你会得到一份系统清单、工作流地图和固定范围——无论你是否与我们一起构建。