引言：ACE框架——大模型自我提升的新范式
今天我们将深入解读一篇来自斯坦福大学、SambaNova Systems和加州大学伯克利分校联合团队的最新研究成果——ACE框架（Agentic Context Engineering: 智能体上下文工程）。这项研究的核心目标是解决大语言模型在上下文适配中最棘手的两个问题：简洁性偏差（Brevity Bias: 现有提示词优化工具过度追求简洁，导致关键信息遗漏的问题）和上下文坍缩（Context Collapse: 随着迭代次数增加，上下文信息量减少，导致模型性能下降的问题）。最终，ACE框架旨在让大语言模型无需更新权重，就能够通过动态演进的上下文实现自我提升。
在正式解读论文之前，我们首先需要理解一个基础问题：什么是上下文适配？以及为什么现在越来越多的AI系统都在依赖它？
上下文适配：不修改权重的模型优化策略
简单来说，上下文适配（Context Adaptation: 不修改大模型权重，通过调整输入上下文来提升模型性能的方法）指的是不修改大模型的权重，而是通过调整输入给模型的上下文，例如系统提示词、任务策略等方式，来提升模型的性能。
与传统的模型微调相比，这种方式具有三个非常关键的优势：
- 可解释性强： 开发者能够直接看到上下文里的内容，清楚模型是基于哪些规则或经验做出判断的，不像微调那样是黑箱操作。
- 知识更新快： 例如，金融领域如果出台了新的监管政策，可以直接将政策要点添加到上下文里，模型就能立即应用，无需重新训练。
- 跨模型兼容性好： 一份优化后的上下文既能用于开源模型，也能用于闭源模型，无需为不同的模型单独进行适配。
此外，当前的技术环境也越来越支持上下文适配。例如，长上下文大模型的普及，以及KV缓存（Key-Value Cache: 大语言模型推理过程中用于存储注意力机制中键值对的缓存机制）的复用、压缩等推理优化技术，都使得使用更长、更丰富的上下文来驱动模型变得越来越实用。可以说，上下文适配已成为构建可扩展、能够自我提升的AI系统的一个核心范式。
现有方法的两大痛点：简洁性偏差与上下文坍缩
尽管上下文适配技术前景广阔，但现有方法却存在两个绕不开的痛点，而这正是ACE框架要解决的核心问题。
第一个痛点是简洁性偏差。许多现有的提示词优化工具，例如大家可能听说过的GEPA，都将简洁性视为核心目标，认为提示词越短、越通用，效果越好。然而，实际情况是，这种追求简洁的思路会漏掉大量的关键信息。例如，在测试代码生成任务中，有研究者发现，迭代优化后的提示词会反复出现“生成单元测试来确保方法按预期运行”这类笼统的指令，却漏掉了如何处理边界值、如何适配特定框架等具体的策略。再如，在金融领域的数值推理中，简洁的提示词可能会忽略XBRL文档中数值单位的特殊标记规则，导致模型提取数据时出现偏差。这种偏差的本质是将通用简洁与有效指导混为一谈，而对于智能体（Agent）和知识密集型任务来说，恰恰是那些细节的策略才决定了最终的效果。
第二个痛点更加致命，被称为上下文坍缩。许多方法会让大语言模型在每次迭代时完整重写已有的上下文，结果就是随着迭代次数的增加，上下文会越变越短、信息越来越少，最终导致性能断崖式下跌。研究团队在AppWorld智能体基准测试上做了一个实验，使用动态备忘单（Dynamic Cheatsheet）框架进行测试。在第60次适配步骤时，上下文还有18282个token，模型准确率能达到66.7%；但到了第61步，模型直接将上下文压缩到了122个token，准确率瞬间跌至57.1%，甚至比没有任何适配的基线模型还低。这种越迭代越差的情况，在需要保留细节的场景中尤为明显，因为模型会主动丢掉那些看似冗余、实则关键的经验。
ACE框架的核心理念：上下文即演进的操作手册
正是看到了这两个问题，论文的研究者们提出了ACE框架。他们的核心思路非常有趣：不将上下文视为简洁的摘要，而是将其视为一个不断演进的操作手册（Playbook）。这个手册需要能够积累策略、细化经验、整理知识，既要全面，又要能够动态更新。
此外，他们还借鉴了人类学习的逻辑：先通过实践积累经验，再从经验中提炼规律，最后将规律系统化。这构成了ACE框架的三个核心组件：生成器（Generator）、反思器（Reflector）和整理器（Curator）。
ACE框架的工作流程：生成、反思与整理
接下来，我们将详细拆解ACE的工作流程，看看它是如何解决上述两个核心问题的。
生成器（Generator）
生成器（Generator: ACE框架中负责针对新任务查询，生成完整推理轨迹的组件）的作用非常明确，即针对新的任务查询，生成完整的推理轨迹。这包括模型是如何思考的、调用了哪些工具、中间结果是什么、最终成功还是失败了。例如，在AppWorld的账单拆分任务中，生成器会输出从调用手机APP获取室友联系人，到调用Venmo API创建付款请求的每一步代码和执行结果。即使中间出现了调用API时参数错误这样的失败，也会完整记录下来。这么做的目的，就是为后续的反思提供最原始、最详细的素材，因为只有看到完整的过程，才能准确判断哪里对、哪里错。
反思器（Reflector）
反思器（Reflector: ACE框架中负责从生成器的推理轨迹中提取可复用洞察的组件）是ACE与其他框架最大的区别之一。许多现有方法会让同一个组件既做生成又做反思，而ACE将反思单独分离出来，让它专注于从生成器的轨迹中提取可复用的洞察。
具体来说，反思器会做三件事：
- 诊断问题： 例如，在刚才的账单拆分任务中，如果生成器使用Venmo交易描述中的关键词来识别室友，而不是使用手机APP的联系人关系，反思器会明确指出这是用不可靠的启发式方法替代了权威的数据源。
- 提炼正确的策略： 例如，总结出识别联系人关系必须调用手机APP的
search_contacts接口，不能依赖交易的描述信息。 - 迭代优化洞察： 如果一次反思不够透彻，反思器还会基于反馈多次调整，直到提炼出的策略足够具体、可以落地。
举一个真实的例子，研究团队在AppWorld的Spotify播放列表统计任务中，生成器使用了for i in range(10)的固定循环来处理API的分页问题，结果只获取了前10页的播放列表，漏掉了后面的13页。这时，反思器就会诊断出用固定范围循环处理分页会导致数据不完整，同时提炼出必须用while True循环直到API返回空时才停止的策略，甚至还会补充循环中要加入异常处理以避免无限循环的细节。显然，这些洞察不是一些笼统的建议，而是能直接用到下次任务中的具体规则。
整理器（Curator）
整理器（Curator: ACE框架中负责以增量更新方式，将反思器提炼的洞察整合到已有上下文的组件）的核心任务是把反思器提炼的洞察，以增量更新的方式整合到已有的上下文，或者说操作手册里，而不是像以前那样重写整个上下文。
这里有两个关键的设计：
- 结构化条目（Structured Entry: 整理器中用于存储知识单元的带元数据（如唯一ID、有用/有害计数器）的条目）：整理器不会把洞察写成大段的文字，而是会拆分成一个个带元数据的条目。每个条目都有唯一的ID，以及有用或有害的计数器。内容则是一个小的知识单元，例如“处理时间敏感的交易时，必须用datetime范围比较，不能用字符串匹配”，“认证失败的时候，要先尝试用手机号代替邮箱登录”，甚至是一段可复用的代码片段。这种结构化设计的好处是，后续生成器在使用上下文的时候，能够快速定位到需要的条目，而且更新时只动对应的条目就行了，不会影响其他内容。
- 确定性合并： 整理器会采用更轻量的逻辑来合并新的条目，例如检查新条目和已有条目是否语义重复，如果重复就更新有用计数器；如果不重复就新增条目。同时，定期清理那些标记为有害或者很少用到的条目。这种方式避免了大模型重写时的主观压缩，确保已有的知识不会被弄丢。
ACE框架的三大创新：彻底解决核心问题
通过生成器、反思器、整理器的配合，ACE还实现了三个核心创新，正是这三个创新彻底解决了简洁性偏差和上下文坍缩的问题。
- 反思器的分离设计： 之前的方法要么没有专门的反思环节，要么让生成器兼顾反思，导致洞察提取不深入。而ACE的反思器只专注于从轨迹中挖掘规律，不用考虑生成任务，这样提炼出的策略会更加精准、更加详细。同时，这种细分规则恰恰是解决简洁性偏差的关键，因为它保留了领域知识的细节，而不是把知识压缩成模糊的指令。
- 增量Delta更新（Incremental Delta Update: ACE框架中每次只增加或更新少量结构化条目，而非重写整个上下文的更新方式）：传统方法每次更新都要重写整个上下文，既耗时又容易丢失信息。而ACE的更新是增量的，每次只增加几个新的结构化条目，或者更新已有条目的计数器。例如，在AppWorld任务中，一次适配只新增3-5个条目，每个条目几十到几百个token。相比重写动辄上万token的上下文，效率提升非常明显。研究数据显示，在AppWorld的离线适配中，ACE的延迟比GEPA低82.3%，需要的rollout少75.1%。这意味着开发者不用等太久，就能拿到优化后的上下文。更重要的是，增量更新不会覆盖已有知识，从根本上避免了上下文坍缩。
- 生长-精炼机制（Grow-and-Refine Mechanism: ACE框架中上下文在不断积累新洞察的同时，通过合并、删除、调整优先级等方式进行优化的机制）：ACE的上下文不是无限增长的，而是边生长边精炼。一方面，新的洞察会不断以新条目的形式生长进来，确保知识的全面性；另一方面，整理器会定期做精炼，例如合并语义相似的条目、删除有害的条目，以及根据有用计数器来调整条目的优先级。这种机制既保证了上下文的丰富度，又避免了臃肿，让模型始终能够用到最有价值的知识。
ACE框架的实际效果：性能、效率与成本的三重优化
讲完了ACE的设计，我们再来看看它的实际效果到底怎么样？团队在两类典型任务上做了全面测试：一类是需要多轮推理的智能体（Agent）任务，另一类是需要领域知识的金融推理任务。他们还对比了目前主流的5种基线方法，包括基础大模型、上下文学习（ICL）、MIPROv2、GEPA和Dynamic Cheatsheet。
智能体任务表现
AppWorld（一个权威的智能体基准测试平台）是目前比较权威的智能体基准，包含邮件处理、账单拆分、音乐播放列表管理等真实场景，还分为测试正常集（Test-Normal）和测试挑战集（Test-Challenge），后者的难度更高。评估指标使用的是任务目标完成率（TGC: 任务目标完成率，评估模型能否完成核心任务的指标）和场景目标完成率（SGC: 场景目标完成率，评估模型能否适配整个场景需求的指标），简单来说就是看模型能不能完成核心任务，以及能不能适配整个场景的需求。
在离线适配、有真值标签的情况下，ReAct+ACE的表现非常突出。测试正常集的TGC达到76.2%，比基础ReAct框架的63.7%提升了12.5个百分点；SGC更是从42.9%提升到了64.3%。对比其他基线，例如ReAct+GEPA，ACE的TGC比它高11.3个百分点，SGC高19.7个百分点。这都说明ACE积累的细节策略在多轮任务中，比GEPA的简洁提示词更有效。
更关键的是，ACE在没有真值标签的情况下，依然能够实现高效适配。许多实际场景中，开发者拿不到标注好的训练数据，这时候ACE就能靠执行反馈来提炼策略。数据显示，没有真值标签时，ReAct+ACE的平均准确率依然能够比基础ReAct提升14.8个百分点。这意味着ACE真正实现了无监督自我提升，无需人工标注就能优化。
在在线适配场景下，ACE的优势更加明显。对比同样支持在线更新的Dynamic Cheatsheet（DC-CU），ReAct+ACE在测试挑战集的TGC达到66.0%，比DC-CU的52.3%提升了13.7个百分点；SGC达到48.9%，比DC-CU的30.8%提升了18.1个百分点。而且ACE的在线适配延迟比DC-CU低91.5%，token成本低83.6%。这对于需要实时响应的智能体应用来说，简直是降维打击。
最令人惊喜的是ACE在AppWorld排行榜上的表现。截至2025年9月20日，排行榜上排名第一的是IBM CUGA智能体，它使用的是GPT-4.1模型，平均准确率60.3%；而ReAct+ACE使用的是更小的开源模型DeepSeek-V3.1，平均准确率达到59.4%，几乎追平了GPT-4.1的效果。更重要的是，在难度更高的测试挑战集上，ACE的TGC比IBM CUGA高8.4个百分点，SGC高0.7个百分点。这说明ACE的上下文优化能让小模型发挥出接近大模型的能力，大大降低了智能体应用的部署成本。
金融领域任务表现
团队选择了两个典型任务：分别是金融数值实体识别FiNER（Financial Numerical Entity Recognition: 金融数值实体识别任务）和金融数值推理Formula（金融数值推理任务）。前者需要识别XBRL文档（eXtensible Business Reporting Language: 可扩展商业报告语言文档，一种用于财务报告的国际标准）中的139种细分的实体类型，后者需要根据XBRL数据做计算，例如计算净利润、资产负债率等等，都是金融领域的核心需求。
在FiNER任务中，离线适配且有真值标签的情况下，ACE的准确率达到78.3%，比基础模型提升了7.6个百分点，比GEPA（73.5%）提升4.8个百分点。要知道，FiNER的实体类型非常细分，例如同样是现金类实体，但前者是无限制现金，后者是受限现金。ACE能通过上下文积累，区分这两类实体的规则，而其他方法往往会把它们归为一类。
在Formula任务中，ACE的提升更为显著。离线适配有真值标签时，准确率达到85.5%，比基础模型提升18个百分点，比Dynamic Cheatsheet（69.5%）提升16个百分点。Formula任务的难点在于计算逻辑的正确性，例如计算稀释每股收益时，需要考虑可转换债券、期权等潜在的稀释因素。ACE能从错误轨迹中提炼出必须先计算潜在普通股加权平均数，再用净利润除以该数值的完整步骤，而其他方法往往会漏掉潜在普通股这个关键环节。
不过，这里也要客观地说一句，ACE的表现也依赖于高质量的反馈信号。如果没有真值标签，也没有可靠的执行反馈，ACE的性能会有所下降。例如，在FiNER任务中，没有真值标签时，ACE的准确率只有71.1%，只比基础模型高0.4个百分点；不过Dynamic Cheatsheet的准确率甚至会下降到68.3%。这说明上下文适配的核心还是反馈质量，如果模型不知道自己做得对不对，那么再先进的框架也难以发挥作用。
成本与效率优势及长上下文的误区
除了性能以外，ACE在成本和效率上的优势也特别值得关注。对于企业来说，AI系统的部署成本往往和延迟、计算资源直接挂钩，而ACE在这两方面都做了优化。
在离线适配场景下，对比目前效率较高的提示词优化器GEPA，ACE在AppWorld任务中的适配延迟从53898秒下降到9517秒，降低了82.3%；需要的rollout次数从1434次下降到357次，减少了75.1%。Rollout次数减少意味着更少的任务执行，也就减少了API调用、计算资源的消耗。对于需要大量测试的企业来说，这能节省一大笔成本。
在在线适配场景下，对比Dynamic Cheatsheet，ACE在FiNER任务中的延迟从65104秒降到了5503秒，降低了91.5%；token成本从17.7美元下降到2.9美元，降低了83.6%。要知道，在线适配是实时进行的，延迟降低意味着用户等待的时间更短；而token成本降低则直接减少了模型调用的费用。例如，一个每天处理1000个金融文档的系统，用ACE每年能节省的token成本可能超过1万美元。
可能有朋友会问，ACE的上下文是不断生长的，会不会导致推理时的上下文窗口不够用呢？或者说，长上下文会不会增加推理的成本？这里要纠正一个常见的误区，那就是长上下文不等于高服务成本。现在的大模型推理基础设施已经有了许多优化技术，例如KV缓存复用、KV缓存压缩、缓存卸载等等。这些技术能让频繁使用的上下文片段被缓存起来，无需每次推理都重新处理，从而大幅降低计算成本。例如，KV缓存复用技术能够让重复出现的上下文片段的处理时间减少90%以上。这意味着ACE的长上下文在实际部署时的成本并不会比短上下文高太多，反而会因为策略更精准，减少了重复推理的次数，整体成本反而更低。
另外，ACE对在线学习和持续学习也有重要的意义。现在许多AI系统都面临着分布偏移（Distribution Shift: AI系统在部署后，其输入数据的统计特性与训练数据发生变化的现象）的问题，例如金融领域的会计准则更新、智能体调用的API版本变更。这时候传统的微调方法需要重新准备数据、训练模型，成本高、周期长。而ACE只需要通过新的执行反馈，更新上下文里的策略条目，例如把旧会计准则下的收入确认规则替换成新准则下的规则，模型马上就能适配新场景。更重要的是，ACE的上下文是可解释、可编辑的。如果发现某个条目是错误的，例如旧版本的API参数，开发者可以直接删除或者修改这个条目，实现选择性遗忘；而微调后的模型要删除错误知识几乎是不可能的。这对于需要遵守数据隐私法规的企业来说，是非常关键的优势。
ACE框架的局限性
当然，ACE也不是万能的，它有两个明显的局限性。
- 依赖强反思器： 如果反思器无法从生成轨迹中提炼出有用的洞察，那么ACE的上下文质量也会下降。例如，在某些特殊的医疗文档分析任务中，如果反思器分不清DICOM格式和HL7格式的区别，就无法提炼出正确的文档处理策略，这时ACE的效果可能还不如简单的上下文学习。
- 并非所有任务都需要长上下文： 对于一些简单任务，例如生成一句话总结、回答常识问题，简洁的提示词反而比长上下文更加高效。例如，在多跳问答任务HotPotQA中，模型只需要知道如何检索证据、如何合成答案的通用规则，不需要积累大量的细分策略；再例如24点游戏，只需要一个加减乘除凑24的规则，额外的上下文反而会增加推理时间。所以，ACE更适合那些需要细节策略的复杂任务，例如智能体、领域推理、多轮工具调用等等。
总结与展望
总结一下，ACE框架的核心价值在于它重新定义了大语言模型的自我提升方式。它不再依赖权重更新，而是通过生成-反思-整理的闭环，让上下文成为一个动态演进的知识库。它解决了现有方法的简洁性偏差和上下文坍缩问题，在智能体和领域相关任务中实现了性能、效率、成本的三重优化，甚至能够让小模型发挥出接近大模型的能力。
对于开发者来说，ACE能够带来的启示是，未来在构建大模型系统的时候，与其一味地追求更大的模型参数，不如花更多的精力来优化上下文，因为好的上下文能让模型用更少的参数，做更多的事。而对于企业来说，ACE可以显著降低复杂AI系统的部署成本，尤其是开源模型+ACE的组合，可能会成为许多场景下的性价比之选。