Agentic Context Engineering（ACE）：让大模型“越用越聪明”的上下文工程方法
你有没有发现：
大模型（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 系统越用越聪明、可审计、可回滚。