大家好，我是肆〇柒。今天我們一起閱讀一項由斯坦福大學(xué)與SambaNova Systems聯(lián)合研究團(tuán)隊提出的突破性技術(shù)——Agentic Context Engineering（ACE）框架。這項研究直面LLM應(yīng)用中的核心挑戰(zhàn)：當(dāng)上下文從18,282個Token坍縮至122個Token時，準(zhǔn)確率竟從66.7%驟降至57.1%，甚至低于無適應(yīng)的基線水平。ACE通過創(chuàng)新的模塊化設(shè)計，成功將上下文轉(zhuǎn)化為可積累、可進(jìn)化的戰(zhàn)術(shù)手冊，在AppWorld智能體任務(wù)中讓開源模型DeepSeek-V3.1超越了GPT-4.1驅(qū)動的頂級智能體。

在 AppWorld 智能體任務(wù)中，一個令人費(fèi)解的現(xiàn)象發(fā)生了：第 60 步的上下文包含 18,282 個 Token 且準(zhǔn)確率達(dá) 66.7%，但下一步卻驟然坍縮至僅 122 個 Token，準(zhǔn)確率跌至 57.1%——甚至低于無適應(yīng)的基線（63.7%）。

上下文坍縮現(xiàn)象

這一現(xiàn)象揭示了當(dāng)前上下文優(yōu)化方法的致命缺陷：隨著迭代進(jìn)行，系統(tǒng)反而丟失關(guān)鍵信息，性能不升反降。研究顯示，在第 60 步，上下文準(zhǔn)確率達(dá)到 66.7%，但當(dāng) LLM 被要求在下一步完全重寫累積的上下文時，它將 18,282 個 Token 的豐富知識壓縮為僅 122 個 Token 的簡短摘要，導(dǎo)致性能斷崖式下跌。

這種"越優(yōu)化越差"的現(xiàn)象對實際應(yīng)用具有災(zāi)難性影響。想象一個處理金融交易的智能體，在多次迭代后丟失了關(guān)鍵的 XBRL 規(guī)則或 API 分頁邏輯，可能導(dǎo)致嚴(yán)重錯誤卻難以察覺根源。上下文坍縮不僅是性能下降，更是系統(tǒng)可靠性的致命威脅——當(dāng)智能體在處理復(fù)雜任務(wù)時，丟失的不僅是 Token 數(shù)量，更是關(guān)鍵的領(lǐng)域知識和操作細(xì)節(jié)。

為何主流上下文優(yōu)化方法在長期迭代中會出現(xiàn)這種反直覺現(xiàn)象？Agentic Context Engineering（ACE）框架的提出，為這一問題提供了系統(tǒng)性解決方案，成功克服了 brevity bias（簡潔性偏見）與 context collapse（上下文坍縮）兩大瓶頸。與傳統(tǒng)方法將上下文視為需壓縮的"指令摘要"不同，ACE 主張將上下文構(gòu)建為可積累的"戰(zhàn)術(shù)手冊"（playbook）——詳盡、包容、富含領(lǐng)域洞見，讓 LLM 在推理時自主提取相關(guān)性。

ACE在智能體與領(lǐng)域任務(wù)上的性能對比

實驗數(shù)據(jù)顯示，ACE 在智能體和領(lǐng)域特定任務(wù)上分別實現(xiàn)平均 10.6% 和 8.6% 的性能提升，為上下文工程樹立了新標(biāo)桿。

上下文工程為何成為 LLM 應(yīng)用的關(guān)鍵路徑

上下文適應(yīng)（Context Adaptation）是指通過修改 LLM 輸入而非調(diào)整模型權(quán)重來提升性能的方法。這種方法適用于系統(tǒng)提示優(yōu)化、記憶管理、事實證據(jù)注入等多種場景，已成為當(dāng)下 LLM 應(yīng)用的核心范式。上下文適應(yīng)通過將澄清的指令、結(jié)構(gòu)化推理步驟或特定領(lǐng)域輸入格式直接整合到模型輸入中，從而在模型訓(xùn)練后提升性能。上下文支撐著 AI 系統(tǒng)的多個組件，包括指導(dǎo)下游任務(wù)的系統(tǒng)提示、承載過去事實和經(jīng)驗的記憶，以及減少幻覺和補(bǔ)充知識的事實證據(jù)。

相較于模型微調(diào)，上下文適應(yīng)具有顯著優(yōu)勢：上下文對用戶和開發(fā)者而言是可解釋和可解釋的，允許在運(yùn)行時快速集成新知識，并可在復(fù)合系統(tǒng)中的模型或模塊間共享。同時，長上下文 LLM 和上下文高效推理技術(shù)（如 KV cache 復(fù)用）的進(jìn)步使基于上下文的方法在部署中日益實用。隨著這些發(fā)展，上下文適應(yīng)正成為構(gòu)建能力強(qiáng)大、可擴(kuò)展且自進(jìn)化的 AI 系統(tǒng)的核心范式。

ACE 與 Dynamic Cheatsheet 的關(guān)系值得深入剖析。雖然 ACE 建立在 Dynamic Cheatsheet 的 agentic 架構(gòu)基礎(chǔ)上，但通過三大關(guān)鍵改進(jìn)解決了其根本局限：(1) 專用 Reflector 將評估與洞察提取分離，避免單一模型過載；(2) 增量 Delta 更新替代全量重寫，防止上下文坍縮；(3) grow-and-refine 機(jī)制平衡擴(kuò)展與冗余控制，確保上下文既詳盡又精煉。這一設(shè)計反映了現(xiàn)代 LLM 的一個重要特性：與人類不同，LLM 在長而詳盡的上下文中表現(xiàn)更佳，能夠自主過濾無關(guān)信息，無需人為壓縮關(guān)鍵領(lǐng)域知識。

在 AppWorld 案例中，當(dāng)智能體需要處理分頁任務(wù)時，簡潔的提示可能僅建議"獲取數(shù)據(jù)"，而丟失了“使用 while True 循環(huán)遍歷所有頁面索引直到無更多結(jié)果返回”這一關(guān)鍵細(xì)節(jié)，導(dǎo)致智能體只能獲取部分?jǐn)?shù)據(jù)。在金融分析任務(wù)中，簡潔的提示可能遺漏 XBRL 報告中的特定財務(wù)規(guī)則，使模型無法正確執(zhí)行財務(wù)計算。這些場景中，上下文不應(yīng)作為簡潔摘要，而應(yīng)作為全面、進(jìn)化的戰(zhàn)術(shù)手冊——詳細(xì)、 inclusive、富含領(lǐng)域洞見。

論文中詳細(xì)介紹了當(dāng)前上下文適應(yīng)的代表方法：Reflexion 通過反思失敗來改進(jìn)代理規(guī)劃；TextGrad 通過類梯度文本反饋優(yōu)化提示；GEPA 基于執(zhí)行軌跡迭代優(yōu)化提示，在某些場景甚至超越強(qiáng)化學(xué)習(xí)方法；Dynamic Cheatsheet 構(gòu)建外部記憶，從過去成功和失敗中積累策略和經(jīng)驗。這些基于自然語言反饋的方法代表了重大進(jìn)步，為改進(jìn) LLM 系統(tǒng)提供了靈活且可解釋的信號。ACE 在此基礎(chǔ)上進(jìn)一步發(fā)展，解決了現(xiàn)有方法在長期迭代中丟失關(guān)鍵信息的根本問題。

現(xiàn)有方法的兩大致命缺陷

現(xiàn)有上下文適應(yīng)方法面臨兩個根本性挑戰(zhàn)。首先是簡潔性偏見：優(yōu)化過程傾向于生成簡短、泛化的指令，犧牲領(lǐng)域特定細(xì)節(jié)。比如有的方法，文檔化了這一現(xiàn)象，在提示優(yōu)化過程中，迭代方法反復(fù)產(chǎn)生近似相同的指令（如"創(chuàng)建單元測試以確保方法行為符合預(yù)期"），導(dǎo)致策略同質(zhì)化并丟失多樣性和領(lǐng)域特定細(xì)節(jié)。這種收斂不僅 narrows the search space，還使優(yōu)化后的提示繼承種子提示的相同錯誤，傳播反復(fù)出現(xiàn)的錯誤。

這種現(xiàn)象在 AppWorld 智能體任務(wù)中尤為明顯，當(dāng)模型需要處理多步驟推理、工具使用和環(huán)境交互時，簡潔的泛化指令無法捕獲關(guān)鍵的領(lǐng)域特定策略。例如，當(dāng)智能體需要處理 API 分頁邏輯時，簡潔的提示可能僅建議獲取數(shù)據(jù)，而丟失了"使用 while True 循環(huán)遍歷所有頁面索引直到無更多結(jié)果返回"這一關(guān)鍵細(xì)節(jié)，導(dǎo)致智能體只能獲取部分?jǐn)?shù)據(jù)。在金融分析任務(wù)中，簡潔的提示可能遺漏 XBRL 報告中的特定財務(wù)規(guī)則，使模型無法正確執(zhí)行財務(wù)計算。

其次是上下文坍縮：當(dāng) LLM 被要求在每一步完全重寫累積的上下文時，隨著上下文增長，模型傾向于將其壓縮為更短、信息量更少的摘要，導(dǎo)致關(guān)鍵信息急劇丟失。AppWorld 案例清晰地展示了這一問題：在第 60 步，上下文包含 18,282 個 Token 且準(zhǔn)確率達(dá) 66.7%，但下一步卻坍縮至僅 122 個 Token，準(zhǔn)確率降至 57.1%。這種現(xiàn)象不僅限于 Dynamic Cheatsheet，而是 LLM 全量重寫上下文時的固有風(fēng)險——累積的知識可能被突然擦除而非保留。

上下文坍縮的根本原因在于 LLM 在重寫過程中傾向于偏好簡潔、概括性的表述，而丟失了具體、詳盡的領(lǐng)域知識。例如，當(dāng)處理金融分析任務(wù)時，長上下文可能包含詳細(xì)的 XBRL 規(guī)則和財務(wù)計算方法，但全量重寫后可能僅保留"提取財務(wù)數(shù)據(jù)"這樣泛泛的指令，導(dǎo)致模型無法執(zhí)行精確的財務(wù)分析。論文中特別指出，這種坍縮不是 Dynamic Cheatsheet 特有的問題，而是端到端上下文重寫中 LLM 的根本風(fēng)險，其中累積的知識可能被突然擦除而非保留。

在實際應(yīng)用中，上下文坍縮可能導(dǎo)致災(zāi)難性后果。當(dāng)智能體在處理復(fù)雜任務(wù)時，丟失的不僅是 Token 數(shù)量，更是關(guān)鍵的領(lǐng)域知識和操作細(xì)節(jié)。例如，在 AppWorld 任務(wù)中，智能體可能已經(jīng)學(xué)會了如何處理音樂播放列表的分頁邏輯，但一次全量重寫后，這些關(guān)鍵知識被壓縮為泛泛的"獲取數(shù)據(jù)"指令，導(dǎo)致智能體只能獲取部分播放列表，無法完成任務(wù)。這種"越優(yōu)化越差"的現(xiàn)象使開發(fā)者難以信任自動化的上下文優(yōu)化過程，限制了 LLM 系統(tǒng)的自進(jìn)化能力。

ACE 框架核心設(shè)計：讓上下文成為"進(jìn)化型 playbook"

ACE 通過將上下文視為可進(jìn)化的戰(zhàn)術(shù)手冊，從根本上解決了上述問題。該框架采用模塊化設(shè)計，將工作流分為三個專業(yè)化角色：

ACE框架結(jié)構(gòu)

ACE 的工作流始于 Generator 為新查詢生成推理軌跡，這些軌跡既包含有效策略也揭示常見陷阱。Reflector 隨后批判性分析這些軌跡，提取結(jié)構(gòu)化洞見，并可進(jìn)行多輪迭代優(yōu)化。Curator 則將這些洞見轉(zhuǎn)化為緊湊的增量條目（delta items），通過輕量級非 LLM 邏輯確定性合并到現(xiàn)有上下文中。這種設(shè)計使多個增量條目可并行合并，支持大規(guī)模批量適應(yīng)。ACE 還支持多輪精煉（multi-epoch adaptation），通過重復(fù)訪問相同查詢來逐步強(qiáng)化上下文。

基于這一角色分工，ACE 引入了三項關(guān)鍵創(chuàng)新機(jī)制解決傳統(tǒng)方法的局限。首先是增量 Delta 更新：ACE 的上下文以結(jié)構(gòu)化 bullet 形式組織，每個 bullet 包含兩部分：(1) 元數(shù)據(jù)（唯一標(biāo)識符及記錄被標(biāo)記為有用/有害次數(shù)的計數(shù)器）；(2) 內(nèi)容（如可重用策略、領(lǐng)域概念或常見失敗模式）。當(dāng)解決新問題時，Generator 會標(biāo)記哪些 bullets 有用或誤導(dǎo)，這些反饋指導(dǎo) Reflector 提出修正建議。

論文中詳細(xì)描述了 bullet 的結(jié)構(gòu)：每個 bullet 包含唯一標(biāo)識符和計數(shù)器，用于跟蹤其被標(biāo)記為有用或有害的次數(shù)。這種設(shè)計使系統(tǒng)能夠量化每個知識片段的有效性，為后續(xù)優(yōu)化提供數(shù)據(jù)支持。例如，在 AppWorld 任務(wù)中，當(dāng)智能體成功完成分頁任務(wù)時，相關(guān) bullet 會被標(biāo)記為有用，其計數(shù)器增加；當(dāng)分頁失敗時，相關(guān) bullet 會被標(biāo)記為有害，其計數(shù)器減少。這種機(jī)制使 ACE 能夠基于實際執(zhí)行結(jié)果動態(tài)調(diào)整上下文內(nèi)容，而非依賴靜態(tài)的預(yù)定義提示。

Curator 通過非 LLM 邏輯確定性合并這些增量，避免了全量重寫的高開銷。這種設(shè)計實現(xiàn)了三個關(guān)鍵特性：(1) 局部化更新，僅修改相關(guān) bullets；(2) 細(xì)粒度檢索，使 Generator 能聚焦最相關(guān)的知識；(3) 增量適應(yīng)，支持推理時的高效合并、修剪與去重。ACE 產(chǎn)生的增量條目通過結(jié)構(gòu)化方式組織，使系統(tǒng)能夠并行處理多個增量，顯著提升了大規(guī)模適應(yīng)的效率。

Reflector對分頁錯誤的精準(zhǔn)診斷

ACE 在 AppWorld 基準(zhǔn)測試中展現(xiàn)了具體錯誤診斷能力。如上圖所示，當(dāng)智能體錯誤地使用 for i in range(10) 循環(huán)而非正確分頁邏輯時，Reflector 能夠精確識別問題："生成的代碼使用了固定范圍循環(huán)（range(10)）進(jìn)行分頁，而非正確迭代直到無更多結(jié)果返回。這導(dǎo)致代理僅收集前10頁播放列表，遺漏了后續(xù)存在的13個額外播放列表。"這種精準(zhǔn)的錯誤診斷為上下文優(yōu)化提供了堅實基礎(chǔ)。

上圖提供了 Reflector 的具體工作示例：當(dāng)智能體在 AppWorld 任務(wù)中使用 for i in range(10) 而非正確的 while True 循環(huán)進(jìn)行分頁時，Reflector 能夠準(zhǔn)確分析錯誤原因、識別根本問題、提供正確方法，并總結(jié)關(guān)鍵洞見："對于分頁，始終使用 while True 循環(huán)而非固定范圍迭代，以確保收集所有可用頁面上的完整數(shù)據(jù)。"這種精準(zhǔn)診斷能力是 ACE 能夠有效優(yōu)化上下文的關(guān)鍵。

其次是 grow-and-refine 機(jī)制：新標(biāo)識符的 bullets 被追加，而現(xiàn)有 bullets 在原地更新（如增加計數(shù)器）。隨后通過語義嵌入進(jìn)行去重，系統(tǒng)通過計算語義相似度來識別重復(fù)或高度相似的 bullets，保留更精確或被標(biāo)記為更有用的條目。這種去重過程確保了上下文既詳盡又不冗余，是 ACE 避免上下文坍縮的關(guān)鍵。精煉可主動執(zhí)行（每次 delta 后立即執(zhí)行，適合對準(zhǔn)確性要求高的場景）或惰性執(zhí)行（僅當(dāng)上下文窗口超出時執(zhí)行，適合延遲敏感型應(yīng)用），為不同應(yīng)用場景提供靈活性。

ACE 的多輪精煉機(jī)制進(jìn)一步提升了上下文質(zhì)量。通過重復(fù)訪問相同查詢，系統(tǒng)能夠從多個角度診斷問題，提煉更精確的解決方案。這種機(jī)制使 Reflector 能夠進(jìn)行深度反思，避免表面層次的修正，從而構(gòu)建更高質(zhì)量的上下文。在消融實驗中，多輪精煉將準(zhǔn)確率從 56.8% 提升至 59.4%，證明了這一機(jī)制對上下文質(zhì)量的關(guān)鍵影響。

第三是無監(jiān)督自進(jìn)化能力：ACE 能夠僅依靠執(zhí)行反饋（如代碼執(zhí)行成功或失敗）而非人工標(biāo)注來指導(dǎo)上下文優(yōu)化。在 AppWorld 智能體任務(wù)中，系統(tǒng)僅依靠結(jié)構(gòu)化執(zhí)行反饋（如單元測試報告、代碼執(zhí)行結(jié)果、API 調(diào)用反饋）而非人工標(biāo)注來指導(dǎo)優(yōu)化。如上圖所示，當(dāng)智能體錯誤地使用 for i in range(10) 循環(huán)而非正確分頁邏輯時，Reflector 能精確識別問題并提供具體修正建議。這種基于執(zhí)行結(jié)果的精準(zhǔn)診斷使系統(tǒng)能在真實環(huán)境中持續(xù)學(xué)習(xí)，無需依賴昂貴的監(jiān)督信號。

ACE 的上下文組織方式使其能夠有效支持復(fù)雜任務(wù)。例如，在 AppWorld 智能體任務(wù)中，ACE 生成的上下文包括多個領(lǐng)域特定策略部分：Bill Splitting Tasks、File Organization Tasks、Music Playlist Tasks、File Compression Tasks、Alarm Management Tasks 和 Message Management Tasks。每個部分都包含具體的操作指南和常見錯誤預(yù)防措施，如在音樂播放列表任務(wù)中明確指出："計算所需總時長（例如，90分鐘=5400秒）→ 搜索不同流派的適當(dāng)歌曲（健身、活力、搖滾、流行、舞蹈）→ 使用 show_song() 獲取單個歌曲時長 → 添加歌曲到播放列表直到滿足總時長要求 → 使用 play_music() 與 playlist_id 開始播放"。

ACE生成的上下文示例

上圖展示了 ACE 在 AppWorld 基準(zhǔn)上生成的上下文，其中包含詳細(xì)的領(lǐng)域特定見解、工具使用指南和可直接使用的代碼片段，構(gòu)成了一個全面的戰(zhàn)術(shù)手冊，而非泛化摘要。值得注意的是，ACE 的效果依賴于 Reflector 的質(zhì)量。若 Reflector 無法從生成軌跡中提取有意義的見解，構(gòu)建的上下文可能變得嘈雜甚至有害。正如研究指出，"在領(lǐng)域特定任務(wù)中，若沒有模型能提取有用見解，結(jié)果上下文自然缺乏這些內(nèi)容"。

實證效果：ACE 在智能體與金融領(lǐng)域的雙重突破

ACE 在 AppWorld 智能體任務(wù)上展現(xiàn)了顯著優(yōu)勢。

AppWorld基準(zhǔn)測試結(jié)果

上表顯示，ReAct+ ACE 在離線設(shè)置中比 ReAct+ ICL 和 ReAct+ GEPA 分別高出 12.3% 和 11.9%，證明結(jié)構(gòu)化、進(jìn)化的詳細(xì)上下文比固定演示或單一優(yōu)化指令更有效。在無監(jiān)督設(shè)置下（無 GT 標(biāo)簽），ReAct+ ACE 仍比 ReAct 基線提升 14.8%，表明系統(tǒng)能僅依靠執(zhí)行反饋實現(xiàn)自進(jìn)化。

ACE與頂級智能體對比

更令人矚目的是，上圖顯示，在 AppWorld 領(lǐng)導(dǎo)榜上，ReAct+ ACE（59.4%）匹配了頂級生產(chǎn)級智能體 IBM-CUGA（60.3%）的平均表現(xiàn)，盡管前者使用的是較小的開源模型 DeepSeek-V3.1。在更具挑戰(zhàn)性的 test-challenge 分割上，ReAct+ ACE 甚至以 8.4% 的 TGC 和 0.7% 的 SGC 超過 IBM-CUGA，凸顯了 ACE 在構(gòu)建全面自進(jìn)化上下文方面的有效性。

ACE 在 AppWorld 上的成功源于其對復(fù)雜任務(wù)的精確處理能力。例如，在處理音樂播放列表任務(wù)時，ACE 能夠?qū)W習(xí)到："計算所需總時長（例如，90分鐘=5400秒）→ 搜索不同流派的適當(dāng)歌曲（健身、活力、搖滾、流行、舞蹈）→ 使用 show_song() 獲取單個歌曲時長 → 添加歌曲到播放列表直到滿足總時長要求 → 使用 play_music() 與 playlist_id 開始播放"。這種詳細(xì)的領(lǐng)域特定策略使智能體能夠正確執(zhí)行任務(wù)，而不會遺漏關(guān)鍵步驟。

在金融分析領(lǐng)域，ACE 同樣表現(xiàn)卓越。

金融分析基準(zhǔn)測試結(jié)果

上表顯示，當(dāng)提供訓(xùn)練分割中的真實答案時，ACE 在離線設(shè)置中以平均 10.9% 的優(yōu)勢超過 ICL、MIPROv2 和 GEPA，表明結(jié)構(gòu)化和進(jìn)化的上下文在需要精確領(lǐng)域知識（如金融概念、XBRL 規(guī)則）的任務(wù)中特別有效。在 Formula 任務(wù)中，ACE 達(dá)到 85.5% 的準(zhǔn)確率（+18.0%），遠(yuǎn)超其他方法。

ACE 在金融分析中的成功源于其對領(lǐng)域特定知識的精細(xì)積累。Formula 任務(wù)聚焦于從結(jié)構(gòu)化 XBRL 文件中提取值并執(zhí)行計算以回答財務(wù)查詢，這一任務(wù)需要精確的數(shù)值推理和領(lǐng)域知識。ACE 通過積累 XBRL 實體識別規(guī)則和數(shù)值計算策略，顯著提高了準(zhǔn)確性。例如，系統(tǒng)能夠?qū)W習(xí)識別"總資產(chǎn)"與"總負(fù)債"的計算方法，以及如何處理財務(wù)報表中的復(fù)雜關(guān)系，這些領(lǐng)域特定知識被精確編碼在上下文中，使模型能夠執(zhí)行準(zhǔn)確的財務(wù)分析。

ACE 還在成本和效率方面展現(xiàn)出顯著優(yōu)勢。

ACE與基線方法的成本與速度對比

顯示，由于支持增量"delta"上下文更新和非 LLM 上下文合并與去重，ACE 在 AppWorld 離線適應(yīng)中實現(xiàn)了 82.3% 的適應(yīng)延遲降低和 75.1% 的 rollouts 減少；在 FiNER 在線適應(yīng)中，實現(xiàn)了 91.5% 的適應(yīng)延遲降低和 83.6% 的 Token 美元成本降低。這些優(yōu)勢源于 Curator 生成的增量通過非 LLM 邏輯確定性合并，避免了 GEPA/DC 中 LLM 全量重寫的高開銷。

適應(yīng)延遲降低 86.9% 的具體含義是：ACE 將上下文適應(yīng)所需的平均時間大幅縮減。在上表(a) 中，ReAct+ ACE 僅需 9,517 秒完成離線適應(yīng)，而 ReAct+ GEPA 需要 53,898 秒；在上表(b) 中，ACE 僅需 5,503 秒完成在線適應(yīng)，而 DC(CU) 需要 65,104 秒。這種效率提升使得 ACE 能夠在實際應(yīng)用中快速迭代和優(yōu)化上下文，為實時系統(tǒng)提供了可行性。

ACE 的成本優(yōu)勢源于其增量更新機(jī)制。傳統(tǒng)方法如 GEPA 需要對整個上下文進(jìn)行重寫，每次重寫都需要 LLM 處理大量 Token，而 ACE 僅需更新相關(guān)部分。在 AppWorld 離線適應(yīng)中，ACE 將 rollouts 從 1,434 減少到 357（減少 75.1%），大幅降低了計算資源消耗。在 FiNER 在線適應(yīng)中，ACE 將 Token 成本從 17.7 美元降至 2.9 美元（降低 83.6%），使大規(guī)模上下文適應(yīng)在經(jīng)濟(jì)上變得可行。

為何 ACE 的設(shè)計選擇至關(guān)重要？

消融實驗揭示了 ACE 設(shè)計選擇的關(guān)鍵價值。

ACE設(shè)計選擇的消融研究

上表顯示，移除 Reflector 或多輪精煉導(dǎo)致性能顯著下降：ReAct+ ACE w/o Reflector 或多輪精煉的準(zhǔn)確率為 55.1%，比完整 ACE 低 4.3%。這證明 Reflector 通過分離評估和洞察提取，提高了上下文質(zhì)量和下游性能。多輪精煉進(jìn)一步將準(zhǔn)確率從 56.8% 提升至 59.4%，而離線預(yù)熱（offline warmup）則使在線適應(yīng)性能從 56.1% 提升至 59.5%。

ACE 的成功部分源于其對反饋質(zhì)量的敏感性。當(dāng)缺乏可靠反饋信號時，如 上表所示，DC(CU) 在無 GT 標(biāo)簽的 FiNER 任務(wù)上性能下降至 68.3%，而 ACE 在相同條件下仍能保持 67.3% 的準(zhǔn)確率。這表明 ACE 的框架設(shè)計使其在反饋質(zhì)量波動時更具魯棒性，但仍強(qiáng)調(diào)了可靠反饋對上下文適應(yīng)的重要性。

ACE 的 Reflector 組件是其性能優(yōu)勢的關(guān)鍵。在消融研究中，移除 Reflector 導(dǎo)致準(zhǔn)確率下降 4.3%，從 59.4% 降至 55.1%。Reflector 通過將評估與洞察提取從策展中分離，避免了單一模型過載。在傳統(tǒng)方法中，同一 LLM 需要同時負(fù)責(zé)生成、評估和優(yōu)化，導(dǎo)致認(rèn)知負(fù)荷過重。而 ACE 通過專業(yè)化分工，使每個組件專注于特定任務(wù)，從而提高了整體性能。

ACE 的多輪精煉機(jī)制也是其成功的關(guān)鍵因素。通過重復(fù)訪問相同查詢，系統(tǒng)能夠從不同角度診斷問題，提煉更精確的解決方案。這種機(jī)制使 Reflector 能夠進(jìn)行深度反思，避免表面層次的修正。在消融實驗中，多輪精煉將準(zhǔn)確率從 56.8% 提升至 59.4%，證明了這一機(jī)制對上下文質(zhì)量的關(guān)鍵影響。

ACE 的離線預(yù)熱機(jī)制為在線適應(yīng)提供了高質(zhì)量的初始上下文。通過先在訓(xùn)練數(shù)據(jù)上進(jìn)行離線適應(yīng)，ACE 為在線適應(yīng)階段提供了更全面、更準(zhǔn)確的初始上下文，減少了探索成本。在消融實驗中，離線預(yù)熱使在線適應(yīng)性能從 56.1% 提升至 59.5%，證明了這一機(jī)制對實際部署的重要性。

一個常見誤解是更長的上下文必然導(dǎo)致更高的推理成本。ACE 產(chǎn)生的更長上下文并不意味著線性增加的推理成本或 GPU 內(nèi)存使用。正如論文中所提到，當(dāng)下服務(wù)基礎(chǔ)設(shè)施通過 KV Cache 復(fù)用、壓縮和卸載等技術(shù)，使頻繁重用的上下文段可以被緩存，避免重復(fù)昂貴的 prefill 操作。這些機(jī)制允許上下文片段在本地或遠(yuǎn)程緩存，顯著降低長上下文的攤銷成本。隨著 ML 系統(tǒng)的持續(xù)發(fā)展，處理長上下文的實際開銷將進(jìn)一步降低，使 ACE 等上下文豐富的方法在部署中越來越實用。

ACE 的上下文管理機(jī)制使其能夠高效處理長上下文。通過將上下文組織為結(jié)構(gòu)化的 bullet，系統(tǒng)可以僅將相關(guān)部分加載到內(nèi)存中，避免處理整個長上下文。同時，通過語義嵌入進(jìn)行去重，系統(tǒng)可以識別和移除冗余信息，保持上下文的緊湊性。這些技術(shù)使 ACE 能夠在保持上下文詳盡性的同時，控制推理成本。

總結(jié)

ACE 源于信任 LLM 能從詳盡上下文中自主提取關(guān)鍵信息，而非人為壓縮。這是對"簡潔即高效"傳統(tǒng) Prompt 工程的范式挑戰(zhàn)。這篇研究還明確指出了 ACE 的適用邊界：其效果依賴于 Reflector 的質(zhì)量：若 Reflector 無法從生成軌跡中提取有意義的見解，構(gòu)建的上下文可能變得嘈雜甚至有害。在領(lǐng)域特定任務(wù)中，若沒有模型能提取有用見解，結(jié)果上下文自然缺乏這些內(nèi)容。 此外，并非所有任務(wù)都適合長上下文——像 HotPotQA 這類任務(wù)通常受益于簡潔、高級指令，而 Game of 24 等固定策略場景只需單一可重用規(guī)則，額外上下文反而冗余。ACE 最適用于需要詳盡領(lǐng)域知識、復(fù)雜工具調(diào)用或環(huán)境特定策略的任務(wù)（如智能體、金融或法律分析）。

ACE 的效果也依賴于可靠的反饋信號質(zhì)量。當(dāng)缺乏真實標(biāo)簽且無執(zhí)行環(huán)境時，構(gòu)建的上下文可能被虛假或誤導(dǎo)性信號污染，導(dǎo)致性能下降。如下表所示，在無 GT 標(biāo)簽的 FiNER 任務(wù)上，DC(CU) 性能下降至 68.3%，而 ACE 仍能保持 67.3% 的準(zhǔn)確率，表明 ACE 對噪聲反饋具有一定的魯棒性，但性能仍低于有監(jiān)督設(shè)置。這凸顯了在上下文適應(yīng)中，反饋質(zhì)量對系統(tǒng)可靠性的重要性。

ACE設(shè)計選擇的消融研究

在復(fù)雜系統(tǒng)中，構(gòu)建"可積累、可演進(jìn)、可審計"的上下文基礎(chǔ)設(shè)施，而非追求一次性最優(yōu) Prompt，將成為未來實踐的關(guān)鍵。ACE 為在線和連續(xù)學(xué)習(xí)提供了靈活高效的替代方案，適應(yīng)上下文通常比更新模型權(quán)重更便宜，且上下文的可解釋性使選擇性遺忘成為可能——無論是出于隱私或法律約束，還是當(dāng)領(lǐng)域?qū)＜易R別出過時或錯誤信息時。隨著長上下文 LLM 和高效推理技術(shù)的進(jìn)步，ACE 所代表的上下文工程范式有望推動更可靠、可擴(kuò)展、自進(jìn)化的 AI 系統(tǒng)發(fā)展。

ACE 的增量更新機(jī)制使其能夠?qū)崿F(xiàn)選擇性遺忘。通過跟蹤每個 bullet 的有用/有害計數(shù)器，系統(tǒng)可以識別并移除有害信息，而無需重新訓(xùn)練整個模型。這種能力對于滿足 GDPR 的"被遺忘權(quán)"或 CCPA 的"刪除權(quán)"等法規(guī)要求至關(guān)重要，使系統(tǒng)能夠快速響應(yīng)隱私請求，同時保留其他有用知識。這為構(gòu)建負(fù)責(zé)任的 AI 系統(tǒng)提供了實用工具，使上下文適應(yīng)不僅提升性能，還能滿足合規(guī)要求。

在實際應(yīng)用中，ACE 為開發(fā)者提供了明確的實踐指導(dǎo)：在需要處理 API 分頁邏輯、金融 XBRL 規(guī)則或法律條文解釋的復(fù)雜任務(wù)中，ACE 能顯著提升性能；而在需要快速邏輯推理或固定策略的任務(wù)中，簡潔的提示可能更有效。這種明確的邊界定義有助于開發(fā)者做出明智的技術(shù)選擇，構(gòu)建更可靠、可解釋、自進(jìn)化的 AI 系統(tǒng)。隨著 ACE 框架的廣泛應(yīng)用，上下文工程將從"壓縮即美"的傳統(tǒng)范式，轉(zhuǎn)向"詳盡即強(qiáng)"的新時代，為 LLM 應(yīng)用提供更強(qiáng)大的支持。

本文很適合結(jié)合google 這篇一起看??《從失敗中學(xué)習(xí)：Google 提出 ReasoningBank 讓 LLM 智能體真正“吃一塹長一智”》。這兩篇都是工程化方面優(yōu)秀的研究。需要注意的是，這些方法都是在 test-time 進(jìn)行 scaling，所以對推理時的算力會有一定的要求。如果你用的是閉源模型，那么??token 幾乎是必然的。

除了對算力的消耗以外，從算法角度，我依據(jù)過去 2 年多的實踐經(jīng)驗來看，這兩類方法都有相同的適應(yīng)性和不適應(yīng)性的邊界問題。本文這個總結(jié)部分的第一段，在上面的內(nèi)容已經(jīng)提到了一些 ACE 論文中對“適用性邊界”的洞見。我在這里想多補(bǔ)充一個觀點(diǎn)，是針對造成“適用性邊界”的底層因素的補(bǔ)充：同類方法在不變更模型參數(shù)的前提下，需要在模型 pretrain 數(shù)據(jù)覆蓋度高的場景中應(yīng)用，可以取得良好的收益（這些前兩天我在社群中已經(jīng)有聊到過）。

這是因為當(dāng)前模型在算法架構(gòu)還沒取得實質(zhì)性進(jìn)化、突破的前提下，仍高度依賴特定模式，導(dǎo)致其在跨領(lǐng)域、跨環(huán)境場景下的泛化能力非常有限，甚至難以滿足實際商用落地需要。當(dāng)下的模型可以在數(shù)據(jù)覆蓋充足的場景中，有限的泛化出 training 時沒有見過的模式與推理。但，如果要求用ACE 或者 reasoningbank 這類工程方法，來實現(xiàn)在 training 數(shù)據(jù)覆蓋不足的場景中“進(jìn)化”推理，這對于模型來講會有點(diǎn)勉為其難了。

可，如果你一定要在一個私域、垂域中做推理進(jìn)化，怎么辦？在當(dāng)下這個時點(diǎn)，training 幾乎就是最好的路徑（但不是唯一路徑），模型要先有知識，才會建模，然后形成模式推理，最后才是工程化手法在 test-time scaling 實踐諸如本文的 ACE或 reasoningBank 這些上下文工程。這是因為，領(lǐng)域數(shù)據(jù)覆蓋不足，則建模不足，那么就需要用對應(yīng)的數(shù)據(jù)工程來覆蓋，用算法來建模，以期在特定業(yè)務(wù)領(lǐng)域內(nèi)的性能提升。

這就如同，對于人類的孩子而言，你無法讓一個沒有學(xué)過加法的、不到 3 歲的托班小朋友，去算 1+1=？。當(dāng)我們理解了這些底層原理、邏輯以后，再面對具體業(yè)務(wù)場景，我們心里才會有一個大概的輪廓來判斷：對于模型而言，應(yīng)用這些方法論，是否適合當(dāng)下的場域。在有了初步判斷以后，我們真正推進(jìn)工程構(gòu)建之前，在自己的業(yè)務(wù)領(lǐng)域中，對模型性能在私域中的評估是接下來的必經(jīng)之路，模型邊界在自己業(yè)務(wù)上的邊界，需要用評估數(shù)據(jù)來說話。

這一輪 AI 發(fā)展至今，各類媒體的聲音、不同人的認(rèn)知交織在一起，雜音很大，而工程落地需要透過現(xiàn)象看本質(zhì)。我們堅持不悲不喜、不魅惑、不盲從權(quán)威，以不變的做業(yè)務(wù)的、科學(xué)的、工程態(tài)度，應(yīng)對千變?nèi)f化的外部聲音，就能更加科學(xué)的思辨用好 AI，真正的服務(wù)于業(yè)務(wù)、服務(wù)于人！