Hi，大家好，我叫秋水，當前專注于 AI Agent（智能體）。

相信做過AI Agent開發的朋友都遇到過這些痛點：

• 為什么我的智能體在執行長任務時會突然"失憶"，前面的重要信息都忘記了？
• 為什么給智能體提供了大量工具，它反而變得更加混亂，選擇錯誤的工具？
• 為什么智能體的響應越來越慢，成本越來越高，但效果卻在下降？
• 為什么智能體會產生幻覺，把錯誤信息當作事實來使用？
• 為什么多個智能體協作時，信息傳遞會出現混亂和沖突？

這些問題的根源都指向同一個核心挑戰：Context Engineering（上下文工程）。

什么是Context Engineering（上下文工程）？

要理解Context Engineering，我們先來看一個很形象的比喻。

OpenAI的前研究科學家Andrej Karpathy說過：LLM（大語言模型）就像一種新的操作系統，LLM是CPU，而它的上下文窗口就是RAM。

這個比喻非常精準。我們都知道，電腦的RAM容量有限，操作系統需要管理哪些數據放在內存里，哪些數據暫時存儲到硬盤。同樣，LLM的上下文窗口容量也有限（即使是最新的模型也只有幾百萬Token（令牌）），需要管理放入什么信息。

Context Engineering（上下文工程）就是這樣一門藝術和科學：在智能體執行任務的每一個步驟中，都要精確地選擇合適的信息放入上下文窗口。

為什么Context Engineering（上下文工程）如此重要？

在傳統的LLM應用中，我們通常只需要處理一輪對話，上下文管理相對簡單。但AI Agent不同，它們需要：

1. 長期運行：可能需要執行幾十個甚至上百個步驟

2. 工具調用：頻繁使用各種工具，每次調用都會產生反饋信息

3. 狀態維護：需要記住執行過程中的重要信息

這就導致了一個嚴重問題：上下文信息會快速積累，很快就會超出模型的處理能力。

上下文過載會帶來什么問題？

LangChain的技術專家Drew Breunig總結了四種典型的上下文問題：

1. Context Poisoning（上下文污染）當智能體產生幻覺時，這些錯誤信息會被保存在上下文中，影響后續的判斷。就像一個人記住了錯誤的事實，后面的決策都會受到影響。

2. Context Distraction（上下文干擾）當上下文信息過多時，智能體會被大量無關信息干擾，無法專注于當前任務。就像你在一個嘈雜的環境中很難集中注意力工作。

3. Context Confusion（上下文混亂）過多的冗余信息會讓智能體產生混亂，影響響應的準確性。比如同一個概念在不同地方用不同方式表達，智能體可能會理解錯誤。

4. Context Clash（上下文沖突）當上下文中的不同部分包含矛盾信息時，智能體不知道該相信哪個，導致決策混亂。

Context Engineering（上下文工程）的四大核心策略

目前主流AI Agent產品和學術研究，Context Engineering主要有四大策略：Write（寫入）、Select（選擇）、Compress（壓縮）、Isolate（隔離）。

1. Write Context（寫入上下文）

核心思想：把重要信息保存在上下文窗口之外，需要時再調用。

Scratchpads（暫存區）

這就像人類做復雜任務時會記筆記一樣。智能體也需要一個"暫存區"來記錄重要信息。

實際應用場景：

• 電商客服智能體在處理復雜售后問題時，需要記錄客戶的歷史訂單信息、投訴記錄等
• 營銷智能體在制定推廣策略時，需要記錄市場調研結果、競品分析等

Anthropic的多智能體研究系統就是典型例子。當主研究員智能體開始工作時，它會先制定計劃并保存到Memory中。因為如果上下文超過20萬Token就會被截斷，保存計劃能確保重要信息不丟失。

Memories（記憶）

暫存區解決的是單次會話中的信息保存，但智能體還需要跨會話的長期記憶。

三種記憶類型：

• Procedural memories（程序記憶）：記錄如何執行任務的步驟和方法
• Episodic memories（情節記憶）：記錄具體的執行案例和經驗
• Semantic memories（語義記憶）：記錄事實和知識

這個功能現在在ChatGPT、Cursor、Windsurf等產品中都能看到。它們會根據用戶的使用習慣自動生成長期記憶。

2. Select Context（選擇上下文）

核心思想：從大量可用信息中精準選擇當前任務需要的信息。

這是最具挑戰性的一個環節。信息選擇不當會直接影響智能體的表現。

工具選擇

當智能體擁有大量工具時，如何選擇合適的工具是個大問題。最新研究表明，使用RAG（檢索增強生成）來選擇工具描述，可以將工具選擇準確率提升3倍。

知識選擇

代碼智能體是這方面最好的例子。Windsurf的技術負責人Varun分享了他們的經驗：

"代碼索引不等于上下文檢索...我們使用AST（抽象語法樹）解析代碼，按照語義邊界進行分塊...但隨著代碼庫規模增長，嵌入搜索變得不可靠...我們必須結合grep/文件搜索、知識圖譜檢索，還有重新排序步驟。"

這說明了一個重要問題：技術選擇需要根據具體場景來優化，沒有萬能的解決方案。

3. Compress Context（壓縮上下文）

核心思想：只保留執行任務所需的最少Token數量。

Context Summarization（上下文總結）

Claude Code是這方面的典型應用。當你的對話超過95%的上下文窗口時，它會自動運行"壓縮"功能，總結整個用戶-智能體交互歷史。

總結可以應用在多個地方：

• 遞歸或分層總結：把長對話分層總結
• 工具調用后處理：總結工具返回的冗長信息
• 智能體邊界：在多個智能體交接時總結關鍵信息

Context Trimming（上下文修剪）

相比總結需要用LLM來提煉信息，修剪可以用更簡單的規則。比如：

• 移除較舊的消息
• 過濾掉不相關的信息
• 使用經驗規則清理冗余內容

4. Isolate Context（隔離上下文）

核心思想：將上下文分割到不同的區域來幫助智能體完成任務。

Multi-agent（多智能體架構）

OpenAI的Swarm庫就是基于這個思想設計的。通過將復雜任務分解給多個專門的智能體，每個智能體都有自己的工具集、指令和上下文窗口。

Anthropic的多智能體研究系統證明了這種方法的有效性：多個具有隔離上下文的智能體表現優于單一智能體，主要因為每個子智能體的上下文窗口可以專注于更窄的子任務。

當然，多智能體也有挑戰：

• Token使用量大（Anthropic報告稱比單智能體多15倍）
• 需要精心設計提示詞來規劃子智能體工作
• 智能體間的協調復雜

環境隔離

HuggingFace的深度研究智能體展示了另一種隔離方式。它使用CodeAgent輸出代碼，然后在Sandbox（沙盒環境）中運行。只有選定的上下文（如返回值）才會傳回LLM。

這種方法特別適合處理高Token消耗對象，比如圖像、音頻等大型數據。

實際應用建議

基于以上分析，我給大家幾個實際的應用建議：

1. 建立監控機制

在開始優化之前，你需要能夠觀察到問題。建議：

• 追蹤Token使用情況
• 監控響應時間和成本
• 記錄智能體的決策過程

2. 逐步優化

不要試圖一次性解決所有問題，建議按以下優先級：

1. 先解決最耗費Token的部分

2. 然后優化關鍵信息的選擇

3. 最后考慮復雜的架構調整

3. 場景化設計

不同場景需要不同策略：

• 客服智能體：重點關注會話歷史的總結和客戶信息的持久化
• 營銷智能體：重點關注市場數據的選擇和策略記憶
• 碼智能體：重點關注代碼上下文的檢索和工具選擇

4. 以測試為導向的優化

每一個優化都應該通過測試來驗證效果，避免過度優化。