你的 Agent 到底需要多少记忆？
在上一篇文章中，我们对比了ALTK-Evolve与ACE，结果表明：如何向 Agent 提供自我蒸馏出的指导原则——是按任务检索少量内容，还是一次性注入全部内容——会同时影响准确率和成本。本文进一步追问一个更基础的问题：到底应该给它多少？
为 Agent 配备智能体记忆，听起来似乎很简单：从过去的工作中提炼经验，将其重新放回上下文，经验越多，性能应该越好。但事实并不总是如此。当我们把评测扩展到八个模型——从 30B 的稠密模型到顶尖的闭源系统——有一个发现格外突出：
智能体记忆不是一个打开开关就能生效的功能，而是需要根据模型能力调整用量。
TL;DR
ALTK-Evolve 能让 Agent 从自身过去的轨迹中学习：提炼可复用的指导原则，并在推理时重新注入，无需更新模型权重，也无需人工标注。
合适的用量因模型层级而异：能力强且仍有提升空间的模型适合使用完整的指导原则集合；较弱的模型使用精简核心内容，再结合按任务检索，效果最好；已经达到饱和的模型则几乎看不到可测量的收益。
精心筛选的检索方案既可能是最准确的，也是成本最低的：gpt-oss-120b 仅增加 5% 的 token 消耗，任务完成率就提升了 16.1 个百分点；而 Prompt caching 还能让生产环境中使用完整指导原则集合的成本保持在可接受范围内。
核心洞察：用量取决于模型能力
并非所有模型都能从相同规模的记忆中受益。在覆盖不同能力区间的八个模型中，我们反复观察到三种模式：
能力强且仍有提升空间的模型适合使用完整的指导原则集合——包括每一条指导原则，以及针对罕见边界情况的经验。它们有足够的能力吸收并运用这些内容。DeepSeek-V3.2（671B MoE）在获得完整的自挖掘指导原则集合后，任务完成率提升了9.5 个百分点。
较小或能力较弱的模型容易被过于庞大的指导集淹没。 对这类模型，最好使用一套精简且高置信度的核心指导，再针对每项任务检索少量相关指导。gpt-oss-120b（117B MoE）采用这种选择性方案后提升了 16.1 个百分点；相比之下，使用完整指导集的提升更小，Token 消耗却高出约 50%。
已经接近饱和的模型则看不到可测量的收益。 我们将这种情况称为“饱和模式”——这个名称描述的是观察结果，并不代表已经证明了具体原因。可能是模型在这些任务上的表现本就接近上限，也可能是指导没有覆盖它剩余的失误，或者模型没有有效利用这些指导。在我们的实验中，GLM-5（745B MoE）就属于这一类。
决定模型属于哪种模式的，并不只是参数规模。 基准测试的提升空间、上下文窗口大小、架构、指导质量和任务分布，似乎都会影响模型最终落入哪种模式；如何区分这些因素，仍有待进一步研究。但实践结论无论如何都成立：模型需要多少记忆，取决于模型本身，而且这个量可以校准。
学习发生在模型之外，而不是模型内部
这里的“记忆”并不是重放过去的对话记录，而是一套指导集——从智能体此前的运行轨迹中提炼出的有效策略、需要避免的错误和边界情况。整个流程并不复杂：
智能体尝试完成任务，并生成运行轨迹。
ALTK-Evolve 从成功和失败的运行中提取行为指导。
将这些指导整合成可复用的指导集。
推理时，向智能体提供完整指导集，或从中筛选出与当前任务相关的部分。
整个过程不会更新模型权重。学习循环改变的是智能体能够获得的指导，而不是底层模型本身——这正是它成本低、且能跨我们测试的八个模型移植的原因。
全系列模型的实验结果
我们在 AppWorld 上进行了评测：涵盖 9 个模拟应用（包括日历、消息、支付等）的 585 项多步骤任务（168 项 test_normal + 417 项 test_challenge）。任务采用两种方式评分：一是智能体是否完整完成每项任务（TGC — Task Goal Completion，任务目标完成率）；二是某个场景的所有变体是否全部通过（SGC — Scenario Goal Completion，场景目标完成率），后者是更严格的“全有或全无”标准。完整定义见附录。
我们比较的三种配置
记忆研究中最容易令人困惑的地方，是上下文窗口里究竟放了什么。因此，我们先明确三种配置。
两种记忆配置都来自同一套指南：通过上述流程，仅使用 AppWorld 的训练集数据提炼一次。两者的区别只在于这套指南如何注入上下文——完整指南集会在每一步注入全部指南，而精选检索只提供其中经过筛选的部分。指南的生成方式完全相同，构建过程中也不会使用测试集数据。
| 配置 | 智能体上下文中的内容 |
|---|---|
| 基线 | 不使用记忆，即开箱即用的智能体。 |
| 完整指南集 | 每一步 ReAct 推理都注入所有提炼出的指南。 |
| 精选检索 | 从同一套指南中选取一组固定的高置信度核心指南，再为每项任务检索少量相关指南（由固定部分和可变部分组成）。 |
模型能够提炼出的指南数量取决于自身能力。因此，我们按策略——“完整指南集”与“精选检索”——来报告配置，而不直接比较指南数量，因为不同模型之间的数量并不具备可比性。
三种模式，一图看懂
以下是八模型测试中的代表性模型，指标为它们在 test_normal 上的任务完成率（TGC）：
图 1：三种典型模式下的代表性模型。柱状图展示了各模型在 AppWorld test_normal 上，基线配置与最佳记忆配置的 TGC；横轴从 40% 起，以便更清楚地呈现差异。仅看 TGC 会低估 SGC 的提升幅度——详见下表中的 SGC 列。
图中展示 TGC 以保持可读性；下表进一步加入了更严格的 SGC 指标，其提升通常更为明显：
| 模型 | 模式 | 基线 TGC / SGC | 最佳记忆配置 TGC / SGC | 最佳配置 | Δ TGC | Δ SGC |
|---|---|---|---|---|---|---|
| gpt-oss-120b（117B MoE） | 较弱 / 选择性受益 | 39.9 / 21.4 | 56.0 / 37.5 | 精选检索 | +16.1 | +16.1 |
| DeepSeek-V3.2（671B MoE） | 较强，仍有提升空间 | 79.8 / 64.3 | 89.3 / 80.4 | 完整指南集 | +9.5 | +16.1 |
| Claude Opus 4.6 | 较强，仍有提升空间 | 90.5 / 87.5 | 94.6 / 94.6 | 完整指南集 | +4.1 | +7.1 |
| GPT-5.5 | 较强（接近上限） | 92.3 / 82.1 | 95.2 / 89.3 | 完整指南集 | +2.9 | +7.2 |
| GLM-5（745B MoE） | 已趋于饱和 | 87.5 / 80.4 | 87.5 / 80.4 | 完整指南集 | 0.0 | 0.0 |
从 SGC 一列可以看出，这一更严格的指标通常比 TGC 变化更大——DeepSeek 的 SGC 提升了 +16.1 个百分点，而 TGC 仅提升 +9.5 个百分点。这是因为高质量指南尤其有助于智能体通过某个场景的所有变体，而不只是取得平均意义上的成功。即使模型已经接近能力上限，这种效果也不会消失：GPT-5.5 和 Opus 在 TGC 上都已接近上限，但 SGC 仍分别提升了 +7.2 和 +7.1 个百分点。只要模型还存在可针对的失败模式，记忆就仍然有价值。
成本最低的记忆策略，也可能是效果最好的策略
一个实际问题是：注入完整指南集会增加每一步 ReAct 的输入开销，因为每轮都要重新发送这些指南。我们的观察结果如下：
| 模型 | 配置 | 每个任务的 Token 数（基线） | 每个任务的 Token 数（+ 记忆） | 额外开销 |
|---|---|---|---|---|
| DeepSeek-V3.2 | 完整指南集 | 148K | 263K | +78% |
| gpt-oss-120b | 完整指南集 | 110K | 166K | +51% |
| gpt-oss-120b | 精选检索 | 110K | 116K | +5% |
表 1. 每项任务的平均 token 使用量，汇总了 Agent 各步骤的消耗，并以无记忆基线作为对照。
这里有两点值得注意：
精选检索能将成本控制在接近基线的水平。 对于较弱的模型，精选检索在准确率上占优，成本上也同样更低——可谓两全其美（gpt-oss-120b 的 TGC 提升了 +16.1 个百分点，而 token 仅增加 5%）。在这里，性能提升并不需要更高的推理成本。
Memory 不会让推理循环失控。 DeepSeek 使用 Memory 时执行的 ReAct 步数与不使用时基本相同（平均约 18–19 步），因此新增成本主要来自输入 token 增多，而不是轨迹变长。
在生产环境中，真正能显著提升效率的是提示词缓存：指南集中的静态部分在各步骤之间保持不变，可以缓存，从而大幅降低实际成本。针对缓存设计提示词——保持共享的指南集前缀稳定，使其能够持续命中缓存——值得专门投入工程工作。我们还推测，上下文窗口大小也会产生影响：窗口更大的模型可能更能有效吸收完整指南集，而上下文较小的模型则更适合使用检索，以控制注入内容的规模。不过，我们尚未开展能够单独验证这一因素的受控实验。
Memory 应该经过校准，而不是一味累积
这里的关键并不是把 Agent 学到的一切都交给它，而是提供它真正能够用上的经验。
对于较弱的模型，应采用精简核心内容，再加上少量特定任务的经验——而且恰好也是成本最低的方案。
对于仍有能力余量的强模型，可以保留完整指南集，并通过提示词缓存控制生产环境中的成本。
对于已经饱和的模型，在进一步了解其剩余失败模式之前，不应再额外增加上下文。
总体来看，这些收益确实存在：它们是自动获得的，不会引入数据泄漏，也不需要人工标注——但前提是 Memory 的“剂量”要与模型相匹配。
下一步
这只是起点，而不是终点：
训练得到的选择器。 目前的检索系统会根据余弦相似度为指南排序，但我们已经证明，相似度并不能完美预测哪些指南真正有助于完成特定任务。下一步自然是利用任务结果信号训练一个选择器。
面向能力极弱模型的记忆。 当模型能力低于最低基线时，自蒸馏缺乏足够信号。如何为这类模型构建由教师模型蒸馏得到的记忆，是我们正在探索的另一项课题。
不止 AppWorld。 这些结果目前只在 AppWorld 上得到验证——这是一个严谨的多步骤基准，但毕竟只有一个。我们正在推进更广泛的智能体基准测试和真实场景部署。
单独考察上下文窗口。 如上所述，我们希望开展受控实验，将上下文窗口大小的影响与模型本身的能力区分开来。
试用 ALTK-Evolve 库——其中包含本文使用的提取、整合和检索流程——或阅读完整技术报告，了解完整方法和消融实验。
附录：理解评测指标
AppWorld 任务采用两个指标评分，均以百分比表示（越高越好）：
TGC——任务目标完成率（Task Goal Completion）。 指智能体完整且正确完成的单个任务占比。这是最直观的“任务到底完成了吗”指标。
SGC——场景目标完成率（Scenario Goal Completion）。 这是一个更严格的“全有或全无”指标。每个场景包含同一任务的多个变体（请求相同，但数据、措辞或边界条件不同）。只有智能体成功完成所有变体，该场景才算通过。它衡量的是可靠性——如果智能体大多数时候都能完成任务，却在其中一个变体上失败，那么它在 TGC 上会得分，但在 SGC 上不会。