Thinking of ACE? We Can Do It with Fewer Tokens
Thinking of ACE? We Can Do It with Fewer Tokens
考虑使用 ACE？我们可以用更少的 Token 实现
ALTK-Evolve and ACE both let an agent learn from its own trajectories. The difference is what they do with what they learn — and that decides the token bill. ALTK-Evolve 和 ACE 都允许智能体从自身的轨迹中学习。两者的区别在于如何处理所学到的知识——而这决定了 Token 的消耗成本。
Give an LLM agent a realistic multi-step task — split a bill, find a song, reconcile an order across nine simulated apps — and when it fails, it usually isn’t for lack of knowledge. It mis-paginates an API, resolves the wrong person, or returns a value when none was asked for. The model knows the APIs; what it hasn’t internalized is how to use them reliably. That’s learnable from the agent’s own history. 给一个 LLM 智能体分配一个现实的多步骤任务——比如分摊账单、查找歌曲或在九个模拟应用中核对订单——当它失败时，通常不是因为缺乏知识。它可能是分页 API 出错、解析了错误的人，或者在不需要时返回了值。模型了解这些 API，但它尚未内化如何可靠地使用它们。而这正是可以从智能体自身历史中学习到的。
Two recent systems do exactly this, on the same kind of agent: ACE (Agentic Context Engineering) and our ALTK-Evolve (introduced here). Both are a form of agentic memory — turning an agent’s past trajectories into reusable lessons and feeding them back at inference time, no weight updates, no human labels. They even agree on the hard part. Where they part ways is delivery. 最近有两个系统在同类智能体上实现了这一点：ACE (Agentic Context Engineering) 和我们的 ALTK-Evolve（在此介绍）。两者都是一种智能体记忆形式——将智能体过去的轨迹转化为可重用的经验教训，并在推理时反馈给模型，无需更新权重，也无需人工标注。它们甚至在难点上达成了共识，但在交付方式上分道扬镳。
A note on words, because the two systems name things differently: we’ll call the raw thing an agent learns a lesson. ACE organizes its lessons into one comprehensive, evolving playbook; we consolidate ours into individually retrievable guidelines. Same lessons, two containers. 关于术语的说明，因为这两个系统对事物的命名不同：我们将智能体学习到的原始内容称为“经验教训”（lesson）。ACE 将其经验教训组织成一本全面且不断演进的“剧本”（playbook）；我们将我们的内容整合为可单独检索的“指南”（guidelines）。同样的经验教训，两种容器。
What we agree on
我们的共识
Both systems refuse to compress. ACE names the failure modes precisely: brevity bias — optimization collapsing toward short, generic instructions — and context collapse — a model asked to rewrite its whole context each step summarizing the detail away. Its answer is to keep a rich, itemized playbook, with a helpful/harmful counter on every bullet, and let the model distill relevance at read time. 两个系统都拒绝压缩。ACE 精确地指出了失败模式：简洁偏见（brevity bias）——即优化过程趋向于简短、通用的指令；以及上下文崩溃（context collapse）——即模型在每一步被要求重写整个上下文时，会丢失细节。它的解决方案是保留一本丰富、逐条列出的剧本，并在每个要点上设置有用/有害计数器，让模型在读取时提取相关信息。
We reach the same conclusion from the other direction. Every distinct guideline keeps a support count — how many independent episodes produced it — and we never summarize the store down to a handful of rules. A lesson five different tasks discovered is a different object from one that appeared once, and both are worth keeping. So on the core question — should you compress an agent’s hard-won lessons into a tidy summary? — ACE and ALTK-Evolve give the same answer: no. Count them, don’t collapse them. ACE’s per-bullet counters and our support counts are two spellings of the same idea. 我们从另一个方向得出了相同的结论。每一条独立的指南都保留一个支持计数（即有多少次独立任务产生了该指南），我们从不将存储内容总结为少数几条规则。在五个不同任务中发现的经验教训与仅出现一次的经验教训是不同的对象，两者都值得保留。因此，关于核心问题——是否应该将智能体辛苦获得的经验教训压缩成整洁的摘要？——ACE 和 ALTK-Evolve 给出了相同的答案：不。要统计它们，不要压缩它们。ACE 的逐条计数器和我们的支持计数只是同一理念的两种表达方式。
Where we differ
我们的分歧
Two places: how the memory is built, and how it’s delivered — and it’s the delivery difference that shows up in the token bill. 主要在两个方面：记忆如何构建，以及如何交付——正是交付方式的差异体现在了 Token 账单上。
Consolidation (how the store is built). ACE grows one playbook through a Generator → Reflector → Curator loop, applying incremental delta updates and de-duplicating by embedding. We cluster near-duplicate lessons and merge within a cluster, support-conserving — when several lessons merge, the survivor inherits their combined count, so the store shrinks without losing the record of how much experience backs each guideline. We also extract typed guidelines — strategy, recovery, and optimization — with causal attribution and provenance back to the source trajectory, and at subtask granularity, so a lesson learned on one app can transfer to another. 整合（存储如何构建）。 ACE 通过“生成器 → 反思器 → 策展人”循环来增长剧本，应用增量更新并通过嵌入（embedding）进行去重。我们将近乎重复的经验教训进行聚类并在簇内合并，同时保持支持计数——当多个经验教训合并时，幸存者继承它们的总计数，因此存储空间缩小了，但没有丢失支持每条指南的经验记录。我们还提取了分类指南（策略、恢复和优化），并带有因果归因和回溯到源轨迹的来源信息，且精确到子任务粒度，因此在一个应用中学到的经验可以迁移到另一个应用。
Delivery (what reaches the model at inference). This is the one that drives the numbers. ACE injects the comprehensive playbook on every step, the same way regardless of model or task. We treat delivery as a dial, not a constant: a small fixed core of high-support guidelines, extended per task with a handful selected for the task at hand (cosine or LLM-guided, priority-weighted) — or, when a model has the headroom to use it, the full consolidated set. The same lessons are available to both agents; the difference is that ACE always sends all of them, and we send however many a given model can actually use. 交付（推理时模型接收的内容）。 这是影响数据指标的关键。ACE 在每一步都注入完整的剧本，无论模型或任务如何，方式都一样。我们将交付视为一个可调节的旋钮，而不是常量：包含一小部分高支持度的核心指南，并根据任务需求扩展（通过余弦相似度或 LLM 引导，按优先级加权）——或者在模型有足够余量时，提供完整的整合集。两个智能体可以使用相同的经验教训；区别在于 ACE 总是发送全部内容，而我们根据给定模型实际能使用的数量进行发送。
Why it matters
为什么这很重要
On AppWorld, with the same base ReAct agent, running both systems in-house: 在 AppWorld 上，使用相同的 ReAct 基础智能体，在内部运行两个系统：
| Model | TGC / SGC | Tokens/task |
|---|---|---|
| DeepSeek-V3.2 ACE | 80.4 / 73.2 | 634K |
| DeepSeek-V3.2 ALTK-Evolve | 89.3 / 80.4 | 263K |
| gpt-oss-120b ACE | 54.8 / 35.7 | 777K |
| gpt-oss-120b ALTK-Evolve | 56.0 / 37.5 | 116K |
On the strong model we’re better on both metrics at ~40% of ACE’s inference cost. On the weak model we edge ACE 56.0 to 54.8 — close enough that we call it a tie on accuracy (a repeat run of ours landed at 54.8, matching ACE almost exactly, which is within this benchmark’s run-to-run noise) — at about one-seventh the cost. A fair word on cost: ACE’s own efficiency story is about building its context cheaply. Ours is on a different axis — serving it. Retrieving a few guidelines per task instead of injecting the whole playbook on every step is where the tokens go, and it’s the direct consequence of the delivery difference above. 在强模型上，我们在两个指标上都表现更好，且推理成本仅为 ACE 的约 40%。在弱模型上，我们以 56.0 对 54.8 微弱领先 ACE——差距小到我们可以称之为准确率持平（我们的重复运行结果为 54.8，几乎与 ACE 完全一致，这在基准测试的运行误差范围内）——而成本仅为 ACE 的约七分之一。关于成本的公允评价：ACE 的效率优势在于低成本构建上下文。我们的优势在于另一个维度——服务上下文。每个任务仅检索少量指南，而不是在每一步注入整个剧本，这才是节省 Token 的关键，也是上述交付方式差异的直接结果。