SelfMem 深度分析 - 2026-07-11

type

status

date

slug

summary

原始链接

论文页面：SelfMem: Self-Optimizing Memory for AI Agents

PDF：arXiv PDF

DOI：10.48550/arXiv.2607.03726

论文 HTML 原图来源：arXiv HTML

今天为什么选 SelfMem

今天看了几个近期活跃的 Agent 方向：Orca 把多个 coding agent 放进并行 worktree，Rowboat 做本地长期工作记忆，agent-device 给移动端和真实设备测试补上“眼睛和手”，OpenConnector 解决 agent 调工具时的授权和动作目录问题。这些都很实用，但更像产品形态或基础设施。

SelfMem 值得单独写，是因为它碰的是更底层的问题：Agent 长期运行时，记忆到底该由人写规则来管，还是让 Agent 在受控环境里自己学会“该记什么、该删什么、该回源查什么”。这和最近几天写过的 harness、loop、评测不同，焦点落在 memory policy 本身。

它解决的问题：不是记住更多，而是记得更会取舍

很多 Agent 记忆方案会在三条路里选一条：全量上下文、RAG 检索、摘要/画像/知识图谱。问题是长任务里信息有新旧、有稳定和临时、有事实和偏好。把所有东西塞进上下文很贵，压缩会丢细节，RAG 又常常只在提问时捞几个片段，没形成可维护的工作记忆。

SelfMem 的核心判断很朴素：记忆不是一个静态仓库，而是一套可被检查和修订的策略。论文把这句话画成“教 Agent 钓鱼，而不是直接给鱼”。

图 1 来自论文 HTML 原图。它表达的是 SelfMem 的出发点：不要预先规定一种固定记忆格式，而是给 Agent 原则、工具和反馈，让它自己学习记忆取舍。

系统怎么运作

SelfMem 把系统拆成两层。第一层是不可变的原始对话记录，论文实现里用 SQLite 表保存 turn_index、role、time_anchor、content 等字段。它是事实来源，Agent 只能读，不能改。第二层是 Agent 管理的 memory workspace，里面可以是用户画像、偏好、项目状态、时间线，也可以是 Agent 自己整理出来的策略笔记。

Agent 不直接“生成一份总结”就结束，而是在工具循环里做几类动作：读原始 transcript，读当前 memory，写入或修订 memory，检查 memory 质量，必要时做 self-test。检查项包括来源是否可靠、事实是否过期、是否有矛盾、摘要是否太粗、以后是否容易检索。

图 2 是 SelfMem 的主流程。左边保留原始 transcript，中间是 memory action space，右边是 Agent 生成的可用记忆。关键不在 SQLite，也不在某个具体工具名，而在这个闭环：inspect -> write -> review -> revise。记忆第一次写错并不可怕，可怕的是系统没有让它发现错误和修正错误的地方。

回答问题时，SelfMem 会同时使用最终 memory workspace 和从原始 transcript 找回来的相关片段。这样可以避免两种极端：只靠记忆导致事实失真，只靠检索又缺少长期结构。

它和常见 Agent 记忆方案的区别

RAG 的强项是便宜、直接、可扩展，但它通常是“提问时检索”，不是“长期维护记忆”。SelfMem 不是否定 RAG，而是把 RAG 放回一个更大的记忆管理过程里：哪些内容该长期保存，哪些内容该临时回源查，由 Agent 根据反馈决定。

MemGPT、MemoryBank、Mem0、A-Mem 都比普通 RAG 更接近 Agent 记忆。MemGPT 让模型在不同记忆层之间搬运信息，MemoryBank 做长期用户记忆，Mem0 更偏生产化抽取和检索，A-Mem 允许 Agent 写、索引、链接记忆。SelfMem 往前推了一步：不只让 Agent 操作记忆，还让它调整“记忆策略”本身。

但这里也别夸过头。SelfMem 仍然依赖人设计好的 harness：原始记录怎么存、工具能做什么、review 看哪些风险、反馈怎么给，都是系统边界。真正新的地方，是把 memory policy 暴露给模型，让模型在工具反馈下修订策略。工程包装的部分，是 SQLite、工具接口、review checklist 这些实现形式。

实验结果怎么看

论文在 BEAM 长对话记忆评测上比较了 RAG、Full context、Compression、LoCoMo、ReadAgent、MemoryBank、MemGPT、A-Mem、Mem0 和 SelfMem。测试覆盖 100K、500K、1M token 三个规模，问题类型包括信息抽取、多轮推理、时间推理、偏好、更新、摘要等。

主表里，SelfMem 在三个规模上都拿到最高 Score 和 Pass0.5。100K 时 Score 是 0.504，RAG 是 0.339；500K 时 SelfMem 是 0.487，RAG 是 0.346；1M 时 SelfMem 是 0.454，RAG 是 0.320。论文还给了成本：1M token 规模下，SelfMem 成本为 2.004 美元，Mem0 是 18.830 美元，RAG 是 1.843 美元。也就是说 SelfMem 不是最便宜，但比很多重型记忆系统更准、更省。

图 3 来自论文的 BEAM 分问题类型结果。它比较重要，因为它说明 SelfMem 的优势不只来自某一类题。论文报告称，SelfMem 在 100K 规模下 10 类问题中拿下 9 类最佳，500K 下 8 类最佳，1M 下 7 类最佳。对 Agent 产品来说，这比单一总分更有参考价值，因为真实用户问的问题不会只落在一种记忆模式里。

更有意思的是策略优化

SelfMem 不只构造记忆，还测试了“记忆策略能不能继续被优化”。论文把 conversation 0-8 用作训练反馈，把 conversation 9-19 作为 held-out 测试。Agent 看不到测试答案，只能根据训练分数和记忆工具诊断，生成新的策略说明。

图 4 显示默认策略的 held-out 分数是 0.472，最终 Agent 合成策略到 0.497，搜索过程中最好的策略到 0.510。这里最值得注意的不是涨了多少，而是最强策略并不出现在最多迭代或最多训练样本时。换句话说，记忆优化不是“跑越久越好”，而是需要找到合适的程序性规则：哪些事实长期保存，哪些事实保持可回源，哪些摘要必须带来源，哪些细节不能提前压扁。

对产品和研发的启发

第一，长期记忆不要只做成资料库。真正难的是“记忆治理”：过期事实怎么降级，稳定偏好怎么保留，冲突信息怎么提示，重要细节怎么回源。

第二，原始记录要当作事实底座保留。SelfMem 的 transcript store 很关键，因为 memory workspace 可以错、可以改、可以压缩，但原始证据不能跟着一起变形。

第三，把诊断反馈做成工具，而不是只靠提示词提醒。比如“这个记忆有没有来源”“是否和旧记忆冲突”“未来能不能检索到”，这些都可以变成 Agent loop 里的显式检查。

第四，memory 和 eval 要一起设计。没有长周期、多类型、带成本的评测，团队很容易把“记得多”误判成“记得好”。SelfMem 的结果提醒我们，记忆系统至少要同时看正确率、成本、请求次数、缓存利用和可审计性。

风险和没验证的地方

SelfMem 目前主要在 BEAM 上验证，论文自己也说还需要更多 long-horizon benchmark、模型家族和真实部署场景验证。策略优化实验只在 100K 规模做了，500K 和 1M 下能否稳定优化，还没有结果。

它还依赖模型自己判断记忆质量。review 工具能降低风险，但不能保证 Agent 不会把错误事实写得很自信。真实产品里还要考虑隐私、用户可见性、删除权、团队共享记忆、多 Agent 同时写 memory 时的冲突处理。

还有一点现实问题：我在 arXiv 页面没有看到作者提供代码链接。论文给了相当多流程和指标，但如果没有可复现实装，外部团队要判断它在自己业务里的成本和收益，还需要重做一遍 harness。

今日沉淀

长期记忆的难点不是容量，是取舍。

好的 Agent memory 应该能回源、能审计、能修订。

记忆策略本身可以成为 Agent 优化对象。

RAG 适合找证据，不等于长期工作记忆。

做 Agent 产品时，要把 memory、loop、eval 放在同一个设计里看。