MCP 已转向无状态，但你的 AI 应用仍需要一份状态所有权契约

Model Context Protocol（MCP）在 2026 年 7 月 28 日发布了迄今规模最大的一次修订。新协议默认采用无状态核心：强制性的初始化握手和协议会话退出核心流程；每个请求都携带解释自身所需的信息；客户端可以显式发现服务端能力；长时间运行或需要多步交互的工作，则交给 Tasks、Multi Round-Trip Requests 等明确机制处理。

这看起来像基础设施新闻，实际上会直接改变 AI 产品的状态设计。“MCP 无状态”并不等于研究智能体可以忘记任务、引导助手可以丢掉审批，或客服工作流在重试时可以再次退款。它只是不再把这些责任藏在一条连接里。团队必须明确：哪些持久事实属于产品，谁能读取和修改，任务中断后怎样恢复，以及拿什么证据证明同一个业务动作没有执行两次。

本文面向使用连接器、无代码构建器、托管智能体或自定义 MCP 集成的非技术创始人和小团队。你将得到一份通俗的状态地图、一份可复用的状态所有权契约、一个客服退款场景、一张新旧协议并存期矩阵、六项上线测试，以及一份 48 小时行动清单。

核心判断很简单：不要因为连接器成功重连就批准 MCP 2026 迁移。只有当每一项重要状态都有明确所有者、有效期、权限规则、恢复路径和验证收据时，才应该放行。

MCP 2026-07-28 改了什么，又没有改什么

MCP 官方的版本说明列出了无状态核心、显式能力发现、作为扩展的 Tasks、Multi Round-Trip Requests（MRTR，多轮往返请求）、MCP Apps、授权强化、缓存语义和正式弃用机制。最终版本已经进入官方的 2026-07-28 规范，并发布在带签名的规范仓库 release中。

生命周期里最关键的变化，是不再强制执行 initialize / initialized 初始化握手。按照已经接受的 SEP-2575 无状态设计，协议版本、客户端身份信息和客户端能力会随请求发送。客户端也可以调用 server/discover，主动查询服务端支持什么。普通请求不应依赖服务端记住它此前与某个客户端进行过的一段隐形对话。

一些旧行为也随之改变。SSE 响应流断开后不再沿用旧式恢复方式；需要持久化的工作应转入任务机制。原先游离于请求之外的服务端到客户端调用，改由原始客户端请求范围内的 MRTR 承担。部分原本属于核心的功能转为扩展或进入弃用流程。可缓存结果会声明有效期和缓存范围。每次请求的认证与授权也必须独立判断，不能再默认“协议会话建立时已经处理过”。

同样重要的是，以下责任并没有消失：

• 客户、订单、工单、项目和权益记录仍然需要可靠的持久化存储。
• 长时间运行的任务仍然可能等待、恢复、过期或被取消。
• 审批仍然必须绑定到一个具体动作及其参数。
• 如果产品没有阻止重复副作用，重试仍可能造成重复扣款、发信或发布。
• 界面显示陈旧或互相矛盾的状态，仍然会损害用户信任。
• 不同 SDK、供应商和构建平台采用新规范的速度仍可能不同。

无状态优先的是协议，不是你的产品责任。

先把新术语翻译成产品决策

创始人不必先读懂 JSON-RPC schema 才能做出上线判断，但需要把几个词分清。

协议状态，是连接器过去从既有 MCP 会话中推断的信息，例如已经协商好的版本和能力。新版本把这些信息放进单个请求，或通过显式发现获得。 业务状态，是产品必须负责的事实：一张工单是否仍然打开、一笔退款是否只是提案、一个活动是否已获批准、一张发票是否已经支付。它应该存在于权威记录系统中，而不是 MCP 连接里。 任务状态，描述一项工作随时间推进的位置，例如排队中、处理中、等待输入、已完成、失败、已取消或已过期。Task handle（任务句柄）只是找到这项状态的引用，不是状态本身。 交互状态，是在一个请求过程中向用户追问或取得审批所需的短期上下文。已经接受的 MRTR 提案允许服务端在原始调用范围内向客户端请求输入，不再依赖固定路由或某个特定服务实例。 缓存状态，是对能力发现结果、工具列表、资源或其他结果的可复用副本。缓存必须有明确的有效期和适用受众。如果权限已经变化，缓存却仍然有效，昨天正确的答案今天就可能变成越权入口。 幂等性，是指对同一个预期业务动作进行重试，不会再创建第二笔扣款、第二条消息、第二条记录或第二次部署。它是产品保证，不是网络层的细节。

不要把这些内容统称为“智能体记忆”。它们的权限、有效期、存储位置和失败后果并不相同。

创始人的核心规则：状态引用不等于状态所有权

无状态设计遵循一个很有价值的原则：请求最好自包含；无法完全自包含时，就在请求中携带状态引用。产品团队最危险的捷径，是看到 task ID、conversation ID 或 approval ID 后，就以为底层责任已经解决。

一个引用只能回答“去哪里找”，却回答不了：

• 这条记录由谁创建？
• 它属于哪位用户、哪个租户？
• 它允许执行的具体动作和参数是什么？
• 谁能读取、修改、取消或恢复？
• 它在多长时间内有效？
• 权限发生变化后怎么办？
• 重试会不会再次产生副作用？
• 什么证据可以证明工作已经完成？

假设连接器返回 task_84F2。如果产品无法说明是哪项客户请求创建了它、它可以修改哪个账户、何时过期、原审批是否仍有效，以及下游动作到底有没有发生，那么这个句柄只是一串不透明字符。

因此，“我们保存了 task ID”不能作为验收条件。真正的验收条件是：原来的进程、连接、浏览器标签或服务实例消失后，产品仍能还原这项已获授权的工作及其结果。

改动连接器之前，先盘点六类状态

不要一开始就盘点公司所有集成。先选一条真实工作流，而且它要跨过一个有意义的边界，例如发出消息、创建记录、修改客户账户或进行扣款。

对每一行，都要找出它今天真正存在在哪里。很多团队会发现：工作进度在队列里，审批在聊天历史里，身份在 access token 里，而“完成”只存在于智能体生成的回复里。这种碎片化，才是迁移风险。

不要先问构建平台“是否支持 MCP 2026”，而要问它是否提供了足够的产品控制，让团队可以给这些状态分配所有者。如果平台隐藏了协议实现，就向它索取任务持久化、审批绑定、重试、缓存失效、身份、审计导出和旧协议 fallback 的具体行为说明。

填写一份状态所有权契约

这次迁移最值得复用的交付物，是一份状态所有权契约。每一条会产生实际后果的工作流都应该单独填写，不能用一份模糊总表覆盖整个产品。

一份填写完成的契约可以这样写：

产品只能为一个订单提出一次退款。电商平台拥有退款事实。我们的产品保存一条工作记录，并关联用户、租户、订单、金额、原因、审批快照和幂等键。审批 30 分钟后过期；金额或退款去向变化时，旧审批不可复用。断线后，worker 必须先读取电商平台状态，再决定是否重试。只有同时取得服务商退款 ID，并回读确认订单退款金额后，才算完成。

这段话比“兼容无状态 MCP”更有价值，因为它真正定义了产品承诺。

用一个客服智能体场景走完整条链路

设想一个小型 SaaS 团队做了客服助手。它读取工单，查询账单系统，提出退款方案，请运营人员批准，执行退款，最后回复客户。

10:04，智能体收到工单 681：“我被重复扣款了。”它发现两笔扣款，却无法确定客户指的是哪张订单，于是向运营人员追问订单号。运营人员补充订单信息，确认 45 美元的退款提案并批准。连接器发出退款请求。服务商刚接受请求，响应流就断了。

依赖会话的设计可能出现三种失败：

1. 替补 worker 找不回此前的问题和运营人员的回答。
2. UI 无法把审批关联到原始参数，于是再次要求批准。
3. 智能体没有收到成功响应，因此再次发起退款。

明确拥有状态的设计会这样处理：

• 工单 681 和账单记录继续保存在各自的权威系统中。
• 客服工作记录保存当前步骤，以及“缺少订单号”这个输入请求的父任务。
• 运营人员的批准绑定到订单 918、45 美元金额、退款去向、政策版本和有效期。
• 调用电商平台时，使用由获批工作记录派生出的幂等键。
• 恢复流程先用这个幂等键查询服务商，或回读订单状态。
• 只有在独立确认退款后才向客户发送回复；发信动作使用另一枚幂等键。
• UI 显示“正在核对服务商结果”，而不是“失败”或“正在再次退款”。

MRTR 可以组织这段有明确父请求的问答，Task 可以承载需要持久化的长任务。但两者都不能代替防止二次退款所需的产品记录。

有意识地选择普通请求、MRTR 或 Tasks

新规范把旧实现里容易混在一起的几种交互模式拆开了。

如果结果应该很快返回、不需要用户输入，而且中断后可以安全地重新发起，就用普通请求。有短超时的只读查询通常属于这一类。

如果服务端在处理原始请求时需要客户端补充信息，就用 MRTR。例如让用户选择账户、补齐字段、提供 roots，或对一个边界清楚的动作进行审批。MRTR 会让追问继续关联原始请求，从而避免一条回答漂移到另一项工作中。

如果工作必须跨越单个响应继续运行，或断线后仍需查询，就用 Task。官方的 Tasks 扩展文档描述了异步工作：服务端返回任务句柄，客户端可以查询、更新、取消，或继续提供输入。官方材料同时提醒，新 Tasks 生命周期与早期实验版的 wire protocol 并不兼容。

不要因为一项工作“很智能体化”就默认创建 Task。两秒结束的工具调用不需要持久生命周期。不要把 MRTR 当作隐形审批数据库。也不要强迫耗时导入一直占着连接，然后把“能重连”误叫作恢复。

真正的产品问题是：当前请求消失后，哪些内容必须继续存在？ 如果答案包含进度、审批、证据或用户预期，就必须让这些状态可持久化、可寻址。

把发现和缓存视为受权限影响的产品行为

server/discover 把能力发现从初始化握手中独立出来，带来了更大灵活性，也提出了一个产品问题：应用什么时候可以复用已经发现的信息？

TypeScript SDK 的 2026-07-28 迁移说明为可缓存结果规定了显式的 ttlMs 和 cacheScope，没有真实策略时采用保守默认值。换成产品语言，就是四个问题：

• TTL： 这份结果多久以内可以直接复用？
• Scope： 它属于公开信息、某个租户、某位用户，还是单个请求？
• 失效： 什么事件发生后，它必须立即作废？
• 刷新失败： 产品可以暂用旧结果、隐藏功能，还是必须停止？

工具列表本身也可能涉及安全。用户 A 可以看到“导出客户”，用户 B 可能没有权限；一个工作区启用了某项扩展，另一个工作区可能禁用；部署之后 schema 也可能改变。如果产品把租户专属结果放进全局缓存，无状态传输并没有让系统更安全，只会让越权错误扩散得更快。

缓存 key 必须包含所有会改变答案的维度，例如服务端、协议版本、租户、用户或角色、授权 scope、扩展集合和 schema 版本。在有证据支持更长时间之前，先采用较短 TTL。执行动作时仍要实时授权，不能让缓存的能力信息替代权限检查。

每一次有实际后果的请求都要重新检查身份和授权

协议会话被移除，不代表身份消失。消失的是一个实现者可能默认“身份已经处理过”的位置。

SEP-2575 要求每个请求独立完成认证和授权。整个版本还强化了 OAuth 行为，包括 issuer 校验和凭证绑定。换成产品判断就是：连接器凭证有效还不够。当前这位用户、这个租户、这项资源、这个动作和这个时刻，都必须允许请求继续。

每次有实际后果的调用，都要核对：

1. 操作人： 是哪位用户、服务或被委托的智能体发起？
2. 租户： 目标资源和工作记录属于哪个 workspace？
3. 资源： 会影响哪条记录、哪个账户、项目或工具？
4. 动作： 当前操作人可以读取、提案、审批、执行、取消或重试吗？
5. 参数： 权限是否覆盖当前金额、目的地、范围和版本？
6. 新鲜度： 角色、同意、token、政策或资源状态是否在任务开始后变化？

OWASP 的 AI Agent Security Cheat Sheet建议采用最小权限、工具级授权、高影响动作人工审批、审计追踪，并把外部数据视为不可信输入。无论使用哪个协议版本，这些控制都不能省略。

一句好记的规则是：能力发现告诉你“这个功能存在”；授权决定“现在能不能用”。

为新旧协议并存期制定迁移计划

最终规范的日期，并不会让所有客户端、SDK、托管构建平台和连接器在同一天准备就绪。官方 Go SDK v1.7.0 release已经支持 2026-07-28，并说明了旧版协商；TypeScript v2 迁移材料则区分新版、旧版和自动协商模式。其他 SDK 与供应商的时间表可能不同。

不要只显示一个“MCP 已支持”标签，而要维护迁移矩阵：

上线收据里要固定 SDK 的精确版本。“最新版”无法复现。记录是否发生回退、实际使用了哪个协议修订，以及最终可用能力是否变化。

不能只测试最顺利的新—新组合。迁移最容易在接缝处失败：新版客户端遇到旧服务端；旧桌面应用访问只支持新版的 endpoint；或自动回退虽然保住了连接，却悄悄移除了 Tasks 或某个必需扩展，而 UI 仍然让用户操作。

用可见证据运行六项上线测试

使用合成账户和可撤销动作。只截一张重连成功的图，远远不够。

测试 1：下游动作成功后立刻断线

执行一个可逆写入，在下游系统接受动作后、响应返回前中断连接，然后恢复任务。只有产品能够对账已有结果，而且不会再次执行动作，才算通过。

测试 2：审批后更改参数

先批准一项 10 美元动作，再在执行前改变目标或金额。只有旧审批立即失效，并且用户在重新批准前能看到变化后的参数，才算通过。

测试 3：任务中途撤销权限

启动工作后，撤销用户角色或连接器 scope，再恢复任务。只有执行阶段重新检查权限并安全停止，才算通过。缓存里的旧能力列表不能覆盖新权限。

测试 4：跨租户和用户边界

让两个工具和政策不同的 workspace 使用同一个连接器。Task handle、发现结果、缓存、日志和审批记录都不能跨边界。

测试 5：覆盖每一种兼容组合

测试新—新路径、每一种受支持的回退方式，以及明确不支持的组合。UI 与日志必须标明实际协议和能力集合；不支持的功能必须安全关闭。

测试 6：让等待中的工作过期和取消

让一个等待输入的任务超过审批有效期，再尝试回答或恢复。已经过期的权限不能被重新激活。另取消一个任务，并确认延迟 worker 不会在稍后把动作执行完。

每项测试都要保留：输入、实际身份、协议版本、状态迁移、审批快照、幂等键、外部结果、对账回读、UI 结果和最终处置。整套证据就是上线收据。

避免最常见的六种误读

“无状态就是不需要数据库。” 无状态只表示协议请求不应依赖隐藏的连接状态。业务事实和持久工作仍然需要所有者。 “有 Task handle，任务就持久化了。” 只有底层状态能在故障后继续存在、有明确有效期、始终绑定身份和权限，而且能够对账，任务才真正持久。 “用户已经同意让智能体做事。” 审批必须覆盖一个人能理解的具体动作和可见参数。对助手的笼统信任，不等于授权它未来执行任意工具调用。 “自动回退会完整保留产品行为。” 它可能保住连接，却移除 Tasks、扩展或其他预期能力。必须测试回退后实际还剩什么。 “刚发现到的能力就代表可以执行。” 发现描述服务端有哪些功能；授权仍要检查此刻的操作人、租户、资源、动作和参数。 “供应商说成功，工作就结束了。” 模型生成的成功句子不是业务收据。需要通过供应商 ID、写后读验证或权威事件确认下游结果。

明确这套上线门槛适用于哪里

会写入数据、联系他人、花钱、发布内容、修改访问权、移动文件、改变生产系统或等待人工输入的工作流，应使用完整契约。如果工作可能比浏览器会话活得更久，或同一个连接器服务多个租户，也应使用完整版本。

短时、只读、低风险调用可以采用简化契约。身份、scope、超时和失败行为仍然不能省，但未必需要完整的持久任务生命周期。

本文不是 SDK 实现教程、conformance 测试套件，也不能证明所有 MCP 2026 实现已经适合生产。它不会替你选择数据库或队列，不能取代受监管数据的法律审查、凭证处理的安全审查，或供应商专属文档。

如果构建平台没有公开协议版本、任务状态、授权边界、重试行为或日志，不要假装确定。把这些字段标记为“未知”，并把连接器限制在只读或可逆工作，直到供应商提供证据。

用接下来的 48 小时让一条工作流变得可靠

1. 选择一条已经上线或即将上线、会产生实际后果的 MCP 工作流。
2. 用一句话写清用户请求的业务结果。
3. 盘点六类状态，并找出每类状态今天真正的所有者。
4. 填写状态所有权契约，重点处理权限、参数绑定、重试、恢复和完成证明。
5. 询问构建平台或集成供应商：实际使用哪些协议修订和回退模式。
6. 固定精确版本，记录新版、旧版和不支持组合。
7. 为每一个可重复产生副作用的动作加入幂等键。
8. 把能力发现和执行时授权分开。
9. 使用合成数据跑完六项测试，并保存完整证据包。
10. 只有当所有重要状态都能在进程和连接丢失后恢复，而且不会跨越身份、租户或审批边界时，才做小流量 canary。

MCP 的无状态核心可以让连接器更容易扩容和恢复，也会暴露产品此前无意中向一条连接“借用”的状态。把这种暴露当作有价值的信息。现在真正该问的，不再是“连接器有没有保持连接”，而是：“连接消失后，我们还能不能还原、授权、恢复并证明用户原本要求的业务动作？”

参考资料

1. Model Context Protocol，The 2026-07-28 MCP Specification Release Candidate
2. Model Context Protocol，2026-07-28 规范
3. Model Context Protocol，规范仓库 releases
4. Model Context Protocol，SEP-2575：Make MCP Stateless
5. Model Context Protocol，SEP-2322：Multi Round-Trip Requests
6. MCP TypeScript SDK，Supporting protocol revision 2026-07-28
7. MCP Go SDK，Releases
8. MCP C# SDK，Tasks
9. MCP C# SDK，Stateless and stateful mode
10. MCP C# SDK，Multi Round-Trip Requests
11. OWASP，AI Agent Security Cheat Sheet