Agentic Context Engineering: 用于自改进语言模型的上下文演化框架

大型语言模型(LLM)应用(如代理和特定领域推理)越来越依赖于上下文适应——通过修改输入(如指令、策略或证据)而非更新权重来提升性能。现有的方法虽然提高了可用性,但常常受到简洁性偏差(brevity bias)和上下文崩溃(context collapse)的影响。前者导致领域见解被简洁摘要所取代,后者则使迭代重写随…

目录
  1. 1. 简介
  2. 2. 背景和动机
  3. 2.1 上下文适应
  4. 2.2 现有上下文适应方法的局限性
  5. 3. Agentic Context Engineering (ACE) 框架
  6. 3.1 增量更新(Incremental Delta Updates)
  7. 3.2 增长-细化机制(Grow-and-Refine)
  8. 4. 实验结果
  9. 4.1 任务和数据集
  10. 4.2 基线和方法
  11. 4.3 代理基准测试结果
  12. 4.4 特定领域基准测试结果
  13. 4.5 消融研究
  14. 4.6 成本和速度分析
  15. 5. 讨论
  16. 更长的上下文 ≠ 更高的服务成本
  17. 对在线和持续学习的启示
  18. 6. 结论
文本版 · 供搜索与朗读

Agentic Context Engineering: 用于自改进语言模型的上下文演化框架

Agentic Context Engineering: 用于自改进语言模型的上下文演化框架

1. 简介

大型语言模型(LLM)应用(如代理和特定领域推理)越来越依赖于上下文适应——通过修改输入(如指令、策略或证据)而非更新权重来提升性能。现有的方法虽然提高了可用性,但常常受到简洁性偏差(brevity bias)和上下文崩溃(context collapse)的影响。前者导致领域见解被简洁摘要所取代,后者则使迭代重写随时间推移逐渐侵蚀细节。

基于Dynamic Cheatsheet引入的自适应记忆,我们提出了ACE(Agentic Context Engineering)框架,该框架将上下文视为不断演化的策略手册,通过生成、反思和策划的模块化过程来积累、细化和组织策略。ACE通过结构化的增量更新保留了详细知识,防止了上下文崩溃,并能与长上下文模型一起扩展。在代理和特定领域基准测试中,ACE在线下(如系统提示)和线上(如代理记忆)场景下都能优化上下文,始终优于强基线:在代理任务上提升10.6%,在金融任务上提升8.6%,同时显著降低了适应延迟和部署成本。

2. 背景和动机

2.1 上下文适应

上下文适应(或上下文工程)指的是通过构建或修改LLM的输入来改进模型行为,而不是改变其权重的方法。当前最先进的技术利用自然语言反馈。在这种范式中,语言模型检查当前上下文以及执行轨迹、推理步骤或验证结果等信号,并生成关于如何修改上下文的自然语言反馈。然后将此反馈纳入上下文中,实现迭代适应。代表性方法包括:

Reflexion:通过反思失败来改进代理规划

TextGrad:通过类似梯度的文本反馈优化提示

GEPA:基于执行轨迹迭代优化提示,在某些设置下甚至超过强化学习方法

Dynamic Cheatsheet:构建一个自适应外部记忆,在推理过程中积累过去成功和失败的经验教训

2.2 现有上下文适应方法的局限性

简洁性偏差(Brevity Bias)

上下文适应方法的一个反复出现的局限性是简洁性偏差:优化倾向于崩溃为简短、通用的提示。Gao等人在测试生成的提示优化中记录了这种效应,其中迭代方法反复产生几乎相同的指令(例如"创建单元测试以确保方法按预期行为"),牺牲了多样性并省略了领域特定的细节。这种收敛不仅缩小了搜索空间,还在迭代中传播了重复错误,因为优化的提示通常继承了与其种子相同的缺陷。更广泛地说,这种偏见在需要详细、丰富上下文指导的领域中破坏了性能——如多步骤代理、程序合成或知识密集型推理——在这些领域中,成功取决于积累而非压缩任务特定的见解。

上下文崩溃(Context Collapse)

在AppWorld基准测试的案例研究中,我们观察到一个我们称之为上下文崩溃的现象,这种现象出现在LLM被要求在每个适应步骤完全重写累积的上下文时。随着上下文变大,模型倾向于将其压缩成更短、信息量更少的摘要,导致信息的急剧丢失。例如,在第60步时,上下文包含18,282个令牌,准确率达到66.7%,但在下一步中,它崩溃到仅122个令牌,准确率下降到57.1——比没有适应的基线准确率63.7还要差。虽然我们通过Dynamic Cheatsheet强调了这一点,但这个问题并非特定于该方法;相反,它反映了使用LLM进行端到端上下文重写的根本风险,其中累积的知识可能被突然擦除而不是保留。

3. Agentic Context Engineering (ACE) 框架

我们提出了ACE(Agentic Context Engineering),一个在线下(如系统提示优化)和线上(如测试时记忆适应)场景中实现可扩展和高效上下文适应的框架。ACE不是将知识浓缩为简洁的摘要或静态指令,而是将上下文视为不断演化的策略手册,随着时间的推移持续积累、细化和组织策略。基于Dynamic Cheatsheet的代理设计,ACE引入了三个角色之间的结构化分工(图1):生成器(Generator),产生推理轨迹;反思器(Reflector),从成功和错误中提炼具体见解;策划者(Curator),将这些见解整合到结构化的上下文更新中。这反映了人类学习的方式——实验、反思和巩固——同时避免了将所有责任强加给单个模型的瓶颈。

Generator

→

Reflector

→

Curator

→

Context Playbook

如图1所示,工作流程始于生成器为新查询产生推理轨迹,这些轨迹揭示了有效策略和反复出现的陷阱。反思器批评这些轨迹以提取经验教训,可选择在多次迭代中完善它们。然后,策划者将这些经验教训合成为紧凑的增量条目,通过轻量级、非LLM逻辑确定性地合并到现有上下文中。由于更新是项目化和本地化的,多个增量可以并行合并,实现大规模的批量适应。ACE还支持多轮适应,其中可以重新访问相同的查询以逐步加强上下文。

3.1 增量更新(Incremental Delta Updates)

ACE的一个核心设计原则是将上下文表示为结构化的、项目化的要点集合,而不是单一的、整体的提示。要点的概念类似于LLM记忆框架(如Dynamic Cheatsheet和A-MEM)中的记忆条目,但在此基础上构建,包括(1)元数据,包括唯一标识符和跟踪被标记为有用或有害次数的计数器;以及(2)内容,捕获一个小单元,如可重用策略、领域概念或常见失败模式。在解决新问题时,生成器突出显示哪些要点是有用的或误导性的,提供反馈来指导反思器提出纠正性更新。

这种项目化设计实现了三个关键属性:(1)本地化,只更新相关的要点;(2)细粒度检索,生成器可以专注于最相关的知识;(3)增量适应,允许在推理过程中高效合并、修剪和去重。

ACE不是完全重新生成上下文,而是增量地生成紧凑的增量上下文:由反思器提炼并由策划者整合的小型候选要点集合。这避免了完全重写的计算成本和延迟,同时确保保留过去的知识并稳步添加新的见解。随着上下文的增长,这种方法为长期或领域密集型应用提供了所需的可扩展性。

3.2 增长-细化机制(Grow-and-Refine)

除了增量增长外,ACE还通过定期或惰性细化确保上下文保持紧凑和相关。在增长-细化中,带有新标识符的要点被附加,而现有要点则就地更新(例如,增加计数器)。然后,去重步骤通过语义嵌入比较要点来修剪冗余。这种细化可以主动执行(每个增量后)或惰性执行(仅在超过上下文窗口时),具体取决于应用对延迟和准确性的要求。

增量更新和增长-细化共同维护了能够自适应扩展、保持可解释性并避免整体上下文重写引入的潜在变化的上下文。

4. 实验结果

我们对ACE的评估表明:

实现高性能、自改进的代理:ACE使代理能够通过动态优化其输入上下文来实现自改进。它通过仅从执行反馈中学习来构建更好的上下文,将AppWorld基准测试的准确率提高了高达17.1%,而不需要真实标签。这种上下文驱动的改进使一个较小的开源模型能够与排行榜上排名最高的专有代理相匹配。

在特定领域基准测试中获得巨大收益:在复杂的金融推理基准测试中,ACE通过构建包含领域特定概念和见解的综合策略手册,比强基线平均提高了8.6%的性能。

设计有效:消融研究证实我们的设计选择是成功的关键,像反思器和多轮细化这样的组件各自贡献了显著的性能提升。

更低的成本和适应延迟:ACE高效地实现了这些收益,平均将适应延迟降低了86.9%,同时需要更少的部署和更低的令牌美元成本。

4.1 任务和数据集

我们在两类最受益于全面和演化上下文的LLM应用上评估ACE:(1)代理基准测试,需要多轮推理、工具使用和环境交互,代理可以在情节和环境之间积累和重用策略;(2)特定领域基准测试,需要掌握专业概念和策略,我们专注于金融分析作为案例研究。

LLM代理:AppWorld

AppWorld是一套自主代理任务,涉及API理解、代码生成和环境交互。它提供了一个真实的执行环境,包含常见的应用程序和API(如电子邮件、文件系统)以及两个难度级别(普通和挑战)的任务。一个公共排行榜跟踪性能,在提交时,最佳系统仅达到60.3%的平均准确率,突显了该基准测试的难度和真实性。

金融分析:FiNER和Formula

FiNER和Formula测试LLM在依赖于可扩展商业报告语言(XBRL)的金融推理任务上的表现。FiNER要求用139个细粒度实体类型之一标记XBRL财务文档中的令牌,这是受监管领域中财务信息提取的关键步骤。Formula专注于从结构化XBRL文件中提取值并执行计算以回答金融查询,即数值推理。

4.2 基线和方法

Base LLM:基础模型直接在每个基准测试上进行评估,不进行任何上下文工程,使用数据集作者提供的默认提示。

In-Context Learning (ICL):ICL在输入提示中为模型提供任务演示(少样本或多样本)。这允许模型推断任务格式和期望输出,而无需权重更新。

MIPROv2:MIPROv2是一种流行的LLM应用提示优化器,通过贝叶斯优化联合优化系统指令和上下文演示。

GEPA:GEPA(Genetic-Pareto)是一种基于反思提示演变的样本高效的提示优化器。它收集执行轨迹(推理、工具调用、中间输出),并应用自然语言反思来诊断错误、分配信用并提出提示更新。

Dynamic Cheatsheet (DC):DC是一种测试时学习方法,引入了可重用策略和代码片段的自适应外部记忆。通过持续更新这个记忆以包含新遇到的输入和输出,DC使模型能够积累知识并在任务之间重用它,通常导致比静态提示方法有显著改进。

ACE (ours):ACE通过代理上下文工程框架优化LLM上下文,用于线下和线上适应。为了确保公平性,我们对生成器、反思器和策划器使用相同的LLM(DeepSeek-V3.1的非思考模式),防止更强的反思器或策划器向较弱的生成器传递知识。

4.3 代理基准测试结果

如表1所示,ACE在AppWorld基准测试上始终优于强基线。在离线设置中,ReAct + ACE显著优于ReAct + ICL和ReAct + GEPA(分别高出12.3%和11.9%),表明结构化、演化和详细的上下文比固定演示或单一优化的指令提示能够实现更有效的代理学习。这些收益扩展到在线设置,其中ACE继续优于先前的自适应方法,如Dynamic Cheatsheet,平均高出7.6%。

方法
真实标签
测试-普通
测试-挑战
平均

TGC↑ SGC↑
TGC↑ SGC↑

ReAct
-
63.7 42.9
41.5 21.6
42.4

ReAct + ICL
✓
64.3+0.6 46.4+3.5
46.0+4.5 27.3+5.7
46.0+3.6

ReAct + GEPA
✓
64.9+1.2 44.6+1.7
46.0+4.5 30.2+8.6
46.4+4.0

ReAct + ACE
✓
76.2+12.5 64.3+21.4
57.3+15.8 39.6+18.0
59.4+17.0

ReAct + ACE
✗
75.0+11.3 64.3+21.4
54.4+12.9 35.2+13.6
57.2+14.8

ReAct + DC (CU)
✗
65.5+1.8 58.9+16.0
52.3+10.8 30.8+9.2
51.9+9.5

ReAct + ACE
✗
69.6+5.9 53.6+10.7
66.0+24.5 48.9+27.3
59.5+17.1

值得注意的是,在最新的AppWorld排行榜上(截至2025年9月20日),平均而言,ReAct + ACE(59.4%)与排名最高的IBM CUGA(60.3%)相当,后者是一个基于GPT-4.1的生产级代理,尽管使用了较小的开源模型DeepSeek-V3.1。通过在线适应,ReAct + ACE甚至在更难的测试-挑战分割上超过了IBM CUGA,在TGC上高出8.4%,在SGC上高出0.7%,突显了ACE在为代理构建全面和自演化上下文方面的有效性。

4.4 特定领域基准测试结果

如表2所示,ACE在金融分析基准测试上带来了显著的改进。在离线设置中,当提供来自训练分割的真实答案时,ACE明显优于ICL、MIPROv2和GEPA(平均高出10.9%),表明当任务需要精确的领域知识(例如金融概念、XBRL规则)时,结构化和演化的上下文特别有效。在线设置中,ACE继续超过先前的自适应方法,如DC,平均高出6.2%,进一步确认了代理上下文工程在跨专业领域积累可重用见解方面的好处。

方法
真实标签
FINER (Acc↑)
Formula (Acc↑)
平均

Base LLM
-
70.7
67.5
69.1

ICL
✓
72.3+1.6
67.0-0.5
69.6+0.5

MIPROv2
✓
72.4+1.7
69.5+2.0
70.9+1.8

GEPA
✓
73.5+2.8
71.5+4.0
72.5+3.4

ACE
✓
78.3+7.6
85.5+18.0
81.9+12.8

ACE
✗
71.1+0.4
83.0+15.5
77.1+8.0

DC (CU)
✓
74.2+3.5
69.5+2.0
71.8+2.7

DC (CU)
✗
68.3-2.4
62.5-5.0
65.4-3.7

ACE
✓
76.7+6.0
76.5+9.0
76.6+7.5

ACE
✗
67.3-3.4
78.5+11.0
72.9+3.8

4.5 消融研究

表3报告了在AppWorld基准测试上的消融研究,分析了ACE的各个设计选择如何有助于有效的上下文适应。我们检查了三个因素:(1)带有迭代细化的反思器,这是我们对Dynamic Cheatsheet之外的代理框架的补充;(2)多轮适应,在训练样本上多次细化上下文;(3)离线预热,在在线适应开始之前通过离线适应初始化上下文。

方法
真实标签
测试-普通
测试-挑战
平均

TGC↑ SGC↑
TGC↑ SGC↑

ReAct
-
63.7 42.9
41.5 21.6
42.4

ReAct + ACE w/o Reflector or multi-epoch
✓
70.8+7.1 55.4+12.5
55.9+14.4 38.1+17.5
55.1+12.7

ReAct + ACE w/o multi-epoch
✓
72.0+8.3 60.7+17.8
54.9+13.4 39.6+18.0
56.8+14.4

ReAct + ACE
✓
76.2+12.5 64.3+21.4
57.3+15.8 39.6+18.0
59.4+17.0

ReAct + ACE
✗
67.9+4.2 51.8+8.9
61.4+19.9 43.2+21.6
56.1+13.7

ReAct + ACE + offline warmup
✗
69.6+5.9 53.6+10.7
66.0+24.5 48.9+27.3
59.5+17.1

4.6 成本和速度分析

由于支持增量、"增量"上下文更新和基于非LLM的上下文合并和去重,ACE在降低适应成本(就部署数量或令牌摄取/生成的美元成本而言)和延迟方面表现出特殊优势。

例如,在AppWorld的离线适应中,与GEPA相比,ACE实现了82.3%的适应延迟减少和75.1%的部署数量减少(表4(a))。在FiNER的在线适应中,与DC相比,ACE实现了91.5%的适应延迟减少和83.6%的令牌美元成本减少(表4(b))。

(a) 离线 (AppWorld)

方法
延迟 (s)↓
部署数量↓

ReAct + GEPA
53898
1434

ReAct + ACE
9517(-82.3%)
357(-75.1%)

(b) 在线 (FiNER)

方法
延迟 (s)↓
令牌成本 ($)↓

DC (CU)
65104
17.7

ACE
5503(-91.5%)
2.9(-83.6%)

5. 讨论

更长的上下文 ≠ 更高的服务成本

尽管ACE产生的上下文比GEPA等方法更长,但这并不转化为线性更高的推理成本或GPU内存使用。现代服务基础设施越来越通过KV缓存的重用、压缩和卸载等技术为长上下文工作负载进行优化。这些机制允许频繁重用的上下文段在本地或远程缓存,避免重复且昂贵的预填充操作。ML系统的持续进步表明,处理长上下文的摊销成本将继续下降,使像ACE这样的丰富上下文方法在部署中越来越实用。

对在线和持续学习的启示

在线和持续学习是机器学习中的关键研究方向,用于解决分布偏移和有限训练数据等问题。ACE为传统的模型微调提供了一种灵活且高效的替代方案,因为适应上下文通常比更新模型权重更便宜。此外,由于上下文是人类可解释的,ACE实现了选择性遗忘——无论是由于隐私或法律约束,还是当领域专家识别出过时或不正确的信息时。这些是未来工作的有希望的方向,其中ACE可以在推进持续和负责任的学习中发挥核心作用。

6. 结论

ACE(Agentic Context Engineering)框架通过将上下文视为不断演化的策略手册,解决了现有上下文适应方法中的简洁性偏差和上下文崩溃问题。通过生成、反思和策划的模块化过程,ACE能够积累、细化和组织策略,从而在代理和特定领域基准测试中实现显著的性能提升。ACE的增量更新和增长-细化机制确保了上下文能够自适应扩展,保持可解释性,并避免整体上下文重写引入的潜在变化。此外,ACE还显著降低了适应延迟和部署成本,使其成为构建可扩展、高效和自改进LLM系统的理想选择。

"上下文应该作为全面、演化的策略手册——详细、包容且富有领域见解,而不是简洁的摘要。"

👍 1

想参与讨论或点赞?登录后使用完整功能

讨论回复(1)

✨

期待开源,可能会在DSPy中。 ======

暂无表态
合作

智谱 GLM-5 已上线

在智谱开放平台 BigModel.cn 打造 AI 应用。新一代旗舰模型 GLM-5 在推理、代码、智能体综合能力达到开源模型 SOTA。

领取 2000万 Tokens