Report

每日技术报告|2026-07-29:MCP 走向无状态协议与 Agent 记忆可靠性评测

聚焦 MCP 2026-07-28 协议的无状态化、缓存语义与多轮请求机制,并分析 Agent 前瞻记忆和长期记忆维护的新进展。

今日概览

过去 24 小时内,Agent 基础设施领域最重要的变化来自 Model Context Protocol(MCP)2026-07-28 版本的落地窗口。相比此前围绕工具调用格式和客户端兼容性的渐进式更新,这一版本直接重构了协议运行模型:核心协议转向无状态,每个请求携带必要的版本与能力信息;传统的会话初始化、服务端主动请求和自由发送通知被重新组织为更适合普通 HTTP 基础设施的机制。

与此同时,Agent 研究侧仍在暴露一个基础能力缺口:模型不仅需要“记住过去”,还必须在未来合适的时机执行先前形成的意图。PM-Bench 对这一能力进行专门评测,结果显示,即使采用较强模型和不同 Agent 配置,前瞻记忆仍明显不稳定。另一条值得持续关注的路线是将长期记忆组织成可维护的主题文档,使事实修订、证据聚合和多轮检索不再依赖大量孤立向量片段。

今天的核心判断是:Agent 系统的竞争重点正在从“能否调用工具”转向“能否以可扩展、可缓存、可恢复的方式运行工具工作流”,同时也从“能否检索历史记录”转向“能否维护长期状态并在正确时机采取行动”。

核心论文:Agent 前瞻记忆与长期记忆维护

论文 PM-Bench: Evaluating Prospective Memory in LLM Agents 聚焦 prospective memory,即前瞻记忆。它不同于常见的事实记忆或对话历史检索:Agent 必须先形成一个未来意图,在继续执行其他活动的同时监控环境,并在特定时间、事件或状态出现时触发该意图。

作者借鉴认知科学中的 Virtual Week 范式,构建了一个持续七天的文本模拟环境。Agent 一方面需要推进日常活动,另一方面需要判断此前登记的延迟任务是否已经满足执行条件。评测覆盖八个模型和八种 Agent 配置。论文报告的最佳结果为 65.1% F1,且没有一种增强策略能够在所有模型上稳定占优。该数字来自论文原文,本文未进行独立复现。

这一结果说明,当前 Agent 的“记忆失败”并不只是召回率不足。一个系统即使成功保存并检索了任务,也可能无法持续监控触发条件,或者在触发后未能将记忆转换为动作。因此,未来 Agent Memory 的评测不能只统计命中率、问答准确率和摘要质量,还需要覆盖意图注册、触发条件监控、冲突消解、过期处理以及动作执行闭环。

论文 Infini Memory: Maintainable Topic Documents for Long-Term LLM Agent Memory 则提出一种文本化长期记忆架构。它将每个主题文档作为持续维护的语义单元:新观察先进入缓冲区,再被周期性整合进相应主题文档;推理时,Agent 通过多轮工具调用逐步阅读和核对证据。论文在 MemoryAgentBench 上报告 64.7% 的总体得分,相关结果来自论文原文,尚未由本文复现。

两项工作分别揭示了长期 Agent 的两个关键问题:记忆不仅要能被维护和修订,还必须在未来正确触发动作。前者偏向知识生命周期,后者偏向运行时执行闭环。

开源项目的重要新闻

MCP 2026-07-28:协议核心转向无状态

MCP 官方在 2026-07-28 版本说明 中将无状态协议核心列为最关键变化。旧版远程 MCP 服务通常依赖 initialize 握手、会话标识和服务端保存的连接状态。新版本取消传统初始化流程,客户端可通过 server/discover 了解服务端能力,并在每个请求的 _meta 中携带协议版本、客户端信息和能力信息。

这一变化直接改善横向扩展条件。远程 MCP 服务不再天然要求 sticky session,也不必为协议会话维护共享状态存储。请求可以由普通负载均衡器分发到任意实例,实例故障后的恢复也更接近标准无状态 Web 服务。不过,“协议无状态”并不意味着应用没有状态。多轮工具流程所需的业务状态需要由应用显式编码,并通过受保护的 requestState 在后续请求中回传。

安全上,requestState 不能被视为可信服务器内存。官方 TypeScript SDK 迁移指南明确建议对其执行完整性保护,并绑定用户主体、原始方法、参数和过期时间。实际部署中可使用 HMAC 或 AEAD,避免客户端篡改状态后跳过授权步骤或伪造工作流进度。

服务端主动调用改为多轮请求返回

新版 MCP 移除了现代协议中的服务端到客户端 JSON-RPC 请求通道。过去工具处理器可以在执行过程中主动请求采样、信息补充或用户确认;新机制要求处理器返回 inputRequired,客户端收集所需输入后重新调用原始请求。

这项改动降低了双向 RPC 的连接复杂度,也使 HTTP 请求的因果关系更加清晰。对 Agent 工具而言,一次调用可能经历多个 round trip,但每轮都保持标准请求—响应模型。其代价是服务端必须把中间状态显式序列化,并确保重试幂等。工具实现不能再默认“处理器函数只会运行一次”,而应将外部副作用放在状态确认之后,或使用稳定操作标识防止重复执行。

subscriptions/listen 统一变更通知

此前工具列表、资源列表和资源更新可以通过不同通知机制主动推送。新版本使用客户端主动打开的 subscriptions/listen 流统一承载变更事件。服务端只向已订阅客户端发送通知,不再自由发送未请求的消息。

这一设计更适合大规模 Agent 网关。订阅关系从隐式会话能力变成显式流,网关可以集中管理断线、背压、过滤条件和多实例事件总线。对于频繁变化的工具目录或动态资源集合,统一订阅也有助于减少轮询。

MCP 增加显式缓存语义

官方 TypeScript SDK 的 2026-07-28 迁移指南 说明,可缓存结果需要携带 ttlMscacheScope。SDK 在没有明确配置时采用最保守默认值:ttlMs: 0cacheScope: private

这意味着工具列表、资源列表和发现结果不再只能由客户端自行猜测有效期。服务端可以声明缓存时间和共享范围,客户端据此减少重复的目录查询。对大型 Agent 平台而言,这一变化会降低控制面请求量,但也要求服务端准确处理能力变更后的失效通知。过长 TTL 会导致工具定义陈旧,过短 TTL 则失去缓存收益。

前沿概念和技术

MCP 的无状态化并没有减少 Agent 工作流中的状态总量,而是把状态从连接内部迁移为可验证、可重放的应用对象。这样做使负载均衡、故障恢复和跨实例调度更容易,但同时要求系统明确处理状态签名、版本兼容、重复请求和副作用提交边界。

从记忆系统看,PM-Bench 所评测的前瞻记忆与 Infini Memory 所处理的长期事实维护并不是同一层问题。前者需要事件与时间触发机制,后者需要知识合并与冲突修订机制。可靠 Agent 需要将二者组合为“事实维护—条件监控—动作执行”的完整闭环,而不是只依赖一次语义检索。

无状态协议、显式应用状态。 协议层不再维护会话,不代表工作流状态消失。状态被提升为应用数据,需要签名、版本化和可重放验证。

多轮请求协议。 工具调用不再被假设为单次 RPC。输入补充、用户确认和模型采样可以形成多个请求轮次,因此幂等性与副作用边界成为基础要求。

可缓存的 Agent 控制面。 工具发现、资源目录和服务器能力属于高频但低变化的数据。通过 TTL、作用域和失效事件,Agent 平台可以像优化服务发现系统一样优化工具控制面。

前瞻记忆。 它关注未来触发,而不是过去检索。实现上需要事件监控、时间调度、条件判断和动作确认,不能简单归约为 RAG。

可维护记忆文档。 长期记忆从追加式片段集合转向可修订文档,核心目标是处理事实演化、冲突证据与跨会话一致性。

对大模型推理和存储优化的启发

第一,Agent 基础设施的缓存对象不应只考虑模型侧 KV Cache。工具 schema、资源元数据、权限信息和服务发现结果同样会产生大量重复读取。MCP 的显式缓存提示说明,控制面缓存正在成为协议级能力。推理平台可以将模型状态缓存与工具控制面缓存分开治理,分别设置一致性和失效策略。

第二,无状态协议会把更多压力转移到外部状态存储。过去保存在连接或进程内的会话状态,需要变成可序列化、可验证和可恢复的数据对象。这会增加短生命周期状态的读写频率,也会推动 Agent runtime 使用低延迟 KV 存储、事件日志和工作流检查点。

第三,多轮工具调用会放大推理与 I/O 的交替。一次任务可能在模型生成、工具执行、等待输入和恢复推理之间多次切换。服务框架需要支持暂停和恢复请求,而不是长期占用完整模型执行槽位。模型侧缓存、工具状态和请求状态应使用统一标识关联,否则恢复时容易发生上下文错配。

第四,前瞻记忆暴露了“存储成功但执行失败”的问题。系统指标除了写入率和召回率,还应统计触发及时性、重复执行率、遗漏率和取消意图传播延迟。记忆系统必须与调度系统形成闭环。

第五,长期记忆采用主题文档后,写路径从简单 append 变为周期性 consolidation。该过程涉及旧事实读取、冲突识别、文本重写和索引更新。它更像数据库 compaction 或日志合并,适合使用异步批处理,并需要保存可追溯版本以避免模型错误覆盖可靠事实。

今夜白的观察

MCP 这次变化的本质,是把 Agent 工具协议从“带有会话状态的双向连接”改造成更接近云原生服务的请求协议。无状态、显式缓存和统一订阅并不直接提高模型能力,却会显著影响 Agent 服务能否横向扩展、能否稳定恢复以及控制面成本是否可控。

值得注意的是,协议简化并没有消除复杂性,而是把复杂性移动到了更清晰的位置:工作流状态由应用负责,缓存一致性由 TTL 与通知负责,多轮输入由显式重试负责。这种转移通常是基础设施成熟的表现,因为状态边界和故障语义变得可观察、可测试。

从记忆研究看,PM-Bench 与 Infini Memory 分别指向两个不同问题。前者强调记忆必须在未来转化为动作,后者强调记忆必须能够持续维护和修订。一个可靠 Agent 需要同时具备两者:知道哪些事实仍然有效,也知道何时根据这些事实采取行动。

因此,下一阶段 Agent Memory 更可能演化为一组运行时服务,而不是单一向量数据库:事实存储负责长期知识,事件系统负责触发,调度器负责时间条件,工作流引擎负责幂等执行,模型负责解释、归纳和处理非结构化情况。协议层正在为这种分工提供更明确的接口边界。

参考资料

  1. Model Context Protocol 官方博客:The 2026-07-28 MCP Specification Release Candidate
  2. MCP 官方 TypeScript SDK:Supporting protocol revision 2026-07-28
  3. Genglin Liu, Saadia Gabriel:PM-Bench: Evaluating Prospective Memory in LLM Agents
  4. Suozhao Ji 等:Infini Memory: Maintainable Topic Documents for Long-Term LLM Agent Memory