上下文管理：從Agent失效到高效運行的完整指南

發布于 2025-8-14 08:11

瀏覽

0收藏

上下文管理是AI智能體開發的核心難題。即使大模型有了千萬級token窗口，也不意味著可以無腦塞信息——垃圾進，垃圾出的鐵律依然有效。在此之前我們刊載了Manus在上下文工程上的心得。

近日，Drew Breunig也分享了它對于上下文管理層面的見解。這是一個完整的上下文管理指南，分為問題診斷《How Long Contexts Fail | Drew Breunig^[1]》和解決方案《How to Fix Your Context | Drew Breunig^[2]》兩部分。

第一部分分析了四種長上下文失效模式：污染（幻覺進入上下文被反復引用）、分心（模型過度關注上下文忽略訓練知識）、混亂（無關信息影響回應）、沖突（上下文內部矛盾）。作者用具體研究數據證明，即使Gemini超過10萬token就開始重復歷史動作，工具超過30個就會讓模型困惑。

第二部分提出6種系統性解決方案：RAG選擇性添加信息、工具載荷智能選擇工具、上下文隔離分離任務、上下文剪枝移除無關信息、上下文摘要壓縮內容、上下文卸載外部存儲。每種方法都有具體實現和性能數據。

長上下文的失效與修復：完整指南

第一部分：長上下文如何失效

管理上下文是成功智能體的關鍵

隨著前沿模型上下文窗口持續增長，許多模型支持多達100萬個token，我看到很多關于長上下文窗口將解鎖夢想智能體的興奮討論。畢竟，有了足夠大的窗口，你可以簡單地將可能需要的一切都扔進提示中——工具、文檔、指令等等——讓模型處理其余部分。

長上下文重創了RAG熱情（當你可以將所有文檔都塞進提示時，何必費力找最佳文檔！），催生了MCP炒作（連接到每個工具，模型可以做任何工作！），并推動了對智能體的熱情。

但實際上，更長的上下文并不能產生更好的回應。過載你的上下文會導致智能體和應用程序以令人驚訝的方式失效。上下文可能變得中毒、分散注意力、混亂或沖突。這對智能體尤其成問題，因為智能體依賴上下文收集信息、綜合發現和協調行動。

讓我們看看上下文可能失控的方式，然后回顧緩解或完全避免上下文失效的方法。

上下文失效

上下文污染（Context Poisoning）：當幻覺進入上下文時
上下文分心（Context Distraction）：當上下文壓倒訓練時
上下文混亂（Context Confusion）：當多余的上下文影響回應時
上下文沖突（Context Clash）：當上下文的部分內容相互沖突時

上下文污染（Context Poisoning）

上下文污染是當幻覺或其他錯誤進入上下文，并被反復引用時。

DeepMind團隊在Gemini 2.5技術報告^[3]中指出了上下文污染問題，我們上周分析過^[4]。在玩口袋妖怪時，Gemini智能體偶爾會在游戲中產生幻覺，污染其上下文：

這個問題的一種特別嚴重的形式可能是"上下文污染"——上下文的許多部分（目標、摘要）被關于游戲狀態的錯誤信息"污染"，這通常需要很長時間才能消除。結果，模型可能會專注于實現不可能或無關的目標。

如果其上下文的"目標"部分被污染，智能體會制定荒謬的策略，并重復行為以追求無法實現的目標。

上下文分心（Context Distraction）

上下文分心是當上下文增長到如此之長，以至于模型過度關注上下文，忽略了訓練期間學到的知識。

隨著智能體工作流程中上下文的增長——模型收集更多信息并建立歷史——這種累積的上下文可能變得分散注意力而不是有幫助。玩口袋妖怪的Gemini智能體清楚地展示了這個問題：

雖然Gemini 2.5 Pro支持1M+token上下文，但在智能體中有效使用它呈現了新的研究前沿。在這種智能體設置中，觀察到隨著上下文顯著增長到超過100k token，智能體表現出傾向于重復其龐大歷史中的動作，而不是綜合新穎計劃。這種現象，盡管是軼事性的，突出了長上下文檢索和長上下文多步驟生成推理之間的重要區別。

智能體沒有使用其訓練來制定新策略，而是專注于重復其廣泛上下文歷史中的過去動作。

對于較小的模型，分心閾值要低得多。Databricks研究^[5]發現，模型正確性在Llama 3.1 405b約32k處開始下降，較小模型更早。

如果模型在其上下文窗口填滿之前就開始出現異常行為，那么超大上下文窗口的意義何在？簡而言之：摘要和事實檢索。如果你不在做這兩件事中的任何一件，要小心你選擇的模型的分心閾值。

上下文混亂（Context Confusion）

上下文混亂是當上下文中的多余內容被模型用來生成低質量回應時。

有一段時間，看起來每個人都要發布一個MCP^[6]。一個強大的模型，連接到你的所有服務和東西，做你所有平凡任務的夢想感覺觸手可及。只需將所有工具描述扔到提示中然后開始。Claude的系統提示^[7]向我們展示了方向，因為它主要是工具定義或使用工具的指令。

但即使整合和競爭不會拖慢MCPs^[8]，上下文混亂也會。事實證明，工具太多確實是個問題。

伯克利函數調用排行榜^[9]是一個工具使用基準測試（benchmark），評估模型有效使用工具回應提示的能力。現在是第3版，排行榜顯示每個模型在提供超過一個工具時表現都更差。此外，伯克利團隊"設計了提供的函數都不相關的場景...我們期望模型的輸出是不進行函數調用。"然而，所有模型偶爾會調用不相關的工具。

瀏覽函數調用排行榜，你可以看到問題隨著模型變小而惡化：

上下文混亂的一個突出例子可以在最近的一篇論文^[10]中看到，該論文評估了小模型在GeoEngine基準測試^[11]上的性能，這是一個包含46種不同工具的試驗。當團隊給量化（壓縮）的Llama 3.1 8b一個包含所有46個工具的查詢時，它失敗了，盡管上下文遠在16k上下文窗口之內。但當他們只給模型19個工具時，它成功了。

問題是：如果你把某些東西放在上下文中，模型必須關注它。它可能是無關信息或不必要的工具定義，但模型會將其考慮在內。大型模型，特別是推理模型，在忽略或丟棄多余上下文方面越來越好，但我們持續看到無價值信息絆倒智能體。更長的上下文讓我們塞入更多信息，但這種能力伴隨著缺點。

上下文沖突（Context Clash）

上下文沖突是當你在上下文中積累與上下文中其他信息沖突的新信息和工具時。

這是上下文混亂的更成問題版本：這里的壞上下文不是無關的，它與提示中的其他信息直接沖突。

微軟和Salesforce團隊在最近的一篇論文^[12]中出色地記錄了這一點。團隊從多個基準測試中提取提示，并將其信息'分片'到多個提示中。這樣想：有時，你可能坐下來在點擊回車之前向ChatGPT或Claude輸入段落，考慮每個必要的細節。其他時候，你可能從一個簡單的提示開始，然后在聊天機器人的答案不令人滿意時添加進一步的細節。微軟/Salesforce團隊修改了基準測試提示，使其看起來像這些多步驟交換：

上下文管理：從Agent失效到高效運行的完整指南-AI.x社區

左側提示中的所有信息都包含在右側的幾條消息中，這些消息將在多輪聊天中播放。

分片提示產生了顯著更差的結果，平均下降39%。團隊測試了一系列模型——OpenAI備受推崇的o3得分從98.1下降到64.1。

發生了什么？為什么如果信息是分階段收集而不是一次性全部收集，模型表現會更差？

答案是上下文混亂：組裝的上下文，包含整個聊天交換的內容，包含模型在擁有所有信息之前回答挑戰的早期嘗試。這些錯誤答案仍然存在于上下文中，并在模型生成最終答案時影響模型。團隊寫道：

我們發現LLM經常在早期輪次中做出假設并過早嘗試生成最終解決方案，對此過度依賴。簡而言之，我們發現當LLM在對話中走錯路時，它們會迷失方向并且不會恢復。

這對智能體構建者來說不是好兆頭。智能體從文檔、工具調用和承擔子問題的其他模型中組裝上下文。所有這些從不同來源拉取的上下文都有可能與自身不一致。此外，當你連接到你沒有創建的MCP工具時，它們的描述和指令與你提示的其余部分沖突的可能性更大。

第二部分：如何修復你的上下文

緩解和避免上下文失效

接續我們此前的文章"長上下文如何失效^[13]"，讓我們來看看如何緩解或完全避免這些失效問題。

首先簡單回顧一下長上下文可能失效的幾種方式：

上下文污染（Context Poisoning）：當幻覺或其他錯誤進入上下文后，被反復引用
上下文分心（Context Distraction）：當上下文過長時，模型過度關注上下文，忽略了訓練時學到的知識
上下文混亂（Context Confusion）：當上下文中的多余信息被模型用來生成低質量回應
上下文沖突（Context Clash）：當你在上下文中積累了與提示中其他信息沖突的新信息和工具

這些問題的核心都是信息管理。上下文中的一切都會影響回應。我們又回到了編程的老話："垃圾進，垃圾出"。好在有很多選擇來處理上述問題。

上下文管理策略

RAG：選擇性添加相關信息來幫助LLM生成更好的回應
工具載荷（Tool Loadout）：只選擇相關的工具定義添加到上下文中
上下文隔離（Context Quarantine）：在專用線程中隔離上下文
上下文剪枝（Context Pruning）：從上下文中移除無關或不需要的信息
上下文摘要（Context Summarization）：將累積的上下文壓縮成簡潔摘要
上下文卸載（Context Offloading）：將信息存儲在LLM上下文之外，通常通過存儲和管理數據的工具

RAG

檢索增強生成（Retrieval-Augmented Generation，RAG）是選擇性添加相關信息來幫助LLM生成更好回應的行為。

關于RAG已經寫了太多，我們今天不會深入，只想說：它仍然很有用。

每當模型提高上下文窗口規模時，就會誕生新一輪"RAG已死"的辯論。最近一次重大事件是Llama 4 Scout發布了1000萬token窗口。在這樣的規模下，真的很誘人去想"算了，全塞進去"就完事了。

但正如我們上次提到的：如果你把上下文當作雜物抽屜，雜物會影響你的回應^[14]。如果想了解更多，這里有個看起來不錯的新課程^[15]。

工具載荷（Tool Loadout）

工具載荷是只選擇相關工具定義添加到上下文中的行為。

"載荷"這個術語來自游戲，指的是在關卡、比賽或回合開始前選擇的特定能力、武器和裝備組合。通常，你的載荷會根據具體情況量身定制——角色、關卡、隊友構成和你自己的技能。

這里，我們借用這個術語來描述為給定任務選擇最相關工具。

選擇工具最簡單的方法可能是對工具描述應用RAG。這正是Tiantian Gan和Qiyao Sun在論文"RAG MCP^[16]"中詳述的做法。通過將工具描述存儲在向量數據庫（vector database）中，他們能夠根據輸入提示選擇最相關的工具。

在提示DeepSeek-v3時，團隊發現當工具超過30個時，選擇正確工具變得至關重要。超過30個，工具描述開始重疊，造成混亂。超過100個工具，模型幾乎必然無法通過他們的測試。使用RAG技術選擇少于30個工具產生了顯著更短的提示，工具選擇準確率提高了多達3倍。

對于較小的模型，問題在我們達到30個工具之前就開始了。我們在上一篇文章中提到的論文"少即是多^[17]"證明，Llama 3.1 8b在給出46個工具時無法通過基準測試（benchmark），但只給19個工具時就能成功。問題是上下文混亂，不是上下文窗口限制。

為了解決這個問題，"少即是多"背后的團隊開發了一種使用LLM驅動的工具推薦器動態選擇工具的方法。LLM被提示推理"它'認為'回答用戶查詢需要的工具數量和類型"。然后對這個輸出進行語義搜索（semantic search）（又是工具RAG）來確定最終載荷。他們用伯克利函數調用排行榜^[18]測試了這種方法，發現Llama 3.1 8b的性能提高了44%。

"少即是多"論文指出了較小上下文的另外兩個好處：降低功耗和提高速度，這在邊緣計算（edge computing）時是關鍵指標（意思是在你的手機或PC上運行LLM，而不是在專用服務器上）。即使他們的動態工具選擇方法無法改善模型結果，功耗節省和速度提升也值得努力，分別節省了18%和77%。

好在大多數智能體（agents）的表面積較小，只需要幾個手工篩選的工具。但如果功能廣度或集成數量需要擴展，始終要考慮你的載荷。

上下文隔離（Context Quarantine）

上下文隔離是將上下文隔離在各自專用線程中的行為，每個線程被一個或多個LLM單獨使用。

當上下文不太長且不包含無關內容時，我們會看到更好的結果。實現這一點的一種方法是將任務分解成更小的、隔離的工作——每個都有自己的上下文。

這種策略有很多^[19]例子^[20]，但Anthropic的詳述其多智能體研究系統的博客文章^[21]是這種策略的一個易懂的闡述。他們寫道：

搜索的本質是壓縮：從龐大語料庫中提煉洞察。子智能體（subagents）通過在各自的上下文窗口中并行操作來促進壓縮，同時探索問題的不同方面，然后為主要研究智能體濃縮最重要的token。每個子智能體還提供關注點分離——不同的工具、提示和探索軌跡——這減少了路徑依賴性并實現了徹底、獨立的調查。

研究適合這種設計模式。當給出問題時，可以識別幾個子問題或探索領域，并使用多個智能體分別提示。這不僅加快了信息收集和提煉（如果有可用的計算資源），還防止每個上下文積累過多信息或與給定提示無關的信息，從而提供更高質量的結果：

我們的內部評估顯示，多智能體研究系統在需要同時追求多個獨立方向的廣度優先查詢（breadth-first queries）方面表現尤其出色。我們發現，以Claude Opus 4為主智能體、Claude Sonnet 4為子智能體的多智能體系統在我們的內部研究評估中比單智能體Claude Opus 4的表現好90.2%。例如，當被要求識別信息技術標普500公司的所有董事會成員時，多智能體系統通過將此分解為子智能體任務找到了正確答案，而單智能體系統通過緩慢的順序搜索無法找到答案。

這種方法還有助于工具載荷，因為智能體設計者可以創建幾個智能體原型（agent archetypes），每個都有自己專用的載荷和如何使用每個工具的指令。

因此，智能體構建者的挑戰是找到孤立任務分拆到單獨線程的機會。需要多個智能體之間共享上下文的問題不太適合這種策略。

如果你的智能體領域適合并行化，務必閱讀完整的Anthropic文檔^[22]。它很出色。

上下文剪枝（Context Pruning）

上下文剪枝是從上下文中移除無關或不需要信息的行為。

智能體在啟動工具和組裝文檔時會積累上下文。有時，值得暫停評估已組裝的內容并移除垃圾。這可以是你分配給主LLM的任務，或者你可以設計一個獨立的LLM驅動工具來審查和編輯上下文。或者你可以選擇更適合剪枝任務的東西。

上下文剪枝有相對較長的歷史，因為在ChatGPT之前，上下文長度在自然語言處理（Natural Language Processing，NLP）領域是更成問題的瓶頸。一個當前的剪枝方法，建立在這段歷史之上，是Provence^[23]，"一個高效且穩健的問答上下文剪枝器"。

Provence快速、準確、易用且相對較小——只有1.75 GB。你可以用幾行代碼調用它：

from transformers import AutoModel

provence = AutoModel.from_pretrained("naver/provence-reranker-debertav3-v1", trust_remote_code=True)

# 讀入阿拉米達，加州維基百科條目的markdown版本
with open('alameda_wiki.md', 'r', encoding='utf-8') as f:
    alameda_wiki = f.read()

# 根據問題剪枝文章
question = 'What are my options for leaving Alameda?'
provence_output = provence.process(question, alameda_wiki)

Provence編輯了文章，刪減了95%的內容，只給我留下了這個相關子集^[24]。它做得很好。

可以使用Provence或類似功能來篩選文檔或整個上下文。此外，這種模式有力地論證了在字典或其他形式中維護上下文的結構化版本，在每次LLM調用之前從中組裝編譯的字符串。這種結構在剪枝時會很有用，允許你確保保留主要指令和目標，同時可以剪枝或摘要文檔或歷史部分。

上下文摘要（Context Summarization）

上下文摘要是將累積的上下文壓縮成簡潔摘要的行為。

上下文摘要最初出現是作為處理較小上下文窗口的工具。當你的聊天會話接近超過最大上下文長度時，會生成摘要并開始新線程。聊天機器人用戶在ChatGPT或Claude中手動執行此操作，要求機器人生成簡短回顧，然后粘貼到新會話中。

然而，隨著上下文窗口增加，智能體構建者發現摘要除了保持在總上下文限制內還有其他好處。隨著上下文增長，它變得分散注意力，導致模型較少依賴訓練期間學到的知識。我們稱之為上下文分心^[25]。口袋妖怪游戲Gemini智能體背后的團隊發現任何超過100,000個token都會觸發這種行為：

雖然Gemini 2.5 Pro支持1M+token上下文，但在智能體中有效使用它呈現了新的研究前沿。在這種智能體設置中，觀察到隨著上下文顯著增長到超過100k token，智能體表現出傾向于重復其龐大歷史中的動作，而不是綜合新穎計劃。這種現象，盡管是軼事性的，突出了長上下文檢索和長上下文多步驟生成推理之間的重要區別。

摘要你的上下文容易做到，但對任何給定智能體來說很難完善。知道應該保留什么信息，并在LLM驅動的壓縮步驟中詳細說明這一點，對智能體構建者至關重要。值得將此功能分解為自己的LLM驅動階段或應用程序，這允許你收集可以直接告知和優化此任務的評估數據。