我们先看论文中给出的一个例子。
在 NetHack 这种长流程游戏里，Agent 得记住地图、物品、状态、策略、探索路径这些东西。项目早期，只要看到新位置，Agent 就往同一个 dungeon_map.txt 文件追加位置信息。
这看起来很合理，但很快问题就出现了。Agent 在地图里来回走动是常事，同一个坐标很可能来回被访问。如果每次访问都往文件末尾加一条记录，文件只会越写越长，重复内容也越堆越多。到后面 Agent 想查看这个文件时，真正有用的信息反而被埋在一堆过时记录里翻不出来。
针对这些问题，AutoMem 把这种 append-only 的写法，改成按坐标做 upsert------同一个位置有了新观察，就直接覆盖掉旧记录，文件里始终只留这个坐标的最新状态。
1
图注：NetHack 里的记忆文件演化。早期版本会不断追加地图坐标，导致产生大量重复记录；优化后改成基于坐标的 upsert 格式，同一位置的新记录会覆盖旧记录。同时，系统还把物品、状态和策略参考等信息拆成更清晰的文件，方便 Agent 后续读取和更新。
这个例子体现了 AutoMem 的工程意义。记忆系统的关键不只是能不能写文件，还在于这些文件会不会越写越乱。地图、库存、状态、策略这些信息要是混在一起，Agent 读取时会越来越混乱；反过来，只要把文件和 schema 组织清楚，后续 Agent 的决策就会稳不少。
NetHack 的地图文件从 append-only 改成按坐标去重之后，每一步新增的记忆内容从 138 个字符降到了 6 个字符，减少了 95%。这看起来只是个很小的 schema 调整，但对长任务来说会很有用。毕竟长任务一般要跑很多步，早期写入的一点点冗余，会滚雪球式地积累下去，后面就变成越来越重的上下文噪声。
Agent 表面上看有记忆，实际上只是在一堆脏数据里大海捞针。
AutoMem 的核心：两层外部循环
AutoMem 的框架可以拆成两层来理解。
2
图注：AutoMem 的整体框架。
上图中间米黄色的部分是 Agent 本体。它左边是当前的游戏观察（地图、HP、背包），中间是 game LLM 在做的三件事：LOG（记录/更新记忆）、PLAN（查阅记忆、做决策）、GAMEPLAY（真正落子行动），右边就是那个 memory/ 文件夹，里面是各种 .txt 文件。这一块是两层外循环共同作用的对象，两层外循环都会去改它、影响它。
上方青绿色的部分是 OUTER-LOOP 1，负责优化结构。这里的 meta-LLM 扮演的是结果审查员的角色：它会看完整 episode 的轨迹，哪怕它动辄一万到十万步。然后它会去分析 Agent 在记忆管理上哪里出了问题，再回过头去改 Agent 的 scaffold------包括 prompt、代码逻辑，也包括记忆的 schema。前面提到的地图文件从 append 改成 upsert，就是这一层干的事。meta-LLM 改完之后，会再重新部署、再观察、再迭代，这是一个循环。
下方红色的部分是 OUTER-LOOP 2，负责优化能力。这里的 meta-LLM 干的是另一件事：从海量轨迹里挑出值得学习的记忆操作，定好训练数据的标准和构成，选 LoRA 配置，最后训练出一个专门的 memory specialist。
这里，提一下米黄色部分下面的两块小方框：task model（负责游戏动作）是冻结的，权重完全不动；真正被训练、被替换的是 memory specialist（负责记忆操作），它是由 LoRA 微调出来的。AutoMem 没去优化模型执行任务的能力，优化的始终只是"怎么记、怎么查"这一部分内容。
第一层（青绿）先把 Agent 的记忆结构和规则改对，第二层（红色）再让模型在这套结构里把记忆操作做得更熟练，两层轮流作用在中间这个 Agent 身上，就是 AutoMem 的整体框架。
实验结果
论文在三个长任务游戏环境里做了实验：Crafter、MiniHack 和 NetHack。这三者有个共同点：任务周期长、世界会持续变化、历史信息很关键。Crafter 涉及探索、采集、制作和战斗；NetHack 则是极其复杂的 roguelike 环境，一个 episode 能长到 10⁴ 到 10⁵ 步。
论文实验用的基础模型是 Qwen2.5-32B-Instruct。结果数据显示：只优化记忆，不动任务模型的权重，AutoMem 在三个环境里都带来了大约 2× 到 4× 的提升。
3
图注：AutoMem 在三个长任务环境中的效果。曲线展示 scaffold 优化带来的逐步提升，右侧红色点表示再经过记忆训练后的结果。
4
图注：BALROG 长周期游戏任务表现
上图显示，memory-as-file-system 的初始版本在 Crafter / MiniHack / NetHack 上分别是 25.00、7.50、0.42；经过 scaffold 优化（loop 1）后提升到 47.27、27.5、1.57；再加上记忆训练（loop 2），进一步涨到 51.36、30.00、1.85。
这组结果说明一件事：长任务能力不完全取决于模型参数规模。论文提到，优化后的这个 32B open-weight 模型，在这些任务上已经接近部分闭源前沿系统的水平。
行为层面的变化主要是 scaffold 优化之后，Agent 的低效动作明显地减少了。这里的低效动作是 stuck（动作没带来任何环境变化）和 oscillation（来回折返、原地绕圈）。经过优化后，三类长任务环境的无效动作比例下降了 32% 到 65%。记忆本身的操作也变干净了：重复写下降 68% 到 83%，空搜索下降 13% 到 50%，每一步塞进上下文的 token 量也降了 3% 到 30%。
5
图注：scaffold 优化后，Agent 的任务动作和记忆动作都变得更高效。
这组行为数据其实比最终分数更能说明问题：AutoMem 带来的提升，本质上是把 Agent 在长任务里几种常见的浪费给消掉了------原地卡住、来回绕路、写重复信息、搜索扑空。一个真正会用记忆的 Agent，不会把所有东西不假思索地堆进文件；它会先查已有记录，再决定要不要更新；会用更结构化的方式记地图、库存、状态；也会主动减少重复内容，让自己后面更容易查到有用的东西。
这也作证了外部记忆真正的价值：不在于能存多少东西，而在于能不能把信息压缩、组织好，让模型下一步决策时更容易定位到真正相关的内容。
当然，我们也要看清楚边界。这些实验都是在游戏环境里做的，不能直接等同于真实工程任务。但它给了我们一定的启发，在长流程 Agent 里，记忆管理很可能是一个投入产出比极高的优化方向。
工程价值
我觉得 AutoMem 最值得拿出来讲的一点，是它把 Agent Memory 从"存储组件"往前推了一步，推到了"能力训练"这个层面。
过去聊 memory，讨论往往会落在具体实现上：向量库怎么选，召回怎么做，summary 怎么写，长上下文怎么裁剪。AutoMem 提醒我们的是，真正决定 Agent 长任务表现的，可能还有一层更底层的东西------Agent 会不会管理自己的记忆。
它知不知道什么值得记下来，写之前会不会先查一下有没有记过，能不能避免重复记录，能不能把记忆组织成后面真派得上用场的结构...这些工程细节放在长任务中会不断地累积，最后直接决定 Agent 能不能把事情做完。
这和真实开发工作很像。一个人写项目文档、维护日志、整理 TODO、记录踩过的坑，这些从来不只是简单地多写几个文件。写乱了，后面根本找不到；写太细，噪声就会盖过重点；写太少，关键状态又会丢。Agent 在跑长流程任务时，碰到的其实是同一类问题。
所以这篇论文的价值，不只是提出了 AutoMem 这一个框架，更重要的是它指了个方向：未来的 Agent 系统里，记忆能力也许会像规划、调用工具、执行代码一样，变成一个可以单独优化、单独训练、单独评估的独立模块。
Agent Memory 接下来要卷的，可能不只是"存在哪里"，还会开始卷"来整理、怎么整理、整理得好不好"。
局限性
AutoMem 目前的实验仍然有几个边界。
首先，论文里的记忆是 episodic 记忆，也就是每个 episode 开始时文件系统重新初始化，并没有跨 episode 保留长期经验。未来如果要用于真实工作流实验，持久化记忆会是一个重要方向。
其次，实验主要发生在游戏环境中。游戏任务适合研究长周期记忆，因为它有地图、库存、路径、目标和反馈，但真实工程任务会涉及更多复杂约束，比如代码库演化、权限、安全、多人协作、工具调用失败等。论文也提到，把方法扩展到真实 memory-intensive tasks 是后续方向。
还有一点是，论文中三个环境分别优化了不同 scaffold 和 memory specialist。因此，它还没有证明一个通用 memory scaffold 可以跨任务泛化。
这些限制不会削弱这篇论文的价值，但会提醒我们：AutoMem 更像是一个方向样本，展示"记忆管理可以被优化和训练"，距离通用 Agent 记忆系统还有一段路要走。
小结
AutoMem 这篇论文可以用一句话概括：Agent 的记忆管理，是一种可以被观察、评估、优化和训练的技能。
它把文件系统作为外部记忆，把读、写、查、追加这些操作放进 Agent 的 action space，再用两个外层循环分别优化记忆结构和记忆熟练度。实验结果显示，在长任务环境里，只优化记忆管理，就能显著提升 Agent 表现。