Agentic Context Engineering (ACE): Evolving Contexts for Self-Improving Language Models

一句话总结：不要把"上下文"当成一段会被反复重写、越写越短的 prompt，而要把它当成一本持续生长的 playbook（战术手册）——用 Generator（生成轨迹）/ Reflector（提炼教训）/ Curator（增量并入） 三角分工，把每次执行的经验以结构化条目（bullet）的形式增量 delta 更新进去，再用 grow-and-refine 定期去重，从而彻底避开"整体重写导致细节被抹平"的 context collapse，让上下文既全面又可无限扩展。

• 来源：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¹（¹Stanford、²SambaNova Systems、³UC Berkeley），ICLR 2026 会议论文，arXiv:2510.04618v3，2026-03-29
• 代码：github.com/ace-agent/ace ｜ 项目页：ace-agent.github.io
• 本地 PDF：ref07_ace-agentic-context-engineering.pdf

TL;DR 速览

• 问题：现在主流的"上下文自适应（context adaptation）"——即不改权重、只改输入来提升模型——普遍有两个毛病：① brevity bias（简洁偏好）：prompt 优化器（如 GEPA）以"短、通用"为美德，把领域启发式、工具用法、常见失败模式一并压掉；② context collapse（上下文坍缩）：靠"让 LLM 整体重写上下文"的方法（如 Dynamic Cheatsheet）随着上下文变大，会突然把它压成一段很短的摘要，导致精度断崖式下跌。
• 方法：提出 ACE（Agentic Context Engineering），把上下文当作不断累积/精炼/组织策略的 evolving playbook，三大创新： 1. 三角分工——Generator 跑出推理轨迹（暴露有效策略与反复踩的坑）；Reflector 从成败中提炼具体教训（把"评估/提炼"从"整理"里剥离出来）；Curator 把教训合成紧凑的 delta 条目，用确定性、非 LLM 的逻辑并进现有上下文； 2. incremental delta updates（增量 delta 更新）——上下文是一堆带元数据（唯一 ID + helpful/harmful 计数器）的条目（bullet），只做局部增删改，不做整体重写；多个 delta 可并行合并； 3. grow-and-refine——新条目按新 ID 追加、老条目就地更新（如自增计数器），再用语义 embedding 去重剪枝，可主动（每次 delta 后）或惰性（超上下文窗口时）触发。
• 关键数字：
• Agent（AppWorld）：ReAct + ACE 比强基线平均 +10.6 分；离线相比 GEPA/ICL 高 11.9%/12.3%；无 GT 标签也能靠执行反馈自我改进（比 ReAct 基线 +14.8 分）。
• 金融领域（FiNER + Formula）：平均 +8.6 分；离线 Formula 单项从 67.5 冲到 85.5（+18.0）。
• 打榜：在 AppWorld 排行榜上，用开源 DeepSeek-V3.1 的 ReAct + ACE（59.4% 平均）追平 GPT-4.1 驱动的头名生产级 agent IBM CUGA（60.3%），并在更难的 test-challenge 分片上反超它（TGC +8.4）。
• 成本：离线相比 GEPA 降 82.3% 延迟 / 75.1% rollout；在线相比 DC 降 91.5% 延迟 / 83.6% token 花费；配合 KV cache，长上下文≠高服务成本（91.8% 输入 token 命中缓存 → 计费输入成本降 82.6%）。
• 一句话评价：ACE 是"在自然语言/上下文层面自我改进"这条路线上目前最完整的一块拼图——它把"记忆/上下文"从"一段会退化的摘要"升级成"一本会长大的手册"，核心洞见是 对 LLM 而言应"保留细节、让模型自己在推理时挑相关的"，而不是像给人类那样先替它做概括。它也正是 [[ref09_meta-harness]]（Meta-Harness）和 [[ref17_self-harness]] 反复对标的主基线：ACE 进化的是"上下文文本"，而 Meta-Harness 进化的是"生成上下文的那段代码"，后者在同一 benchmark 上超过了 ACE。

tags: #harness工程 #自我改进 #context-engineering #agent-memory #playbook #delta-update #in-context-learning #test-time-adaptation

related: [[ref09_meta-harness]]（把 ACE 当主基线并超过它：+7.7 分且上下文少 4×）· [[ref08_mce-meta-context-engineering]]（同样"进化上下文"的近邻，进化的是自然语言技能库）· [[ref17_self-harness]]（把 ACE 归入 Reflexion/ACE 谱系，改进对象是"上下文"）· [[ref19_gepa]]（被 ACE 批评"brevity bias"的主要靶子）· [[ref16_stop-self-taught-optimizer]] · [[ref13_adas-automated-design-agentic-systems]]

摘要

LLM 应用（agent、领域推理）越来越依赖 context adaptation：靠改输入（指令、策略、证据）而非改权重来提升表现。既有方法虽提升了易用性，却常受 brevity bias（为求简洁而丢掉领域洞见）与 context collapse（迭代重写随时间侵蚀细节）之苦。我们提出 ACE，把上下文当作不断累积、精炼、组织策略的 evolving playbook，通过 generation / reflection / curation 的模块化流程实现。ACE 用结构化增量更新避免坍缩，保留细节知识并随长上下文模型扩展。

跨 agent 与领域 benchmark，ACE 在离线（如系统 prompt）和在线（如 agent 记忆）都持续超过强基线：agent +10.6%、finance +8.6%，同时显著降低自适应延迟与 rollout 成本。值得注意的是，ACE 无需标注监督、仅靠自然执行反馈就能有效自适应。在 AppWorld 排行榜上，ACE 用更小的开源模型就追平头名生产级 agent 的总平均，并在更难的 test-challenge 分片上反超。

1 介绍：上下文应当是"手册"，而非"摘要"

论文的立场非常鲜明。现代基于 LLM 的应用（agent、compound AI system）越来越依赖 context adaptation：在不改模型权重的前提下，把澄清后的指令、结构化推理步骤、领域专用的输入格式直接塞进模型输入，从而在训练后继续提升表现。上下文支撑了 AI 系统的很多部件：引导下游任务的 system prompt、承载过往事实与经验的 memory、减少幻觉的 事实证据。

作者先列了"用上下文而非权重"的几个好处，这也是全篇的价值观底座：

[!TIP] 为什么"改上下文"胜过"改权重"？（本文的三条理由） 1. 可解释、可调试：上下文是人类可读的自然语言，用户/开发者能看懂、能审计，甚至能选择性遗忘（selective unlearning）——因隐私/法规删掉某条，或专家发现过时信息时手动改掉（§5 展开）。 2. 运行时即时集成新知识：像 RAG 那样在推理时把新知识接进来，不必重训。 3. 可跨模型/跨模块共享：一份好上下文能在 compound system 的不同组件间复用。 此外，长上下文 LLM（YaRN 等）和 KV cache 复用（Prompt Cache、CacheBlend）等推理优化，正让"上下文路线"在部署上越来越划算——这也是 ACE 敢让上下文"长大"的底气。

但既有方法有两个硬伤（这是全文动机）：

• brevity bias（简洁偏好）：很多 prompt 优化器偏爱"简洁、通用的指令"，牺牲了"全面积累"。作者点名 GEPA 把 brevity 当卖点，但这种抽象会丢掉领域启发式、工具用法指南、常见失败模式——恰恰是实战里最关键的东西。
• context collapse（上下文坍缩）：靠"LLM 整体重写（monolithic rewriting）"的方法，随上下文变大会退化成更短、信息更少的摘要，导致精度骤降（见 Figure 2）。

作者由此提出核心主张：上下文不该是"简洁摘要"，而该是"全面、结构化、富含领域洞见的 playbook"。因为人类常受益于简洁概括，但 LLM 反过来——喂它长而详细的上下文、让它在推理时自主蒸馏相关性，反而更有效。所以不该把领域启发式压掉，而该保留它们，让模型在推理时自己决定什么重要。

[!TIP] 什么是 in-context learning（ICL / 上下文学习）？ ICL 指 LLM 无需更新权重，仅凭输入里给出的少量示范（few-shot）或大量示范（many-shot）就能推断出任务格式与期望输出的能力，由 GPT-3（Brown et al. 2020）系统化提出。它是"context adaptation"这一整条路线的能力前提：正因为模型能"读懂并利用"放进 prompt 的内容，我们才可能靠"编辑上下文"而非"改权重"去改变行为。本文把 ICL 也作为一条基线（塞满训练示范），并论证：比"堆示范"更好的是"堆结构化、可累积、带元数据的 playbook 条目"——因为后者能表达 few-shot 无法表达的因果诊断（"为什么错、下次怎么办"）。

ACE 在两类最受益于"演化上下文"的应用上评估：(1) agent（多轮推理、工具调用、环境交互，策略可跨 episode 复用）；(2) 领域专用 benchmark（金融、医疗、text-to-SQL，需要专门战术与知识）。三条关键发现：ACE 一致超过强基线（agent +10.6%、领域 +8.6%）；ACE 无需 GT 标签、靠执行反馈就能构造有效上下文（自我改进的关键）；在 AppWorld 榜上用开源模型超过 GPT-4.1 的头名 agent。

Figure 1 逐元素解读（招牌图，三个并排柱状图对应三类任务）： - 左「Agent: AppWorld」：从 Base LLM 42.4% → ICL 46.0% → GEPA 46.4% → DC 51.9% → ACE 59.5%。ACE 相比次好的 DC 高 7.6 分，相比 Base LLM 高 17.1 分——agent 任务是 ACE 优势最大的场景（策略可跨轮复用）。 - 中「Domain Knowledge: FiNER」（金融实体识别，139 类）：Base 70.7% → … → DC 74.2% → ACE 78.3%。 - 右「Numerical Reasoning: Formula」（金融数值推理）：Base 67.5% → GEPA 71.5% → DC 69.5% → ACE 76.5%。注意 ICL（67.0）甚至低于 Base（67.5）——盲目堆示范会有害，这正是 ACE 想解决的。 - 共同信息：无论 agent 还是领域知识、无论任务难易，ACE（最右、最深色柱）始终最高，且领先幅度可观。三张图分别对应摘要里"agent / domain / numerical"三条主张。

2 背景与动机：什么是 context adaptation，它现在卡在哪

2.1 Context adaptation 的现状

Context adaptation（上下文工程）指"通过构造/修改 LLM 的输入、而非改权重来改善行为"的一类方法。当前 SOTA 靠自然语言反馈：让一个 LM 检视当前上下文 + 执行轨迹/推理步骤/校验结果，生成"该怎么改上下文"的自然语言反馈，再并回上下文，如此迭代。作者把这条谱系的代表前作讲清楚（这对理解"ACE 到底新在哪"很关键）：

[!TIP] ① Reflexion（Shinn et al. 2023）——"言语强化学习" 让 agent 在失败后用自然语言反思"哪里错了"，把这段口头反馈存进记忆，供下次尝试参考，从而改进规划。它开创了"固定模型 + 语言反馈 + 记忆"的范式。局限：改进的对象是"响应策略/记忆"，反思往往是针对单次尝试的、较粗的口头总结，不强调结构化累积。ACE 把"反思"这一步专门交给 Reflector，并把结果结构化成可累积的 delta 条目。

[!TIP] ② TextGrad（Yuksekgonul et al. 2025，Nature）——把"文字反馈"当梯度 把"文字反馈"类比成可反传的"梯度"，沿着 compound AI 系统的多个组件"反向传播"文本反馈来优化 prompt。奠定了"用语言当优化信号"的形式化框架。ACE 与它同属"语言反馈"家族，但 ACE 不做"梯度式全局优化"，而是局部、增量地往 playbook 里加条目。

[!TIP] ③ GEPA（Agrawal et al. 2025）——反思式 prompt 进化（本文的主要批评对象） GEPA = Genetic-Pareto，一个样本高效的 prompt 优化器：收集执行轨迹（推理、工具调用、中间输出），用自然语言反思来诊断错误、做信用分配、提议 prompt 更新；用一个遗传-Pareto 搜索维护"高性能 prompt 的前沿"以避开局部最优。实证上 GEPA 能超过 GRPO 等 RL 方法、也超过 MIPROv2，且 rollout 少达 35×。ACE 的批评：GEPA 明确把 brevity（简洁）当优点，但这会把领域启发式/工具规则/失败模式一并抽象掉；在需要"细节密集指导"的 agent/知识任务上，成功恰恰依赖累积而非压缩。见 [[ref19_gepa]]。

[!TIP] ④ Dynamic Cheatsheet（DC，Suzgun et al. 2025）——测试时学习的外部记忆（ACE 的直接灵感来源） DC 在推理时维护一份"可复用策略 + 代码片段"的自适应外部记忆（cheatsheet），不断用新遇到的输入输出更新它，从而跨任务积累并复用知识。最大优点：不需要 GT 标签，模型能从自己的生成里"自己整理小抄"。致命问题：它靠整体重写（DC-CU 每步重生成整份小抄，或 DC-RS 从检索样本重写摘要）→ 随着内容变多，模型倾向于越写越短，最终 context collapse。ACE 明确"受 DC 的 agentic 设计启发"，但用增量 delta + 确定性合并替换了它的整体重写。

2.2 两个根本限制（配 Figure 2）

Brevity bias：Gao et al. (2025) 在"为测试生成优化 prompt"里记录了这个效应——迭代方法反复产出近乎一样的指令（如"Create unit tests to ensure methods behave as expected"），牺牲多样性、漏掉领域细节。更糟的是这种收敛还会跨迭代传播同一批错误（优化后的 prompt 常继承 seed 的缺陷）。

Context collapse：作者在 AppWorld 上做了个案研究，观察到当 LLM 被要求在每步"整体重写累积上下文"时——

Figure 2 逐元素解读（全文最有冲击力的一张图，横轴"# adaptation steps"、纵轴"# tokens in context"）： - 从 step 0 起，上下文 token 数稳步爬升（红线一路上扬），在 step 60 达到 18,282 tokens、精度 66.7（右上气泡）。 - 紧接着的下一步（step 61）：上下文断崖式坍缩到只有 122 tokens，精度暴跌到 57.1（中下气泡）——这甚至比"完全不做自适应"的基线精度 63.7 还低（左下气泡"Accuracy w/o context: 63.7"）。 - 坍缩后曲线又从近零重新爬升，说明积累的知识被瞬间抹掉、又得从头再来。 - 关键结论：这不是 DC 独有的 bug，而是"端到端 LLM 重写上下文"的结构性风险——积累的知识可能被突然擦除而非保留。这张图就是 ACE"不做整体重写、只做增量 delta"这一核心设计的直接动机。

[!TIP] 什么是 context collapse（上下文坍缩）？（本文提出的关键概念，讲透） 定义：当把"更新上下文"实现为"让 LLM 每步把整份累积上下文重新写一遍"时，随着上下文变长，模型会不由自主地把它压缩成一段更短、信息更少的摘要，造成信息量的戏剧性、往往是突变式的丢失。 为什么会发生？ 两股力叠加：① LLM 天生有"总结/压缩"的倾向（训练目标使然）；② 长输入下"忠实逐字复述所有细节"本身对模型是高难任务，稍不留神就"顺手概括了"。于是一旦触发，几十步辛苦积累的 playbook 可能在一步里蒸发。 它和 brevity bias 的区别：brevity bias 是"优化器主动追求简洁"（价值取向问题）；context collapse 是"重写机制被动导致细节流失"（机制脆弱性问题）。ACE 用结构化增量更新同时避开两者——既不追求简洁（保留全部条目），也不整体重写（不给坍缩机会）。

3 方法：Generator / Reflector / Curator 三角 + 增量 delta + grow-and-refine

ACE 的设计哲学一句话：不把知识浓缩成简短摘要或静态指令，而把上下文当作不断累积、精炼、组织策略的 evolving playbook。 受 DC 的 agentic 设计启发，ACE 引入三种角色的结构化分工（Figure 4），并针对 §2.2 的两个限制给出三个创新：(1) 专门的 Reflector（把"评估 + 提炼洞见"从"整理"里分离）；(2) 增量 delta 更新（局部编辑替代昂贵的整体重写）；(3) grow-and-refine（在稳步扩张与去冗余之间平衡）。

Figure 4 逐元素解读（方法总览图，信息从左向右流动）： - 最左输入：一叠 Query + 一本 Context Playbook（画成带条目的笔记本），一起喂给第一个组件。 - ① Generator（第一个 LLM）：吃 query + 当前 playbook，产出 Trajectory（推理轨迹）——里面既有奏效的策略，也有反复踩的坑；同时它会标注哪些 bullet 有用/有误导，为下游反馈提供依据。 - ② Reflector（第二个 LLM，头顶有个"迭代精炼"的回环虚线箭头）：批判性地分析这些轨迹，抽出 Insights（具体教训）；可跨多轮迭代精炼（图中虚线自环），把教训越磨越准。 - ③ Curator（第三个 LLM）：把 insights 合成紧凑的 Delta Context Items（delta 条目）。 - 底部回边「Update」：delta 条目通过轻量、非 LLM 的确定性逻辑并回 Context Playbook（注意这条 Update 路径不经过 LLM，所以快、稳、可并行）。然后循环。 - 闭环含义：每轮都让 playbook净增长一点（保留旧条目 + 追加新洞见），而"评估—提炼—整理"被拆给三个专职角色，避免让单个模型既当运动员又当裁判又当档案员。作者说这"镜像了人类学习：实验 → 反思 → 巩固"。

[!TIP] 什么是 playbook（战术手册）？为什么是本文的核心隐喻？ playbook 原指体育/军事里"预先编好的战术手册"。在 ACE 里，它是上下文的组织形态：一堆结构化、逐条列举的 bullet，每条捕捉一个"可复用策略 / 领域概念 / 常见失败模式"，并带元数据（唯一 ID + helpful/harmful 计数）。 与"memory 条目"的关系：概念上类似 DC 的记忆条目或 A-MEM 的记忆项，但在其上加了两样东西——① 结构化元数据（ID + 计数器，可追踪某条到底帮没帮上忙）；② 分区组织（如"策略与硬规则 / 代码模板 / 排错与陷阱"三大节，见 Figure 3）。 为什么用"手册"而不是"摘要"？ 因为手册是增量可追加、条目可独立引用/删改的；摘要是整体的、牵一发动全身的。手册天然适配"增量 delta 更新"，摘要天然招致"整体重写→坍缩"。

Figure 3 给了一份真实 ACE-生成 playbook 的片段，是理解"手册长什么样"的最好实例：

Figure 3 逐元素解读（标题"The Generated ACE Playbook on AppWorld"，分三节）： - STRATEGIES AND HARD RULES：条目 [abr-00009]——"处理涉及时间敏感事务（如从联系人解析角色）时，务必从正确来源解析身份、把日期范围比较做进去、字符串匹配前先核对相等条件……"。这是一条领域硬规则。 - USEFUL CODE SNIPPETS AND TEMPLATES：条目 [code-00013]——给了一段可直接用的 Python（用 defaultdict(list) 把歌名映射到艺术家名），供"按艺术家聚合处理歌曲"复用。注意 playbook 里存的不只是自然语言规则，还有可执行代码。 - TROUBLESHOOTING AND PITFALLS：条目 [ts-00009]——"若认证失败，系统性排错：用手机号而非邮箱当用户名、从 supervisor 清理凭据、查 API 文档核对参数……不要绕过去用 workaround。" - 共同信息：每条都有唯一 ID 前缀（abr-/code-/ts- 标明所属节），这正是"增量 delta 更新"能定位到单条的基础。整份 playbook 就是一本"带索引的、可执行的作战手册"。

3.1 Incremental Delta Updates（增量 delta 更新）

ACE 的核心设计原则：把上下文表示成一堆结构化、逐条列举的 bullet，而非单一的整体 prompt。每个 bullet 由两部分构成：

• (1) metadata（元数据）：一个唯一标识符 + 若干计数器（记录它被标为 helpful / harmful 的次数）；
• (2) content（内容）：一个小单元，如一条可复用策略、一个领域概念、或一种常见失败模式。

解新问题时，Generator 会高亮哪些 bullet 有用/有误导，这份反馈引导 Reflector 提出纠正性更新。这种"逐条化"设计带来三个性质：

[!TIP] 逐条化（itemized）带来的三个性质 + 举例 1. localization（定位性）：只更新相关的那几条 bullet，不动其余。举例：发现"分页只翻了 10 页导致漏数据"，只需修改/新增"分页"那一条（如 [api-pagination]），"身份解析"那条完全不受影响。 2. fine-grained retrieval（细粒度检索）：Generator 能聚焦在最相关的知识上（因为条目独立、可被单独引用，见 Figure 12 里 Generator 要输出 bullet_ids 列表标明用了哪几条）。 3. incremental adaptation（增量自适应）：推理时可高效地合并、剪枝、去重——因为操作对象是"一条条 bullet"而不是"一整段文本"。 对比整体重写：ACE 不重新生成整份上下文，而是增量产出紧凑的 delta context（Reflector 蒸馏出的一小撮候选 bullet，由 Curator 并入）。这避免了全量重写的算力与延迟，同时保证旧知识被保留、新洞见被稳步追加。上下文越长，这套的可扩展性优势越明显。

[!TIP] 举个"delta 更新"的完整例子（把机制走一遍） 假设当前 playbook 有 20 条 bullet。来了一道"统计 Spotify 里所有歌单数"的任务： 1. Generator 读 playbook + 任务，写代码，但用了 for i in range(10) 分页 → 只拿到前 10 页 → 少数了 13 个歌单 → 失败。它在轨迹里标注"分页相关的 bullet 似乎没覆盖这种情况"。 2. Reflector 对比失败轨迹（+ 有 GT 时对比标准答案），诊断出根因："用了固定 range(10) 而非"翻到空为止"的循环"，产出一条 insight："分页应 while True 直到 API 返回空再 break"。 3. Curator 把这条 insight 变成一个 ADD 操作：{type: ADD, section: "apis_...", content: "About pagination: 用 while True 而非 range(10) 循环 page_index"}（见 Figure 11 的真实输出）。 4. 确定性合并逻辑（非 LLM）给它分配一个新 ID（如 [api-00021]）、追加到"API"节。其余 20 条纹丝不动。 下次再遇到分页任务，Generator 就能引用 [api-00021]，且这条会随着"被标 helpful"而计数器 +1。整个过程没有任何一步"重写整份 playbook"，所以永远不会坍缩。

3.2 Grow-and-Refine（生长-精炼）

光增量生长还不够——上下文需要保持紧凑与相关。grow-and-refine 的机制：

• grow（生长）：带新 ID 的 bullet 被追加；已有 bullet 就地更新（如自增 helpful/harmful 计数器）。
• refine（精炼）：一个去重步骤通过语义 embedding 比较 bullet、剪掉冗余。
• 触发时机：可主动（proactive）——每次 delta 之后就精炼；也可惰性（lazy）——只在上下文窗口被超出时才精炼。按应用对延迟/精度的需求二选一。

[!TIP] grow-and-refine 的设计动机与权衡（讲透） 它要同时满足两个矛盾诉求：① 保留足够多的积累经验（越多越能"从经验学习"）vs ② 保持上下文紧凑（省成本、限噪声）。 - grow 保证不丢：新知识永远是"追加"，旧条目只会被"就地增强"，不会被覆盖——这从机制上杜绝了 context collapse。 - refine 保证不肿：用 embedding 去重，把语义重复的 bullet 合并；剪枝时优先删过时/低效/被标 harmful 的条目（元数据在这里派上用场）。 - proactive vs lazy 的权衡：proactive 上下文更干净但每步多花去重开销；lazy 更省算力但上下文可能暂时冗余。这是把"何时清理"做成可配置旋钮，而非写死。 一句话：grow-and-refine = "只进不出的增长" + "定期的语义级垃圾回收"，让 playbook 既单调保真又有界可控。

三节合起来的效果：增量更新 + grow-and-refine 让上下文能自适应地扩张、保持可解释，并避免整体重写引入的方差（variance）。

3.3 关键实现细节（公平性与超参）

• 同一个 LLM 扮演三角：为保证公平、隔离"上下文构造本身"的收益，Generator/Reflector/Curator 用同一个模型（默认 DeepSeek-V3.1 的 non-thinking 模式），防止"更强的 Reflector/Curator 把知识偷渡给更弱的 Generator"。
• batch size = 1：每个样本构造一个 delta context。
• 离线自适应：Reflector 精炼轮数上限 = 5，epoch 上限 = 5。
• 离线 vs 在线：离线（如系统 prompt 优化）在训练集上优化、测试集上 pass@1 评估；在线（如测试时记忆自适应）在测试集上顺序评估——每个样本先用当前上下文预测、再据此更新上下文。

4 实验：agent + 领域，离线 + 在线，全面超基线

评估要点摘要：① ACE 让 agent 能自我改进（AppWorld 最高 +17.1%，且无需 GT 标签）；② 领域 benchmark 大涨（金融平均 +8.6%）；③ 消融证明 Reflector、多 epoch、增量 delta 每一项都关键；④ 成本/延迟大降（平均降 86.9% 延迟）。

4.1 任务与数据集

• LLM Agent：AppWorld（Trivedi et al. 2024）——自主 agent 任务套件，涉及 API 理解、代码生成、环境交互（邮件/文件系统等真实 app），分 normal 与 challenge 两档难度。官方排行榜显示投稿时最好系统也只有 60.3% 平均精度，凸显其难度与真实性。
• 领域推理：主案例是金融——FiNER（给 XBRL 财报 token 打 139 种细粒度实体标签）和 Formula（应用金融概念做数值计算）；另加 DDXPlus（医疗诊断）和 BIRD-SQL（text-to-SQL），后两者来自 StreamBench。
• 指标：AppWorld 用官方 TGC（Task Goal Completion）/ SGC（Scenario Goal Completion）；FiNER/Formula/DDXPlus 用精确匹配准确率；BIRD-SQL 用 GPT-4o-mini 做 LLM-as-a-judge。

4.2 基线

[!TIP] 被对标的五个基线（一句话各讲清） - Base LLM：直接用数据集作者给的默认 prompt，无任何上下文工程。 - ICL（In-Context Learning）：把训练示范塞进 prompt（few-shot / many-shot），能塞多少塞多少。 - MIPROv2：DSPy 里流行的 prompt 优化器，用贝叶斯优化联合优化系统指令 + 上下文示范（设 auto="heavy"）。 - GEPA：反思式 prompt 进化 + 遗传-Pareto 搜索（详见 §2.1 ③）。 - Dynamic Cheatsheet (DC-CU)：测试时学习的自适应外部记忆，用 cumulative 模式（详见 §2.1 ④）。

4.3 Agent 结果（AppWorld，Table 1）

DeepSeek-V3.1-671B 为 Base LLM，在官方 ReAct 实现上评估：

分析： - 离线：ReAct + ACE 相比 ICL / GEPA 分别高 12.3% / 11.9%——说明"结构化、演化、细节化"的上下文比"固定示范"或"单条优化指令"更能驱动 agent 学习。 - 在线：继续超过 DC 平均 7.6%。 - 无 GT 标签也强：ReAct + ACE（无标签）相比 ReAct 基线平均 +14.8 分。原因是 ACE 能利用执行时天然可得的信号（代码跑成功/失败）引导 Reflector 与 Curator 形成"成败教训"。 - 打榜（Figure 5，附录 D 是榜单快照）：ReAct + ACE（59.4% 平均）追平 GPT-4.1 驱动的头名 IBM CUGA（60.3%），尽管用的是小得多的开源 DeepSeek-V3.1；在线自适应下，在 test-challenge 上 TGC 反超 CUGA 8.4 分、SGC 反超 0.7 分。

[!NOTE] 作者特意脚注：IBM CUGA 只作为"ACE 处在同一性能区间"的粗略参照，不当方法基线、不做直接对比（CUGA 的内部设计与 ACE 的"上下文自适应"关注点不同）。这体现了论文比较的严谨性——所有真正的基线都在相同设置下评估。

4.4 领域结果（金融，Table 2）

分析：有 GT 标签时，ACE 离线相比 ICL/MIPROv2/GEPA 平均高 10.9%（Formula 单项 +18.0！），因为金融任务需要精确的领域知识（XBRL 规则、金融概念），远超"固定示范/单条优化 prompt"能承载的。在线相比 DC 平均高 6.2%。

[!IMPORTANT] 关键限制信号：当缺乏可靠反馈（无 GT 标签、无执行结果）时，ACE 和 DC 都可能退化——构造出的上下文会被虚假/误导信号污染。看表里"无标签"的 FiNER 行：ACE 只 +0.4（离线）甚至 -3.4（在线），DC 更是 -2.4/-3.7。这说明 context adaptation 的效果严重依赖反馈质量——在 agent 任务里 ACE 无标签也强（因为有代码执行结果这种"天然 verifier"），但在"无天然 verifier 且无标签"的领域任务里就吃力。这是 §5 展开的核心 limitation。

其他领域（附录 A.2）：DDXPlus 医疗从 75.2 → 90.2（+15.0）（GEPA 仅 +1.2）；BIRD-SQL text-to-SQL 平均 +5.1。说明"手册式上下文自适应"能跨领域迁移。

4.5 跨 LLM 泛化（附录 A.1）

不改算法/prompt、只换骨干模型，ACE 在 GPT-OSS-120B、GPT-5.1、Llama-3.3-70B-Instruct 上都一致提升（常 5–12 分）。有趣的是 Llama-3.3-70B 增益较小——因为 ACE 依赖中间反思/校准的质量，越弱的模型产出的反馈越噪，这与 §5 的"依赖强 Reflector"一致。

4.6 消融与敏感性（Table 3 / 18）

三个设计因子的贡献（AppWorld，DeepSeek-V3.1，平均分）：

[!IMPORTANT] 消融讲透：三个因子逐个加都涨——加 Reflector（55.1→56.8）、再加多 epoch（56.8→59.4）、在线加 offline warmup（56.1→59.5）。而最关键的是"增量 delta 更新"（附录 A.5 / Table 18 单独做）：去掉增量更新（退回整体重写），AppWorld test-normal 从 76.2/64.3（TGC/SGC）暴跌到 67.3/46.4——TGC -11.7%、SGC -27.8%。这直接证明：delta 更新不是锦上添花，而是"通过保住本会被 context collapse 抹掉的信息"来贡献了 ACE 的一大半增益。这与 [[ref09_meta-harness]] 的"raw traces 是决定性成分"、[[ref17_self-harness]] 的"非回退回归门"一样，都是"别压缩/别丢信息"这一原则的不同侧面体现。

对 Reflector 质量的鲁棒性（附录 A.4）：换弱 Reflector（GPT-OSS-120B）ACE 仍 +5.9；甚至每 X 步注入一次对抗性 harmful bullet，只要 X≥5（即不是每步都投毒）就仍高于 Base LLM（如 X=5 时 76.1、X=50 时 78.2，无投毒 78.3）；只有"每步都投毒"（X=1）才跌到 66.7（低于 Base 70.7）。grow-and-refine 的语义去重 + harmful 元数据过滤是第一道防线。

超参不敏感（附录 A.6）：反思轮数 3–5、去重阈值 50–90%、剪枝触发 10K–100K token，性能变化都不大且始终高于基线。

4.7 成本与速度（Table 4）

得益于增量 delta + 非 LLM 的合并去重，ACE 在成本/延迟上优势显著：

[!TIP] "更长上下文 ≠ 更高服务成本"——KV cache 的账（讲透） 一个直觉反驳是："ACE 的 playbook 那么长，评估时不是更贵吗？"（评估阶段 ACE 输入 token 确实比 GEPA 多 117.4%，见 Table 14）。作者的回应是 KV cache 复用： - 什么是 KV cache：Transformer 推理时会缓存已处理 token 的 Key/Value；如果一段上下文前缀在多次调用间不变，就能跳过对它的重复 prefill（重新编码），直接复用缓存。 - ACE 为何特别受益：playbook 是相对稳定的前缀（每步只在末尾加几条 delta），所以绝大部分能命中缓存。作者用 OpenAI API（GPT-5.1）实测：评估阶段 91.8% 的输入 token 从缓存供给，把计费输入成本降了 82.6%（相比按"原始 token 数"计费）。 - 启示：在现代推理基建（缓存 + 压缩 + offload）下，"上下文富有"的方法在部署上会越来越划算。这为"让上下文长大"这条路线做了系统层面的辩护。

5 讨论与总结

• 对在线/持续学习的意义：ACE 是"模型微调"的一个灵活且便宜的替代（改上下文比改权重便宜）。且因上下文人类可读，ACE 天然支持选择性遗忘（隐私/法规/纠错场景删掉特定条目），这是权重更新做不到的。
• 核心限制（作者自陈）： 1. 依赖一个足够强的 Reflector：若 Reflector 无法从轨迹/结果里提炼出有意义的洞见，构造出的上下文会变噪甚至有害（与 DC 同病）。领域任务里若"没有模型能抽出有用洞见"，上下文自然也就没有。 2. 不是所有任务都需要富上下文：像 HotPotQA 更受益于简洁高层指令（怎么检索+综合证据）；Game of 24 这种固定策略的游戏只需一条可复用规则，多余上下文反而冗余。 3. ACE 最有用的场景：需要细节化领域知识、复杂工具使用、或环境专用策略——即那些"超出模型权重或简单系统指令已内化范围"的任务。

[!TIP] 附录 C：ACE vs GEPA vs DC 的系统性对比（作者亲述，极有价值） | 维度 | GEPA | Dynamic Cheatsheet (DC) | ACE | |---|---|---|---| | 适配形态 | prompt 进化（选更好的整条指令 prompt） | 测试时外部记忆 | 累积/保留大量细粒度可复用洞见 | | 表示 | 单条端到端优化的完整 prompt | 一整份 cheatsheet | 结构化、逐条的 Playbook | | 更新机制 | 进化循环里生成+选择新 prompt 变体 | 整体重写（DC-CU 每步重生成 / DC-RS 从检索样本重写） | 增量 delta + 确定性合并（Curator 只写新洞见） | | 主要风险 | brevity bias（细节被抽象掉） | context collapse（细节被压没） | 依赖 Reflector 质量 | | 典型场景 | 有 rollout 预算、追求单条最优指令 | 单轮独立推理（AIME、Game-of-24、GPQA） | 多轮 agent + 领域知识密集（AppWorld、FiNER） | 一句话：ACE 相对 GEPA 的差异是"累积 vs 压缩"，相对 DC 的差异是"增量 delta vs 整体重写"。

个人思考

⭐ 与 [[ref09_meta-harness]] / [[ref17_self-harness]] 的三方定位（本项目最该讲清的一组关系）

ACE 是这两篇的共同主基线，把三者放一起能把"自我改进/harness 演化"的设计空间讲透：

我的判断： - ACE 是"文本层"的自我改进天花板。它把"上下文=会退化的摘要"这个隐性假设打破，换成"上下文=会长大的手册"，并用工程手段（增量 delta + 确定性合并 + grow-and-refine）把 context collapse 这个具体病根治住。Table 18（去掉增量更新 SGC 暴跌 27.8%）是全文最硬的因果证据，也和 ref09/ref17 的"别压缩信息"殊途同归。 - Meta-Harness 是"ACE 的上一层抽象"：ACE 手工设计了"Generator→Reflector→Curator + delta + grow-and-refine"这套固定的 harness；Meta-Harness 则把"设计这套 harness 本身"交给搜索——所以它能发现比 ACE 更省 token、更准的上下文管理策略（+7.7 分且上下文少 4×）。换句话说，ACE 是 Meta-Harness 搜索空间里的一个（很好的）点。 - Self-Harness 是"ACE 谱系的受控变体"：ref17 明确把 ACE 归入"为后续调用进化上下文"这一支，但它把改进对象从"上下文"抬到"整个 harness 面"，并用"回归门 + 有界编辑"上了安全锁。

一个合流猜想（可作本项目"未来方向"）：ACE 的"delta 条目 + 计数器元数据 + grow-and-refine 去重"其实是一套很好的"经验管理数据结构"；完全可以把它塞进 Meta-Harness 的"全历史文件系统"里，让强提议者不仅能 grep 原始轨迹、还能读到 ACE 式的"已蒸馏、带 helpful/harmful 标注的手册"——原始诊断（Meta-Harness）+ 结构化蒸馏（ACE）+ 回归门（Self-Harness） 三合一。

方法论启示（可迁移的通用思路）

1. "增量 delta vs 整体重写"是一条可推广的架构原则。任何"让 LLM 维护一份会长大的状态（记忆/文档/配置/代码）"的场景，都应优先考虑结构化条目 + 局部编辑 + 确定性合并，而非"每次让模型重写整份"——后者几乎必然招致某种形式的 collapse/drift。这一条我认为是 ACE 最值得抄的工程范式。
2. 把"评估/提炼"和"整理/写入"解耦（Reflector vs Curator）。让同一个模型既当裁判又当档案员会互相干扰；拆成两个专职角色 + 一个非 LLM 的确定性合并层，既提质又提速（合并层不花 LLM 调用，还能并行）。
3. 给每条知识挂元数据（ID + helpful/harmful 计数）。这让"哪条经验真的有用"变得可追踪、可剪枝、可审计——是"自我改进系统"里被低估的基础设施。
4. 反馈质量是上限。ACE 在"有天然 verifier"（代码执行）时无标签也强，在"无 verifier 无标签"时退化——提醒我们：做任何 test-time 自适应，先确认反馈信号是否可信，否则自适应会主动引入噪声。

在我的工作中能怎么用

• 我们这个 pdf-paper-reader skill 本身就是个 harness，而它读过的论文笔记其实就是一份手动维护的 playbook。可以把 ACE 的思路落进来：把"每次读论文踩的坑（如 Figure 漏检、坐标错位、related 双链写错 slug）"沉淀成带 ID 的 bullet（如 [fig-crop-001] 页顶截图常漏检 → 先 search_for 定位再补渲染），增量追加进 skill 的经验库，而不是每次重写整份 SKILL.md——这正是"delta 更新防坍缩"的直接应用。
• grow-and-refine 的"语义去重" 也可借鉴：笔记积累多了以后，用 embedding 找出重复的方法论条目合并，保持 skill 精炼。
• 若想复现 ACE 本身：最低成本切入点是金融 FiNER/Formula（离线自适应、有 GT 标签、单模型三角），比 AppWorld（需搭 agent 环境）轻得多。

开放问题 / 疑问

• 无 verifier 场景怎么办？ ACE 最漂亮的"无标签自我改进"其实靠的是"代码执行成功/失败"这个天然 verifier。对没有干净 verifier 的开放任务（写作、开放问答），Reflector 拿什么当"成败信号"？论文承认这是软肋（Table 2 无标签行退化），但没给方案。
• playbook 会不会无限膨胀 / 过拟合到某 benchmark？ grow-and-refine 控制冗余，但"跨 benchmark 泛化"只在附录零星验证（DDXPlus/BIRD-SQL）。手册里那些"AppWorld 专用硬规则"（如 Figure 3 的 [abr-00009]）迁到别的环境是包袱还是财富？
• "同一模型扮三角"是公平性选择，但也是能力天花板。作者为隔离变量刻意不用更强的 Reflector；可现实里若允许用强 Reflector 蒸馏给弱 Generator，收益会大很多（附录 A.4 已见端倪）。"公平的 ACE"和"最强的 ACE"之间的差距有多大，值得单列。
• 相比 Meta-Harness 的"代码空间"，ACE 的"文本空间"上限在哪？ ref09 已用实验回答了一部分（代码更省 token、更可检视），但"文本手册"在"可读性/可人工干预"上反而更友好——两条路线的适用边界，是本项目值得深挖的问题。

局限性（补充作者未强调的）

• 依赖强 Reflector + 依赖可靠反馈是两个叠加的前提，缺一个就退化——这让 ACE 在"弱模型 + 无 verifier"的组合里价值有限（正是 Llama-3.3 增益小 + 无标签 FiNER 退化的原因）。
• "上下文自适应"终究没改权重：它把知识存在 prompt 里，受上下文窗口/服务成本约束；虽有 KV cache 缓解，但知识规模无法与"写进权重"相比。
• 报告的 playbook 是任务专用的（AppWorld 手册 ≠ FiNER 手册），跨任务复用性未系统验证。