你有没有发现：
大模型（LLM）很强，但做 Agent 任务时经常“踩坑反复踩”、今天学会明天忘？
那有没有一种办法，不训练模型参数，只靠“写更好的上下文”，就能让它持续变聪明？ <<Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models>>

这正是 ACE（Agentic Context Engineering）要解决的问题。

1. 背景：为什么“上下文工程”越来越重要？

现在很多企业/团队用大模型做：

• 自动化 Agent（写代码、调 API、执行任务）
• 垂直领域助手（金融/法律/医疗）
• 多工具协作（RAG、数据库、网页、脚本等）

但这些系统普遍有两个痛点：

痛点 A：提示词越改越短、越改越空

很多 prompt 优化方法会导致提示越来越“泛化”：

“你是一个专业助手，请谨慎、逐步推理……”

看起来很合理，但对实际任务帮助不大。作者把这个现象叫做 brevity bias（简短偏好）。

痛点 B：动态重写上下文容易崩

有些方法会整段重写系统提示，结果：

• 把细节经验浓缩掉
• 一次更新把之前积累的知识抹掉
• 性能直接掉回 baseline

作者称这种情况为 context collapse（上下文崩塌）。

2. ACE 的核心思想：把上下文当作“可进化的作战手册”

ACE 不把上下文当成“一段提示词”，而是当作一本可以不断增长的：

Playbook（作战手册）

手册里不是长篇大论，而是一条条“小颗粒知识”，称为 bullet，比如：

• API 分页必须 while True，不要写死 range(10)
• 遇到 401 要先刷新 token
• 金融 XBRL 里某字段的含义是什么

每条 bullet 都有：

• id
• 内容
• 统计信息：被认为 helpful/harmful 的次数

3. ACE 的工作流程：三角色闭环，让模型自我改进

ACE 的设计很工程化，它让同一个 LLM 扮演 3 个角色：

① Generator（执行者）

• 读取 playbook
• 执行任务（写代码/调 API/做推理）
• 记录自己用了哪些 bullet（bullet_ids）

② Reflector（老师）

任务做完后，Reflector 会复盘：

• 哪一步错了？
• 为什么错？
• 正确做法是什么？
• 这次应该记住什么？

并且给本次用到的 bullets 打标签：

• helpful / harmful / neutral

③ Curator（知识管理员）

Curator 不会重写整本手册，而是只做增量更新：

• 只把“新发现的经验”写成新 bullet
• 以 ADD 的形式追加到对应章节
• 避免破坏旧经验

4. 为什么 ACE 有用？关键在“只追加，不重写”

ACE 解决了两个大问题：

✅ 避免 brevity bias

因为它不是把经验压缩成一句话，而是把经验拆成很多条 bullet。

结果就是：上下文可以长，但每条都具体、可执行。

✅ 避免上下文崩塌

因为它不做“一刀切”重写，而是增量增长。

就像软件工程里：

• 不会每次都重写整个系统
• 而是不断提交小 patch + review

5. Grow-and-Refine：手册越长怎么办？

ACE 还考虑了可维护性：

Grow（生长）

每次任务结束，新增一些 bullets。

Refine（精炼）

当手册变得太长：

• 用 embedding 相似度合并重复 bullets
• harmful 次数高的条目降权或删除

这就像：

经验不断积累，但也会定期整理“知识库”

6. 实验结果：好上下文真的能补模型差距

论文在几个任务上验证了 ACE：

AppWorld（复杂 Agent 环境）

ACE 用开源模型 DeepSeek-V3.1，效果能逼近甚至超过强闭源系统。

说明：

工程上，“上下文+记忆”可以部分弥补模型能力差距

金融任务（FiNER / Formula）

这类任务对规则细节非常敏感，ACE 的长 playbook 特别占优势：

• 逐轮把规则写进手册
• 明显超过 ICL / 提示搜索等方法

7. 工程启发：ACE 其实就是“上下文层面的持续学习”

我觉得 ACE 对工程落地特别有价值：

对企业：把生产事故变成知识资产

每次模型犯错，其实都是一次“真实数据”：

• 错误日志
• 工具调用记录
• 单测/环境反馈

ACE 提供一个机制，把这些自动转成可用的 playbook 条目。

长期来看：

系统越来越稳定，而不是永远在重复踩坑

对垂直领域：长规则比短提示更可靠

比如金融/法律/医疗：

• 规则多
• 例外多
• 格式严格

这些都不适合被压成一句“你是专家”。

ACE 的 bullet 化知识更像“行业手册”。

8. 局限：ACE 依赖反馈质量

ACE 不是万能的，论文也明确指出：

• 如果没有标签
• 又没有可靠执行反馈（比如任务是否完成都不知道）

Reflector 就可能“瞎猜”，Curator 会把错误经验写进手册：

适配变成越学越坏

所以实际落地时，必须重视：

• 单测/校验器
• 自动评估信号
• 必要时人工审核

9. 一句话总结

ACE 把 prompt 工程升级成了“上下文工程闭环”：

用 playbook 记录经验
用反思更新经验
用精炼维护经验
让 LLM 系统越用越聪明、可审计、可回滚。