智能体记忆不是越多越好：IBM Research 八款模型实测给出剂量表

Hugging Face 博客上一篇来自 IBM Research 的新研究，把"智能体该不该加记忆"这件事拆得比较细。结论不是"加"，也不是"不加"，而是"按模型能力配剂量"。

过去一年，智能体框架普遍把记忆当作默认组件——能塞就塞，能存就存。但越来越多团队发现，给小模型塞太多上下文，反而会让推理跑偏、成本飙升。这篇研究相当于给这一现象补了一份系统化的实验数据。

核心发现

研究者把"记忆"抽象成从历史轨迹中蒸馏出的指南集，在推理时直接注入提示。测试覆盖了八款模型，跨度从轻量级到超大规模。结论是：记忆存在明显的剂量效应——剂量合适时效果递增，过量时收益停滞甚至反向。

这个结果对工程实践是个提醒：记忆模块不是开关，而是一个需要调参的旋钮。团队不能再用"加还是不加"的二选一思维来设计智能体架构。

强模型与弱模型的分歧

研究区分了两类策略。一类是"全量注入"，把完整指南集一次性塞进上下文；另一类是"精选检索"，只注入与当前任务最相关的几条。

对强模型而言，全量注入更划算。DeepSeek-V3.2（671B MoE）的任务完成率因此提升 9.5 个百分点。

而对弱模型来说，精选检索才是正确选择。gpt-oss-120b（117B MoE）用这种方式提升了 16.1 个百分点，同时 token 消耗只增加约 5%。也就是说，弱模型不仅能省成本，还能跑出更猛的收益。

对开发者的实际影响

这项研究的最大价值在于方法门槛低。不需要更新模型权重，不需要人工标注数据，团队只需要把智能体过往的运行轨迹收集起来，离线蒸馏成一套指南文本。

部署时，额外引入的只是 prompt 工程，而不是一整套新基础设施。这对中小团队和个人开发者都比较友好。

另一个判断是：选型阶段就要把"目标模型能消化多少记忆"纳入考量，而不是等记忆模块上线后才发现问题。先决定模型能力边界，再决定记忆注入策略，顺序很关键。

中文用户关注与后续观察

榜单上出现的模型，对中文社区来说不是陌生面孔。DeepSeek-V3.2 是国内团队主导的开源 MoE 模型，研究里直接给出了它在"全量注入"下的表现，这对正在做中文智能体的研究者是个具体参考。

同时，"小模型 + 精选检索"的组合验证，也为成本受限的本地化部署提供了一条务实路径——不必都去跑 671B 的庞然大物。

接下来值得看几件事：

• 指南蒸馏流程是否会被 LangChain、LlamaIndex 这类框架封装成开箱即用能力

• 研究是否扩展到多轮对话、跨会话记忆等更复杂场景

• 中文长尾任务上，"精选检索"的召回质量仍待第三方验证

这篇研究给出的不是"记忆非用不可"的命令，而是一份剂量表。对于正在搭建智能体的人来说，"先量后用"可能比"一上来就堆上下文"更省事。