一个agent系统调用九个模拟应用去拆账单、找歌曲、核对订单，失败的原因往往不是模型不懂API，而是它记不住“怎么用才靠谱”——翻错页、认错人、多返回一个没人要的值。IBM Research上周发博客，拿自家的agent记忆系统ALTK-Evolve去对垒最近很受关注的ACE（Agentic Context Engineering），在AppWorld基准上跑出一组数字：强模型上准确率更高、token成本只要对方四成；弱模型上准确率打平，token成本却只有对方七分之一。
这组数字确实漂亮，但打分的裁判只有IBM自己。
发生了什么：同一套Agent，两种记忆方式
两套系统解决的是同一个问题：让agent从自己过去的执行轨迹里学经验，不改模型权重，不靠人工标注。区别在于学到的东西怎么用。
ACE把经验攒成一份不断增厚的playbook，每一步推理都把整份内容注入上下文，坚决不压缩——它给这种压缩起了两个名字：brevity bias（越优化越简短）和context collapse（一压缩细节就丢）。ALTK-Evolve认同“不压缩”这个前提，但把投递做成了一个可调的旋钮：小部分高频验证过的核心guideline固定带上，剩下的按任务动态检索几条，模型吃得下多少就喂多少。
IBM用同一个ReAct agent、同一套AppWorld基准，让两套系统分别接管DeepSeek-V3.2和gpt-oss-120b两个模型跑分：
强模型上，ALTK-Evolve的TGC/SGC是89.3/80.4，比ACE的80.4/73.2还高，token只用了263K，是ACE 634K的四成左右。弱模型上准确率打平——56.0对54.8——但token只用了116K，约为ACE 777K的七分之一。IBM把这七分之一的差距归因于“投递方式”：ACE每步都塞全部playbook，ALTK-Evolve只挑当下任务用得上的几条。这个解释本身没问题，检索比全量注入省token是常识，问题在于打平的准确率到底有多“平”。
“打平”背后：按难度拆开是另一幅图
IBM自己按任务难度拆了一次gpt-oss-120b的结果，画面和总分不太一样。
换句话说，在容易和中等难度的任务上，ACE的全量playbook反而更好用——这类任务本身靠“通用指令跟随”就能解决大半，全塞进去不算浪费。ALTK-Evolve靠的是Hard档的领先和token优势把总分拉平，再靠省下来的成本把“平分”变成了“更划算”。这不是数字造假，但“整体打平”这个说法确实掩盖了任务分布的敏感性——如果一个企业场景里简单任务占多数，选ACE可能反而更省心。
IBM对56.0比54.8的差距只做了一次重复实验佐证，样本量没有交代，统计上够不够“显著”很难说。而且IBM自己也承认，两边效率叙事根本不是一回事：ACE说的是“构建阶段便宜”，ALTK-Evolve说的是“投递阶段省钱”——各自挑了一个自己占优的维度讲故事，这在技术博客里很常见，但读者不该把它当成两套系统的全面对照。
缺一个裁判
这场对比从头到尾是IBM Research在自己的环境里跑两套系统、自己写博客发布。检索不到ACE原论文自身公开的token成本基准，也找不到ALTK-Evolve的独立代码库，更没有第三方在AppWorld或其他基准上复现过这组数字。ACE团队是否会回应“投递方式决定账单”这个核心论点，目前也没有公开信息。
- 结论.省token的方向是对的，但“打平ACE、省七倍成本”目前只是IBM一方的自我陈述，还没经过独立复现。
- 风险.如果生产场景以简单、中等难度任务为主，按IBM自己公布的拆分数据，ACE反而可能更合适。
对正在为多步骤agent算token账单的开发团队来说，这份对比值得记下来当方向性信号——检索式记忆比全量注入省钱，这一点符合直觉——但下结论前，最好等一个不是发布方自己出的复现结果。