2026-07-28 规范中到底改变了什么
协议层不再保留会话
initialize/initialized 交互已被弃用。服务器可以有选择地实现一个新的 server/discover RPC 来进行能力发现，但这不是必需的。请求路径中没有任何内容假定之前进行过握手，线路上也没有任何内容将一个请求与上一个请求联系起来。
规范直接说明了这意味着什么，以及不意味着什么："放弃协议级别的会话并不会强制您的应用程序成为无状态的。如果您的服务器需要跨调用携带状态，请从工具中生成一个显式句柄（handle），并让模型将其作为参数传回。"
请仔细阅读这段话。协议已将状态交还给您，并告诉了您实现机制：一个由模型传递、由您的应用程序理解的显式句柄。句柄就是一个指针。而指针所指向的内容，正是您仍然需要构建的部分。
围绕无状态性新增了什么
这次发布不仅仅是做减法：
- 多轮往返请求 (MRTR) 允许服务器在执行过程中向客户端发起请求，而无需持久连接。
- 基于请求头的路由 通过
Mcp-Method和Mcp-Name允许网关在不解析 JSON 主体的情况下进行过滤和路由。 - 可缓存的列表结果 在列表和读取响应中添加了
ttlMs和cacheScope，因此客户端可以在服务器允许的时间内缓存tools/list。 - Tasks 从实验性核心升级为正式扩展（由 AWS 贡献），用于通过基于轮询的操作处理可靠的长期运行工作。
- MCP Apps 加入了相同的正式扩展框架。
- 现在适用至少十二个月的弃用窗口，并且 Roots、Sampling、Logging 和 Dynamic Client Registration 已进入弃用阶段。
- Tier 1 SDK（TypeScript、Python、Go 和 C#）已发布更新；Rust SDK 处于 Beta 阶段。
Claude 中已上线该功能
Anthropic 在同一天在 Claude 应用、Claude 平台和 API 以及 Claude Code 中发布了对新规范的支持，同时还推出了用于对话中交互式 UI 的 MCP Apps、与 OAuth 2.0/OIDC 对齐的企业托管身份验证（适用于 Entra 和 Okta 等身份提供商）、已发布连接器的可观测性仪表板，以及研究预览版中的 MCP 隧道。Claude 的连接器目录现在列出了超过 950 个 MCP 服务器。
换句话说，这不是一个您可以静观其变的规范。如果您的 Agent 与 Claude Code 或连接器进行通信，无状态核心已经是它立足的基础。
为什么无状态既不会导致也不会治愈您的 Agent 健忘症
会话从来都不是记忆
MCP 会话的持续时间和连接一样长：几分钟，有时甚至几秒钟。而您的 Agent 的健忘症则运行在完全不同的时间尺度上——明天早上、下一个 Sprint，或者同事第三次询问同一个客户时。即使在以前的有状态世界中，关闭客户端也会丢弃会话所知道的一切。
会话状态是传输层的簿记工作。记忆则是您工作的累积结论。将两者混为一谈，正是为什么许多团队一直期望从一个从未做出过承诺的层中获得持久性。
真正受影响的内容
真正依赖会话状态的模式比恐慌所暗示的要窄得多：在内存中累积工具调用之间中间状态的服务器、以会话 ID 为键的握手衍生缓存，以及需要粘性会话以将客户端固定在单个工作节点上的网关。这些需要重新设计——而好处是，远程服务器现在可以放在普通的轮询负载均衡器后面。
没有受影响的内容：任何已经将持久状态存储在连接之外的系统。如果您的知识存在于数据库、文件存储或记忆服务中，7月28日的变化对您的召回没有任何影响，反而使您的部署变得更加简单。
记忆现在必须存放在哪里
规范给出的答案——生成一个句柄，让模型将其传回——是正确但不完整的。它告诉了您如何引用状态，但没有告诉您状态应该存放在哪里、应该采取什么形式，或者运行在三个不同模型上的五个不同 Agent 应该如何共享它。这就是您现在拥有的层，值得您深思熟虑地去构建，而不是随性而为。
团队采用的折中方案
更大的上下文窗口
前沿模型现在宣传以百万 Token 计的上下文窗口，人们很容易将其视为记忆。但事实并非如此。上下文窗口是模型在这一轮中可以读取的内容；您仍然必须决定在其中放入什么，每轮为这些 Token 付费，并在下一次开始时清空。请参阅为什么 RAG 不是记忆以了解适用于检索的相同区别。
每个工具的内置记忆
Claude、ChatGPT 和大多数 Agent 框架现在都附带了自己的记忆功能。每一个都确实有用，但也确实是孤立的。您的编码 Agent 了解到的关于部署流水线的信息无法传递给起草事件报告的助手，而且当您将任务路由到更便宜的模型时，这些信息都不会跟随您。
句柄加上您自己构建的数据库
这是规范所指引的道路，对某些团队来说，这是正确的选择。但这也意味着需要编写提取、存储、检索排序、范围界定、过期和多 Agent 访问控制——并在周围协议不断演进的同时维护它们。如果记忆是您的产品，这很值得。如果记忆只是通往您产品道路上的管道工程，这代价就太高了。
解决方案：为您的 Agent 提供一个超越任何会话的记忆层
规范建议的持久化版本是将记忆放在一个任何会话、重启或模型切换都无法带走的服务器中。MemoryLake 正是为此而构建的：一个您的 Agent 可以通过 MCP 或 API 进行读写的记忆层，独立于当前连接的客户端。
步骤 1：创建 API 密钥
在大约 30 秒内生成密钥并发出您的第一个请求。此步骤中的任何内容都不依赖于会话——这正是关键所在。
步骤 2：上传您的第一批记忆
放入您的 Agent 持续需要的文档、图像和文件：架构说明、运行手册、客户上下文、先前的决策。这就是句柄应该指向的状态。
步骤 3：连接您的 AI 和 Agent
让 Claude、Codex、OpenClaw 和您的其他 Agent 通过 MCP 或 API 访问该记忆。在 2026-07-28 核心规范下，每次调用都携带自己的身份并访问相同的记忆——无需粘性路由，无需保持会话活跃。有关特定客户端的演练，请参阅如何为 Claude Code 添加记忆；如果您是编写服务器的人，无状态 MCP 服务器的记忆涵盖了实现者的一侧，而MCP Tasks 的记忆涵盖了长期运行的工作。
这在实践中改变了什么
算一算重复解释的账。假设您的常驻上下文——技术栈、约定、当前优先级、已做出的决策——是 2,000 个 Token，而您或您的 Agent 每天重新发送 20 次。那就是每天 40,000 个 Token，每月大约 120 万个 Token，都花在重复您已经说过的话上。Token 账单只是小部分；您真正感受到的成本是每次会话开始时 4 到 5 分钟的重新简报，以及在没人费心解释时 Agent 犯的错误。
持久的记忆层将这种每次会话的“税收”转变为一次性写入。它还使多 Agent 工作变得连贯：当两个 Agent 共享记忆而不是对话记录时，第二个 Agent 会从第一个 Agent 的结论开始。这个问题值得在多 Agent 记忆中单独阅读。
无状态 MCP 世界中记忆的最佳实践
存储结论，而不是对话记录
原始日志会无限制地增长，且检索效果很差。"我们选择 Postgres 而不是 Redis 来存储聊天记录，因为队列模式破坏了进程内内存" 这句话值得保留。而导致这一结论的 40 条消息则不值得。
将记忆与工作绑定，而不是与连接绑定
会话已经不复存在；不要意外地重建它们。将记忆的范围限定在项目、仓库、客户或任务上——这些内容在下个月仍然具有相同的含义，无论哪个客户端在进行调用。
有意识地进行修剪和版本控制
陈旧的记忆比没有记忆更糟糕，因为 Agent 会信任它。给事实指定所有者和有效期，并记录一个决策何时取代了先前的决策，而不是将两者都留在池中。
结论
MCP 在 2026 年 7 月 28 日进入无状态时代，并没有删除您的 Agent 的记忆。它只是结束了协议正在保存记忆的幻觉。会话是传输，而不是召回，规范现在也明确指出了这一点，同时将机制（显式句柄）交给了您，而将实质内容留给了您。
那些将这一变化视为升级的团队，是那些记忆已经存在于连接之外的团队：更简单的部署、相同的召回，以及能够接续上一个 Agent 进度的 Agent。而那些将其视为损失的团队，则是那些指望会话来帮他们记忆的团队。构建一次这个层，比永远支付重复解释的税要便宜得多。