Hugging Face：少 token 也能跑 ACE 推理

给一个 LLM Agent 一个真实的多步骤任务——分摊账单、找一首歌、跨九个模拟应用协调订单——当它失败时，通常不是因为知识储备不足。它 API 分页处理错误、找错了人、或者在没有被要求时返回一个值。模型知道这些 API；它没有内化的是如何可靠地使用它们。这一点可以从 Agent 自己的历史中学习。

两个最新的系统对同一种 Agent 做到了这一点：ACE（Agentic Context Engineering）和我们的 ALTK-Evolve（在此介绍）。两者都是 Agent 记忆的一种形式——将 Agent 过去的轨迹转化为可重用的经验，并在推理时反馈回来，无需权重更新，无需人工标注。它们在困难的部分甚至达成一致。分歧在于交付方式。

需要说明的是，这两个系统的命名方式不同：我们将 Agent 学到的原始内容称为经验（lesson）。ACE 将其经验组织成一个全面的、不断演进的 playbook；我们将我们的经验整合成可单独检索的指南。同样的经验，两种不同的容器。

两个系统都拒绝压缩

ACE 精确地命名了失败模式：简洁偏见（优化坍缩为简短、通用的指令）和上下文坍缩（模型被要求每步重写其整个上下文时将细节摘要掉了）。它的答案是保持一份丰富的、逐条列出的 playbook，每条都有帮助/有害的计数器，让模型在读取时提炼相关性。

我们从另一个方向得出相同的结论。每条独立的指南都保留一个支持计数——有多少个独立的事件产生了它——我们永远不会将存储库总结为少数几条规则。五次不同任务发现的经验与只出现一次的不同，两者都值得保留。

所以在这个核心问题——是否应该将 Agent 辛苦学到的经验压缩成整洁的总结？——ACE 和 ALTK-Evolve 给出了相同的答案：不要。计数它们，而不是压缩它们。ACE 的每条计数器和我们的支持计数是同一想法的两种表达。

两个方面的差异：记忆如何构建，以及如何交付——而正是交付差异体现在 token 账单上。

合并（存储如何构建）

ACE 通过 Generator → Reflector → Curator 循环来扩展一个 playbook，应用增量 delta 更新并通过 embedding 去重。我们将近乎相同的经验聚类并在集群内合并，保留支持计数——当多个经验合并时，幸存者继承它们 combined count，因此存储缩小而不会丢失每条指南背后有多少经验的支持 record。我们还提取类型化的指南——strategy、recovery 和 optimization——并带有因果归因和到源轨迹的来源追溯，粒度在子任务级别，这样在一个应用上学到的经验可以转移到另一个应用。

交付（推理时什么到达模型）

这是驱动数字的地方。ACE 在每一步都注入全面的 playbook，无论模型或任务如何都是一样的方式。我们将交付视为一个旋钮，而不是常量：一小部分固定的高支持指南，通过为手头任务选择的少数指南来扩展（cosine 或 LLM guided，priority-weighted）——或者，当模型有余裕使用时，提供完整的合并集。同样的经验对两个 Agent 都可用；区别在于 ACE 总是发送所有内容，而我们只发送给定模型实际能使用的数量。

在 AppWorld 上，使用相同的基础 ReAct agent，在内部运行两个系统：

在强模型上，我们在两个指标上都更好，约为 ACE 推理成本的 40%。在弱模型上我们以 56.0 比 54.8 略微领先——足够接近以至于我们称之为准确度持平（我们的一次重复运行落在 54.8，几乎与 ACE 完全匹配，在这 benchmark 的运行间噪声范围内）——约为七分之一的成本。

公平地说成本：ACE 自身的效率故事是关于廉价地构建其上下文。我们的在不同的轴上——服务它。每任务检索少数指南而不是每步注入整个 playbook 是 token 消耗的地方，这是上述交付差异的直接后果。

准确性从何而来？

按难度的细分讲述了两个不同的故事：

图 1。按难度划分的记忆后任务目标完成度，我们 vs ACE。在 DeepSeek-V3.2（右）上，我们在 Easy、Hard 和 Overall 上获胜；ACE 仅在 Medium 上略占优势。在 gpt-oss-120b（左）上 ACE 在 easy 和 medium 上领先，但按任务选择赢得了 hard 任务——以及总分。每个系统都从自己的无记忆基线改进（见下面的方法说明中的按难度参考表）。

两个模型讲述不同的故事。在 gpt-oss-120b 上，ACE 的完整 playbook 在 Easy 和 Medium 上有优势——有足够多的任务通过通用指令遵循来解决，以至于全面的 prompt 帮助大于干扰。但在 Hard 任务上，模型必须选择正确的经验而不是浏览所有经验，策展检索胜出——而这层决定了总分。在 DeepSeek-V3.2 上故事反转：更强的模型能够充分吸收 ACE 的完整 playbook，在 Medium 上略微领先，但我们领先 Easy、Hard 和 Overall——有更多剩余容量，更多经验（以我们的方式交付）持续帮助而不是相互挤占。

我们为每个模型提供其最佳配置——强模型使用完整合并集，弱模型使用选择性检索，因为大上下文会压垮弱模型而不是帮助它。（精确注入多少，以及它如何在能力谱上扩展，是下一篇文章的主题。）

相同的经验，不同的交付

两个系统都拒绝将 Agent 辛苦获得的经验压缩成整洁的总结——在这一点上，我们一致。区别在于交付是固定的还是可调的：ACE 无论如何每步都发送整个 playbook；我们只发送给定模型实际能使用的指南集。这种校准正是上面数字的来源——以 ACE 推理成本的一小部分获得相同或更好的准确度——而在弱模型上，这是帮助性指导和干扰性指导之间的区别。

尝试 ALTK-Evolve 库——其中包含这里使用的提取、合并和检索流程——或阅读完整的技术报告以了解完整方法和消融实验。

链接的 artifacts / 参考

Earlier post: ALTK-Evolve introduction — link

ACE (Agentic Context Engineering) — link

AppWorld benchmark — link

Full technical report — link

AppWorld test_normal，168 个任务。一个 ReAct 代码 agent（每步写 Python；环境返回输出）。TGC = Task Goal Completion；SGC = Scenario Goal Completion，需要每个场景的每个变体都通过。记忆仅从 train/dev 挖掘；结果是单次运行（pass@1），这是该 benchmark 的标准。

ACE 数字是我们自己对 ACE agent 的运行，在相同的 AppWorld splits 和与 ALTK-Evolve 相同的基础模型（DeepSeek-V3.2 和 gpt-oss-120b）上进行内部评估。ACE 论文报告了不同的基础模型（DeepSeek-V3.1），所以我们自己运行可以控制模型和测试工具的比较。两个系统是相同的 ReAct agent，仅在 prompt template 上不同——这就是为什么两个无记忆基线不同（72.0 vs 79.8 TGC）；我们不依赖于那个基线差距来作比较，只依赖于 prompt 调整无法触及的主张：以更少的 token 获得相同或更好的准确度。

DeepSeek-V3.2 — test_normal (168 tasks):

gpt-oss-120b — test_normal:

gpt-oss-120b — 按难度（TGC）:

DeepSeek-V3.2 — 按难度（基线 → +记忆）：由于上述 prompt template 差异，两个系统从不同的无记忆基线开始（总体 79.8 vs 72.0 TGC）。

更多来自此作者

Model Routing Is Simple. Until It Isn't.

ScarfBench: Benchmarking AI Agents for Enterprise Java Framework Migration