许多 AI 智能体（Agent）已经配备了常见组件：检索增强生成（RAG）、向量数据库、对话摘要缓存（summary buffer），甚至还将中间结果写入文件。然而，当任务复杂度增加、流程拉长之后，智能体依然容易出现偏离目标的问题。
问题最大的可能性并不在于“有没有存储空间”，而是这些信息根本没有被有效管理。在执行长时间任务时，不断会涌现出新的线索、变化的状态和积累的经验。如果只是一味地将所有内容追加到文件中，很快就会出现重复记录、旧信息未被更新、关键内容难以检索、重要线索被大量无关信息淹没等情况。
因此，一个优秀的记忆系统不能仅仅具备“存储”能力，还必须拥有判断力：什么时候应该记录新信息，什么时候需要回顾已有内容，旧的记录是覆盖还是保留，以及文件该如何组织——这些因素共同决定了记忆能否真正被智能体有效利用。
斯坦福大学的一篇论文正好探讨了这个议题，标题为「AutoMem: Automated Learning of Memory as a Cognitive Skill」，下文简称 AutoMem。论文的核心观点是：记忆管理本身就是一项可以习得的技能，而不是搭建好基础设施后自动获得的副产品。换句话说，智能体除了要完成主任务，还需要学会分辨——哪些信息值得保留，什么时候该查阅历史记录，写过的内容是否需要更新，以及记忆该如何组织才能方便后续使用。
混乱的 Agent 的记忆
我们先来看论文中给出的一个具体示例。
在 NetHack 这类长流程游戏中，智能体需要记住地图布局、物品位置、状态变化、策略选择以及探索路径等信息。项目早期，每当发现一个新位置，智能体就会将位置信息追加到同一个 dungeon_map.txt 文件中。
这种方法表面上看很合理，但很快暴露出问题。智能体在地图中频繁来回移动，同一个坐标可能被多次访问。如果每次访问都向文件末尾追加一条记录，文件会越来越长，重复内容不断堆积。当智能体想要查看这个文件时，真正有价值的信息反而被大量过时记录淹没，难以提取。
针对这些问题，AutoMem 将这种“只追加不更新”的写入方式，改为按坐标进行 upsert——当同一位置出现新观察时，直接覆盖旧记录，文件中始终保持该坐标的最新状态。
图注：NetHack 中的记忆文件演化过程。早期版本不断追加地图坐标，导致大量重复记录；优化后改为基于坐标的 upsert 格式，同一位置的新记录会覆盖旧记录。同时，系统还将物品、状态和策略参考等信息拆分到更清晰的文件中，方便智能体后续读取和更新。
这个示例充分体现了 AutoMem 的工程价值。记忆系统的关键不仅在于能否写入文件，还在于这些文件是否会随着时间变得越来越混乱。如果地图、库存、状态、策略等信息混杂在一起，智能体读取时会越来越困难；反之，只要将文件和 schema 组织得清晰有序，后续智能体的决策稳定性就会显著提升。
NetHack 的地图文件从 append-only 改为按坐标去重后，每一步新增的记忆内容从 138 个字符降低到 6 个字符，减少了 95%。虽然这看起来只是一次微小的 schema 调整，但对于长任务来说效果显著。因为长任务通常需要执行大量步骤，早期写入的微小冗余会像滚雪球一样不断累积，最终演变成越来越严重的上下文噪声。
简而言之，智能体表面上有记忆，实际却等于在一堆脏数据中大海捞针。
AutoMem 的核心：两层外部循环
AutoMem 的框架可以拆解为两个层次来理解。
图注：AutoMem 的整体框架结构。
上图中米黄色部分代表智能体本身。其左侧是当前游戏环境观察（地图、生命值、背包）；中间是游戏大语言模型（game LLM）正在执行的三项任务：LOG（记录/更新记忆）、PLAN（查阅记忆并制定决策）、GAMEPLAY（实际执行操作）；右侧是 memory/ 文件夹，内含多个 .txt 文件。这一部分正是两层外部循环共同作用的目标，两者都会修改并影响它。
上方青绿色部分为 OUTER-LOOP 1，负责优化结构。这里的元语言模型（meta-LLM）扮演结果审查员角色：它会分析整个 episode 的轨迹（即使长达一万到十万步），然后诊断智能体在记忆管理方面出的问题，并回过头来修改智能体的脚手架——包括提示词（prompt）、代码逻辑以及记忆的 schema。前面提到的地图文件从 append 改为 upsert，就是这一层的工作。meta-LLM 修改后，会重新部署、观察、迭代，形成一个闭环。
下方红色部分为 OUTER-LOOP 2，负责优化能力。这里的 meta-LLM 执行另一项任务：从海量轨迹中筛选出值得学习的记忆操作，制定训练数据的标准和构成，选择 LoRA 配置，最终训练出一个专门的记忆专家（memory specialist）。
需要特别说明的是，米黄色部分下方的两个小方块：task model（负责游戏动作）是冻结的，权重完全不变；真正被训练和替换的是 memory specialist（负责记忆操作），它通过 LoRA 微调得到。AutoMem 并没有优化模型执行任务的能力，优化的始终是“如何记录、如何查找”这一部分。
第一层（青绿）先将智能体的记忆结构与规则调整正确，第二层（红色）再让模型在这套结构中将记忆操作执行得更娴熟。两层轮流作用于中间的智能体，这就是 AutoMem 的完整框架。
实验结果
论文在三个长任务游戏环境中进行了实验：Crafter、MiniHack 和 NetHack。这三者有一个共同特点：任务周期长、世界持续变化、历史信息至关重要。Crafter 涉及探索、采集、制作和战斗；NetHack 则是极其复杂的 roguelike 环境，一个 episode 可能长达 10⁴ 到 10⁵ 步。
实验所用的基础模型为 Qwen2.5-32B-Instruct。结果显示：仅优化记忆管理，不改变任务模型的权重，AutoMem 在三个环境中均带来了大约 2 倍到 4 倍的性能提升。
图注：AutoMem 在三个长任务环境中的效果。曲线展示了脚手架优化带来的逐步提升，右侧红色点表示进一步经过记忆训练后的结果。
图注：BALROG 长周期游戏任务表现数据。
上图显示，memory-as-file-system 的初始版本在 Crafter / MiniHack / NetHack 上的得分分别为 25.00、7.50、0.42；经过脚手架优化（loop 1）后提升到 47.27、27.5、1.57；再经过记忆训练（loop 2），进一步涨到 51.36、30.00、1.85。
这组结果说明了一个重要事实：长任务能力并不完全取决于模型参数规模。论文指出，优化后的这个 32B 开源模型，在这些任务上的表现已经接近部分闭源前沿系统。
从行为层面看，脚手架优化之后，智能体的低效动作明显减少。这里的低效动作包括 stuck（动作未带来任何环境变化）和 oscillation（来回折返、原地绕圈）。优化后，三类长任务环境的无效动作比例下降了 32% 到 65%。记忆操作本身也变得更加干净：重复写入下降了 68% 到 83%，空搜索下降了 13% 到 50%，每一步送入上下文的 token 量也减少了 3% 到 30%。
图注：脚手架优化后，智能体的任务动作和记忆动作均变得更加高效。
这组行为数据比最终分数更能揭示本质：AutoMem 带来的提升，实际上是消除了智能体在长任务中常见的几种浪费——原地卡住、来回绕路、写入重复信息、搜索无结果。一个真正善于管理记忆的智能体，不会不加思考地将所有内容堆进文件；它会在写入前先查阅已有记录，再决定是否更新；会用更结构化的方式记录地图、库存、状态；还会主动减少重复内容，让后续检索更轻松。
这也印证了外部记忆的真正价值：不在于能存储多少数据，而在于能否将信息压缩、组织好，使得模型在下一步决策时更容易定位到真正相关的内容。
当然，我们也需要看清边界。这些实验均在游戏环境中进行，不能直接等同于真实工程任务。但它给我们带来了启发：在长流程 Agent 系统中，记忆管理很可能是一个投入产出比极高的优化方向。
工程价值
AutoMem 最值得强调的一点是，它将 Agent Memory 从“存储组件”的概念推进到了“能力训练”的层面。
过去讨论记忆时，焦点往往落在具体实现上：如何选择向量库、如何进行召回、如何写摘要、如何裁剪长上下文。AutoMem 提醒我们，真正决定智能体长任务表现的，可能还有一层更底层的东西——智能体会不会管理自己的记忆。
它是否知道什么值得记录，写入前是否会先检查是否已经记录过，能否避免重复，能否将记忆组织成日后真正有用的结构……这些工程细节在长任务中会不断累积，最终直接决定智能体能否完成任务。
仔细想来，这跟实际开发工作非常相似。一个人写项目文档、维护日志、整理待办事项、记录踩过的坑——这从来不只是简单地多写几个文件。写乱了，后面根本找不到；写太细，噪声会盖过重点；写太少，关键状态又会丢失。智能体在运行长流程任务时，遇到的正是同一类问题。
因此，这篇论文的价值不仅在于提出了 AutoMem 这个框架，更在于它指明了一个方向：未来的 Agent 系统中，记忆能力可能会像规划、调用工具、执行代码一样，成为一个可以单独优化、单独训练、单独评估的独立模块。
Agent Memory 接下来要竞争的，可能不只是“存在哪里”，还会开始竞争“谁来整理、怎么整理、整理得好不好”。
局限性
AutoMem 目前的实验仍然存在几个边界条件。
首先，论文中的记忆属于 episodic 记忆，即每个 episode 开始时文件系统会重新初始化，没有跨 episode 保留长期经验。未来如果要在真实工作流中应用，持久化记忆将是一个重要方向。
其次，实验主要集中于游戏环境。游戏任务适合研究长周期记忆，因为它包含地图、库存、路径、目标和反馈，但真实工程任务会涉及更多复杂约束，例如代码库演化、权限管理、安全机制、多人协作、工具调用失败等。论文也提到，将方法扩展到真实的 memory-intensive 任务是后续方向。
还有一点是，论文中三个环境分别优化了不同的 scaffold 和 memory specialist。因此，目前尚未证明一个通用的 memory scaffold 可以跨任务泛化。
这些限制并不会削弱论文的价值，但提醒我们：AutoMem 更像是一个方向样本，展示了“记忆管理可以被优化和训练”，距离通用的 Agent 记忆系统还有一段路要走。
小结
AutoMem 这篇论文可以用一句话概括：Agent 的记忆管理，是一种可以被观察、评估、优化和训练的技能。
它将文件系统作为外部记忆，把读、写、查、追加等操作纳入 Agent 的动作空间，再通过两个外层循环分别优化记忆结构和记忆熟练度。实验结果表明，在长任务环境中，仅优化记忆管理就能显著提升 Agent 的表现。
这对 Agent 系统设计具有重要启发。当我们讨论 Agent 为什么做不长、为什么容易重复、为什么上下文越跑越乱时，问题可能不只在于模型是否聪明，也在于它是否具备一套成熟的记忆管理习惯。
未来的 Agent，可能不仅要会调用工具、写代码、做计划，还要真正学会：什么该记，什么时候查，怎么整理，以及如何让过去的信息在未来继续发挥作用。
论文文献：AutoMem: Automated Learning of Memory as a Cognitive Skill arxiv.org/pdf/2607.01224
