让上下文像代码库一样演化：ACE 论文精读
很多团队优化 AI Agent 时，都会走向同一条路：收集失败案例，让模型复盘，再让它重写系统提示词。
这个方法看起来合理，却藏着一个危险。上下文越积越长，模型越倾向于把它压缩成短摘要。一次不好的重写，就可能抹掉此前积累的工具用法、领域经验和失败教训。
在 AppWorld 的一个实验里，上下文从 18,282 tokens 突然坍塌到 122 tokens，准确率也从 66.7 降到 57.1，甚至低于完全不做上下文适配时的 63.7。
ACE（Agentic Context Engineering）这篇论文要解决的，正是这个问题。
它的核心判断可以概括成一句话：不要把上下文优化成一条更精炼的 prompt，而要把它维护成一份能够持续演化的 playbook。
我把论文的机制、实验和适用边界重新制作成了一份交互式阅读页面：
为什么“更短的提示词”不一定更好
论文指出，现有上下文适配方法常见两类失败。
第一类是 brevity bias，简短偏差。
提示词优化器通常倾向于生成简洁、通用、容易在验证集上生效的指令。但 Agent 真正需要的往往不是一句原则，而是具体的 API 使用方法、工具调用顺序、领域规则和常见失败模式。压缩得越干净，这些能直接影响执行结果的细节越容易消失。
第二类是 context collapse，上下文坍塌。
如果每轮都让 LLM 重写整份上下文，它实际上承担了三个任务：判断当前执行哪里出了问题、提炼可以复用的经验、重新组织全部历史知识。上下文规模变大后，这三个任务会互相干扰。模型为了完成重写，最自然的做法就是总结，而总结不可避免地丢失细节。
所以问题并不是“模型还不够会写 prompt”，而是更新上下文的基本单位和工作流设计错了。
ACE 如何让上下文持续生长
ACE 把一次学习过程拆成三个角色。
Generator 负责执行任务。它读取当前 playbook，完成推理、工具调用和环境交互，并产生完整轨迹。
Reflector 负责复盘。它检查轨迹、执行结果和反馈信号，从成功与失败中提炼可以复用的策略。
Curator 负责策展。它不重写整份上下文，而是把洞见整理成少量结构化 delta，再由确定性程序合并到 playbook。
这里最关键的变化，是上下文不再是一整块 prompt，而是一组独立条目。每个条目包含唯一 ID、具体策略，以及它曾经被标记为 helpful 或 harmful 的次数。
这种条目化结构带来三个好处：
- 只修改与当前反馈相关的条目，不触碰其他已经验证过的知识。
- 可以按任务检索相关策略，而不是每次读取一段没有结构的历史文本。
- 新经验能够以 delta 形式追加、合并和去重，不需要重新生成全部上下文。
论文把这个过程称为 grow-and-refine：先允许 playbook 吸收新知识，再通过语义去重、计数更新和按需裁剪控制冗余。
这更像维护代码库，而不是润色文章。新增知识对应新增条目，修正错误对应局部 patch，合并重复内容对应重构。历史不会因为一次生成失败而被整体覆盖。
实验真正支持了什么
ACE 在 Agent 和领域推理任务上都取得了明显提升。
在以 DeepSeek-V3.1 为基础模型的 AppWorld 实验中，ReAct 基线平均分为 42.4。ACE 的离线有标签版本达到 59.4，在线无标签版本达到 59.5。后者不依赖 ground-truth labels，而是利用代码是否成功执行、环境状态是否符合目标等自然反馈更新上下文。
在金融推理任务中，FiNER 和 Formula 的基础模型平均准确率为 69.1。GEPA 的离线有标签结果为 72.5，ACE 达到 81.9。医学推理 DDXPlus 上，ACE 又把准确率从 75.2 提高到 90.2。
更重要的是消融实验。
在 AppWorld test-normal 上，不使用增量更新的 ACE，TGC 与 SGC 平均分为 56.9；使用增量更新后提高到 70.3。也就是说，ACE 的主要收益并不只是来自“多调用了几个模型”，而是来自它避免了整段重写，保住了历史经验。
上下文更长，为什么成本反而更低
ACE 生成的 playbook 通常比单条优化提示词更长。但适配成本并不只由最终上下文长度决定，还取决于为了得到这份上下文，需要进行多少次 rollout、验证和重写。
在 AppWorld 离线适配中，相比 GEPA，ACE 的适配延迟降低 82.3%，rollout 数量减少 75.1%。在 FiNER 在线适配中，相比 Dynamic Cheatsheet，ACE 的适配延迟降低 91.5%，token dollar cost 从 17.7 美元降到 2.9 美元。
原因很直接：ACE 不需要反复验证大量候选 prompt，也不需要在每轮重新生成全部上下文。稳定的 playbook 前缀还可以被 prompt cache 或 KV cache 复用。论文在 GPT-5.1 上观察到，评估阶段 91.8% 的输入 tokens 来自缓存。
所以，“长上下文一定更贵”是一个不完整的判断。真正应该比较的是整个适配与推理流程的摊销成本。
ACE 不是万能记忆系统
这篇论文最值得肯定的一点，是作者没有把 ACE 描述成适用于所有任务的通用答案。
ACE 的第一个前提是 存在可靠反馈。如果没有正确答案、测试结果、执行成功信号或可验证的环境状态，Reflector 可能把错误判断写入 playbook。在金融在线无标签实验中，ACE 在 FiNER 上从基础模型的 70.7 降到 67.3，说明上下文确实可能被低质量反馈污染。
第二个前提是 任务值得积累大量细节。复杂工具使用、长期 Agent、金融和医疗等领域知识非常适合 ACE。但对于只需要一条稳定规则的任务，或者更依赖即时检索的问答任务，长 playbook 可能没有必要。
第三个前提是 维护机制必须是系统的一部分。如果只是让模型自由生成“记忆”，却没有 ID、计数、确定性合并、去重和裁剪，那么系统仍然可能回到无结构文本不断膨胀或突然坍塌的老路。
如果要在自己的 Agent 中借鉴 ACE
不一定要完整复现论文，先检查下面五件事：
- 把记忆拆成最小可复用条目。 每条只表达一个策略、事实或失败模式，并保留稳定 ID。
- 分离执行、反思和写入。 负责做任务的模型，不要同时决定如何改写全部记忆。
- 让模型提出 delta，让程序负责合并。 删除、覆盖和去重尽量使用可审计的确定性逻辑。
- 先设计反馈，再设计自我改进。 没有可靠评价信号，自我改进很容易变成自我污染。
- 同时记录效果与成本。 不只看最终准确率，还要看 rollout、适配延迟、缓存命中率和上下文增长速度。
ACE 的价值，不只是提出了 Generator、Reflector、Curator 三个名字。它真正改变的是上下文工程的对象：从“寻找一句最优提示词”，转向“维护一个可以长期演化的知识系统”。
当 Agent 需要连续工作、反复遇到相似任务，并从执行结果中学习时，这种转变很可能比继续打磨 prompt 更重要。
完整的交互式图表、实验对比和机制拆解，可以在这里阅读：
论文与代码：
If you read this far — thank you.
Come tell me what you thought on X.