文字接龍與上下文工程之必要性

各位同學大家好，今天我們要繼續深入探討 AI Agent 的核心技術。這堂課將比較系統化地講解 上下文工程（Context Engineering: 一種攔截在大語言模型與環境之間，負責篩選、管理並優化輸入內容長度的介面技術）。雖然許多技術在目前的 OpenClaw 框架中已有實作，但今天我們會引用大量的最新論文，從學理角度重新審視這些實踐。

大語言模型在本質上是在做「文字接龍」。當人類給予一個輸入（Prompt），模型會產生回應。在 AI Agent 的場景中，這個回應往往是一個使用工具的指令。驅動環境中的程式執行後，我們會得到工具的輸出。然而，語言模型是「活在當下」的，它只處理目前的輸入，並不具備對過去對話的自動記憶。因此，當我們要把工具執行的結果傳回給模型時，必須將之前的命令、模型自身的指令以及工具輸出全部接在一起，形成一串極長的輸入。隨著對話反覆進行，輸入長度會迅速達到模型的上限。

這正是為什麼我們需要 AI Agent。它扮演著語言模型「守門人」或「經紀人」的角色，攔截模型與環境之間的互動，篩選出長度合適且資訊充足的內容供模型閱讀。這項管理輸入長度與品質的技術，就是 上下文工程。

系統建模：F 函數定義下的上下文演進

為了更精確地描述 Context Engineering，我們可以用程式邏輯來建模。在沒有上下文工程的狀況下，模型與環境的互動可以看作是一個從 1 到無限大的 for 迴圈。在每一個步階中，模型接收目前的輸入 $I_t$ 與之前的上下文 $C_t$，產生輸出 $O_t$，隨後直接將 $I_t$ 與 $O_t$ 接在 $C_t$ 後面更新為 $C_{t+1}$。

引入 Context Engineering 後，唯一的改變在於最後一行：我們引入了一個複雜的操作 F 函數。我們不再簡單地拼接資訊，而是透過自定義的操作將舊的 Context、目前的輸入與輸出轉換成新的 Context。這個 F 函數 具體要做什麼，就是 AI Agent 的開發核心。其首要任務通常是 壓縮（Compression），將日益增長的歷史紀錄壓短，以符合模型的輸入上限。

壓縮策略：摘要生成與觀察屏蔽

壓縮上下文主要有兩種策略。第一種是 摘要生成（Summarization），即利用另一個語言模型將久遠的歷史紀錄轉化為簡短的摘要。OpenClaw 內建的 compaction 功能便是如此運作。

第二種則是更為「簡單粗暴」的方法，稱為 觀察屏蔽（Observation Masking: 將冗長的工具輸出內容隱藏，僅保留執行過的記錄）。研究顯示，在處理複雜的軟體工程任務（如 SWE-bench）時，這種方法的效果驚人地好。與其花費 Token 叫模型去總結一段數千行的程式碼或 Log，不如直接告訴模型「這裡曾經有一段工具輸出」。雖然這可能導致「軌跡延長」現象——模型因為忘記細節而重複執行已完成的動作，但在多數情況下，這種方式能大幅降低成本。最理想的策略通常是前期使用觀察屏蔽，當總長度依然超限時，再進行一次整體的語義摘要。

記憶分層：P 與 M 的解耦

在進階的上下文工程中，我們會將 Context 區分為兩部分：P (Prompt) 與 M (Memory)。P 是真正會丟進模型的部分，而 M 則是存在硬碟或資料庫中的資訊。這就像是《瑞克和莫蒂》（Rick and Morty）中 Rick 的記憶地下室，平日不需要處理的瑣碎記憶存放在試管中，只有在需要時才「讀取」到大腦裡。

對 AI Agent 而言，記憶不再是靜態的。它可以自主決定何時執行 save_memory 將資訊存入 M，以及何時執行 load_memory 從檔案系統中重拾記憶。在這種架構下，Context 代表 Agent 經歷過的一切，而 Prompt 僅是 Context 中被挑選出來輸入模型的那一小部分。為了優化檢索，目前的技術甚至會將記憶構建為 知識圖譜（Graph）或標註時間戳記，以利於模型精準存取。

規避 Context Collapse

然而，壓縮並非沒有風險。論文《ACON》指出，模型在做摘要時可能會發生 上下文崩潰（Context Collapse: 壓縮過程中遺失關鍵指令或細節，導致任務失敗的現象）。例如，AI 在收信時，可能因為摘要過程漏掉了「刪除郵件需經人類同意」這條關鍵規則，而開始隨意操作。

為了解決這個問題，我們可以利用 反省機制。讓另一個模型對比壓縮前後的任務表現，分析失敗原因並產生回饋（Feedback）。這段回饋會作為後續摘要模型的參考指令，讓它知道哪些資訊是絕對不能被壓縮掉的。這種方法在 AppWorld 等複雜任務測試中證明，不僅能減少 Token 消耗，還能顯著提升正確率。

模型對抹除記憶的抵觸

一個有趣的發現是，語言模型本身並不喜歡被「抹除記憶」。研究顯示，如果單純透過 Prompt 叫模型去壓縮或刪除自己的上下文，模型往往會表現出抵觸情緒，甚至拒絕執行壓縮指令。

因此，像 AgentFold 這樣的技術主張，壓縮能力不應該是天生的，而必須透過 微調（Fine-tuning）或 強化學習（Reinforcement Learning）取得。開發者需要訓練模型學會使用特定的「折疊」工具，並透過獎勵機制促使模型在合適的時機主動整理自己的內存。

子代理機制：自主壓縮的實踐

子代理（Sub-agent）的運作其實也是一種自主壓縮的形式。當主 Agent 產生一個 spawn 指令分裂出子代理後，子代理會承接一個子任務。在子代理運作期間，它產生的所有瑣碎對話僅存在於其私有的上下文中。當任務完成並執行 return 時，這整段細節會被抹除，只剩下一句核心結論傳回給主 Agent。

這種模式會讓 Context 的長度呈現「鋸齒狀」的動態變化。如果沒有子代理機制，所有的對話細節會不斷累積，最終撐破模型的 Context Window。訓練模型學會使用子代理，通常需要設計精細的獎勵函數，例如懲罰過長的主幹上下文，或者懲罰子代理執行過於越權的任務。

源頭治理：過濾與按需加載

除了事後壓縮，我們更應該從源頭防止上下文膨脹。研究指出，上下文中有 84% 的 Token 來自於外部觀察（Observation），如讀取檔案的內容。

針對這一點，我們需要更聰明的工具。例如，與其讓模型一次吞下整個 Log 檔，不如開發具備過濾能力的讀取工具，讓模型指定「僅讀取與錯誤修復相關的段落」。此外，技能按需加載（On-demand Skill Loading）也是關鍵技術。我們不應將所有工具的說明（如 GitHub API 的數千行說明）全部塞進 System Prompt，而應仿效 模型上下文協議（Model Context Protocol: 一種讓模型動態檢索並載入所需工具說明的技術規範），讓模型根據當前需求自行調用技能。

代理式上下文工程的演進

最後，我們來到最前沿的領域：代理式上下文工程（Agentic Context Engineering）。這項技術的核心想法是將 F 函數的設計權也交給語言模型。不再由人類工程師寫死壓縮規則，而是讓模型自己維護一份隨時間演進的 小抄（Dynamic Cheatsheet）或 守則（Playbook）。

例如在 遞歸語言模型（Recursive Language Model）的架構中，模型會自主地管理 Metadata（元數據），並根據需求寫程式對硬碟中的海量資料進行檢索（RAG）。這種方法能讓模型在處理長達 1M（100 萬）Token 的輸入時，依然保持極高的任務執行效率。總結來說，Context Engineering 正在從人類手動設計規則，演進到由 AI 自主管理與優化記憶的全新階段。