跨会话智能体记忆的失效合约
摘要
本文引入了失效合约,作为LLM智能体在跨会话中管理缓存恢复建议的协议,以解决服务器端数据漂移问题,并通过驱逐过时条目来提高令牌效率,同时保持高合规率。
arXiv:2609.00243v1 公告类型:新
摘要:缓存API错误恢复建议的LLM智能体可以在后续会话中跳过重新推导,从而减少令牌使用和模型调用次数。服务器端数据漂移会使这些缓存修复变成静默失败,而通常的补救措施是在每个会话重新推导,这会把节省的资源还回去。我们引入了失效合约,这是一个协议层,为每个恢复建议附加版本戳和缓存提示,使客户端能够无需试错即可驱逐过时条目,并保留其余部分。合约将实际节省分解为两个独立因素:有效性(失效事件后缓存建议中保持正确的比例)和合规率(规划器首次尝试应用的比例)。有效性仅取决于协议,且与供应商无关。合规率取决于规划器模型:相同的网络字节在Claude Haiku 4.5上实现100%的首次尝试合规率,而在Claude Sonnet 5上仅为11%或更低,后者表现出输入模式保守主义,拒绝添加原始请求中未包含的字段的修复。我们评估了七个模型、三个服务路径、两个领域和约9,400个会话。行级失效将七个模型的合规率提高了0到66.7个百分点,其中三个模型提高了55.6到66.7个百分点,并在其中四个模型上恢复了29-33%的基线令牌成本,而表级失效破坏了共存条目,导致五个模型在失效后首次尝试率降至0%。在行粒度上,驱逐精度在每个模型上均为1.00(如第4.1节的行级预言机所示)。合约为响应负载增加了15%。版本戳有效性在构造上是确定性的,在所有模型和服务路径上产生相同的结果,在整个评估中合约失败为零。
查看缓存全文
缓存时间: 2026/09/02 05:59
# 跨场景智能体记忆的失效合约 来源:https://arxiv.org/html/2609.00243 会议:; ; Michael Wu 注:两位作者对本工作贡献相等。 单位:南达科他州立大学,布鲁金斯,美国 邮箱:[[email protected]](mailto:[email protected]) Arquimedes Canedo 单位:西门子数字工业软件,普林斯顿,美国 邮箱:[[email protected]](mailto:[email protected]) © , ###### 摘要。缓存API错误恢复建议的LLM智能体可以在后续场景中跳过重新推导过程,对已学习的约束条件减少令牌消耗和模型调用次数。服务端的数据漂移会使这些缓存的修复方案悄然失效,而通常的补救措施——在每个场景重新推导——又会将节省的成本返还。我们引入*失效合约*协议层,该协议为每个恢复建议附加版本戳记和可缓存性提示,使客户端无需反复试错即可淘汰过时条目,同时保留有效的条目。合约将实现的节约分解为两个独立因素:*有效性*(数据漂移事件后仍正确的缓存建议比例)和*遵循率*(规划器首次尝试即应用的建议比例)。有效性仅取决于协议实现,与供应商无关。遵循率取决于规划器模型:相同的字节流在Claude Haiku 4.5上达到100%的首次遵循率,而在Claude Sonnet 5上仅为11%或更低,后者表现出*输入模式保守性*——拒绝添加原始请求中不存在字段的修复方案。我们针对七个模型、三种服务路径、两个领域和约9,400个场景进行评估。行级失效机制使七个模型的遵循率提升0至66.7个百分点,其中三个模型提升55.6至66.7个百分点,并在七个模型中的四个模型上恢复了29–33%的基线令牌成本;而表级失效机制会破坏共位条目,使五个模型在数据漂移后的首次尝试率降至0%。在§4.1(https://arxiv.org/html/2609.00243#S4.SS1)的行级预言机下,所有模型在行粒度上的淘汰精度均为1.00。合约使响应载荷增加15%。版本戳记有效性在设计上是确定性的,在所有模型和服务路径上产生完全相同的结果,整个评估过程中合约失败次数为零。 ###### 关键词:LLM智能体,跨场景记忆,缓存失效,API协议,数据漂移,恢复建议 ## 1. 引言 重复调用API的LLM智能体倾向于记住成功经验并在后续场景中重用(Shinn等,2023 (https://arxiv.org/html/2609.00243#bib.bib30);Wang等,2023 (https://arxiv.org/html/2609.00243#bib.bib34))。当服务端参考数据保持不变时,这能节省令牌消耗。当数据发生变化时,缓存的修复方案就会失效。朴素的记忆机制(无失效的缓存)相比完全无记忆能节省5–28%的令牌,但表级失效机制会破坏所有与发生漂移的表共享表的约束类别的收益:七个模型中五个在漂移后的首次尝试率降至0%。1 所有初始数据均追溯至表3(https://arxiv.org/html/2609.00243#S5.T3)和表6(https://arxiv.org/html/2609.00243#S5.T6)中漂移流的A1和A2组。不精确的失效机制实际上是有害的。问题的根源具有结构性。当前的恢复建议(Canedo和Grama,2026 (https://arxiv.org/html/2609.00243#bib.bib4))不携带任何有效性元数据。缓存建议的智能体没有信号来判断建议何时过期,只能通过重放错误并观察修复失败来发现过时情况。HTTP数据响应数十年前就通过Cache-Control、ETag和条件请求(Fielding等,2014 (https://arxiv.org/html/2609.00243#bib.bib10))解决了这个问题。IETF传统已标准化API错误的诊断信封(Nottingham和Wilde,2016 (https://arxiv.org/html/2609.00243#bib.bib23);Nottingham和Wilde,2023 (https://arxiv.org/html/2609.00243#bib.bib24)),但留空了恢复层。没有协议告诉智能体该缓存什么、缓存多久,或者何时重新验证。图1(https://arxiv.org/html/2609.00243#S1.F1)展示了架构。LLM智能体跨场景重复调用API服务器。场景之间,智能体可以缓存先前失败产生的恢复建议,并作为记忆块注入下一个请求。服务器可能随时更新其参考数据(数据漂移)。失效合约是服务器附加在每个响应上的字段集,使客户端能够决定保留和淘汰什么。 LLM智能体 → 规划器(LLM)→ 记忆存储 → 淘汰策略 → 修复提取 ↑ 请求 ↓ 响应 + 失效合约 ↓ API服务器 → 参考表 → 表注册表 → 业务逻辑 → 反馈生成器 (数据漂移通过重载端点进入服务器) 图1. 系统概览。在客户端(左侧),规划器使用缓存的修复方案生成下一个请求;响应返回给修复提取器,淘汰策略管理记忆存储,存储再为规划器提供输入。在服务器(右侧),参考表输入版本化注册表,注册表输入业务逻辑策略,策略输入反馈生成器。反馈生成器在每个响应上附加失效元数据。数据漂移通过重载端点进入服务器。 本文介绍*失效合约*协议层,该协议为恢复建议附加缓存控制语义。每个建议上的两个字段(可缓存性提示和版本戳记)加上架构重载时的结构化差异,为智能体提供了足够的信息以无需反复试错即可淘汰过时知识。我们实现了六个协议级别,从基本的版本戳记到行级差异再到依赖向量比较,并在七个模型、三种服务路径、两个领域和约9,400个场景上对每个级别进行测量。该合约将实现的节约分解为两个因素: 节约等式 (1) 实现的节约 = 有效性 × 遵循率(m, p, a) 其中 m = 模型,p = 协议,a = 操作类型 *有效性*是数据漂移事件后仍正确的缓存建议比例。合约完全控制有效性。我们在测试的所有七个模型和三种服务路径上,有效性完全相同,在约9,400个场景中合约失败次数为零。*遵循率*是智能体首次尝试即实际应用的有效建议比例。它取决于LLM模型(m)、协议级别(p,我们的0-6级)和操作类型(a,修复是改写现有字段还是添加新字段)。遵循率随模型变化但可设计。添加行级失效机制使七个模型的遵循率提升0至66.7个百分点,其中三个模型提升55.6至66.7个百分点,且无需更改模型。2 表3(https://arxiv.org/html/2609.00243#S5.T3)中A2D相对于A1的数据:Claude Haiku 4.5(+55.6百分点)、Claude Sonnet 4.6(+63.0百分点)、GPT-5-mini(+66.7百分点);gemini-3.5-flash(+48.2百分点)、Claude Sonnet 5(+11.1百分点),以及gpt-5.4-mini和deepseek-v4-flash(0.0百分点),后两者在A1时已分别达到遵循率的上限和下限。 我们的贡献包括: 1. (1) *失效合约*协议,包含从版本戳记到依赖向量的六个测量级别(§3 (https://arxiv.org/html/2609.00243#S3))。 2. (2) 跨七个模型、三种服务路径、两个领域和约9,400个场景的实证证据,显示有效性是协议属性,遵循率是模型属性(§5 (https://arxiv.org/html/2609.00243#S5))。 3. (3) 将API提供商控制的项(有效性)与模型供应商控制的项(遵循率)分离的节约分解,为API提供商提供了具体的工程目标(§5 (https://arxiv.org/html/2609.00243#S5))。 4. (4) 急切式与懒惰式规则漂移检测的成本对比表,两列数据在同一数据流上测量(表5 (https://arxiv.org/html/2609.00243#S5.T5),§6.3 (https://arxiv.org/html/2609.00243#S6.SS3))。 5. (5) 输入模式保守性:观察到即使明确告知要添加哪个字段,模型也可能拒绝添加其输入模式中未包含的字段,这界定了任何协议能实现的效果,且不能被模型新近性预测(§6.1 (https://arxiv.org/html/2609.00243#S6.SS1))。 ## 2. 相关工作 #### 存储成功经验。部署的智能体将成功的调用和修复写入持久化存储,并在后续场景中重用(Shinn等,2023 (https://arxiv.org/html/2609.00243#bib.bib30);Wang等,2023 (https://arxiv.org/html/2609.00243#bib.bib34);Liang等,2023 (https://arxiv.org/html/2609.00243#bib.bib18);Mialon等,2023 (https://arxiv.org/html/2609.00243#bib.bib22))。这些调用所经过的接口已经并行标准化,从工具调用框架(Qin等,2023 (https://arxiv.org/html/2609.00243#bib.bib29))到当前承载它们的供应商和智能体协议(OpenAI,2025 (https://arxiv.org/html/2609.00243#bib.bib26);Anthropic,2025 (https://arxiv.org/html/2609.00243#bib.bib3)),基准测试也在API套件、Web环境和代码库任务中评估这些智能体(Li等,2023 (https://arxiv.org/html/2609.00243#bib.bib17);Chen等,2023 (https://arxiv.org/html/2609.00243#bib.bib6);Liu等,2024 (https://arxiv.org/html/2609.00243#bib.bib19);Zhou等,2024 (https://arxiv.org/html/2609.00243#bib.bib38);Yang等,2023 (https://arxiv.org/html/2609.00243#bib.bib36);Yang等,2024 (https://arxiv.org/html/2609.00243#bib.bib35))。这条线控制的是什么进入存储以及如何检索。条目的有效性在写入时即被确定,接口中没有任何内容表明它何时停止生效。 #### 客户端自行计算的判定。一个自然的补救措施是让客户端审核存储的条目,记录区分了两种场景。在没有外部信号的情况下,自我修正不能可靠地改善答案,且自我批判分数反映的是模型的置信度而非客观世界(Huang等,2024 (https://arxiv.org/html/2609.00243#bib.bib14);Kamoi等,2024 (https://arxiv.org/html/2609.00243#bib.bib15);Stechly等,2023 (https://arxiv.org/html/2609.00243#bib.bib32);Valmeekam等,2023 (https://arxiv.org/html/2609.00243#bib.bib33)),尽管当文本本身就是目标时,迭代精炼仍然有用(Madaan等,2023 (https://arxiv.org/html/2609.00243#bib.bib20);Paul等,2023 (https://arxiv.org/html/2609.00243#bib.bib28))。第二种场景提供了外部信号:编译器、测试或工具响应。在这种情况下修复是有效的,收益归功于信号而非内省(Gou等,2024 (https://arxiv.org/html/2609.00243#bib.bib12);Chen等,2024 (https://arxiv.org/html/2609.00243#bib.bib5);Olausson等,2024 (https://arxiv.org/html/2609.00243#bib.bib25))。最近的基准测试现在直接测量这种分离(Le等,2026 (https://arxiv.org/html/2609.00243#bib.bib16);Dai等,2026 (https://arxiv.org/html/2609.00243#bib.bib7);Sriram等,2026 (https://arxiv.org/html/2609.00243#bib.bib31))。两种场景都从客户端已拥有的内容计算判定。服务器上轮换的参考表在该上下文中没有留下痕迹,因此无论多少次自我检查都无法恢复它。 #### 在数据传输中为新鲜度定价。决定调用者可以保留什么以及何时必须重新检查,这是陈旧的工作。HTTP为响应赋予明确的有效期和验证器,调用者可以使用它进行重新验证而无需重新获取(Fielding等,2014 (https://arxiv.org/html/2609.00243#bib.bib10))。服务描述将这一规范带入API,从语义标记(Martin等,2004 (https://arxiv.org/html/2609.00243#bib.bib21);Fensel等,2005 (https://arxiv.org/html/2609.00243#bib.bib8))到超媒体约束(Fielding,2008 (https://arxiv.org/html/2609.00243#bib.bib9);Fowler,2010 (https://arxiv.org/html/2609.00243#bib.bib11)),再到机器可读的模式和类型化内省(OpenAPI Initiative,2021 (https://arxiv.org/html/2609.00243#bib.bib27);GraphQL Foundation,2021 (https://arxiv.org/html/2609.00243#bib.bib13)),面向智能体的协议也继承了这一特性(Yang等,2025 (https://arxiv.org/html/2609.00243#bib.bib37))。错误路径是单独标准化的,作为报告问题所在的类型化信封(Nottingham和Wilde,2016 (https://arxiv.org/html/2609.00243#bib.bib23);Nottingham和Wilde,2023 (https://arxiv.org/html/2609.00243#bib.bib24)),结构化的恢复建议位于其上一层(Canedo和Grama,2026 (https://arxiv.org/html/2609.00243#bib.bib4))。在所有这一切中,缓存控制词汇表附加在数据响应上,诊断词汇表附加在错误上,而建议——智能体实际缓存的对象——两者都不携带。失效合约将两者都附加到该对象上:一个提示说明建议是否可以保留,以及一个戳记说明它何时停止有效。 ## 3. 失效合约 失效合约是一组随每个API响应传输的机器可读字段,告诉调用者它可以缓存什么、该缓存依赖什么,以及依赖项何时发生变化。 ### 3.1. 两个API 本节其余部分中的合约字段命名属于底层API的概念,而非协议本身。我们首先定义它们,否则列表将不可读。两个API共享一个领域模型,如图2(https://arxiv.org/html/2609.00243#S3.F2)所示。*参考表*是服务器端的命名字典,将*键*映射到值的*行*:例如,token_funding_map将支付令牌映射到其资金类型。每个表带有一个*版本*,当表内容更改时服务器会更新该字符串。*推导规则*将一个表与另一个表关联:声明表A中的值必须对应表B中的值。规则声明集有其自己的指纹,当规则被添加或重新声明时指纹会改变,但当表数据更改时不会。*策略*是API通过零个或多个规则查询一个或多个表来对传入请求强制执行的验证。当请求违反策略时,服务器会拒绝它并发出*恢复建议*:一个类型化的、机器可读的更改描述,该更改将使请求通过。合约添加的所有内容都是关于给定建议所依赖的哪些表和规则的元数据。 领域模型: 参考表 v 行(键 → 值) 推导规则 策略 恢复建议 包含 关联于 由…强制执行 违反 ⇒ Acme 计费实例 active_csm_codes 1.0.0 plan_partner_growth requires_recognition promo must be eligible USE_REQUIRED_PROMROMO 漂移更新版本号 图2. 两个API共享的领域模型,旁边是Acme计费实例化。一个带版本的参考表保存键控行;推导规则关联跨表的行;策略强制执行规则;被违反的策略发出恢复建议。数据漂移更改表并更新其版本号,这正是失效合约需要报告的事件。第5级列表的图节点是第二行的table:key对。 #### Acme计费。主要领域包装了Stripe(一个商业支付处理服务),在六个参考表上应用了五个策略。三个表包含论文的示例。active_csm_codes将计划映射到客户成功经理(CSM,即人类账户所有者)当前分配给它的促销代码;这些代码在业务场景中轮换。
相似文章
新鲜记忆,过时计划:面向分布式LLM代理记忆的依赖作用域验证
本文介绍了PlanFence,这是一种依赖作用域的验证协议,通过验证计划与当前公开记录的一致性来防止分布式LLM代理系统中执行过时的计划,并通过受控的实时工作流进行了演示。
STALE:LLM智能体能否识别记忆何时失效?
本文识别了LLM智能体中的一个关键失效模式:当新证据与先前信念冲突时,它们无法更新个性化记忆。本文引入了STALE基准和一个三维探测框架,揭示了即使最佳模型也仅达到55.2%的准确率,并提出了CUPMem作为鲁棒记忆修正的原型。
代理事务:迈向符合ACID的代理系统
本文介绍了代理事务的概念,并提出了一个面向LLM代理的符合ACID的代理系统框架,通过实验改进提升了可靠性和一致性,优于最先进的代理。
当存储证据不再可用时:Agent 记忆的条件规模评估
本文提出了一种针对 Agent 记忆的条件规模评估协议,分析随着无关会话的累积,可靠性如何下降。该研究识别了不同记忆接口和大型语言模型(LLM)下的特定失效区域和可用规模边界。
RecMem:基于重复的记忆整合方法,用于高效且有效的长期运行LLM智能体
RecMem是一种基于重复的记忆整合方法,适用于长期运行的LLM智能体,通过仅在语义相似的交互重复出现时调用LLM,可减少高达87%的令牌消耗,同时提高准确性。