思考ACE？更少令牌，我们也能行

IBM研究院的团队近日发布了一项关于AI智能体（Agent）记忆机制的最新研究，对比了自家提出的ALTK-Evolve系统与业界关注的ACE（Agentic Context Engineering）方案。核心结论很直接：在让AI智能体从自身过往操作轨迹中学习这件事上，两家思路一致，但在如何“交付”这些学习成果给模型时，路径分叉，导致最终的Token消耗账单天差地别。 核心差异：不压缩的共识与交付方式的决裂 先交代背景。给大语言模型智能体一个真实的多步骤任务，比如拆分账单、跨九个模拟应用核对订单，它失败的原因往往不是“不知道API怎么用”，而是“用得不稳”——翻错页、认错人、该返回值时没返回。这种“操作可靠性”是能从智能体自身历史中学到的。ACE和ALTK-Evolve都做这件事：把过去的轨迹变成可复用的经验，在推理时喂回给模型，不更新权重，不需要人工标注。双方甚至在最难的问题上达成一致：坚决不压缩经验。ACE明确指出了两种失败模式——“简洁性偏见”（优化时倾向生成简短通用指令）和“上下文崩溃”（模型每步重写整个上下文时把细节弄丢），因此坚持保留一份详尽、带正反例计数器的playbook。ALTK-Evolve同样用“支持计数”（有多少独立事件产生了这条经验）来标记每条准则的权重，五条不同任务发现的教训和只出现一次的教训，价值完全不同，都值得保留。用他们的话说：数它们，别压扁它们。 但真正的分歧在“交付”环节，这也直接决定了Token账单。ACE的做法是：无论模型或任务类型，每一步推理都把那份详尽的playbook完整注入。而ALTK-Evolve把交付当成一个“旋钮”而非常量：一个由高支持度准则组成的小型固定核心，再根据当前任务额外挑选几条（通过余弦相似度或LLM引导，按优先级加权）注入。当模型本身有足够上下文窗口余量时，甚至可以动态调整注入量。这个看似微小的设计差异，在长链路任务中会累积成巨大的Token消耗差距——因为ACE每步都全量加载，而ALTK-Evolve只带“够用”的经验上场。 对中国卖家和AI从业者的启示：成本敏感场景下的务实选择 对于正在搭建AI客服、订单处理或营销内容生成管线的中国跨境电商卖家来说，这个研究传递了一个非常实际的信号：AI智能体的“记忆”不是越全越好，而是越精准越好。如果你的业务场景是高频、多步骤的API调用（比如自动处理退款、跨平台比价），ACE那种“全量playbook每步注入”的模式，虽然理论上信息最完整，但在Token计费模式下，长此以往成本会非常可观。ALTK-Evolve的“核心+按需扩展”思路，更像一个精打细算的运营策略——把最常用的经验常驻，把特定任务的临时经验按需调用，既保住效果，又控制预算。 另一个值得关注的点是“支持计数”这个机制。它本质上是在给经验做“置信度加权”。对卖家而言，这意味着AI系统能自动识别哪些操作路径是被反复验证有效的（高支持度），哪些只是偶然成功（低支持度），从而在决策时更倾向于前者。这种能力对于处理电商场景中大量非结构化的异常情况（比如买家投诉、物流异常）尤其有价值——系统不再是死记硬背规则，而是学会了“哪些招数在实战中真的管用”。目前IBM团队表示，ALTK-Evolve的代码和实验细节已公开，感兴趣的团队可以基于自身业务数据测试这两种记忆机制的性价比差异。