一个被长期回避的问题
Agent 的长期记忆已经被讨论了两年，但业界衡量它的方式一直有个盲区。据论文描述，当前主流评测基准（LoCoMo、LongMemEval）测的是「模型能不能从对话历史里回忆起事实」，也就是问答准确率。可对于真正在干活的工具型 Agent 来说，更重要的问题不是「记不记得住」，而是「记住的事实有没有改变它的动作」。
一篇新论文直接把这个盲区摆上台面。论文标题为《When Does Memory Help? A Cost-Aware Evaluation of Long-Term Memory in Tool-Using LLM Agents》，编号 arXiv:2609.05441v1，提出了一个名为 MERIT（Memory Evaluation for Realistic Instrumented Tasks）的基准与测试框架，用来测量记忆对任务执行型 Agent 的边际效用，并且把成本显式计入。
MERIT 是怎么设计的
据公开摘要，MERIT 的设计有四个关键特征。
一是任务形态。它提供三个领域的「情节式」工具使用任务（episodic tool-use tasks），这些任务的完成依赖前面 episode 中产生的事实。二是有防作弊机制。任务对早前 episode 事实的依赖关系经过自动泄漏检查（leak check）验证，确保 Agent 不能从当前上下文里直接找到答案——这一点看似基础，但在记忆评测中几乎从未被实现。三是有难度阶梯。任务从简单依赖一路延伸到「更新事实的回忆」，也就是考察当同一个事实被后续信息覆盖后，Agent 是否使用最新值。四是成本计量。每一次记忆操作都被完整记录 token 消耗与美元成本。
实验规模上，论文报告在 23440 条计分 episode 上完成评测，总成本 42.57 美元；采用两代试点（gpt-4.1-mini）加一个预注册的「3 模型 × 3 种子」网格（GPT-4.1、Claude Haiku 4.5，记忆侧保持固定），并用最新一代模型（Claude Sonnet 5）做了一次抽查，且抽查以「干净的全量重放对照」为门控条件。
结论一：记忆确实有用，而且是从 0 到 1 的差别
论文报告的最直接结论是：在依赖早前 episode 事实的任务上，没有记忆的 Agent 成功率落在经过泄漏验证的 0.00 地板上；引入记忆后，成功率上升到 0.55 至 1.00 之间。也就是说，在这类任务里记忆不是「锦上添花」，而是决定 Agent 能否工作的前提。
这个数字对工程团队的意义很直接：如果你的 Agent 需要跨会话、跨天完成任务，那么记忆能力的缺失会导致任务在特定环节必然失败，而不是概率性变差。
结论二：真正难的不是检索，是「更新」
论文里最有价值的发现出现在「更新事实」这一档。当同一个事实被后续信息覆盖时，不同记忆架构的表现出现了巨大分化：
嵌入检索（embedding retrieval，也是目前最主流的做法）表现不可预测地崩塌，跨模型得分区间在 0.30 至 0.95 之间，最大种子间差距达 0.45。更关键的是，Agent 在检索到正确值之后，只有 55% 的情况下会真正按这个值行动——换句话说，差不多一半的工程投入花在提升检索上，却没有转化为行为改变。
相比之下，采用「写时更新」（update-on-write）思路的存储保持在 0.70 至 1.00：一类是结构化事实库，另一类是 LLM 摘要——后者保持同样的水平，论文作者对此也表示了意外。更反直觉的是，把两者组合起来的混合方案，表现反而比单独使用结构化事实库更差。
论文还报告了一个整体性数字：仅仅更换记忆的实现方式，任务成功率最多会变动 60 个百分点。
结论三：全量重放从来不划算
面对「记不住」的问题，最粗暴的解法是把整段对话历史全部塞回上下文，也就是全量重放（full replay）。论文的计量结论是：全量重放从来不是经济的选择。按领域计算，每个领域里表现最好的记忆条件，其每美元边际效用是全量重放的 2.7 到 3.9 倍。
这条结论对成本敏感的团队尤其重要。长流程 Agent 的上下文开销是乘数级的，全量重放在 token 账本上会迅速失控，而结构化的记忆存储能在保留关键事实的同时把上下文压下来。
同一周的其他论文指向同一个断层
据公开梳理，与 MERIT 同一周提交的多篇相邻论文，都指向同一个失效模式：事实的「被取代」（supersession）。
Fortunate Recall 把个人事实分类到一套行为本体中，并按类别应用衰减与取代规则，报告在 LifecycleBench 上达到 76.9%，对比竞争系统的 61% 至 70.5%；其自身预注册的消融实验显示，本体的可测量贡献主要在于校准，把虚构（confabulation）减半，而对正确率的影响在统计上并不显著。RD-Forget 采取「保留原始归档、在回答时构建查询条件视图」的思路，把「存什么」和「用什么」分开。EdgeMem 则更彻底，构建与检索记忆的过程完全不调用生成式大模型，报告在七个受评系统中取得了严格评判口径下的最高分。
这些工作的分歧点也很清楚：一派主张在写入时就做压缩与类型化策略，另一派主张原样保留、在读时过滤；此外还有一派认为记忆构建环节根本不应该调用生成式模型。但它们在一件事上高度一致——记忆评测必须超越对话回忆基准，而被取代的旧事实才是主要失效来源，而不是检索覆盖率不够。
对 Agent 团队的可操作建议
把这篇论文的结论翻译成工程动作，至少有三条是可以马上做的。
其一，把「行为率」纳入评测指标。不要只统计检索命中率，还要统计「检索到正确值之后 Agent 是否照做」。论文里 55% 这个数字说明，检索正确与行为正确之间存在显著缺口，只盯前者会高估记忆系统的实际效果。
其二，对需要更新的事实优先采用写时更新。结构化事实库与摘要式写入在更新场景下的稳定性明显优于纯嵌入检索，尤其在事实会被后续信息覆盖的场景（如客户信息、配置项、项目状态）。
其三，不要默认混合方案更好。论文的结果显示混合可能低于单一方案，架构选择应该以自己的任务数据做 A/B 验证，而不是按「组合一定更强」的直觉决策。
此外，评测设计上有一个容易被忽略的细节值得借鉴：自动泄漏检查。如果任务答案可以从当前上下文里直接读到，那测出来的就不是记忆能力。自建评测时加上这一道检查，可以避免大量假阳性结论。
中立思辨
需要客观看待这项工作的边界。其一，实验使用的模型是 GPT-4.1 系列与 Claude Haiku 4.5，另有 Sonnet 5 抽查，结论是否适用于其他模型族与本地部署模型仍需验证。其二，三个领域的任务设计虽然做了泄漏检查，但领域数量有限，任务分布的广度不足以断言结论在所有场景成立。其三，成本核算以 token 与美元计，未计入工程实现复杂度、运维成本与延迟，而这些在实际选型中同样重要。其四，论文提到「LLM 摘要」在更新场景下表现与结构化事实库相当，但摘要的稳定性可能受模型版本变化影响，长期维护成本需要单独评估。其五，42.57 美元的总成本虽然低廉，但也说明单条 episode 的评测预算很小，任务复杂度与实际生产场景仍有距离。其六，记忆架构的效果高度依赖任务类型，短任务、单轮任务上记忆可能完全不必要，盲目引入反而增加开销。其七，同一周相邻论文的结论方向一致，但它们各自的评测口径不同，直接横向比较具体分数需要谨慎。
趋势研判
短期，记忆评测会从「回忆准确率」转向「行为改变率 + 单位成本」，具备成本核算能力的基准会成为新的参照；中期，写时更新的结构化存储可能成为长周期 Agent 的默认选择，嵌入检索则更多承担召回与探索的角色，两者在架构上分工而非叠加；长期，记忆的价值衡量会进一步向「每美元完成多少任务」收敛，记忆系统的设计目标会从「记得更多」变成「记得更准、更省、更少过期」。
对正在做长周期 Agent 的团队来说，一个务实的起点是：先给自己的记忆链路建一份账本——记下每次写入、检索与注入的 token 与耗时，再统计「检索正确但行为错误」的比例。这两个数字，往往比任何基准分数更能说明问题出在哪里。