ACE: Agentic Context Engineering 論文首頁

作者： Wisely Chen 日期： 2026 年 4 月 系列： AI Agent 實戰觀察 關鍵字： ACE, Agentic Context Engineering, Context Engineering, Fine-tuning, Agent Memory, Playbook, Stanford, CLAUDE.md, ICLR 2026

先講結論：這篇論文在講什麼

Stanford、SambaNova、UC Berkeley 三家聯合發了一篇叫 Agentic Context Engineering (ACE) 的論文（arXiv: 2510.04618），已被 ICLR 2026 收錄。

一句話版本：

讓 AI Agent 持續進步，不一定要動模型權重。把 context 設計成一份會自我演化的 playbook，效果可能更好。

它不是在改 Transformer、不是在調 loss function、不是在做 RLHF。它在做的事情是：把 system prompt、agent memory、策略筆記、失敗經驗、成功案例，全部當成一份持續增長的「作戰手冊」來管理。

聽起來很簡單？但這篇論文做到了兩件讓我認真看待的事：

  1. 在 AppWorld leaderboard 上，用較小的開源模型追平了頂級商用 Agent
  2. 在更難的 test-challenge split 上，還超過了對手

這不是 toy benchmark，這是真實的 agent 任務環境。

論文想解的兩個問題

問題一：Brevity Bias（過度簡短偏誤）

很多 prompt optimization 方法，會把 context 越改越短、越抽象。

看起來更精煉，但問題是：

  • 真正有用的 domain knowledge 被壓掉了
  • 工具使用的細節被摘要掉了
  • 失敗模式的具體描述被泛化了

結果就是，「優化」後的 prompt 反而比原始版本表現更差。

這個現象我自己也遇過。之前在整理 CLAUDE.md 的時候，試過用 AI 幫我「精簡」指令——結果精簡完，Agent 的行為反而退步了。因為它把那些看起來「冗餘」但其實很關鍵的細節刪掉了。

問題二：Context Collapse（Context 崩塌）

如果每次都把整份 context 重新摘要重寫，久了就會：

  • 細節流失： 第一次摘要保留 80%，第二次 64%，第三次 51%⋯⋯指數衰減
  • 策略退化： 原本具體的「遇到 X 錯誤時，先檢查 Y 再嘗試 Z」變成「注意錯誤處理」
  • Performance 下降： 模型越來越像剛出廠的狀態，之前學到的經驗全部歸零

這個問題在 Claude Code 的上下文管理裡也出現過。我之前寫過一篇拆解 Claude Code 四層壓縮機制的文章，裡面提到它的 Full Compact 做了 9 個維度的結構化摘要——而不是無差別壓縮——就是為了對抗這個問題。

但 ACE 的野心更大：它不只是「怎麼壓縮不丟資訊」，而是「怎麼讓 context 越用越好」。

ACE 框架：三步循環

ACE 的核心不複雜，就是三件事反覆做：

1. Generation（生成）

Agent 在執行任務時，產生新的觀察和策略。

不是隨便記，而是結構化地記錄：

  • 這個任務用了什麼工具、什麼順序
  • 哪個步驟卡住了、為什麼
  • 最終成功的路徑是什麼

2. Reflection（反思）

根據執行結果回頭看：

  • 哪些策略有效？保留
  • 哪些策略失敗了？標記原因
  • 有沒有更好的替代方案？

關鍵是：這個反思不是人在做，是 Agent 自己做的。它根據 execution feedback 和環境信號來判斷。

3. Curation（策展）

把有價值的內容整理進 context，但不是整份重寫。

這是 ACE 跟傳統 prompt optimization 最大的差異：

傳統做法 ACE 做法
整份 context 重新摘要 增量式更新，保留原始細節
越改越短 結構化增長，有組織地變長
追求「精煉」 追求「完整且可檢索」
丟掉失敗經驗 把失敗轉成可重用的避雷指南

數字說話

論文的實驗結果：

指標 數據
Agent tasks 平均改善 +10.6%
Finance/domain-specific reasoning +8.6%
Adaptation latency 顯著降低
Rollout cost 更低
需要 labeled data？ 不需要
AppWorld leaderboard 追平 top production agent
更難的 test-challenge split 超過對手

最後一行最狠：用較小的開源模型，在最難的測試集上打贏了商用頂級 Agent。

這說明什麼？模型大小不是唯一決定因素，context 的品質和組織方式也是。

為什麼我認為這篇論文很重要

它驗證了我們已經在做的事

坦白說，看到這篇論文的時候，我的第一反應不是「哇好新」，而是「終於有人把這件事寫成論文了」。

因為如果你認真在用 Claude Code，你其實已經在做 ACE 描述的事情：

ACE 概念 Claude Code 對應
Playbook（作戰手冊） CLAUDE.md
Strategy notes memory/ 目錄下的經驗記錄
Task heuristics 工具使用的 system prompt
Failure patterns 熔斷器、重試邏輯
Incremental curation Session Memory Compact 的結構化事實提取

CLAUDE.md 不就是一份會持續演化的 playbook 嗎？你每次跟 Claude Code 合作完一個專案，發現某個模式有效，就把它寫進 CLAUDE.md。下次開新專案，Agent 就從這份演化過的手冊開始，而不是從零開始。

這不就是 ACE 說的 generation → reflection → curation 循環？

它回答了一個很多企業在問的問題

「我們要不要 fine-tune 自己的模型？」

這個問題我在做顧問的時候被問過很多次。我的標準回答一直是：

先把 context 管好，再考慮 fine-tuning。

現在有了學術論文背書，這個建議更容易被接受了。

ACE 的數據很清楚：在 agent、tool use、long workflow、domain reasoning 這些場景裡，context engineering 的投資回報率遠高於 fine-tuning。

原因也不難理解：

  Fine-tuning Context Engineering
成本 高（GPU、數據標註、訓練時間） 低（文字編輯）
迭代速度 慢（重新訓練） 快（改一行 prompt）
可解釋性 低（權重是黑盒） 高（你能看到每條策略）
可回滾 難 容易（git revert）
適用場景 特定任務、大量數據 Agent workflow、多步推理

它指出了一個容易踩的坑

「Context 越短越好」是一個很流行但很危險的觀念。

ACE 用實驗證明了：過度壓縮 context 會導致 performance 退化。那些被「精簡」掉的細節，很多時候正是 Agent 做出正確決策的關鍵。

這跟我在 Claude Code 源碼裡看到的設計哲學一致。Anthropic 的四層壓縮架構，最底層（Micro Compact）只刪工具輸出，不動策略。最重的一層（Full Compact）做 9 個維度的結構化摘要，而不是無差別壓縮。

它們都在保護同一件事：context 裡的決策知識。

Fine-tuning 的商業實戰踩坑：朋友們交過的學費

論文講的是學術證據，但我身邊做過 fine-tune 專案的朋友，踩過的坑其實更痛。

坑一：驗證地獄

Fine-tune 完一個場景變得更棒，但很多相對應的場景就變得更差。

這個問題在學術上叫「災難性遺忘」，在實戰裡叫「修 A 壞 B」。而大語言模型的驗證 test case 接近無限——你不可能把所有邊界情況都測完。結果就是，每次以為調好了，上線後又冒出新的退化。

一個朋友的原話：「我們花了兩個月 fine-tune，然後花了四個月在修 fine-tune 造成的 regression。」

坑二：Base Model 迭代太快

往往 3 到 6 個月，原本需要 fine-tune 的 case，新一代 base model 就直接原生支援了。

你花了大量時間和 GPU 資源調出來的模型，一個 model iteration 就變得毫無意義。這不是假設性的風險——過去兩年，幾乎每一輪模型更新都讓一批 fine-tune 專案直接報廢。

坑三：高成本但護城河不明顯

Fine-tuning 是一個高成本的投資：GPU 租用、數據標註、訓練迭代、驗證測試。但它建立的護城河商業效益不明顯——因為你的競爭對手用新版 base model 加上好的 prompt，可能就達到你 fine-tune 的效果。

最致命的問題：Fine-tune 無法積累

這是我認為最關鍵的差異：

提示詞是可以積累的，fine-tune 不行。

Context engineering 的成果——你的 CLAUDE.md、你的 memory 系統、你的策略筆記——全部都是可積累的資產。今天寫的一條避雷指南，明天、後天、明年都還在發揮作用。換了模型，這些 context 大部分還能用。

Fine-tune 呢？就是一個 model checkpoint。Base model 一更新，這個 checkpoint 就廢了。你不能把上一版 fine-tune 學到的東西「搬」到新版 base model 上——你得從頭再來。

這就是為什麼 ACE 的 playbook 演化理念特別有說服力：它的產出物是知識，不是權重。知識可以跨模型、跨版本、跨工具地復用。權重不行。

學術與實戰的共同結論

從學術上，ACE 論文用實驗數據證明了 context engineering 的效果。從實戰上，做過 fine-tune 專案的人用真金白銀證明了同一件事。

結論很直接：要嘛找大資本直接做模型，要嘛 context engineering。沒有中間值。

Fine-tuning 卡在一個尷尬的位置：投入不夠大，做不出真正的差異化；投入夠大，不如直接做基礎模型。對絕大多數企業來說，context engineering 才是投資回報率最高的路。

對企業 AI Agent 落地的三個啟示

1. Context Layer 是你的第一優先投資

不要一開始就想著要 fine-tune。先做好這些事：

  • 建立 Agent 的知識手冊（類似 CLAUDE.md）
  • 設計失敗經驗的回饋機制（遇到錯誤自動記錄）
  • 結構化你的 domain knowledge（不是丟一堆文件進 RAG，而是有組織地整理）

這些投資的回報是即時的，而且可以隨時調整。

2. 記憶系統要增量更新，不要整份重寫

如果你的 Agent 有記憶功能，注意不要每次都把記憶整份摘要重寫。應該要：

  • 增量式新增：新經驗加進去，舊經驗保留
  • 標記式更新：某條策略失效了，標記為失效但不刪除（因為「為什麼失效」本身也是知識）
  • 版本控制：記憶的演化過程本身就是有價值的資訊

3. 99% 不需要 Fine-tuning？數字太激進，但方向正確

你可能看過推特上有人用 ACE 的結果喊「99% 的 AI 應用不需要 fine-tuning 了」。

這句話有流量效果，但比論文原意更激進。

論文真正支持的是：

  • 很多應用先做 context engineering，比先 fine-tune 更合理
  • 尤其是 agent、tool use、long workflow、domain reasoning 這類場景
  • 但它沒有證明 fine-tuning 已經被淘汰

在某些場景——比如你有大量標註數據、任務非常明確、需要極致延遲——fine-tuning 仍然是正確選擇。

準確的說法應該是：

對大多數 AI Agent 場景，context engineering 應該在 fine-tuning 之前做。做完之後，你可能發現根本不需要 fine-tune 了。

跟我之前寫的文章怎麼接

如果你一直在看這個系列，ACE 其實串起了好幾個我之前聊過的主題：

  1. Claude Code 四層壓縮機制：ACE 的 curation 階段，本質上就是在做 Claude Code 的 Session Memory Compact — 結構化地保留有價值的資訊，而不是無差別壓縮
  2. CLAUDE.md 作為 Agent 規範：ACE 的 playbook 概念，跟我們每天在用的 CLAUDE.md 完全對應
  3. Google Nested Learning：ACE 關注的是 inference-time 的 context 演化，Nested Learning 關注的是 training-time 的記憶形成。兩者從不同方向在解同一個問題——怎麼讓 AI 持續進步
  4. Context Rot 問題：ACE 的 brevity bias 和 context collapse，就是我之前在 RLM 那篇文章裡討論的 context rot 的另一個面向

結語

ACE 這篇論文最大的貢獻不是提出了什麼全新的技術，而是用嚴謹的實驗證明了一件很多實踐者已經知道的事：

對 Agent 來說，context 應該像會持續演化的操作手冊，而不是一次次被摘要掉的便條紙。

如果你正在建 AI Agent，與其花三個月收集數據做 fine-tuning，不如先花三天把你的 context layer 設計好。寫一份好的 CLAUDE.md、建一個結構化的記憶系統、設計一個失敗經驗的回饋循環。

這些東西的效果，可能比你想像的大得多。

延伸閱讀

常見問題 Q&A

Q: ACE 跟 RAG 有什麼差別？

RAG 是「查詢時去外部資料庫撈相關文件」，ACE 是「讓 Agent 的 context 本身會學習和演化」。RAG 解決的是「知識量太大放不進 context」的問題，ACE 解決的是「context 裡的策略怎麼持續改進」的問題。兩者互補，不衝突。

Q: 這篇論文用的是什麼模型？

論文使用較小的開源模型（具體模型未在摘要中詳列），重點是證明 context engineering 可以彌補模型規模的差距。在 AppWorld 最難的 test-challenge split 上超過了使用更大商用模型的 Agent。

Q: 我已經在用 CLAUDE.md，還需要做什麼？

CLAUDE.md 是靜態的——你手動寫、手動更新。ACE 的進階版本是讓這個過程半自動化：Agent 執行任務後自動記錄有效策略，人類定期 review 和整理。如果你有 Claude Code 的 memory 功能，其實已經在做這件事了。下一步是讓這個循環更結構化。

Q: 企業應該完全放棄 fine-tuning 嗎？

不應該。但應該調整優先順序：先做 context engineering，確認效果不足之後再考慮 fine-tuning。很多場景你會發現，做好 context 之後就不需要 fine-tune 了。