讓AI越用越聰明——斯坦福這篇ICLR論文讓微調信仰開始動搖

這是一篇來自斯坦福大學、SambaNova Systems與UC Berkeley的聯合研究，標題叫《Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models》，中文可以譯作"智能體上下文工程：為自我進化的語言模型構建動態語境"。

論文的核心主張只有一句話：與其修改模型的權重，不如讓模型的"記憶"越來越好用。發表后，這篇論文在AI社區引發了不小的討論，甚至有工程師直接喊出"微調已死"。原因在于，他們用一個更小的開源模型，通過這套方法，在公開榜單上追平了IBM用GPT-4.1構建的生產級智能體——而且沒有花一分錢去做微調。

這個結果足夠令人吃驚，值得認真拆解一遍。

先說一個被低估的問題：上下文工程

在深入ACE之前，需要先厘清一個術語：上下文適配（Context Adaptation），或者更通俗地說，"上下文工程"。

對LLM來說，提升性能有兩條路：一條是改模型本身，也就是微調（fine-tuning）；另一條是改模型的輸入，也就是往prompt里塞更好的指令、策略、示例、領域知識。后者就是上下文工程。

這條路并不新鮮。每個認真做過RAG、寫過system prompt、調過few-shot的工程師都在無意識地做上下文工程。它的優勢顯而易見：不需要動模型權重，改起來快、看得見、可以隨時回滾。

但它的天花板在哪里？

研究者在論文里指出了兩個老對手從未解決的根本缺陷。

第一個：簡潔偏差（Brevity Bias）。 現有的提示優化方法，比如GEPA，傾向于把上下文壓縮成簡短的通用指令。這在某些場景里夠用，但在需要大量領域知識的任務里，把"當分頁API返回為空時停止循環"這類具體的工程經驗濃縮成"請注意API規范"，就等于把最有價值的東西扔掉了。

第二個：上下文崩塌（Context Collapse）。 這個現象更危險。當讓一個LLM在每次更新時全量重寫上下文，隨著內容越來越多，模型會傾向于把它壓縮成更短的摘要。論文里給出了一個實測數據：在AppWorld基準測試的第60步，上下文里有18,282個token，準確率達到66.7。但下一步，LLM全量重寫后，上下文直接塌縮到了122個token，準確率跌到57.1，比什么都不做（基準線63.7）還要差。一次重寫，把60步積累的所有經驗清零了。

這就是ACE要解決的核心問題。

ACE的核心思路：把上下文當成一本會生長的手冊

ACE的設計哲學可以用一句話概括："上下文不是摘要，而是劇本（playbook）。"

背后有一個關鍵判斷——人類和LLM的處理習慣恰好相反。人類喜歡高度濃縮的信息，靠背景知識和直覺填補空白；而LLM在接收詳細、具體、豐富的上下文時，表現往往更好，它們有能力在推理時自己判斷哪些內容有用。

所以，與其幫LLM"提煉"，不如幫它"積累"。

ACE的架構由三個角色協同完成：

Generator（生成器）執行實際任務，產出推理軌跡——哪些步驟走通了，哪些報錯了，哪些API用錯了，完整記錄。

Reflector（反思器）拿著這份軌跡做診斷。它會分析哪里出了問題，為什么出問題，正確做法應該是什么，并提煉出"關鍵洞察"。它還會對劇本里現有的每個知識條目打標簽：這次有沒有幫上忙？

Curator（整理器）把反思器的輸出轉化為結構化的"增量條目"（delta entries），然后用非LLM的確定性邏輯合并進劇本。合并、去重、修改計數器——全部不需要再跑一次大模型。

這里有一個細節值得注意：Curator在合并時用的是代碼邏輯，而不是讓LLM重寫整個劇本。這直接消除了上下文崩塌的根源。更新是原子的、局部的，過去積累的內容不會因為一次新的迭代而消失。

增量更新與"生長再精煉"機制

ACE的防崩塌設計有兩個具體機制，值得展開說。

增量delta更新：劇本由一條條帶ID的知識條目（bullets）組成，每個條目記錄著它被標記為"有用"和"有害"的次數。新的經驗只會追加或修改已有條目，不會觸發全量重寫。多個增量可以并行處理，然后一次性合并——這也是為什么ACE的延遲能大幅低于傳統方法。

生長再精煉（Grow-and-Refine）：劇本會持續變長，但這不能無限膨脹。ACE用語義嵌入做相似度比較，把語義相近的條目合并或去重。這個精煉操作可以主動觸發（每次delta之后），也可以懶觸發（只有當上下文窗口快撐不住了才運行）。

論文里展示了一個AppWorld生成的劇本樣例，里面分成"策略與硬規則"、"可用代碼片段與模板"、"故障排查與陷阱"三個板塊。比如其中一條寫道：如果身份驗證失敗，按順序嘗試用手機號而非郵箱作為用戶名，清除supervisor里的憑證，查閱API文檔確認正確參數，不要使用變通方法（workaround）。

這不是一條抽象的"注意認證問題"，而是一條可以直接指導下一次操作的具體經驗。這正是ACE與之前方法的本質區別。

實驗結果：更小的模型，頂尖的成績

研究團隊在兩類任務上做了系統評測。

智能體基準（AppWorld）：這是一個要求LLM通過Python代碼調用API、完成日常任務的復雜環境，包含郵件、文件系統、音樂、支付等場景。任務分"普通"和"挑戰"兩個難度級別，公開榜單上有來自工業界的對標系統。

在離線適配（先用訓練集優化劇本，再在測試集上評估）的設置下，ReAct + ACE的平均準確率達到59.4%，而ICL基準線是46.0%，GEPA是46.4%，提升幅度接近13個百分點。在線適配（邊測試邊更新劇本）的設置下，ACE達到59.5%，比Dynamic Cheatsheet高出7.6個點。

更重要的比較來自公開榜單快照（2025年9月20日）。榜首是IBM的CUGA，使用GPT-4.1，平均準確率60.3%。ACE使用的是DeepSeek-V3.1（一個更小的開源模型），平均59.4%，基本持平。在更難的test-challenge分項上，ACE的TGC（任務目標完成率）比CUGA高8.4個百分點。

金融領域基準（FiNER + Formula）：這兩個任務要求對XBRL格式的財務文件做實體識別和數值推理，需要大量金融領域的專門知識。有標注監督時，ACE在FiNER上比基線提升7.6個點，在Formula上提升高達18個點。平均來看，比GEPA高出10.9個點。

還有一個值得關注的數字：在無標注場景下（只靠執行反饋，沒有人工標注的正確答案），ACE在AppWorld上仍然比基準線高14.8個點。這說明ACE的自我改進機制不依賴人工監督，代碼執行的成功或失敗本身就是足夠強的信號。

效率的對比同樣戲劇性。在離線適配上，ACE的適配延遲比GEPA低82.3%，需要的rollout數量少75.1%。在線適配上，比Dynamic Cheatsheet的延遲低91.5%，token費用低83.6%。

消融實驗揭示了什么

論文花了不少篇幅做消融（逐步拆掉某個組件，看性能如何變化），結論比較清晰。

去掉Reflector和多輪迭代，只保留基本框架，AppWorld平均準確率從59.4%跌到55.1%，損失4.3個點。只去掉多輪迭代，保留Reflector，準確率56.8%，損失2.6個點。這說明Reflector的存在本身就有價值，而多輪迭代在此基礎上進一步改善了質量。

在線適配中，加入"離線預熱"（先用訓練集跑一遍積累初始劇本，再進入在線測試）從56.1%提升到59.5%，增益明顯。這個設置在實際部署中是可行的——對于確定的業務場景，提前用歷史數據初始化劇本，然后在生產環境里繼續在線更新。

這套方法的邊界在哪里

論文在Limitations一節坦誠地討論了幾個限制。

ACE的表現強依賴Reflector的質量。如果模型本身連有效的反思都做不到，劇本就會被噪聲污染。金融任務在無標注場景下，ACE和DC都出現了性能下降，就是因為缺乏可靠的信號，錯誤的反思反而干擾了劇本。

不是所有任務都適合這套方法。HotPotQA這類問答任務更需要的是如何檢索和整合證據的高層策略，而不是堆砌細節；Game of 24這類有固定解法的游戲，一條規則就夠了，多余的上下文只是負擔。

ACE最適合的場景是：需要掌握大量領域知識、工具使用有很多細節、或者環境交互有很多特定經驗值得積累的任務——恰好是當下企業級AI應用最集中的方向。

長上下文不等于高成本

這個點被論文單獨拿出來討論，因為它是一個常見的誤解。

ACE會生成比GEPA更長的上下文，有人擔心這意味著更高的推理成本。但作者指出，現代推理基礎設施對長上下文做了專門優化——KV cache復用、壓縮和卸載等技術讓重復使用的上下文段不需要反復做prefill計算。隨著長上下文推理的效率持續提升，ACE這類方法的攤銷成本會越來越低，而它帶來的性能收益會持續存在。

更深的一層含義是，上下文里存儲的知識是"可解釋的"。合規官員可以直接閱讀劇本，知道AI學到了什么；發現問題時可以直接編輯或刪除某條知識，而不是重新跑一遍微調。這在金融、法律、醫療等受監管行業里，是一個實質性的優勢。

論文地址：

https://arxiv.org/pdf/2510.04618

END本文來自至頂AI實驗室，一個專注于探索生成式AI前沿技術及其應用的實驗室。致力于推動生成式AI在各個領域的創新與突破，挖掘其潛在的應用場景，為企業和個人提供切實可行的解決方案。

Q&A

Q1：ACE與傳統prompt優化方法（如GEPA）的本質區別是什么？

GEPA等方法會不斷重寫整個提示，傾向于生成越來越簡短的通用指令，以此來滿足驗證指標。ACE的不同之處在于它不做全量重寫。每次迭代只生成"增量條目"，用非LLM的代碼邏輯合并進劇本，保證舊知識不會因為一次新的更新而消失。這直接解決了"簡潔偏差"和"上下文崩塌"兩個問題。

Q2：沒有人工標注的正確答案，ACE怎么知道該學什么？

在智能體任務中，代碼執行本身就是天然的反饋信號——代碼跑通了、任務完成了，就是正確的；報錯了、任務失敗了，就是錯誤的。ACE的Reflector利用這些執行結果做反思，不需要人工標注。這使得ACE可以在生產環境中持續自我改進，而不需要持續的人工干預。

Q3：這套方法是否意味著模型微調變得不必要了？

不是這個意思，但它確實改變了微調的必要性邊界。對于需要快速適配、知識需要頻繁更新、或者領域知識量大但結構清晰的場景，ACE提供了一條更輕量的替代路徑。微調在需要改變模型底層推理能力或語言風格時仍然有價值，但在"讓模型知道更多領域經驗"這件事上，ACE表明上下文工程可以做到原來認為需要微調才能實現的效果。