考虑ACE？我们可以用更少的Token完成

来源：https://huggingface.co/blog/ibm-research/altk-evolve-sldd 返回文章列表 (https://huggingface.co/blog)

• 我们的共识 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#what-we-agree-on)
• 我们的分歧 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#where-we-differ)
• 为什么这很重要 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#why-it-matters)
• 相同的经验，不同的传递方式 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#same-lessons-different-delivery)
• 相关成果/参考文献 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#linked-artifacts–references)
• 方法说明 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#method-notes)- 参考表格 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#reference-tables)

ALTK-Evolve和ACE都让智能体从自身的轨迹中学习。区别在于它们如何利用所学到的内容——而这一点决定了token开销。

给一个LLM智能体布置一个现实的多步骤任务——分摊账单、找一首歌、在九个模拟应用中核对订单——当它失败时，通常不是因为缺乏知识。它可能翻错了API的页码、认错了人，或者在没人要求时返回了一个值。模型认识这些API；它没有内化的是如何可靠地使用它们。这是可以从智能体自身的历史中学到的。

最近的两个系统恰好做到了这一点，并且作用于同一类智能体：ACE (https://arxiv.org/abs/2510.04618)（Agentic Context Engineering，智能体上下文工程）和我们的ALTK-Evolve（在此介绍 (https://huggingface.co/blog/ibm-research/altk-evolve)）。两者都是一种智能体记忆——将智能体过去的轨迹转化为可复用的经验，并在推理时反馈回去，无需更新权重，无需人工标注。它们甚至在难点上也达成了共识。它们分道扬镳的地方在于传递方式。

先说明一下用词，因为两个系统对事物的命名不同：我们把智能体学到的原始内容称为经验。ACE将其经验组织成一份综合性的、持续演化的策略手册；我们则把我们的经验整合为可单独检索的准则。相同的经验，两种容器。

我们的共识

两个系统都拒绝压缩。

ACE精确地指出了失败模式：简洁偏差——优化过程坍缩为简短、通用的指令——以及上下文坍缩——模型被要求每一步都重写整个上下文，从而把细节都概括掉了。它的解决方案是保留一份丰富、逐条列出的策略手册，每个条目都附带有用/有害计数器，并让模型在读取时自行提炼相关性。

我们从另一个方向得出了同样的结论。每一条独立的准则都保留一个支持数——即有多少个独立事件产生了它——而且我们永远不会把记忆库压缩成寥寥几条规则。一个被五个不同任务发现的经验，与一个只出现过一次的经验是不同的对象，两者都值得保留。

所以在核心问题上——是否应该把智能体来之不易的经验压缩成一份简洁的总结？——ACE和ALTK-Evolve给出了相同的答案：**不。统计它们，不要压缩它们。**ACE的逐条计数器和我们的支持数是同一想法的两种写法。

我们的分歧

有两处：记忆如何构建，以及如何传递——而正是传递方式的差异体现在了token开销上。

整合（记忆库如何构建）。ACE通过一个生成器 → 反思器 → 策展器的循环来扩展单一策略手册，应用增量式delta更新，并通过嵌入向量进行去重。我们则对近重复的经验进行聚类，并在聚类内部合并，同时保留支持数——当多条经验合并时，幸存者会继承它们的合并计数，这样记忆库在缩小的同时，不会丢失每条准则背后有多少经验支撑的记录。我们还提取带类型的准则——策略、恢复和优化——并带有因果归因和指向源轨迹的溯源信息，而且是在子任务粒度上，因此从一个应用中学到的经验可以迁移到另一个应用。

传递（推理时什么内容会到达模型）。这是决定数字的那一处。ACE在每一步都注入完整的策略手册，无论模型或任务是什么都一样。我们把传递当作一个旋钮，而不是一个常量：一个由高支持准则组成的固定核心，再按任务额外扩展几条针对当前任务选出的准则（余弦相似度或LLM引导，按优先级加权）——或者，当模型有足够的余量可以使用时，就注入完整的整合集。相同的经验对两个智能体都是可用的；区别在于，ACE总是发送全部内容，而我们发送的是特定模型实际能利用多少。

为什么这很重要

在AppWorld上，使用相同的基座ReAct智能体，我们在内部运行了两个系统：

在强模型上，我们在两个指标上都更好，而且推理成本约为ACE的40%。在弱模型上，我们以56.0对54.8略微超过ACE——差距非常小，我们称之为准确率打平（我们重复运行一次的结果为54.8，与ACE几乎完全一致，处于该基准的逐次运行噪声范围内）——而成本约为七分之一。

关于成本要公平地说一句：ACE自己的效率故事在于廉价地构建其上下文。我们的效率则在另一个维度——提供/服务上下文。按任务检索几条准则，而不是每一步都注入完整的策略手册，这才是token消耗差别的来源，也是上述传递方式差异的直接结果。

准确率来自哪里？按难度划分的结果讲述了两个不同的故事：

image (https://cdn-uploads.huggingface.co/production/uploads/6435a1131860001f144239ea/RlNmW6Vps10XLGW4DuJQh.png)

图1. 加入记忆后按难度划分的任务目标完成率，我们的系统 vs. ACE。在DeepSeek-V3.2上（右），我们在简单、困难、总体上都获胜；ACE仅在中等难度上略胜。在gpt-oss-120b上（左），ACE在简单和中等难度上领先，但按任务选择的方式在困难任务上获胜——并赢下总体。每个系统都相对自身无记忆基线有所提升（见下方方法说明下的按难度参考表格）。

两个模型讲述了不同的故事。在gpt-oss-120b上，ACE的完整策略手册在简单和中等难度上占优——因为这类任务已有足够部分可以通过通用指令遵循来解决，所以全面的提示带来的帮助大于干扰。但在困难任务上，模型必须挑选正确的经验，而不是在全部经验中艰难翻找，精心筛选的检索便脱颖而出——而这一档正是决定总体结果的部分。在DeepSeek-V3.2上，故事反了过来：更强的模型能够很好地消化ACE的完整策略手册，从而在中等难度上略微胜过我们，但我们在简单、困难和总体上都领先——更强的模型有更多余量，因此更多经验（以我们的方式传递）会持续带来帮助，而不会互相排挤。

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

相同的经验，不同的传递方式

两个系统都拒绝把一个智能体来之不易的经验压缩成一份简洁的总结——这一点，我们达成共识。区别在于传递是固定的还是经过校准的：ACE无论什么情况都在每一步发送整个策略手册；我们则发送特定模型实际能利用多少准则。正是这种校准带来了上面那些数字——在只有ACE推理成本一小部分的情况下达到相同或更好的准确率——而在较弱的模型上，它决定了帮助性的指导与碍事的指导之间的差别。

试试ALTK-Evolve (https://github.com/AgentToolkit/altk-evolve)库——其中包含本文使用的提取、整合和检索流程——或阅读完整技术报告 (https://arxiv.org/abs/2603.10600)，了解完整方法和消融实验。

相关成果/参考文献

• **之前的文章：**ALTK-Evolve介绍——链接 (https://huggingface.co/blog/ibm-research/altk-evolve)
• ACE（Agentic Context Engineering）——链接 (https://arxiv.org/abs/2510.04618)
• AppWorld基准——链接 (https://appworld.dev/appworld)
• ALTK-Evolve——链接 (https://github.com/AgentToolkit/altk-evolve)
• 完整技术报告——链接 (https://arxiv.org/abs/2603.10600)

方法说明

AppWorld的test_normal，168个任务。一个ReAct代码智能体（每一步都编写Python；环境返回输出）。TGC = 任务目标完成率；SGC = 场景目标完成率，要求场景的每个变体都通过。记忆仅从训练/开发集中挖掘；结果是单次运行（pass@1），该基准的标准做法。

ACE的数字是我们自己对ACE智能体的运行结果，在内部使用相同的AppWorld划分和与ALTK-Evolve相同的基座模型（DeepSeek-V3.2和gpt-oss-120b）进行评估。ACE论文报告的是不同的基座模型（DeepSeek-V3.1），因此我们自己运行可以保证模型和测试框架在比较中受到控制。两个系统都是同一个ReAct智能体，唯一区别是提示模板——这也是两个无记忆基线不同的原因（TGC分别为72.0和79.8）；我们并不把比较建立在基线差距上，只建立在提示调整无法动摇的主张上：以一小部分的token数实现相同或更好的准确率。

参考表格

DeepSeek-V3.2 — test_normal（168个任务）：

注意：表格中 “10” 是Guidelines for ACE? Actually table says “Guidelines” column: ReAct + ACE 10? In source table: SystemGuidelinesTGCSGCTokens/taskReAct, no memory079.864.3148KReAct + ACE10680.473.2634KReAct + ALTK-Evolve19189.380.4263K. Wait “ACE 106” maybe 106 guidelines? Actually in original table: “ReAct + ACE | 10? No, “ACE 10680.473.2” maybe “10” ? Let’s parse source: “ReAct + ACE10680.473.2634K” It could be “10” then “680.4”? No, “ACE 10 680.4 73.2” weird. Wait source table from prompt:

DeepSeek-V3.2 —test\_normal(168 tasks):

SystemGuidelinesTGCSGCTokens/taskReAct, no memory079.864.3148KReAct + ACE10680.473.2634KReAct + ALTK-Evolve19189.380.4263K

Actually “ReAct + ACE10680.473.2634K” - There’s “ACE” then “10680.4”. Could be “ACE 10” and “680.4”? But from blog article above, they list ACE TGC 80.4, SGC 73.2, tokens 634K. So “10” likely guidelines count? But ACE playbook has many bullets. The column header “Guidelines” for ACE maybe “playbook” count? In original, likely “ACE” with “10” guidelines? In previous blog? Actually given table formatting from markdown: ReAct + ACE10680.473.2634K maybe “ReAct + ACE | 10 | 680.4 | 73.2 | 634K”? Wait “680.4” not valid. So it’s “10” then “680.4”? No, TGC should be 80.4. Maybe “ACE” no guidelines? Let’s inspect the provided content: “SystemGuidelinesTGCSGCTokens/taskReAct, no memory079.864.3148KReAct + ACE10680.473.2634KReAct + ALTK-Evolve19189.380.4263K”. The substring “ACE10680.4” could be “ACE | 10 | 680.4”? Impossible.

Let’s look at the second table for gpt-oss: “ReAct + ACEfull54.835.7777K” So ACE Guidelines column is “full”. For first table, likely “ACE” has “10”? Actually maybe “ACE106” as in “ACE | 10 | 680.4”? Wait if first table says “ReAct + ACE10680.4” maybe it’s “ReAct + ACE | 10 | 680.4” because markdown didn’t have pipes in source? But source has “SystemGuidelinesTGCSGCTokens/task” with no pipes. The blog text is in markdown, but table lines might have been concatenated due to missing pipes? Actually the prompt includes table as plain text without pipes, not formatted. Need reconstruct.

Let’s read the snippet:

“DeepSeek-V3.2 —test\_normal(168 tasks):

SystemGuidelinesTGCSGCTokens/taskReAct, no memory079.864.3148KReAct + ACE10680.473.2634KReAct + ALTK-Evolve19189.380.4263K“

This is likely a markdown table with pipes stripped? It might be:

Alternatively “ACE” has “10” guidelines? But earlier they said in our delivery: full consolidated set for strong model. For DeepSeek, ALTK-Evolve guidelines = 191 (from table). ACE guidelines maybe “10”?? But ACE playbook is comprehensive, likely many bullets. Could be “106” (guidelines) and TGC = 80.4. Yes! “ReAct + ACE10680.473.2634K” could be “ReAct + ACE | 106 | 80.4 | 73.2 | 634K”. The “106” is guidelines count. Then “80.4” TGC. That makes sense: Guidelines 106, TGC 80.4. Because no separator after ACE. So table should be: ReAct + ACE | 106 | 80.4 | 73.2 | 634K. Similarly ALTK-Evolve | 191 | 89.3 | 80.4 | 263K. Good.

The gpt-oss table: “SystemGuidelinesTGCSGCTokens/taskReAct, no memory039.921.4110KReAct + ACEfull54.835.7777KReAct + ALTK-Evolve (selected)~2956.037.5116K” So for gpt-oss, ACE Guidelines = “full”, ALTK = “~29” selected. So our table should preserve that: “full” for ACE, “~29” for ALTK.

We need be accurate. Since original markdown in prompt is mangled, we should reformat as proper table with our best interpretation. But we can also keep similar plain text? However user expects markdown. We’ll render tables with pipes. Need be careful to not introduce data errors. Let’s infer correctly.

First table:

• ReAct, no memory: Guidelines 0, TGC 79.8, SGC 64.3, Tokens/task 148K
• ReAct + ACE: Guidelines 106, TGC 80.4, SGC 73.2, Tokens/task 634K
• ReAct + ALTK-Evolve: Guidelines 191, TGC 89.3, SGC 80.4, Tokens/task 263K

Second:

• ReAct, no memory: Guidelines 0, TGC 39.9, SGC 21.4, Tokens/task 110K
• ReAct + ACE: Guidelines full, TGC 54.8, SGC 35.7, Tokens/task 777K
• ReAct + ALTK-Evolve (selected): Guidelines ~29, TGC 56.0, SGC 37.5, Tokens/task 116K

By-difficulty (TGC) for gpt-oss: Difficulty | Baseline | ACE | ALTK-Evolve Easy 66.7 84.2 82.5 Medium 35.4 60.4 56.2 Hard 19.1 23.8 31.8 Aggregate 39.9 54.8 56.0

DeepSeek by difficulty (baseline → +memory): Tier | ALTK TGC | ALTK SGC | ACE TGC | ACE SGC Overall | 79.8 → 89.3 | 64.3 → 80.4 | 72.0 → 80.4 | 57.1 → 73.2 Easy | 93.0 → 94.7 | 84.2 → 84.2 | 78.9 → 84.2 | 63.2 → 78.9 Medium | 81.2 → 97.9 | 62.5 → 93.8 | 85.4 → 100.0 | 75.0 → 100.0 Hard | 66.7 → 77.8 | 47.6 → 66.7 | 55.6 → 61.9 | 38.1 → 47.6

Need ensure the “Easy” line: “93.0 → 94.7” etc. Source says “84.2 → 84.2” yes. Good.

Let’s incorporate.

Now translate rest. Need preserve links. Ensure “DeepSeek-V3.2” and “gpt-oss-120b” as is.

Let’s also translate “post-memory Task Goal Completion” as “加入记忆后的任务目标完成率”.

In figure caption, adjust.

Need ensure all original links preserved exactly, including anchors. Yes.

Let’s craft final translation with proper markdown tables. Also we need insert line breaks where appropriate.

Let’s output.# 考虑ACE？我们可以用更少的Token完成 来源：https://huggingface.co/blog/ibm-research/altk-evolve-sldd 返回文章列表 (https://huggingface.co/blog)

• 我们的共识 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#what-we-agree-on)
• 我们的分歧 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#where-we-differ)
• 为什么这很重要 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#why-it-matters)
• 相同的经验，不同的传递方式 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#same-lessons-different-delivery)
• 相关成果/参考文献 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#linked-artifacts–references)
• 方法说明 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#method-notes)
• 参考表格 (https://huggingface.co/blog/ibm-research/altk-evolve-sldd#reference-tables)

ALTK-Evolve和ACE都让智能体从自身的轨迹中学习。区别在于它们如何利用所学到的内容——而这一点决定了token开销。

给一个LLM智能体布置一个现实的多步骤任务——分摊账单、找一首歌、在九个模拟应用中核对订单——当它失败时，通常不是因为缺乏知识。它可能翻错了API的页码、认错了人，或者在没人要求时返回了一个值。模型认识这些API；它没有内化的是如何可靠地使用它们。这是可以从智能体自身的历史中学到的。

最近的两个系统恰好做到了这一点，并且作用于同一类智能体：ACE (https://arxiv.org/abs/2510.04618)（Agentic Context Engineering，智能体上下文工程）和我们的ALTK-Evolve（在此介绍 (https://huggingface.co/blog/ibm-research/altk-evolve)）。两者都是一种智能体记忆——将智能体过去的轨迹转化为可复用的经验，并在推理时反馈回去，无需更新权重，无需人工标注。它们甚至在难点上也达成了共识。它们分道扬镳的地方在于传递方式。

先说明一下用词，因为两个系统对事物的命名不同：我们把智能体学到的原始内容称为经验。ACE将其经验组织成一份综合性的、持续演化的策略手册；我们则把我们的经验整合为可单独检索的准则。相同的经验，两种容器。

我们的共识

两个系统都拒绝压缩。

ACE精确地指出了失败模式：简洁偏差——优化过程坍缩为简短、通用的指令——以及上下文坍缩——模型被要求每一步都重写整个上下文，从而把细节都概括掉了。它的解决方案是保留一份丰富、逐条列出的策略手册，每个条目都附带有用/有害计数器，并让模型在读取时自行提炼相关性。

我们从另一个方向得出了同样的结论。每一条独立的准则都保留一个支持数——即有多少个独立事件产生了它——而且我们永远不会把记忆库压缩成寥寥几条规则。一个被五个不同任务发现的经验，与一个只出现过一次的经验是不同的对象，两者都值得保留。

所以在核心问题上——是否应该把智能体来之不易的经验压缩成一份简洁的总结？——ACE和ALTK-Evolve给出了相同的答案：**不。统计它们，不要压缩它们。**ACE的逐条计数器和我们的支持数是同一想法的两种写法。

我们的分歧

有两处：记忆如何构建，以及如何传递——而正是传递方式的差异体现在了token开销上。

整合（记忆库如何构建）。ACE通过一个生成器 → 反思器 → 策展器的循环来扩展单一策略手册，应用增量式delta更新，并通过嵌入向量进行去重。我们则对近重复的经验进行聚类，并在聚类内部合并，同时保留支持数——当多条经验合并时，幸存者会继承它们的合并计数，这样记忆库在缩小的同时，不会丢失每条准则背后有多少经验支撑的记录。我们还提取带类型的准则——策略、恢复和优化——并带有因果归因和指向源轨迹的溯源信息，而且是在子任务粒度上，因此从一个应用中学到的经验可以迁移到另一个应用。

传递（推理时什么内容会到达模型）。这是决定数字的那一处。ACE在每一步都注入完整的策略手册，无论模型或任务是什么都一样。我们把传递当作一个旋钮，而不是一个常量：一个由高支持准则组成的固定核心，再按任务额外扩展几条针对当前任务选出的准则（余弦相似度或LLM引导，按优先级加权）——或者，当模型有足够的余量可以使用时，就注入完整的整合集。相同的经验对两个智能体都是可用的；区别在于，ACE总是发送全部内容，而我们发送的是特定模型实际能利用多少。

为什么这很重要

在AppWorld上，使用相同的基座ReAct智能体，我们在内部运行了两个系统：

在强模型上，我们在两个指标上都更好，而且推理成本约为ACE的40%。在弱模型上，我们以56.0对54.8略微超过ACE——差距非常小，我们称之为准确率打平（我们重复运行一次的结果为54.8，与ACE几乎完全一致，处于该基准的逐次运行噪声范围内）——而成本约为七分之一。

关于成本要公平地说一句：ACE自己的效率故事在于廉价地构建其上下文。我们的效率则在另一个维度——提供它。按任务检索几条准则，而不是每一步都注入完整的策略手册，这才是token消耗差别的来源，也是上述传递方式差异的直接结果。

准确率来自哪里？按难度划分的结果讲述了两个不同的故事：

image (https://cdn-uploads.huggingface.co/production/uploads/6435a1131860001f144239ea/RlNmW6Vps10XLGW4DuJQh.png)

图1. 加入记忆后按难度划分的任务目标完成率，我们的系统 vs. ACE。在DeepSeek-V3.2上（右），我们在简单、困难、总体上都获胜；ACE仅在中等难度上略胜。在gpt-oss-120b上（左），ACE在简单和中等难度上领先，但按任务选择的方式在困难任务上获胜——并赢下总体。每个系统都相对自身无记忆基线有所提升（见下方方法说明下的按难度参考表格）。

两个模型讲述了不同的故事。在gpt-oss-120b上，ACE的完整策略手册在简单和中等难度上占优——因为这类任务已有足够部分可以通过通用指令遵循来解决，所以全面的提示带来的帮助大于干扰。但在困难任务上，模型必须挑选正确的经验，而不是在全部经验中艰难翻找，精心筛选的检索便脱颖而出——而这一档正是决定总体结果的部分。在DeepSeek-V3.2上，故事反了过来：更强的模型能够很好地消化ACE的完整策略手册，从而在中等难度上略微胜过我们，但我们在简单、困难和总体上都领先——更强的模型有更多余量，因此更多经验（以我们的方式传递）会持续带来帮助，而不会互相排挤。

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

相同的经验，不同的传递方式

两个系统都拒绝把一个智能体来之不易的经验压缩成一份简洁的总结——这一点，我们达成共识。区别在于传递是固定的还是经过校准的：ACE无论什么情况都在每一步发送整个策略手册；我们则发送特定模型实际能利用多少准则。正是这种校准带来了上面那些数字——在只有ACE推理成本一小部分的情况下达到相同或更好的准确率——而在较弱的模型上，它决定了帮助性的指导与碍事的指导之间的差别。

试试ALTK-Evolve (https://github.com/AgentToolkit/altk-evolve)库——其中包含本文使用的提取、整合和检索流程——或阅读完整技术报告 (https://arxiv.org/abs/2603.10600)，了解完整方法和消融实验。

相关成果/参考文献

• **之前的文章：**ALTK-Evolve介绍——链接 (https://huggingface.co/blog/ibm-research/altk-evolve)
• ACE（Agentic Context Engineering）——链接 (https://arxiv.org/abs/2510.04618)
• AppWorld基准——链接 (https://appworld.dev/appworld)
• ALTK-Evolve——链接 (https://github.com/AgentToolkit/altk-evolve)
• 完整技术报告——链接 (https://arxiv.org/abs/2603.10600)

方法说明

AppWorld的test_normal，168个任务。一个ReAct代码智能体（每一步都编写Python；环境返回输出）。TGC = 任务目标完成率；SGC = 场景目标完成率，要求场景的每个变体都通过。记忆仅从训练/开发集中挖掘；结果是单次运行（pass@1），该基准的标准做法。

ACE的数字是我们自己对ACE智能体的运行结果，在内部使用相同的AppWorld划分和与ALTK-Evolve相同的基座模型（DeepSeek-V3.2和gpt-oss-120b）进行评估。ACE论文报告的是不同的基座模型（DeepSeek-V3.1），因此我们自己运行可以保证模型和测试框架在比较中受到控制。两个系统都是同一个ReAct智能体，唯一区别是提示模板——这也是两个无记忆基线不同的原因（TGC分别为72.0和79.8）；我们并不把比较建立在基线差距上，只建立在提示调整无法动摇的主张上：以一小部分的token数实现相同或更好的准确率。

参考表格

DeepSeek-V3.2 — test_normal（168个任务）：

gpt-oss-120b — test_normal：

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

**DeepSeek-V3.2 — 按难度（基线 → 加记忆）：**两个系统因上述提示模板差异，起始无记忆基线不同（总体TGC分别为79.8和72.0）。