ACE：让上下文成为会进化的作战手册

上下文为什么越“优化”越容易塌？

上下文适配的优势很直观：它可解释、更新快、可跨模型复用，也不需要昂贵的权重训练。但当任务依赖大量领域规则、API 用法与失败教训时，“写得更短”并不等于“学得更好”。

• 简洁偏差（brevity bias）：优化器偏爱短而通用的指令，具体策略和边界情况被抽象掉。
• 上下文塌缩（context collapse）：每一步都让 LLM 整体重写，旧知识没有稳定锚点，可能在一次更新中突然消失。
• 职责拥挤：同一个模型既执行、又评估、又重写记忆，轨迹诊断和知识维护互相干扰。

论文 Figure 2：Dynamic Cheatsheet 的整份上下文重写在某一步突然压缩信息，性能同时跌破无适配基线。

展开说明 ▸

• 横轴是连续适配步骤；上下文会随经验累积逐渐增长。
• 长度变化并非平滑修剪：第 60 到 61 步从 18,282 token 断崖式跌到 122 token。
• 性能变化与信息丢失同步：准确率从 66.7 降至 57.1，低于不做适配的 63.7。
• 因果警示不是“长上下文必然好”，而是整体重写没有办法保证关键条目仍被保留。
• ACE 的对应设计是把知识拆成带 ID 的条目，只应用局部 delta，让未被修改的经验原样留下。

两条重要路线，都还差了哪一步？

ACE 不是从零开始。GEPA 证明了自然语言反思可以高效优化 prompt；Dynamic Cheatsheet 证明了模型可以在测试时积累外部记忆。ACE 接过这两条线，专门解决“细节必须长期留下”的场景。

▸

ICLR'26 OralGEPA：反思式 Prompt 进化

角色：离线 prompt 优化强基线。它从轨迹反思并搜索完整 prompt 候选，但目标仍是选出一份高分指令，难以稳定承载大量细粒度知识。

输入 → 处理 → 输出：GEPA 接收系统执行轨迹、评估分数和文本反馈；LLM 诊断失败并变异某个 prompt；Pareto 前沿保留在不同样本上各有所长的候选，最后输出高性能 prompt。

它的优势是把稀疏标量奖励变成可读的自然语言学习信号，并通过候选多样性避免贪心搜索陷入局部最优。它适合“找到更好的总体指令”，却不是为维护一份不断增长的领域知识库而设计。

与 ACE 的关键区别：GEPA 的候选是完整 prompt；ACE 的状态是带 ID 和计数器的条目集合。前者在候选间搜索，后者对知识做增量维护。

GEPA v1 Figure 3：每轮从 Pareto 前沿选择候选，通过反思式变异或合并提出新 prompt，再经小批量和更大集合评估；最新版 v2 的 arXiv HTML 暂不可用。

展开说明 ▸

• 候选池保存历轮 prompt 及其在各样本上的表现，而非只保留单一全局冠军。
• Pareto 选择让在某些样本上最优的候选仍有机会被继续改进，维持搜索多样性。
• 反思式变异读取轨迹与文本反馈，定位具体失败原因，再修改目标模块的 prompt。
• 两阶段评估先用小批量筛选，再扩大评估；箭头形成“选择—变异—验证—入池”的迭代闭环。
• 在 ACE 叙事中的缺口是候选仍以完整 prompt 为单位，没有为长期增长的知识条目提供稳定身份。

阅读 GEPA 原论文 ↗

▸

EACL'26Dynamic Cheatsheet：测试时自适应记忆

角色：ACE 的直接起点。它让模型保存策略、代码和教训，但 cumulative 版本反复重写整份 cheatsheet，正是 context collapse 的风险来源。

输入 → 处理 → 输出：模型解答连续问题，Curator 从新轨迹中提取可复用经验；DC-CU 把经验并入一份累计 cheatsheet，DC-RS 则检索相似历史再为当前问题合成记忆；Generator 使用这份外部记忆回答后续问题。

这项工作的重要贡献是把独立推理变成“带经验的连续推理”，无需更新权重，也不强制依赖人工标签。Game of 24 中，模型一旦保存 Python 暴力搜索程序，后续就能反复复用。

ACE 补上的一步：不再让 Curator 输出重写后的整份 memory，而只输出新增或修订条目；稳定合并由轻量逻辑完成。

Dynamic Cheatsheet Figure 3：Generator、Curator 与 Retriever 如何组成累计记忆和检索合成两种测试时学习路线。

展开说明 ▸

• Generator读取当前问题和可用记忆，产生解答；它本身可以是黑盒 LLM。
• Curator观察问题、输出和已有经验，把新策略或代码整理进外部 cheatsheet。
• DC-CU让同一份 cheatsheet 跨查询累计更新，形成持续学习，但整份重写会逐轮压缩旧细节。
• DC-RS先用 Retriever 找相似历史，再为当前查询合成局部 cheatsheet，减少无关记忆。
• 流向关系是“解题轨迹 → 经验整理 → 外部记忆 → 下一次解题”；ACE 保留这条闭环，替换了记忆写入机制。

阅读 Dynamic Cheatsheet 原论文 ↗

两者共同留下的缺口可以压成一句话：反思能产生好建议，但建议如何写回长期上下文，仍缺少不丢旧知识的更新协议。 ACE 的主要创新就在这个“写回”环节。

ACE：分工反思，只提交局部修改

ACE 同时支持离线适配（用训练集优化系统 prompt）和在线适配（测试时根据自然执行反馈更新记忆）。两种设置共享同一条主线：把每次执行变成一份可审查、可合并的经验增量。

论文 Figure 4：Generator 产生轨迹，Reflector 提取可复用洞察，Curator 生成 delta；确定性合并把 delta 写入结构化 playbook。

展开说明 ▸

• Generator接收查询与当前 playbook，执行推理、工具调用或领域任务，并标记哪些条目有帮助或有害。
• 轨迹与反馈把结果、执行成功/失败、可选真值送给 Reflector；这条箭头承载的是“发生了什么以及结果如何”。
• Reflector把一次轨迹转成具体经验，可迭代多轮，目的是分离“判断哪里错了”和“如何维护上下文”。
• Curator不重写整份上下文，只把洞察变成新增、修改、计数更新等小型 delta entries。
• 确定性合并按 ID 应用更新，并通过语义相似度去重；它避免让 LLM 在每轮重新生成所有旧内容。
• 反馈闭环是“playbook → Generator → Reflector → Curator → delta → playbook”；多条 delta 还能并行生成后批量合并。

跟着一条 AppWorld playbook 更新走完四步

用论文中的关系识别案例看 ACE 如何纠错：Agent 需要找到用户的室友并处理相关交易，但旧条目允许从交易描述猜关系，导致选错对象。点击下一步，看同一个 playbook 条目如何被局部修订。

这个 case 为什么必须用“带 ID 的 bullet”？

shr-00009 给这条关系规则一个稳定身份。Curator 因此可以精准更新这一条，把 helpful / harmful 计数和来源一并保留；其他 API、分页与认证条目完全不必重新生成。相比“请把整份手册重写得更完善”，信息损失的风险小得多。

Grow-and-Refine：增长，但不任其膨胀

• Grow：新 ID 直接追加；已有 ID 原位更新，旧条目不被无关改写波及。
• Refine：用语义 embedding 比较相似条目，合并重复知识，并结合 helpful / harmful 计数修订。
• 两种时机：可在每次 delta 后主动去重，也可等到接近上下文窗口时再懒惰整理，交换延迟与紧凑度。

具体示例：论文中的 AppWorld playbook 长什么样？（展开查看）

论文展示的 ACE 上下文不是抽象口号，而是按领域组织的操作性知识：API 使用顺序、常见错误、可复用代码片段、实体解析规则以及失败后的修正。它更像工程团队维护的 runbook，而不是一句“谨慎使用工具”。

论文 Figure 3：ACE 生成的部分 AppWorld playbook，保留可直接复用的领域洞察、工具规则和代码。

展开说明 ▸

• 组织方式是结构化条目而非连续散文，便于按任务检索和局部修订。
• 内容粒度落在具体动作与失败条件上，让 Generator 能直接把经验用于下一次工具调用。
• 代码与 API作为可执行知识保留，避免被压缩成失去参数细节的泛化描述。
• 元数据为后续 helpful / harmful 反馈和去重提供锚点，使条目具备生命周期。
• 教学要点是 ACE 追求“全面但可维护”，不是无筛选地保存完整历史轨迹。

实验支持了什么，又没有支持什么？

论文在 AppWorld Agent 任务和金融领域任务上，同时评估离线与在线适配。最有说服力的不是单一榜单名次，而是增量更新的消融、无标签执行反馈，以及适配成本三条证据互相对齐。

什么时候值得用 ACE？

长 playbook 也不是“免费”的：ACE 评估时原始输入 token 多于 GEPA。论文认为 KV cache 复用能摊薄成本，并报告 91.8% 输入 token 命中缓存；这依赖实际服务基础设施，部署前仍应测量延迟、缓存命中率与账单口径。