IBM：Agent记忆不是越多越好

IBM Research 近日发布了一项关于 Agent 动态记忆管理的研究，试图回答一个长期被工程团队回避的问题：Agent 到底需要多少记忆？这项工作被放进 Agent Learning Toolkit（ALTK）的 Evolve 框架中，并引入 HMM 对交互轨迹进行序列建模，让系统根据任务所处阶段调整可用记忆，而不是把全部历史一股脑塞回上下文窗口。

**Agent 记忆是智能体在连续交互中保存、更新和调用历史信息的机制。**它既包括当前上下文里的工作记录，也包括外部数据库中的事实、过去任务的完整轨迹，以及可以重复调用的操作经验。

IBM 这项研究最值得关注的地方，不是又造了一个向量数据库，而是把“保留多少历史”从固定配置改成了可学习的决策。过去，开发者通常会直接设置最近 10 轮对话、检索 Top 5 片段或保留 32K token；新方法则试图根据任务阶段、轨迹变化和历史有效性动态决定记忆预算。

这听起来只是上下文压缩，实质上却触及了 Agent 系统的一个核心矛盾：**更多记忆能够减少遗忘，但也会增加成本、延迟、噪声和错误传播。**对于需要连续调用工具的 Agent，记住所有事情并不等于更聪明，有时反而意味着更难从一堆过期信息中找到当前真正重要的那一条。

HMM 在这里解决的不是存储，而是判断

**HMM，即隐马尔可夫模型，是一种用可观察序列推断隐藏状态的概率序列模型。**在 Agent 场景里，用户消息、模型回答、工具调用、执行结果和错误信息都是可观察信号，而“正在探索方案”“已经锁定目标”“进入执行阶段”“发生异常并回退”等任务阶段，则可以被看作无法直接观测的隐藏状态。

HMM 的核心假设是，当前隐藏状态主要取决于前一个状态，而当前观察由当前状态产生。这个假设不适合描述所有复杂推理过程，却非常适合做轻量级的阶段判断：Agent 不需要每一步都重新阅读完整轨迹，也能估计自己当前处于什么阶段，并据此切换记忆策略。

**ALTK Evolve 是 IBM 用于优化和演化 Agent 行为的实验框架，而 HMM 在其中扮演的是轨迹建模与策略选择层。**它不是一个新的存储后端，也不是用概率模型替换大语言模型；它更像操作系统里的内存调度器，负责决定哪些历史应继续留在快速工作区，哪些内容可以压缩、归档或暂时移出。

从工程流程看，这类动态记忆机制通常可以拆成四步：

1. **观察轨迹：**读取当前输入、近期行动、工具返回、错误状态和任务进度。
2. **推断阶段：**根据连续观察估计当前任务所处的隐藏状态，而不是只看最后一条消息。
3. **调整记忆：**改变工作记忆长度、召回范围、摘要粒度或不同记忆类型的优先级。
4. **评估结果：**根据任务是否完成、调用次数、奖励和成本，继续修正后续策略。

**动态记忆管理的关键不是无限扩容，而是让记忆规模随任务变化。**例如，Agent 在需求澄清阶段可能需要保留较长的对话历史；进入数据库查询阶段后，它更需要字段定义、查询约束和最近一次工具结果；完成任务后，系统则只需沉淀最终结论、用户偏好与可复用经验，没有必要永久保存全部中间推理。

为什么“把历史全塞进去”不是稳妥方案

**长上下文窗口只是记忆载体，不等于有效记忆。**模型能接收 128K、200K 甚至更多 token，只能说明输入容量提高了，不能保证每一段历史都会被同等准确地利用。

固定全量历史至少会带来四类问题。

第一类问题是成本。假设一个 Agent 每轮都携带 30K token 历史，并连续运行 20 个步骤，仅重复输入的理论规模就可能达到 60 万 token；如果每一步真正有用的信息只有最近工具结果和少数任务约束，那么大部分输入预算都消耗在重复内容上。

第二类问题是延迟。上下文越长，预填充阶段需要处理的 token 越多；即使底层推理服务做了前缀缓存，检索、重排、序列化和跨组件传输也仍会产生额外开销。对于需要在网页、终端和数据库之间连续行动的 Agent，单步多出几百毫秒，累积十几步后就会明显影响体验。

第三类问题是注意力稀释。旧计划、失败尝试、过期工具结果和重复摘要会争夺模型注意力，Agent 可能继续引用已经失效的页面状态，或者把上一轮参数错误带进下一轮调用。更多上下文有时不是更多证据，而是更多互相冲突的证词。

第四类问题是安全边界扩大。历史网页中的提示注入、用户曾经输入的敏感字段，以及未经验证的工具输出，都可能随着上下文反复传播。记忆系统如果只会写入、不会降权和删除，就会把一次性的脏数据变成长期风险。

动态方法与主流记忆方案有什么不同

**固定窗口、摘要、检索和 HMM 动态策略解决的是不同层次的问题。**前三者主要回答“内容怎么存、怎么缩、怎么找”，而动态策略进一步回答“当前阶段应该启用哪一种记忆，以及给它多少预算”。

| 方案 | 核心规则 | 计算与存储成本 | 主要优点 | 主要缺点 | 适合场景 | |---|---|---:|---|---|---| | 全量历史 | 每轮携带全部轨迹 | 随轮次持续增长 | 实现最简单，可追溯性强 | 成本高、噪声多，容易超过窗口 | 短流程、调试环境 | | 固定滑动窗口 | 只保留最近 N 轮或 N 个 token | 成本可预测 | 延迟稳定，工程实现容易 | 可能机械删除早期关键约束 | 简单客服、短对话 | | 递归摘要 | 定期把旧历史压成摘要 | 需要额外生成开销 | 压缩率高，适合长会话 | 摘要错误会不断累积 | 长期对话、会议记录 | | 向量或图检索 | 按当前查询召回相关片段 | 增加索引与检索成本 | 可扩展到大量外部记忆 | 相似不等于有用，依赖切分与重排 | 知识问答、用户档案 | | HMM 动态策略 | 根据序列状态调整记忆策略 | 增加状态推断与策略维护成本 | 能随任务阶段改变预算 | 状态设计、训练数据和评估更复杂 | 长流程、多工具 Agent | | 混合分层方案 | 工作区、摘要、检索与策略联合 | 工程复杂度最高 | 兼顾速度、容量和长期一致性 | 调试困难，需完整可观测性 | 编程 Agent、企业流程 Agent |

**HMM 的价值在于它为动态策略提供了一个成本较低、可解释性较强的控制器。**与直接再调用一次大模型决定“该记住什么”相比，概率序列模型更容易观察状态转移，也更容易给出确定的预算边界；与写死的条件规则相比，它又能利用连续轨迹，而不是只根据单个关键词做判断。

不过，HMM 并不会自动理解所有复杂任务。真实 Agent 的状态并不总满足一阶马尔可夫假设，一个编程 Agent 可能同时处于“修复测试”“等待依赖安装”和“重新理解需求”三个过程；多 Agent 系统里，不同角色还拥有彼此不完全同步的局部状态。因此，这套方法更适合作为记忆调度层，而不是取代规划器、检索器或大模型推理本身。

Agent 需要的不是一种记忆，而是四种记忆

**工作记忆是当前任务中直接放进模型上下文、可立即读取的信息。**它包括用户当前要求、最近几步操作、临时计划和最新工具输出，特点是访问快，但受上下文窗口和输入成本限制。

**语义记忆是经过抽象后相对稳定的事实与概念。**用户偏好、企业规则、项目结构和产品知识都属于这一层，它们通常存放在文档库、数据库、向量索引或知识图谱中。

**情景记忆是对过去具体事件和任务轨迹的记录。**例如，Agent 上周如何解决某个部署故障、哪一次工具调用失败，以及当时使用了什么绕行方案，都属于可复盘的经历。

**程序性记忆是可以重复执行的方法、技能和操作流程。**重置密码、发布版本、生成周报或排查服务异常等步骤，往往应被整理成稳定流程，而不是每次从原始聊天记录中重新推导。

| 记忆类型 | 保存内容 | 生命周期 | 典型载体 | 动态管理重点 | |---|---|---|---|---| | 工作记忆 | 当前输入、计划、最近工具结果 | 秒到小时 | 上下文窗口、状态对象 | 控制 token 预算，及时淘汰过期状态 | | 语义记忆 | 事实、规则、用户偏好 | 天到长期 | 数据库、向量库、知识图谱 | 去重、版本管理、冲突处理 | | 情景记忆 | 任务轨迹、成功与失败案例 | 任务后到长期 | 日志、轨迹库、事件存储 | 提炼经验，避免原始日志无限增长 | | 程序性记忆 | 技能、SOP、工具使用方式 | 中长期 | 工作流、技能库、模型参数 | 验证适用条件，防止流程过时 |

**不是每个 Agent 都需要四种记忆全部上线。**一个只负责路由请求的 Agent，可能只需要工作记忆；一个重置密码的客服 Agent，需要工作记忆和程序性记忆；编程 Agent 则往往同时依赖代码事实、历史修复案例、当前终端状态和可复用操作技能。

这也解释了 IBM 研究问题的现实意义：Agent 需要多少记忆，没有一个统一的 token 数字。真正可回答的问题应该是，在某个任务阶段、某种错误代价和某个延迟预算下，哪一类记忆需要保留多少，以及哪一类内容可以安全遗忘。

开发者应该怎么把动态记忆做进系统

**第一步是先建立基线，再引入学习型策略。**如果现有 Agent 连固定窗口、摘要和检索命中率都没有可观测性，直接加 HMM 只会多出一个无法解释的组件。

开发团队至少应记录以下数据：

• 每一步输入、输出和缓存命中的 token 数；
• 检索候选数量、最终注入数量和实际被引用的记忆；
• 工具调用次数、错误率、重试次数与任务完成率；
• 首 token 延迟、单步延迟和完整任务耗时；
• 被删除、摘要、归档和重新召回的内容；
• 记忆中敏感数据、过期数据和冲突事实的比例。

**第二步是给工作记忆设置硬预算。**以 32K token 的可用上下文为例，如果系统提示、工具定义和输出预留合计占 10K token，那么历史与检索内容最多只能使用约 22K token；这比“模型支持 32K，所以历史可以放 32K”更符合真实部署条件。

**第三步是按内容价值而不是时间远近淘汰。**用户最早提出的合规约束可能比最近一次寒暄更重要，已经执行完成的五段终端日志则可能只需要保留退出码和结论。一个实用的评分函数通常要同时考虑相关性、时效性、可信度、任务依赖和重新获取成本。

**第四步是把事实、轨迹和技能分开存储。**事实需要版本和来源，轨迹需要时间顺序，技能需要适用条件和成功率；如果把三者全部切成文本块扔进同一个向量索引，检索结果很容易混在一起。

**第五步是为记忆策略设置回退路径。**当状态推断置信度不足、任务进入异常分支或连续工具调用失败时，系统可以临时扩大工作窗口、恢复原始轨迹，或者请求用户确认，而不是继续基于错误摘要执行。

评估动态记忆，不能只看问答准确率

**动态记忆的评估目标应该是质量、成本和稳定性的联合最优。**如果一种方法把输入 token 减少 50%，却让关键任务成功率下降 10 个百分点，它未必比固定窗口更实用；反过来，如果成功率只提高 1 个百分点，却让每个任务多调用数次模型，商业价值也需要重新计算。

比较不同策略时，建议至少固定同一个基础模型、工具集合、任务集和最大步骤数，并同时报告以下指标：

| 指标 | 回答的问题 | |---|---| | 任务完成率 | Agent 最终是否把事情做成 | | 平均输入 token | 记忆策略实际节省了多少上下文 | | 完整任务延迟 | 状态推断、摘要和检索是否拖慢流程 | | 关键事实保留率 | 早期约束是否在后期仍可正确使用 | | 过期信息引用率 | Agent 是否继续使用失效状态 | | 工具重试次数 | 记忆丢失是否导致重复探索 | | 恢复能力 | 摘要或状态判断错误后能否回退 |

**IBM 的工作现阶段更像一个值得验证的研究方向，而不是已经给出万能参数的商业产品。**它没有消除记忆系统的工程复杂度，也不能证明所有 Agent 都应该部署 HMM；它真正改变的是问题的提法：开发者不该再问“窗口能塞多少”，而应该问“下一步决策真正需要哪些历史”。

这项研究的实际判断

**动态记忆管理很可能成为长流程 Agent 的基础设施，但不会取代检索、摘要和结构化状态。**HMM 这类控制器最合理的位置，是在多个记忆组件上方做调度：短任务使用小窗口，知识任务扩大语义检索，异常恢复重新加载情景轨迹，稳定流程优先调用程序性记忆。

**HMM 的优势是轻量、可解释和适合序列状态，短板则是状态表达能力有限。**对于阶段清晰的客服、审批、运维和数据分析流程，它比纯规则更灵活，也比再调用一个大模型更容易控制成本；对于开放式研究、复杂编程和多 Agent 协作，单一隐藏状态可能不足以表达并行任务和长期依赖。

**真正成熟的 Agent 记忆系统应该同时具备写入、压缩、检索、更新、遗忘和审计能力。**今天不少产品只实现了“把对话存下来”和“按相似度找回来”，这离记忆管理仍有明显距离。IBM 的研究提醒开发者，遗忘不是系统缺陷，而是一项必须显式设计的能力。

截至 2026 年 8 月 18 日，Agent 行业已经不再缺更大的上下文窗口，真正稀缺的是能判断信息价值的记忆策略。Agent 的下一轮能力提升，未必来自记住更多，而可能来自更准确地知道什么时候应该忘记。

参考来源

• IBM Research：How Much Memory Does Your Agent Actually Need? —— IBM 关于 ALTK Evolve HMM 与动态 Agent 记忆管理的官方技术文章。
• AgentGuide：Agent Memory 核心论文整理 —— 汇总外部记忆、工具化记忆、参数记忆与相关研究脉络。
• AI Agent Memory 记忆机制综述 —— 介绍 Agent 记忆类型、评估方式和典型应用场景。