Agentic Context Engineering

先讲一个故事

想象一个负责在 AppWorld 里完成多步任务的智能体：它要调用账户、订单等 API，任务越做越多，前几次踩过的坑本来值得记住。工程师最初用一份不断更新的 cheatsheet 帮它；每轮结束，再请模型把旧笔记重写成“更精炼的版本”。起初读起来更整洁，但某次重写把具体 API 用法、代码片段和失败教训统统压成几条泛化建议，智能体又开始犯旧错。

问题不只是“笔记太长”，而是每次整体改写都可能把有用细节一起抹掉。于是团队换了思路：执行者继续做任务，复盘者只从轨迹中提炼可验证的经验，整理者把经验作为带编号的小条目增量并入 playbook，而不是整份推倒重写。这个转折正是 ACE 关注的方向。

教学性场景：这是依据论文 AppWorld 任务、context collapse 案例和 Generator–Reflector–Curator 机制编写的合成故事，不是作者经历或论文中某次真实事件。

故事与技术如何对应

• 故事中的持续任务执行者对应论文的 Generator：拿当前 playbook 解决任务，并标出相关条目。
• 整体改写导致经验消失对应论文指出的 context collapse：monolithic rewriting 可能缩短上下文并丢失信息；这是论文展示的风险，不代表每种改写必然失败。
• 从轨迹复盘、抽取可操作教训对应 Reflector；把小条目合并进 playbook对应 Curator 输出增量操作，再由程序整合。
• 证据边界：论文 Figure 2 展示 collapse 案例，Figure 3 给出 AppWorld playbook 片段，Figure 4 展示三组件架构。故事的角色和情节是类比；组件、任务类型与图中内容是论文事实。

先给结论

ACE 最有价值的地方，不是又提出一个 prompt optimizer，而是把 context 从一段会被反复重写的文本，改造成一个可以持续增长、局部追加、可审计的 playbook。

如果只读论文，ACE 容易被理解成 “Generator-Reflector-Curator 三个 LLM 角色互相配合”。但结合 repo 之后，真正的系统形态更清楚：它维护一个分 section 的 bullet list，每条规则有 ID，主循环从执行轨迹中提取新 lesson，再由 Curator 输出 JSON operations，最后用确定性逻辑并入 playbook。

研究动机

ACE 的起点是一个很实用的观察：很多 context adaptation 方法会走向两个坏方向。

这也是它和 GEPA、Dynamic Cheatsheet 的关键分歧。GEPA 更像在搜索一个强 prompt；Dynamic Cheatsheet 会积累 cheatsheet，但论文认为其 cumulative/full rewrite 路径仍可能塌缩。ACE 的答案是：别每次重写全文，改成 itemized playbook + delta update。

数学表示及建模

ACE 论文不是数学定理型论文，但为了读懂它的贡献，可以把系统压成一个最小状态更新模型。令 \(P_t\) 表示第 \(t\) 步的 playbook，\(\tau_t\) 表示 Generator 在当前样本上的执行轨迹，\(f_t\) 表示 ground-truth、环境返回或自然语言反馈。

这个形式化的关键不是符号本身，而是把 ACE 和普通 prompt optimization 区分开：被优化的对象不是单个 prompt 字符串 \(p\)，而是一个带 section、ID、计数器和可追踪增量的结构化对象 \(P\)。

方法机制

ACE 的方法可以压缩成一句话：用 Generator 产生轨迹，用 Reflector 从轨迹里抽 lesson，用 Curator 把 lesson 变成 playbook delta。

Playbook 表示

论文把 context 表示成一组 structured bullets。主 repo 的通用 playbook 格式类似：

## STRATEGIES & INSIGHTS
[str-00001] helpful=5 harmful=0 :: Always verify data types before processing

## FORMULAS & CALCULATIONS
[cal-00003] helpful=8 harmful=0 :: NPV = sum(Cash Flow / (1+r)^t)

## COMMON MISTAKES TO AVOID
[mis-00004] helpful=6 harmful=0 :: Do not forget timezone conversions

AppWorld repo 的真实 playbook 更偏 agent workflow：硬规则、API source-of-truth、code snippets、common mistakes、verification checklist、troubleshooting。它不是抽象“记忆”，而是能直接放进 ReAct prompt 的操作手册。

训练 / 更新循环

for each sample:
    answer = Generator(question, current_playbook)
    used_bullets = parse_bullet_ids(answer)
    if answer wrong:
        reflection = Reflector(trace, feedback, used_bullets)
        answer = Generator(question, current_playbook, reflection)
    else:
        reflection = Reflector(trace, success_feedback, used_bullets)
    operations = Curator(current_playbook, reflection, question_context)
    current_playbook = deterministic_apply(operations)

Repo 读法

这篇论文必须结合 repo 看。论文写的是完整框架，repo 则暴露了真实可执行路径和未完成边界。

三类 prompt

实验设计

ACE 在两类任务上验证：agent benchmark 和 domain-specific reasoning。

适配方式分两类：offline adaptation 在 train split 上学 context，再在 test 上评估；online adaptation 按顺序处理 test stream，先用当前 context 做题，再基于当前样本更新 context。

关键结果

AppWorld 主表

Finance 主表

为什么 incremental update 重要

我的评论

ACE 对我们最有用的地方，是它把“memory representation”这件事推进到了一个具体 artifact：playbook bullet collection。它不是 embedding，不是 RAG，不是纯 prompt，而是可读、可追加、可日志化的 context object。

它已经解决了什么

• 避免每一步重写整个 cheatsheet/context，降低 context collapse 风险。
• 用 section + bullet ID 给 memory 一个粗粒度结构，让模型可以引用自己用过哪些规则。
• 把 reflection 和 curation 分开，降低“同一个模型边做题边总结边改记忆”的混乱度。
• 提供 offline / online 两种评估路径，适合对齐我们想做的 static cheatsheet + dynamic evolution。

它没有完全解决什么

• 可编辑性还不够。公开 repo 的主路径仍以 ADD 为主，完整 UPDATE / MERGE / DELETE / split / condition / priority 没有成为稳定 patch algebra。
• 冲突处理偏弱。helpful/harmful counters 和 dedup 只能粗略描述条目质量，不能真正表达两条规则的 activation conflict。
• validation gate 不够强。它有 val set / test set，但每个 patch 是否应被接受，并没有以“局部收益 + 全局回归 + 冲突检测”的形式成为核心机制。
• 长度预算主要是 pruning threshold。还不是 rule-level value density 或 marginal utility 选择。

One More Thing

如果把 ACE 接到我们前面讨论的 cheatsheet / GEPA 路线，我建议这样定位：

Cheatsheet bootstrap:
    用很多样本先生成覆盖主分布的初始 playbook M0

ACE-style residual evolution:
    用 Generator/Reflector/Curator 从失败轨迹里生成 candidate patches

Our missing piece:
    patch must be add/refine/merge/delete/condition/reorder,
    and every patch must pass verifier + regression + conflict gates

这样我们不是“做一个 ACE 变体”，而是在 ACE 暴露出来的空档上继续推进：从 evolving playbook 走向 verifier-gated editable memory program。

跨论文洞见：context、harness 与记忆

• Lee 的 Harness Engineering 讲义把 context 放回完整 harness：ACE 的 playbook 是可演化的上下文载体，但可靠改进仍需要工具边界、验证和反馈通路共同约束；仅优化文本并不等于优化整个 agent 系统。
• Dynamic Cheatsheet与 ACE 都让测试时经验进入后续上下文；ACE 的结构化条目和增量并入针对整段重写的塌缩风险。两者差异不能简化成“记忆优劣”，还取决于反馈来源、更新策略与任务分布。
• EvoMemBench提醒我们：记忆系统应按记忆的获取、保留、更新与使用效果评测，而非只看 playbook 是否增长。把 ACE 的 patch 过程接到记忆评测维度，可形成“生成—筛选—回归验证”的闭环；这是研究建议，不是 ACE 已报告的结果。

完整图谱

论文源码中的全部 14 个 includegraphics 图项均收录；图片均按宽度 1600 优化，图注保留源码原文。主文图与附录提示词截图在上文有部分重复展示，此处作为完整索引。

Other Discussion Roles / 其他讨论角色

以下是依照 paper2html 标准七角色模板新增的论文专属讨论；事实边界限于本地存档论文/代码与可公开核验来源，未联网核验的内容明确标示。

playbook = {"rules": []}

def apply_delta(book, lesson):
    # 简化 Curator：新经验作为独立条目追加，旧条目不重写
    next_id = 1 + max((r["id"] for r in book["rules"]), default=0)
    book["rules"].append({"id": next_id, "text": lesson, "helpful": 0, "harmful": 0})
    return book

def record_outcome(book, rule_id, success):
    rule = next(r for r in book["rules"] if r["id"] == rule_id)
    rule["helpful" if success else "harmful"] += 1

# Toy task: API 调用需要先检查账户 ID
apply_delta(playbook, "调用订单 API 前先从用户资料确认 account_id。")
record_outcome(playbook, 1, success=True)
print(playbook["rules"])

Reference / Evidence