有状态工具：协议删会话，工具藏状态

2026 年的「工具使用」正在发生一次静悄悄却影响深远的状态归属迁移：一边是 MCP 2026-07-28 版本候选规格（5 月 21 日锁定）把协议级会话彻底删除、走向无状态核心；另一边，工具本身却越来越「有状态」——Cloudflare 用 Durable Objects 给每个 MCP 服务挂上持久 SQLite，OpenAI Responses API 通过 previous_response_id 把会话态外包给平台，学术界则用 DialogTool 专门评测多轮有状态工具交互。结论很反直觉：状态正在同时离开上下文窗口、离开协议会话，沉淀进工具自己的耐久存储。这重构了 Agent 循环的 token 经济学、安全边界与评测口径，本期实测六栈。

状态归属对比表

深度分析

一、状态归属三选一：上下文 / 协议 / 服务端

工具调用的「状态」无非三类东西：游标（分页 cursor）、累计态（购物车、草稿、计数器）、凭证态（OAuth token、临时签名）。问题是它们到底该放哪。放上下文窗口，意味着每一轮都要把整份状态重新喂给模型——一个 10 件的购物车约 300 token，跑 20 轮就是 6000 token 纯用来「回声」状态，模型还容易在复制中抄错。放协议会话，状态在 initialize 握手后留在 server 端，上下文只持一个 session_id，干净但有锁定税。最干净的是第三种：状态焊进工具自己的耐久存储，上下文只持一个 opaque 句柄（cursor、resource URI、cart_id）。这也是 2026 年的主旋律——状态「下沉」到离数据最近的地方。

二、MCP 删会话 ≠ 工具无状态：被误读的 2026-07-28 RC

2026-07-28 RC 是 MCP 自发布以来最大一次修订，最抓眼球的是「删除协议级 session」。很多人据此推断「MCP 全面无状态化、工具不能记东西」，这是致命误读。规格删除的是 协议层 的会话语义（initialize 握手、session_id 维护），目的是让远程 MCP 变成纯无状态的 streamable HTTP，便于水平扩展和边缘部署。但工具本身完全可以有状态——只不过这份状态不再由协议替你托管，而要由工具服务器用自己的存储（Durable Object、Redis、数据库）来管。换句话说：协议卸下了「状态托管」的包袱，把它还给了应用层。旧式依赖 session_id 的服务端必须迁移：要么把状态外化到存储里用 opaque key 寻址，要么接受无状态重启。

三、Cloudflare Durable Objects：把状态焊进工具运行时

Cloudflare 的打法最彻底：每个 Agent/MCP 服务就是一个 Durable Object，自带一份持久 SQLite。状态不再需要外部数据库，也不再需要协议会话——它就在工具进程里。其官方示例就是一个由 Durable Object 支撑的「有状态 MCP 服务」，状态跨请求持久：

import { McpAgent } from "agents/mcp";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

export class CartMCP extends McpAgent {
  server = new McpServer({ name: "cart", version: "1.0.0" });
  async init() {
    this.server.tool("add_to_cart",
      { sku: z.string(), qty: z.number() },
      async ({ sku, qty }) => {
        const cart = (await this.ctx.storage.get<Record<string,number>>("cart")) ?? {};
        cart[sku] = (cart[sku] ?? 0) + qty;
        await this.ctx.storage.put("cart", cart);   // 耐久落盘，跨请求/跨重启存活
        return { content: [{ type: "text", text: JSON.stringify(cart) }] };
      });
  }
}

注意 this.ctx.storage——这就是「工具吞下状态」的物理实现。模型调用 add_to_cart 时，上下文里不需要带着整辆购物车，工具自己记得。代价是：状态和工具生命周期强绑定，迁移成本高（见第七节）。

四、Responses API：previous_response_id 把状态外包给平台

OpenAI 走的是另一条路：状态外包给平台。Responses API 用 previous_response_id 把整段会话（含已发生的工具调用、工具返回、中间推理）留在 OpenAI 服务端，下一轮只传一个 ID。叠加内置的 mcp 工具类型，远程有状态工具的 OAuth 与 server 端会话也可由平台协调：

resp = client.responses.create(
    model="gpt-5",
    input="把 SKU-7 再加两件",
    tools=[{"type": "mcp", "server_label": "cart",
            "server_url": "https://cart.example.com/mcp",
            "require_approval": "never"}],
    store=True,
    previous_response_id=prev_id,   # 服务端持有会话态 + 工具调用历史
)
prev_id = resp.id

这是最省心智的形态——开发者几乎不用管状态。但它是最强的供应商锁定：状态黑箱化在平台内，跨厂商迁移意味着整段会话历史不可携带，审计、回放、合规都得依赖平台 API。store=True 还意味着敏感数据进了厂商存储，合规团队要单独评估。

五、DialogTool：现有基准对有状态工具的集体盲区

学界已经意识到这个评测缺口。ACL 2025 Findings 的《Rethinking Stateful Tool Use in Multi-Turn Dialogues》（arXiv:2505.13328）直指：绝大多数工具使用基准评测的是无状态、单轮调用，模型调一次工具、拿到结果、回答，结束。但真实世界是多轮的：工具状态会在轮次间变化，用户会回头修改，模型必须基于「当前真实状态」而非「历史快照」决策。该工作提出 DialogTool，把整段对话历史与工具状态联合建模。这解释了为什么 BFCL 上成绩漂亮的模型，到了 τ-bench 多轮零售/航空场景会「塌方」——单轮能调对工具 ≠ 能在状态持续演化的多轮里调对。选型时务必看多轮有状态基准，而不是单轮准确率。

六、有状态工具的安全账：服务端态即攻击面

状态一旦下沉到工具服务器，那份耐久状态本身就成了攻击面与信任边界，这恰恰是被严重低估的一环。三类典型风险：其一，状态投毒——攻击者通过一次 add_to_cart 注入恶意结构（超长字段、嵌套对象），若工具未做 schema 校验就持久化，后续每一轮都带着毒数据跑。其二，跨会话污染——若 cart_id 或 resource URI 可枚举/可预测，A 用户的状态会被 B 用户读到，等于把鉴权从「调用时」推迟到「状态寻址时」。其三，OAuth token 滞留——远程有状态 MCP 把刷新令牌缓存在服务端以省去每轮授权，一旦该服务被攻破或下线，令牌不会自动失效。把状态放进服务端不是免责声明，而是新增了一份「耐久态的存储安全 + 访问控制 + 生命周期治理」债务。

七、实测：状态归属的三轴权衡（token / 延迟 / 恢复）

把六种形态放在三条轴上权衡，结论相当清晰。token 轴：上下文窗口态最贵（线性膨胀），服务端态最省（上下文只持句柄），代价是工具自付存储成本。延迟轴：上下文态首轮快但随轮次劣化（窗口越长推理越慢）；服务端态每轮接近恒定，但多一次存储往返。恢复轴最反直觉：上下文态崩溃即全丢；协议会话态断连需重新握手；服务端耐久态反而最健壮——Durable Object 重启后 SQLite 自动恢复，跨进程、跨重启存活。也就是说，「有状态工具」在工程鲁棒性上完胜手搓上下文回灌，真正要付的代价是迁移与锁定（见第四节）和安全债务（见第六节）。

八、变现与训练营评估：护城河还是负债

从商业视角，有状态工具是一把双刃剑。B2B 交付场景下它是护城河：客户的状态（购物车、合同草稿、工单上下文）沉淀在你的服务端耐久存储里，迁移成本极高，天然形成黏性；这也是 Cloudflare Agents 把 Durable Objects 当卖点的原因——锁定的是运行时与数据。但通用 Agent 框架/训练营场景下它是负债：一旦教学生「状态外包给平台」，就等于把他们绑死在某个 Responses API 或某家 DO 厂商上，迁移时整段会话历史不可携带。训练营正确教法应是：先讲透三种归属的权衡与迁移成本，再让学生用「opaque 句柄 + 自有存储」实现一次可移植的有状态工具——这才是真正值钱、不绑定单一厂商的能力。

状态归属迁移架构图

flowchart LR
  subgraph GEN1[第一代：状态在上下文窗口]
    A1[Agent Loop] -->|每轮把 cursor/cart/token 塞回| A2[Context Window 线性膨胀]
  end
  subgraph GEN2[第二代：状态在协议会话]
    B1[Agent] -->|initialize 握手拿 session_id| B2[MCP 会话态]
    B2 -. 2026-07-28 RC 删除 .-> BX[❌ 协议会话移除]
  end
  subgraph GEN3[第三代：状态在工具服务器耐久态]
    C1[Agent Loop 瘦身] -->|opaque cursor / resource URI / cart_id| C2[Durable Object / 平台存储]
    C2 --> C3[(SQLite / KV 持久化)]
  end
  GEN1 ==> GEN2 ==> GEN3
  BX ==> C2

推荐方案

• 高频长会话 + 数据敏感（电商、CRM）：首选服务端耐久态（Durable Object / 自建存储），上下文只持 opaque 句柄。token 最省、崩溃可恢复，但必须自担安全债务。
• 快速原型 / 单一厂商生态：Responses API + previous_response_id + 内置 MCP，心智成本最低，但要清醒接受最强锁定，会话历史不可携带。
• 多厂商、要可移植：坚持「工具自有存储 + opaque 句柄」，拒绝把状态外包给任一平台；用 DialogTool/τ-bench 这类多轮有状态基准选模型。
• 迁移已上线的旧 MCP 服务：趁 2026-07-28 RC 把会话外化到存储、用 opaque key 寻址，这是被迫也是最好的一次重构窗口。
• 安全红线：任何落盘状态都要过 schema 校验、状态键不可枚举、OAuth 令牌要设短 TTL + 可吊销，把「耐久态治理」纳入运维，而不是写进免责声明。

参考来源

1. Cloudflare Agents · Build and deploy AI Agents — 官方仓库，明确「persistent, stateful execution environments」并由 Durable Object + 持久 SQLite 支撑，含 stateful MCP 示例。
2. The 2026-07-28 MCP Specification Release Candidate — MCP 官方博客，确认这是发布以来最大修订，删除协议级会话、走向无状态核心。
3. Rethinking Stateful Tool Use in Multi-Turn Dialogues (arXiv:2505.13328) — ACL 2025 Findings 论文，指出多数基准只评无状态单轮调用，提出 DialogTool 评测多轮有状态交互。
4. OpenAI Responses API · Migrate to the Responses API — previous_response_id 服务端会话态、内置 mcp 工具类型与 OAuth 远程工具支持。
5. BFCL V3 · Multi-Turn & Multi-Step Function Calling — Berkeley 函数调用榜单 V3 引入多轮/多步评测，佐证单轮高分 ≠ 多轮有状态可靠。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。