ACE 阅读笔记：让智能体积累经验，也别把旧经验改没了

笔记日期： 2026 年 9 月 28 日
作者： Zhongzhu Zhou
阅读论文： Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models
论文作者： Qizheng Zhang, Changran Hu, Shubhangi Upasani, Boyuan Ma, Fenglu Hong, Vamsidhar Kamanuru, Jay Rainton, Chen Wu, Mengmeng Ji, Hanchen Li, Urmish Thakker, James Zou, Kunle Olukotun
版本： arXiv:2510.04618v3，2026 年 3 月 29 日
阅读范围： 全文 32 页，包含不同模型、细分成本、有害反思实验和提示词附录。文中实验数字均来自论文；公式推导、说明性例子和建议实验属于本笔记的分析，不是新的评测结果。

1. 真正难的不是写下一条经验

读 ACE 时，我最关心的问题是：一个智能体做完今天的任务以后，究竟留下了什么？它可能保存了完整对话，也可能写了一句“下次仔细检查”。前者细节很多，后者很简洁，但两者都未必能让它下次少犯一次同样的错误。

更棘手的是，今天明明写下了有用的经验，过了几十轮整理，这条经验却消失了。反复让模型“综合旧笔记和新经验，重写一份更好的笔记”，很容易把具体条件压缩成泛泛的建议。文风变得流畅，真正决定任务能否完成的例外条件反而被抹掉。

ACE 的办法是把上下文做成一本可逐条维护的 playbook，可以理解为操作手册。Generator 负责尝试任务，Reflector 从过程和反馈中提取经验，Curator 判断哪些内容值得加入；最后由确定性的合并步骤把新增条目接到原有手册上。一次新经验不需要让模型重新生成所有旧经验。

这个设计与最近的 harness 自我改进讨论很相关，但需要分清对象。ACE 主要改变智能体使用的知识和规则；它没有因此证明，智能体已经能可靠地改写所有工具接口、控制流程和自我更新机制。上下文演化是整个系统自我改进中的一个明确层次。

我的总体判断是：ACE 把“积累经验”从一句口号变成了可以检查的状态更新过程。它的价值不只在实验分数，更在于明确了什么应当保留、什么应当新增。但保护旧条目也会保护旧错误，后面必须继续追问反馈是否可信、规则何时失效，以及长手册到底要付出多少使用成本。

2. 前置知识：参数没变，什么在学习？

2.1 模型之外也有会变化的状态

设模型参数为 $\theta$，第 $t$ 个任务为 $x_t$，当前手册为 $P_t$。模型读取任务和由手册组织出来的上下文，生成答案 $\hat y_t$ 及交互轨迹 $\tau_t$。拿到反馈 $f_t$ 后，再更新手册。下面是为了理解论文而写的抽象表达，并非论文原有公式：

$$(\hat y_t,\tau_t)\sim p_\theta(\cdot\mid x_t,C(P_t)),\qquad P_{t+1}=U(P_t,\tau_t,f_t). \tag{1}$$

其中 $C$ 表示把手册组织成模型输入，$U$ 表示更新过程。这里变化的是 $P_t$，不是 $\theta$。同一个模型明天表现更好，可以是因为系统给它提供了更合适的经验；这不等于它在一个空白会话里也永久获得了同样能力。

因此，讨论自我改进时必须指明状态放在哪里。权重训练、外部规则库、检索记忆和当前会话历史，都可能改变行为，但它们的持久性、可编辑性和成本不同。ACE 的一个优势是更新对象可读，出现问题时可以追踪到一条经验，而不必把全部变化都归因于模型内部的隐式状态。

2.2 保存轨迹、保存原则、保存条件，是三种不同选择

假设一个任务需要把两份业务记录关联起来，两条记录的显示名称恰好相同。保存整段轨迹，能留下全部细节，但下一次模型仍要从长对话里自己归纳。写一句“注意身份匹配”，过于宽泛。更有用的条目应该说明：这里必须使用稳定 ID，显示名称不是唯一键，并且指出这一规则适用的记录类型。

这个例子是我的说明，不是论文的实验样本。它想强调的是，一条好经验并不等于一句短经验，而是把成功所需的条件保留下来。适度抽象能够跨任务复用，过度抽象会失去操作性；过度具体则可能把某一次任务中的常数当成普遍规律。

检索与更新也应分开。检索回答“这次应该读哪条已有经验”，更新回答“这次经历应该成为怎样的新经验”。ACE 更直接处理后者。未来可以加检索层，但不能把“条目存在”当成“模型一定找到并正确使用了它”。

2.3 没有标准答案，不等于没有反馈

论文中的 GT 指 ground truth，即用于适配的标准答案或参考信息。去掉 GT 后，交互环境仍可能返回错误、执行结果或任务检查信息。比如，接口明确拒绝了一个参数，这是可用证据；一次调用顺利执行，却不能证明整个任务已经完成。

这在细分类任务中尤其重要。模型给出了一个格式正确的标签，系统可能没有任何直接信号告诉它语义上是否选对。如果它只根据自己刚才的解释再写一条“经验”，错误就可能被保存为规则。反思越自信，并不意味着证据越可靠。

另一方面，在线有标签的设置也不一定泄漏答案。关键是时间顺序：先在当前手册下预测并计分，再揭示允许使用的反馈，用于下一道题。若先看到当前答案再修改手册，最后回头声称这是当前题的预测结果，评测含义就完全变了。

2.4 离线和在线回答的不是同一个问题

离线适配通常用训练集建立手册，随后在测试集上评估。多轮训练可以重复访问旧样本。在线适配则让手册随着测试序列变化：先预测，再反馈，再更新。第一个任务和最后一个任务使用的系统状态并不相同。

如果把这种在线平均成绩写出来，可以得到：

$$\widehat A_{\mathrm{online}}= \frac{1}{T}\sum_{t=1}^{T} \mathbf 1\{\hat y_t(P_t)=y_t\}. \tag{2}$$

这个表达最重要的不是求和，而是答案依赖 $P_t$。它表示“边做边学的这一段过程”表现怎样，而不是最终手册在一个独立测试集上表现怎样。论文让不同方法使用相同的打乱顺序，这有利于公平比较；若再重复多个顺序，就可以看出结果是否依赖某次恰好有利的经验排列。

3. 上下文为什么会越整理越差？

3.1 简短不等于保留了关键区别

一种常见的提示词优化直觉，是把经验变成精炼原则。但操作经验往往有条件。例如“遍历所有页面”还必须说明何时停止；“读取前十页”可能漏数据，“一直读取”又可能无法结束。少掉的那几个字，恰恰可能决定程序是否正确。

ACE 所批评的 brevity bias，可以理解为偏好简短表述而丢掉领域细节。它不是反对清晰写作，而是提醒我们：为了减少字数而压缩掉约束，会让手册失去功能。保留所有轨迹也不是免费替代方案，因为模型要反复读大量无关内容，还要自己重新提炼规则。

3.2 一个上下文坍缩实例

论文图 2 展示了 Dynamic Cheatsheet 的一次运行：手册先增长到 18,282 个 token，随后一次重写把它压缩到 122 个 token；对应准确率由 66.7 降到 57.1，低于基线的 63.7。这个例子非常直观，但不能据此估计所有模型发生坍缩的概率，也不能把准确率变化全部归因于长度这一单独变量。

3.3 用一个小模型理解“少动旧内容”的价值

假设一条有用经验在每次全文重写后仍然保留的概率为 $q$，各轮风险独立。经过 $T$ 次重写，全部存活事件同时发生的概率为：

$$\Pr(\text{全文重写后存活})= \prod_{t=1}^{T}q=q^T. \tag{3}$$

现在改成局部更新，假设每轮只有比例 $a$ 的条目可能被触碰。一条经验以概率 $1-a$ 完全不动，以概率 $a$ 被处理，而处理后保留的条件概率仍为 $q$。所以单轮存活概率为 $(1-a)+aq$，连续 $T$ 轮为：

$$\Pr(\text{局部更新后存活})= \left[1-a(1-q)\right]^T. \tag{4}$$

取 $q=0.99$、$T=100$，全文重写模型给出约 0.366 的存活概率；若每轮只触碰十分之一条目，即 $a=0.1$，则约为 0.905。它说明了一个容易忽略的事实：单次只丢一点信息，重复很多次以后，也可能造成明显损失。

现实当然没有这么简单。遗忘风险会相关，某些条目应当主动删除，去重也可能影响新增条目以外的内容。因此这个推导只用于解释设计动机，不能证明 ACE 必然达到某个保留率。更关键的是，错误条目同样会因“不重写”而更容易存活。保留机制必须配合纠错和遗忘机制。

4. 从一次经历到一条稳定规则

4.1 三个角色分别解决什么问题？

Generator 用现有手册完成任务，产生过程和结果。Reflector 解释这一过程为什么成功或失败，尝试提出能复用的经验。Curator 再看这些经验与旧手册的关系，判断哪些已经有了、哪些值得添加。最终合并不要求模型把整本手册重新输出。

这里有两次不同的压缩。反思把一段轨迹压缩成经验；整理把经验压缩成对现有知识库的增量。如果合并为一次不受约束的全文重写，模型同时承担诊断、去重、改写、保留旧规则等任务，很容易顾此失彼。把职责拆开，至少能看清哪一步制造或丢失了信息。

但三个角色并不等于三个独立裁判。主实验让它们都使用 DeepSeek-V3.1 的 non-thinking 版本，避免把收益解释成一个更强教师在向弱模型传授知识；代价是错误也可能高度相关。一个角色提出似是而非的结论，另一个角色可能因为使用相似的模型而轻易接受。

4.2 算法 1：一次上下文适配

下面按论文机制写出解释性伪代码。它不是原论文逐字算法，也不表示每次反思都能提高质量。是否有标准答案、反思多少轮，都属于实验设置的一部分。

算法 1：一次 ACE 适配循环
1. 读取任务 x 与当前手册 P。
2. Generator 使用适用条目尝试完成任务。
3. 保存轨迹和本设置允许使用的结果反馈。
4. Reflector 诊断成功、错误与可复用经验。
5. 在规定轮数内，按需要继续细化反思。
6. Curator 对照 P，仅提出尚缺的局部增量。
7. 确定性合并为新条目分配 ID 并写入。
8. 更新可获得的 helpful/harmful 条目反馈。
9. 到达指定触发条件时去重或整理。
10. 返回供后续任务使用的新手册。

第三步不仅适用于错误答案。一个任务可能最后做对了，却经过多次无效重试；也可能使用了偶然奏效的捷径。过程能为下一次更稳妥的策略提供线索。不过，对成功过程的事后解释仍然只是关于“什么起了作用”的假说，不能直接升级成因果结论。

4.3 为什么给条目分配稳定 ID？

手册中的条目具有标识符、内容，以及 helpful/harmful 等反馈计数。稳定 ID 的作用很朴素：以后再提到某条经验时，指向的是同一个对象，而不是一段不断改写、位置也在变化的文字。

为了讨论，可以把手册表示成：

$$P_t=\{(i,c_i,h_i,b_i)\}_{i\in I_t}. \tag{5}$$

$i$ 是条目标识，$c_i$ 是内容，$h_i$ 和 $b_i$ 分别记录有帮助和有害的反馈次数。这是本笔记的抽象记号，不是对具体数据格式的断言。计数能够支持后续管理，但不能仅凭这个表示就说论文已经定义了一套完整的自动删除规则。

附录里的 Curator 提示词尤其值得细看。AppWorld 和 FiNER 的例子列出的操作是 ADD；正文则另行讨论 grow-and-refine、语义去重和元数据管理。不能把两部分拼成一套论文并未明确给出的任意编辑协议，更不能擅自补出一个“所有错误都能自动修复”的能力。

4.4 算法 2：确定性合并能保证什么？

以下用一个保守的合并约定解释边界。版本记录、重复事件保护等属于值得增加的工程约束，而不是论文实验已经证明的功能。

算法 2：解释性的增量合并约定
1. 接收增量及其所依据的手册版本。
2. 检查新增条目是否具有分类和内容。
3. 给接受的新条目分配独立 ID。
4. 保持无关旧条目的内容不变。
5. 将条目反馈关联到相应 ID。
6. 记录本次更新产生的版本及变更条目。
7. 单独运行预先定义的去重和整理策略。
8. 返回新版本及变更记录。

确定性合并能避免模型在追加一条经验时顺手改写全部旧内容，但结构合法不代表内容正确。一条错误规则照样可以是完全合法的 JSON。因此，合并层主要解决保存和寻址问题，不能替代判断经验是否可信的环节。

第七步必须单独看待。机械追加可以保证旧文本不变，语义去重却可能删除否定词、版本条件或例外。两段话看起来很相似，不意味着它们可以安全地合成一句。去重是一项会改变含义的操作，不应被当成无风险的格式整理。

4.5 批量更新的边界：独立追加容易，冲突修正困难

若两个任务产生独立 ID 的新条目，把它们合并到集合里，顺序确实不影响结果：

$$(P\cup\Delta_a)\cup\Delta_b =(P\cup\Delta_b)\cup\Delta_a. \tag{6}$$

这个等式来自集合并集的性质，不来自模型理解矛盾的能力。两个任务若分别要求改写同一个旧条目，或者给出了互相冲突的接口规则，问题就变了。重复处理同一条 helpful 事件，也可能把计数错误地加两次。

所以论文所说的局部增量有利于批处理，是合理的结构优势；但并发纠错是否可靠，仍取决于冲突处理、版本检查和事件身份。对于异步收集经验的系统，我会要求保存“这条更新来自哪个事件、基于哪个版本”。这样才有机会区分独立支持、重复报告和过期修正。

4.6 手册最终仍然需要容量管理

附录 A.6 把 FiNER 的整理触发长度设为 10K、50K、100K token，准确率分别为 78.6、78.4、78.3。它说明这个实验没有依赖某个非常精确的大阈值，但不能推出所有任务都只需要 10K，也不能说超过这一长度的内容必然多余。

同一附录测试 50%、70%、90% 的去重阈值，结果为 77.0、73.9、78.6。虽然都高于 70.7 的基线，最好和最差仍差 4.7 个百分点。因此我会说方法在这些设置下都有收益，而不会说阈值完全不重要。

真正有意思的是删什么。常用通则、少见但关键的例外、过时接口细节，价值并不相同。按出现次数删减，可能优先牺牲最需要保留的稀有边界。随着环境变化，一条曾经很有用的规则，也应有重新评估和退出的机会。

5. 评测必须保留信息到达的顺序

5.1 算法 3：先计分，再学习

在线评测最容易被误读的地方，是把“已经看过这个样本后的表现”当成“第一次遇到这个样本的表现”。下面把时间顺序明确写出来。是否使用离线预热，需要提前决定并单独报告。

算法 3：在线评测的时间顺序
1. 在比较方法前固定任务顺序。
2. 初始化空手册，或明确记录离线预热手册。
3. 依次读取任务 x_t：
4.     在本题预测期间固定当前手册 P。
5.     生成答案，并在任何更新前计分。
6.     揭示本设置允许使用的反馈。
7.     进行适配，生成下一题使用的手册。
8. 汇总首次预测的成绩与全部成本。
9. 保存初始状态、顺序和反馈政策。

ACE 的表 3 显示，没有离线预热的在线平均成绩为 56.1，有预热时为 59.5；后者对应主表中的在线成绩。3.4 个百分点的差距说明，初始手册不是可以略去的小细节。不能把使用已有经验的系统描述成完全从零开始的在线学习。

如果训练结束后把最终手册冻结，再用同一批已经参与更新的题目测试，得到的也不是上面的在线指标。更严谨的做法是同时保留独立测试集，检查经验有没有泛化，而不只是对已经出现过的模式越来越熟悉。

5.2 AppWorld 的“平均分”到底平均了什么？

AppWorld 给出 Task Goal Completion（TGC）和 Scenario Goal Completion（SGC），分别覆盖 normal 与 challenge 两个划分。主表平均分是四个数的汇总，不能简单叫作某一个任务的单一准确率。

例如离线、有 GT 的 ACE 行为：

$$\bar s=\frac{76.2+64.3+57.3+39.6}{4} =59.35\approx59.4. \tag{7}$$

四个指标一起看，能够判断收益来自正常难度、挑战难度，还是更严格的场景完成要求。只保留均值，会把这些差异压扁。基线均值为 42.4，按展示值相减是提高 17.0 个百分点；如果改为相对增幅，则必须除以基线：

$$\frac{59.4-42.4}{42.4}\approx40.1\%. \tag{8}$$

“17 个百分点”和“相对增长约 40%”都可以有数学意义，但不是同一表达。本笔记在比较百分制成绩时优先使用百分点；只有明确分母时才使用相对百分比。

5.3 不同任务提供的纠错信号不一样

FiNER 要在 139 个细粒度 XBRL 类别中给金融实体打标签。Formula 测试金融数值问题。正文使用精确答案准确率；附录的 DDXPlus 也报告准确率，而 BIRD-SQL 使用 GPT-4o-mini 作为模型裁判。不能把后者直接重命名为 SQL 执行正确率。

这影响的不只是指标名称，还影响能学到什么。环境明确报错时，Reflector 可以定位一次失败调用；细分类标签错了但没有参考答案时，它可能连错误是否存在都无法确认。金融计算内部能做一致性检查，也不意味着所有前提假设已经被验证。

因此，不能只问“ACE 是否会反思”，还要问“反思在依据什么证据”。标签、任务检查、工具异常和模型自评是不同信息源。它们混在一起平均后，容易让人误以为无标签适配在所有任务上都同样有效。

6. 实验结果：提升很明显，但不是每列都一起上涨

6.1 AppWorld 主结果

下面保留表 1 的关键行。GT 表示适配阶段可用标准答案信息；最后一行的离线预热条件结合表 3 标明。Normal 与 Challenge 的两个数依次为 TGC 和 SGC。

方法	Normal TGC / SGC	Challenge TGC / SGC	均值
ReAct 基线	63.7 / 42.9	41.5 / 21.6	42.4
离线 ICL，有 GT	64.3 / 46.4	46.0 / 27.3	46.0
离线 GEPA，有 GT	64.9 / 44.6	46.0 / 30.2	46.4
离线 ACE，有 GT	76.2 / 64.3	57.3 / 39.6	59.4
离线 ACE，无 GT	75.0 / 64.3	54.4 / 35.2	57.2
在线 DC，无 GT	65.5 / 58.9	52.3 / 30.8	51.9
在线 ACE，预热、无 GT	69.6 / 53.6	66.0 / 48.9	59.5

相对静态基线，ACE 的改善覆盖了多个指标，挑战集也受益。但在线 ACE 并没有全面超过离线 ACE：它的 challenge 两项更高，normal 两项反而低。这种结果更像手册随着经历改变了擅长的任务分布，而不是所有能力同步增长。平均分接近时，具体列的变化尤其值得看。

表 1 下方正文还有一个应当保留的口径问题：文字称相对 ICL 和 GEPA 分别提升 12.3、11.9，而按离线有 GT 行的展示均值相减，应为 13.4、13.0 个百分点；改用无 GT 行也不能得到那两个数字。由于论文没有在这一处给出能对上的聚合定义，本笔记采用表格数据，不自行替作者补一个解释。

这个差异不改变 ACE 优于这些基线的方向，但说明复述 headline 时不能省略核算。尤其是同一论文含有不同模型、不同划分、不同反馈和不同预热设置，读者很容易在不知不觉中把它们拼成一个并不存在的最佳配置。

历史榜单也要放回时间里看。论文引用 2025 年 9 月的 AppWorld 榜单，ACE 为 59.4，IBM CUGA 为 60.3，属于接近的性能区间，并非数值相等。作者脚注明确说，这只是背景参照，CUGA 的内部系统不同，不能作为受控方法比较。它更不能被写成今天仍成立的最新榜单结论。

6.2 金融任务让反馈边界变得具体

ACE 设置	FiNER	Formula	均值
基础模型	70.7	67.5	69.1
离线，有 GT	78.3	85.5	81.9
离线，无 GT	71.1	83.0	77.1
在线，有 GT	76.7	76.5	76.6
在线，无 GT	67.3	78.5	72.9

我认为表 2 中最值得记住的，是最后一行。均值 72.9 高于基线 69.1，但 FiNER 从 70.7 降到 67.3，下降 3.4 个百分点；Formula 则提高 11.0 个百分点。平均收益并不能保证每一类用户任务都受益。

一个合理解释是：不同任务能够提供的自我纠错证据不同。细粒度标签靠模型自己判断时，可能把原有混淆固化成规则；某些计算程序和问题模式却容易从经验中提炼。这里说的是与结果一致的解释，不是论文已经排除了所有替代机制的因果结论。

离线有 GT 的 ACE 达到 81.9，表中 GEPA 为 72.5、MIPROv2 为 70.9。这说明详细手册在该离线设置下很有价值，但不能拿它与在线无 GT 的方法直接比较后归因于某一个模块。论文概览里出现的 Formula 76.5 对应在线有 GT，最好离线数值是 85.5，两者也必须分清。

6.3 消融：增量更新的证据比单个坍缩案例更强

表 3 的离线消融是逐步加组件：同时去掉 Reflector 和多轮训练，均值为 55.1；保留 Reflector 但只训练一轮，为 56.8；完整设置为 59.4。两步分别提高 1.7 和 2.6 个百分点。这支持两个设计在该顺序下都有用，但它不是完整的双因素实验，不能证明每个模块都具有固定、互不影响的独立贡献。

附录表 18 更直接针对增量更新。Normal 两项均值中，基线为 53.3，无增量更新的 ACE 为 56.9，有增量更新为 70.3。两个 ACE 版本差 13.4 个百分点。拆开看，TGC 差 8.9 个百分点，SGC 差 17.9 个百分点。附录 C 用相对百分比表达对应下降时，分母又不同，不能混用。

这组消融比单次坍缩图更能支持“增量更新是关键因素”。但我仍希望看到更严格的比较：给全文重写、只追加和增量整理相同的反馈、调用预算和上下文容量。否则，究竟是局部表示本身更好，还是某种全文重写提示词比较容易丢信息，仍有进一步分解的空间。

6.4 换模型、换领域以后还成立吗？

附录提供了有价值的扩展。GPT-OSS-120B 上，AppWorld 基线均值为 34.6，离线有 GT 的 ACE 为 40.5，报告的在线 ACE 为 42.2。GPT-5.1 的 AppWorld 表只报告 normal 两项平均，因此不能与前面的四项均值直接比较：它的基线为 54.2，在线 ACE 为 65.8。

在 Llama-3.3-70B 上，FiNER 基线 62.5，离线有 GT 的 ACE 为 64.9，增幅比主实验小。这个结果提醒我们，方法能迁移并不等于收益大小不受模型能力影响。一个模型能否理解、选择并执行手册中的规则，也是整个环节的一部分。

领域扩展中，DDXPlus 从 75.2 提高到 90.2。BIRD-SQL 总体从 47.8 提高到 52.9，但 Moderate 和 Challenging 两组中 GEPA 高于 ACE。表内总体成绩也不是把三个难度子集均匀平均，读者不应自行换成另一种均值后再比较。

这些结果支持 ACE 是一种可迁移的设计思路，而不只是单个金融任务的技巧。它们仍不足以证明所有任务、所有模型都适合不断增长的手册。部分附录设置的验证资源不同，而且若要判断小分差是否稳定，还需要多个适配轨迹和任务顺序下的不确定性估计。

7. 成本要分成“写手册”和“用手册”

7.1 增量输出为什么可能省很多？

假设初始手册长度为 $L_0$，每次更新增加 $a$ 个 token。若每轮都输出完整新手册，连续 $T$ 次更新的文字生成量为：

$$W_{\mathrm{full}}=\sum_{t=1}^{T}(L_0+at) =TL_0+\frac{aT(T+1)}{2}. \tag{9}$$

第一步只是把每次输出长度相加；第二步利用等差数列求和。若每次只生成长度为 $d$ 的增量，则：

$$W_{\mathrm{delta}}=Td. \tag{10}$$

在手册不断增长的简化条件下，一个包含二次项，一个随更新次数线性增长。这解释了局部增量为什么能减少“重新抄写手册”的输出成本。但它没有证明整个系统都从二次复杂度变成线性复杂度，因为 Curator 仍可能要读完整旧手册，Generator 也可能在每次任务、甚至任务内多步调用中反复使用它。

取一个纯说明性例子：$L_0=1{,}000$，$a=d=100$，$T=100$。全文重写累计输出 605,000 个 token，增量只输出 10,000 个，两者为 60.5 倍。这是上述假设下的算术，不是 ACE 的实测加速比。反思、验证、去重和读取成本都没有包括进去。

7.2 正文中的适配成本数字

表 4 报告，AppWorld 离线适配中 GEPA 用时 53,898 秒，ACE 为 9,517 秒。对应的降低比例为：

$$1-\frac{9{,}517}{53{,}898}\approx82.34\%. \tag{11}$$

如果改成速度比，则约为 5.66 倍。表中的 rollout 数为 1,434 与 357，对应减少约 75.1%。在线 FiNER 中，DC 与 ACE 的适配用时为 65,104 和 5,503 秒，费用为 17.7 和 2.9 美元，分别对应约 91.5% 的时间降低和 83.6% 的费用降低。

这些是特定配置下的适配阶段结果，不是未来每次请求都能得到的加速。手册如果只用几次，准备成本占比很大；如果被几百万次请求反复使用，后续输入成本可能成为主要部分。讨论“便宜”之前，必须先确定要服务多长时间、多少任务。

7.3 附录提示我们别把 rollout 当成统一货币

附录 A.3 单独做了细分核算，其中 ACE 使用一轮离线适配和一轮反思细化。GEPA 的输入 token 为 204,076,096，输出为 1,870,188；ACE 分别为 39,250,925 和 307,128，降低约 80.8% 和 83.6%。

但同一张表的总 rollout 数，ACE 是 2,075，GEPA 是 1,455，反而多 42.6%。它列出了 Generator、Reflector、Curator 等部分的调用。不能拿这个计数替换正文表 4 的 357 与 1,434，然后声称论文有一个不依赖设置的统一 rollout 优势。配置和统计边界必须随数字一起报告。

评估阶段，表 14 中 ACE 输入 token 为 58,623,267，GEPA 为 26,960,675，同样是 160 个问题，增加 117.4%。输出增加 7.6%，rollout 减少 4.7%。一个系统完全可能调用稍少，却每次都读取更多上下文；调用数、token、耗时和费用不是可以随意互换的指标。

这也是我觉得论文最有启发的一点：详细手册可以让学习阶段更高效，却使后续推理承担更多输入。两种效应并不矛盾，关键在于应用能否接受这笔交换。

7.4 缓存节省的分母到底是什么？

设未缓存输入的单价为 $p$，缓存输入为 $\rho p$，总输入量为 $N$，其中比例 $c$ 命中缓存。把两部分费用相加：

$$K=pN(1-c)+\rho pNc =pN[1-c+\rho c]. \tag{12}$$

如果对照对象是“同一批输入全部按未缓存单价计费”，费用降低比例就是：

$$1-\frac{K}{pN}=c(1-\rho). \tag{13}$$

取 $c=0.918$、$\rho=0.1$，得到 0.8262，即 82.62%。这可以解释论文 GPT-5.1 缓存分析中约 91.8% 的缓存输入比例与约 82.6% 的输入费用节省。

但这个分母是同一份 ACE 输入的未缓存成本，不是 GEPA 的总成本。它没有包括输出费用，也没有把另一种方法更短的提示词放进比较。若直接写“ACE 因缓存比 GEPA 整体便宜 82.6%”，就越过了数据支持的范围。

缓存还依赖文本稳定性。较稳定的前缀可能重复使用，开头频繁变化则可能影响后续命中。增量追加对稳定前缀有潜在好处，但实际路由、过期规则和服务方式仍然重要。账单打折也不等于长上下文完全没有 KV 内存和解码负担。

7.5 反思越多并不一定越好

表 19 的反思轮数为 1、3、5、10 时，normal 均值分别为 61.3、65.8、67.6、65.2。前几轮可能补出遗漏的经验，再多几轮却可能增加噪声或重复内容。后半句是一个合理机制解释，实验本身只直接告诉我们收益不单调。

因此，更完整的决策指标应同时包括适配总费用、后续推理总费用和尾延迟。论文给出了其中一些重要组成部分，却没有证明任何工作负载下都存在同一个经济上的最优点。

8. 局限：把经验留下来以后，问题还没有结束

8.1 错误经验也会被稳定保存

附录表 17 很值得单独看。作者在 FiNER 离线适配中，每隔 $X$ 步插入一次有害反思。如果每一步都插入，准确率为 66.7，低于基础模型的 70.7；每 5、10、25、50、100 步插入一次时，分别为 76.1、77.0、77.8、78.2、78.2；完全不插入有害反思时为 78.3。

这个实验比“反思可能出错”的口头提醒更有分量。它说明系统能容忍一定程度的噪声，同时也展示了持续错误更新可以抵消收益。但不能因此说只有每一步都被攻击才会失败。一个很少出现、却适用于大量未来任务的错误规则，可能具有不同的传播方式。

更有针对性的后续测试包括：长时间潜伏的错误记忆、相互矛盾的规则、接口版本变化，以及错误条目被重复引用后的自我强化。当前噪声实验提供了起点，没有穷尽这些情况。

8.2 具体经验可能变成脆弱的特例

ACE 的手册能保存操作步骤、领域细节甚至示例代码。这些内容有时很有用，但也可能把一次任务的常数、对象关系或目录约定错误地推广。附录提示词展示的经验足够具体，恰好说明适用范围必须跟着内容一起保存。

一种改进是让条目分清三件事：什么条件下适用，支持它的观察是什么，哪些内容仅是例子。这样，规则不会因为写得具体就被误当成普遍正确，也不会因为想提高泛化而被压缩成空泛的“仔细检查”。这属于本笔记的设计建议，不能说论文已经通过平均准确率验证了它。

8.3 相似句子可能有相反含义

语义向量很适合找相近话题，却不自动保证逻辑等价。两条规则可能只差一个否定词、版本号或单位；这些小差异在词面上不显眼，却决定行动方向。用相似度直接合并，可能恰好删除了最重要的区别。

论文的阈值实验说明若干设置在 FiNER 上仍有收益，但不等于去重具有保留矛盾条件的保证。我会专门构造一组近似规则：对象相同、条件相反，观察整理后是否保留边界。这个实验比只看总准确率更直接地测试“保留必要细节”的核心主张。

8.4 条目还在，不代表模型会正确使用

至少要区分三类问题：经验从未被学到；经验学到了但后来丢了；经验还在，但当前模型没有找到或没有正确执行。ACE 对第二类提供了直接机制，也组织了第一类过程；第三类仍与检索、上下文竞争和模型能力有关。

手册越长，相关规则越可能被淹没。加一层检索或路由有帮助的可能，但也会带来漏检和错误选择。若没有分别记录条目的存在、被选中和被正确使用，就很难判断失败究竟来自记忆管理还是执行能力。

8.5 有限评测不能证明无限持续学习

论文覆盖多个模型和领域，但仍是有限任务、固定配置下的研究。点估计并不自动包含不同任务顺序、不同适配轨迹下的不确定性。额外任务的验证资源、在线预热和模型裁判等条件，也都应随结果一起带到新应用中。

这些限制不意味着方法没有价值。它们只是规定了结论的使用范围：ACE 支持一种有效的上下文更新思路，尚未证明任何长时间运行的智能体都可以靠不断写经验稳定进步。

9. 独立批判性分析：怎样让保留下来的经验值得信任？

9.1 helpful 计数不是因果贡献

设智能体在简单任务上引用规则 A 并成功，在困难任务上引用规则 B 并失败。如果据此增加 A 的 helpful 和 B 的 harmful，统计到的可能是任务难度，而不是规则质量。规则被选择的过程本身，就与任务性质有关。

一个直观的经验比例是：

$$\widehat u_i=\frac{h_i}{h_i+b_i}. \tag{14}$$

没有观测时它没有定义；有观测时，它也只描述被选择使用后的反馈。增加平滑项可以解决分母为零，却不能消除选择偏差。一次成功也可能同时用了多条规则，真正有帮助的是哪一条，并不能从最终结果直接读出来。

我会考虑少量配对评测：在其余上下文相同的情况下，比较有无某条经验的表现，或者在相似任务上随机决定是否提供该条目。它会增加调用成本，因此若采用这种机制，成本也必须计入“经验学习比训练更便宜”的论证。不能一面要求更可靠的条目信用，一面把验证开销排除在外。

还有一种延迟归因问题：一条规则在很早的步骤避免了错误，最终反思却只关注最后一次成功调用。比起一个终身累积的计数，保存证据类型、适用范围和环境版本，可能更能帮助判断一条经验为什么有效。

9.2 规则的收益和危害通常不对称

考虑一个简单决策模型。候选规则正确的概率为 $q$，正确时带来期望收益 $g$，错误时造成期望损失 $h$。暂时忽略条目之间的相互作用，则净价值为：

$$V=qg-(1-q)h. \tag{15}$$

如果只接受期望价值为正的规则，从 $qg>h-qh$ 移项，可得：

$$q>\frac{h}{g+h}. \tag{16}$$

这是本笔记的决策论说明，不是 ACE 原有的接受公式。它解释了为什么所有规则不应共用一个置信度门槛。若错误很容易被发现并撤销，$h$ 较小；若错误会悄悄影响大量后续任务，$h$ 就很大，所需的正确概率也应更高。

因此我更倾向于让证据不足的条目先进入暂存状态，让适用面广的规则承担更严格的证据要求，并保留撤回机制。这个方向不一定需要再加一个更强模型审判所有内容。多次相互独立的任务结果，有时比同一条轨迹上反复生成的几段解释更有价值。

论文的有害反思实验说明，错误更新可以累积到损害基础能力；上面的推导进一步提示，应该按传播范围和失败代价区别处理，而不只是按“这段反思看起来多有道理”决定是否记住。

9.3 保留需要配套遗忘和回滚

增量更新减少了无意丢失，但不自动处理过时知识。一条在旧 API 下很可靠的规则，可能在版本变化后继续得到很高的历史评分。只累计终身 helpful 次数，会让早期经验越来越难以被新证据推翻。

我会给条目增加时间、环境与来源维度，必要时重新确认其适用性。出现系统性退步时，能够回到某个已知较好的手册版本，也比继续无止境追加“修正规则”更容易诊断。否则新旧规则不断叠加，模型必须自己猜哪条优先，原本清晰的手册又变成含糊的长上下文。

这里还要区分删除与彻底遗忘。把条目从当前手册移除，意味着后续输入不再主动使用它；日志、缓存和旧版本里可能仍然有副本。外部可读记忆使修改更容易，但不能据此声称整个系统已完成可验证的彻底擦除。

9.4 算法 4：更直接检验核心主张的实验

我希望验证的命题是：在相同信息和计算预算下，增量管理能否更好地保存有用经验，并在遇到错误经验时更快恢复。以下是建议方案，本笔记没有运行这项实验。

算法 4：固定预算的经验保留评测建议
1. 固定模型、训练任务、反馈来源和总 token 预算。
2. 比较全文重写、只追加、增量整理三种状态更新。
3. 为各方法设置相同的上下文容量上限。
4. 在多个预先固定的任务顺序上重复适配。
5. 加入稀有例外、相互矛盾证据及一次领域变化。
6. 每题先计分再更新，另保留独立冻结测试集。
7. 分别记录条目存活、检索、使用与任务成功。
8. 报告质量、输入输出 token、延迟和恢复时间。
9. 给出评测协议及跨运行的不确定性。

“只追加”这一组尤其重要。如果在同样容量下它已经接近 ACE，主要收益可能来自保留旧内容；如果容量饱和以后，增量整理明显更好，才更能证明管理策略超出了简单追加。也可以给全文重写加上保护关键条目的约束，进一步区分表示结构与提示词约束的贡献。

稀有例外测试用来检查系统是否只记住常见模式；矛盾证据测试用来检查规则能否修正；领域变化测试用来检查旧经验能否退出。它们分别对应持续学习的不同环节，比只测一条最终平均分更容易解释方法为什么有效。

预算也应该统一到更接近真实代价的层面。一次调用可能读一千 token，也可能读十万 token；将二者都计为一次 rollout，会遮蔽长上下文方法的成本。至少应同时报告输入、输出、调用类型和时延，而不是挑一个最有利的计数。

9.5 放回 harness 自我改进的全景里

ACE 更新的是智能体已经积累的规则和知识。更广义的 harness 还包括工具接口、执行控制、测试反馈，以及“下一次如何更新”的过程。它们可以一起改变，但应分别评测，避免把一个层次的成功推广成整个系统都具备可靠自我修改能力。

一个自然的后续方向，是让更新策略本身也演化：内层负责改手册，外层负责改怎样反思、怎样选择经验、怎样整理。这样可以减少人手设计更新流程的局限，却又引入了新的验证问题：系统分数变好，是手册内容变好，还是更新机制真的更能适应未来任务？

这也解释了为什么 ACE 适合作为阅读起点。它把内层状态和更新动作讲得比较具体，能够为更复杂的元层演化提供一个可比较的基础。但它本身的实验并不证明，外层更新政策可以不受约束地自行改变而始终可靠。

10. 结论

ACE 最值得带走的设计，是把上下文当作一组持久、可寻址的经验条目。生成、反思、整理分工，使一条新经验怎样进入系统变得清楚；局部增量则避免了每次更新都让旧知识重新经过一遍有损改写。

AppWorld、金融任务、增量更新消融和多模型扩展，支持这套思路在论文所测条件下有效。但论文也给出了需要认真面对的边界：无标准答案反馈可能导致退步，有害规则可以被稳定保存，长手册在评估阶段可能增加输入成本。

因此，下一步不应只追求“记得更多”。更有价值的是同时检查：经验是否学对、有没有保住、现在是否仍适用、模型有没有真正用对，以及整个过程付出了多少成本。这样的自我改进才有机会从持续积累，走向可解释、可纠错的持续进步。

参考资料与图表来源

1. Zhang 等，Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models，arXiv:2510.04618v3，ICLR 2026。所有实验数字来自该版本正文表 1-4、附录表 5-21；附录 F 给出提示词实例。
2. 作者项目页与官方资源入口，作为进一步阅读入口。
3. 图 1 为原创结构总结；图 2 重绘论文中的单次坍缩案例；图 3 为明确假设下的说明性计算；图 4-7 与图 9 重绘论文表格；图 8 将费用关系推导与表 19 的实验数据分别展示。图中的英文用于复用同一组技术图，中文图注说明含义与来源。
4. 本笔记的编号公式和伪代码均是解释性表达，或明确标注的建议方案；不是声称论文原样列出了这些算法，也不代表已经完成新的实验。GT 指适配时的标准答案反馈，online 指先预测再更新，百分点差值与相对比例按正文所列分母区分。