當一個AI Agent完成一次任務平均要調用50次工具，海量工具結果不斷涌入上下文窗口時，LLM的性能會不可避免地遭遇滑鐵盧。Chroma的“上下文衰減”研究與Anthropic提出的“注意力預算耗盡”理論，都印證了這一痛點。

Manus作為當下熱門的通用消費級AI Agent，其聯合創始人兼首席戰略官Yichao “Peak” Ji在 webinar 中，首次系統拆解了Manus的上下文工程核心邏輯。

以下是我整理出了這份能直接復用的實踐指南。

一、為什么上下文工程是AI Agent的“生命線”？

在理解Manus的方案前，先要明確一個關鍵定義：Anthropic將AI Agent定義為“LLM自主引導流程、調用工具，掌控任務完成路徑的系統”，本質是LLM循環調用工具的過程。

而這個過程中，最大的隱患藏在“上下文窗口”里：

1. 工具結果堆積：Manus單次任務平均觸發50次工具調用，所有結果若全存進上下文，窗口會迅速被填滿。
2. 性能持續衰減：隨著上下文內容增多，LLM的注意力會被分散，就像人面對雜亂無章的書桌無法高效工作——Chroma稱之為“上下文衰減”，Anthropic則解釋為“注意力預算被耗盡”。
3. 行業共識明確：AI領域權威人物Karpathy直接點明，上下文工程的核心，就是“為Agent的每一步行動，精準填充上下文窗口所需的信息”。

二、Manus的3大上下文工程策略

Manus為每個會話分配獨立虛擬機，讓Agent擁有文件系統和終端工具。在此基礎上，它通過“減少、卸載、隔離”三大策略，實現上下文窗口的高效管理。

策略1：Reduce（減少）——壓縮與總結雙管齊下

Manus為工具調用結果設計“完整版”和“精簡版”兩種形態：

• 完整版：存儲原始工具結果（如完整搜索內容），但僅保存在沙盒文件系統中，不占用上下文窗口。

• 精簡版：僅保留完整結果的引用（如文件路徑“/home/ubuntu/foo.txt”），直接放入上下文窗口。

當Agent接近上下文窗口上限時，系統會自動觸發壓縮機制：

1. 將舊工具結果的“完整版”替換為“精簡版”，釋放窗口空間。
2. 新工具結果仍保留“完整版”，確保Agent能基于最新信息決策。
3. 當壓縮效果達到瓶頸時，啟動總結機制——按預設 schema 生成工具結果摘要，保證不同任務的摘要格式統一，進一步節省空間。

策略2：Offload（卸載）——構建分層行動空間

很多開發者會為Agent配置大量工具，但這會導致兩個問題：工具描述占用大量 tokens，且工具間的重疊、模糊會讓LLM confusion。 Manus的解決方案是“分層行動空間”：

• 函數調用層：僅保留不到20個“原子函數”，如shell（執行終端命令）、text editor（讀寫文件）、search（搜索）等。這些函數功能通用，能覆蓋絕大多數任務需求。
• 沙盒層：將大量工具（如語音工具、MCP CLI命令）轉移到沙盒中，以終端命令形式存在。Agent無需記憶這些工具的細節，只需通過“--help”命令即可隨時查看用法。

這種設計不僅減少了上下文窗口中工具描述的占用，還降低了LLM的認知負擔——無需在眾多工具中做選擇，只需調用通用函數，再在沙盒中執行具體命令。

策略3：Isolate（隔離）——用子Agent實現上下文隔離

Manus不采用“擬人化分工”（如設計“設計師Agent”、“工程師Agent”），而是僅保留3類核心子Agent，避免跨Agent通信的冗余：

• 規劃者（Planner）：負責任務管理，決定何時調用其他子Agent。
• 知識管理者：梳理對話內容，判斷哪些信息需要存入文件系統。
• 執行者（Executor）：接收規劃者指令，完成具體任務。

子Agent與主Agent的上下文交互分兩種場景：

• 簡單任務：規劃者僅向執行者發送任務指令，執行者完成后返回結果（類似Claude Code的任務工具）。
• 復雜任務：規劃者向執行者共享完整上下文（如全部對話歷史），但執行者仍擁有獨立的工具庫和提示詞，確保任務執行的獨立性。

無論哪種場景，規劃者都會為執行者定義輸出schema，并通過“約束解碼”技術，保證執行者的結果符合格式要求，避免上下文混亂。

2.1 模型選擇：成本優先，混合搭配

Manus的模型選擇核心是“KV緩存效率”：

• 大量使用緩存技術（如緩存系統指令、重復內容），降低成本和延遲。
• 優先選擇支持分布式KV緩存的前沿模型（如Claude、Gemini、OpenAI），這類模型雖看似昂貴，但緩存帶來的成本節省，實際比開源模型更劃算。
• 不綁定單一模型，而是按任務路由：編碼用Claude，多模態任務用Gemini，數學推理用OpenAI，最大化不同模型的優勢。

2.2 擁抱“痛苦教訓”，設計可進化架構

Manus團隊深受“Bitter Lesson”（痛苦教訓）理論影響——AI的進步往往來自計算能力的提升，而非復雜的結構設計。

因此，他們的開發理念有兩個核心：

1. 頻繁重構：自2025年3月上線以來，Manus已重構5次，不斷適配模型能力的提升。
2. 持續評估：定期用不同強度的模型測試Agent性能。如果更強的模型無法提升Agent表現，說明當前的架構（如Agent的“ harness ”框架）已成為瓶頸，需要及時調整。

三、最后總結AI Agent上下文管理的6條實踐啟示

從Manus的實踐中，我們可以提煉出6條能直接復用的經驗：

1. 上下文管理的核心是“精準”——只在窗口中保留Agent下一步需要的信息。
2. 工具設計宜“精”不宜“多”，通用原子函數+沙盒工具的組合，比大量專用工具更高效。
3. 子Agent的價值是“隔離上下文”，而非“擬人化分工”，過多子Agent會增加通信成本。
4. 緩存是降低模型成本的關鍵，優先選擇支持分布式KV緩存的模型。
5. 架構設計要“留有余地”，避免過度結構化，以便適配模型能力的快速提升。
6. 定期用更強模型測試Agent，及時發現并打破架構瓶頸。

AI Agent的競爭，本質是“效率”的競爭——而上下文窗口的管理效率，直接決定了Agent的性能上限。Manus的實踐證明，通過科學的策略，即使是平均50次工具調用的任務，也能讓LLM始終保持高效運轉。

本文轉載自??CourseAI??，作者：CourseAI