前幾天我寫了一篇文章分享了Anthropic 上下文工程最佳實踐，這篇文章分享達到了1109次，感覺大家對Context Engineering還是很感興趣的，今天這篇文章更深入和細節一些，LangChain 的創始工程師 Lance Martin 和 Manus 的聯合創始人 Yichao "Peak" Ji（季逸超《麻省理工科技評論》評選的 2025 年 35 歲以下創新者之一） 深入探討了上下文工程，分享了他們在生產環境中管理上下文窗口、優化性能和構建可擴展代理的實戰策略

核心論點是，隨著 AI Agents 執行日益復雜的長期任務，其上下文窗口會因大量的工具調用而急劇膨脹，導致性能下降。因此，有效的上下文工程，即通過 offloading（卸載）、reduction（精簡）、retrieval（檢索）、isolation（隔離）和 caching（緩存）等一系列技術，將“恰到好處的信息”填入上下文窗口，是構建高效、穩定和智能代理的決定性因素。最終結論強調，優秀的上下文工程不僅是技術組合，更是一種“少即是多”的哲學，即通過簡化架構、信任模型，而非過度工程化，才能實現代理性能的最大飛躍

強烈建議大家圍觀

上下文工程的興起：為何它對 AI 代理至關重要

在人工智能領域，我們見證了一個重要的范式轉變。隨著 ChatGPT 的問世，prompt Engineering（提示工程）在 2022 年底應運而生，成為與聊天模型交互的核心學科。然而，進入 2023 年，一個新的、更為關鍵的領域——Context Engineering（上下文工程）開始嶄露頭角

與簡單的聊天機器人不同，AI Agents 的核心特征在于它們能夠自主地、循環地調用一系列工具來完成復雜任務。這個過程帶來了一個獨特的挑戰：上下文的無界爆炸

工作機制：一個 Agent 通常綁定了一個或多個工具。每當 Agent 調用一個工具，它會收到一個工具的觀測結果，這個結果會作為一個新的消息被追加到對話歷史中

規模問題：根據 Manus 的實踐經驗，一個典型的任務可能需要大約 50 次工具調用。而 Anthropic 的研究也指出，生產環境中的代理可能會進行長達數百輪的對話

性能悖論：這種工具的自由使用，導致了上下文信息的快速累積。然而，正如 Chrome 團隊在一份關于“上下文腐爛 (context rot)”的報告中指出的，隨著上下文長度的增加，模型的性能會顯著下降

這就形成了一個核心矛盾：Agents 的強大功能依賴于利用大量上下文信息，但模型的性能卻會因為上下文過長而受損

正是為了解決這個挑戰，Context Engineering（上下文工程）的概念應運而生。Andrej Karpathy 將其精辟地定義為：一門將恰到好處的信息在下一步需要時填入上下文窗口的精妙藝術與科學。它的目標是抑制在 Agents 運行過程中因工具調用而產生的上下文爆炸，確保在任務的每一步，Agent 都能接收到做出正確決策所需的核心信息，不多也不少

為了實現這一目標，行業內涌現出了一系列共通的主題和策略，構成了上下文工程的支柱：

1.Context Offloading (上下文卸載)：將信息從核心的對話歷史中移出，存放到外部系統（如文件系統），只在上下文中保留一個輕量級的引用

2.Reducing Context (上下文精簡)：通過總結或壓縮來減少信息量，例如修剪舊的工具調用記錄

3.Retrieving Context (上下文檢索)：在需要時，按需從外部系統將信息取回。實現方式包括基于索引的語義搜索，或更簡單的基于文件系統的搜索工具（如 glob 和 grep）

4.Context Isolation (上下文隔離)：通過將任務分解給多個子代理（sub-agents），每個子代理擁有自己獨立的、更小的上下文窗口，從而實現關注點分離和上下文管理

5.Caching Context (上下文緩存)：對上下文信息進行緩存，以提高效率（這一點在 Manus 的實踐中被特別提及）

這些策略并非孤立存在，而是相互關聯、協同工作，共同構成了現代 AI Agents 架構的基石

戰略抉擇：優先上下文工程，而非過早模型專業化

在深入探討上下文工程的具體技術之前，一個更根本的問題值得思考：我們為什么需要它？尤其是在模型微調和后訓練技術日益普及的今天。Manus 的聯合創始人 Peak Ji 分享了他從多年實踐中得出的深刻見解，認為上下文工程是應用層和模型層之間最清晰、最實用的邊界

在創辦 Manus 之前，Peak 擁有超過十年的自然語言處理經驗，他的上一個創業項目就是從零開始訓練自己的語言模型。這段經歷讓他痛苦地認識到，過早地構建專用模型會帶來巨大風險：

扼殺創新速度：產品的迭代速度完全被模型的迭代速度所限制。一個訓練加評估的周期可能需要一到兩周，這對于需要快速驗證產品市場契合度的初創公司是致命的

優化目標錯位：在產品方向尚未完全明朗時，團隊可能會花費大量時間去提升一些對產品價值可能毫無意義的基準測試分數

因此，初創公司應該盡可能長時間地依賴通用模型和上下文工程。然而，隨著產品成熟和開源基礎模型的崛起，另一個陷阱也隨之出現：用自有數據微調一個強大的基礎模型，使其在特定用例上表現出色

Peak 指出這同樣是危險的，因為強化學習通常需要固定一個行動空間，并圍繞當前的產品行為設計獎勵函數。但這在 AI 和 Agents 的早期階段是極其脆弱的，因為底層技術可能一夜之間發生顛覆

一個典型的例子**：MCP的發布，徹底改變了 Manus 的設計，使其從一個緊湊、靜態的行動空間，轉變為一個幾乎無限可擴展的系統。如果你已經訓練了自己的模型，你會知道這種開放域問題極難優化

避免重復造輪子：雖然可以投入巨大努力進行后訓練以確保模型的泛化能力，但這無異于在嘗試成為一家語言模型公司，重復了基礎模型公司已經完成的工作

綜上所述，Peak 的核心觀點是：要堅定地劃清界限。在當前階段，上下文工程為應用開發者提供了一個強大的杠桿，可以在不觸碰底層模型訓練的情況下，極大地影響和提升 Agent 的性能。它允許應用層保持靈活性和快速迭代的能力，同時充分利用日益強大的通用模型。因此，與其過早地投入到模型專業化的深淵，不如精通上下文工程這門藝術

上下文精簡：壓縮與總結

上下文精簡是上下文工程的核心技術之一，但它并非一個單一的操作。Manus 在實踐中將其細分為兩種截然不同但相輔相成的方法：Compaction (壓縮)和 Summarization (總結)，并建立了一套嚴謹的工作流程來協同使用它們

壓縮 (Compaction)：一種可逆的信息外化

壓縮的核心思想是一種可逆的信息縮減。它并非真正地“減少”信息，而是將信息的一部分外化（externalized）到上下文窗口之外的某個地方（如文件系統或外部狀態），同時在上下文中保留足以重建完整信息的線索

工作原理：在 Manus 中，每一次工具調用和其結果都有兩種格式：完整格式和緊湊格式。緊湊版本會剝離掉所有可以從外部環境中重建的信息

具體例子：假設一個工具的功能是向文件中寫入內容，它可能包含兩個字段：path (路徑) 和 content (內容)。一旦這個工具執行成功，我們就可以確定該文件已經存在于環境中。因此，在緊湊格式中，可以安全地丟棄可能非常長的 content 字段，只保留 path。如果 Agent 后續需要再次讀取該文件，它可以通過 path 輕松地檢索到全部內容

為何可逆性至關重要：Agents 的決策是鏈式的，基于之前的行動和觀察。我們永遠無法預知過去的哪個動作會在十步之后突然變得至關重要。可逆的壓縮確保了沒有任何信息被真正丟失，只是被暫時移出了即時上下文

總結 (Summarization)：一種不可逆的謹慎精煉

當僅靠壓縮已無法將上下文大小控制在閾值以下時，就需要動用更傳統的總結方法。總結是不可逆的，意味著信息會有損失，因此必須非常謹慎地使用

執行時機：總結是最后的手段，只有在多輪壓縮后，上下文長度仍然接近性能“腐爛”的臨界點時才會觸發

操作前的準備：在進行總結之前，一個最佳實踐是先將上下文中的關鍵部分卸載到文件中。在更激進的情況下，甚至可以將整個待總結的上下文（pre-summary context）作為一個文本或日志文件轉儲到 file system 中。這樣，即使總結丟失了細節，Agent 仍然有可能通過文件搜索（如 glob 或 grep）來恢復原始信息

總結的藝術：在 Q&A 環節中，Peak 補充了一個關鍵技巧來提升總結質量：不要使用自由格式的提示。相反，應該定義一個結構化的模式（schema）或表單，讓模型去填充字段，例如“我修改了哪些文件”、“用戶的目標是什么”、“我上次進行到哪一步”。這種結構化的輸出比自由生成的文本更穩定、更可控，也更容易保證關鍵信息不被遺漏

一套基于閾值的工作流程

為了讓壓縮和總結能夠和諧共存，Manus 設計了一套基于多層上下文長度閾值的自動化流程：

1.確定閾值：

硬性限制 ：模型支持的最大上下文長度，例如 100 萬 token

預腐爛閾值：模型性能開始顯著下降的實際閾值。這需要通過大量評估來確定，通常在 128K 到 200K token 之間。當模型開始出現重復、推理變慢、質量下降等“上下文腐爛”現象時，就接近這個閾值了

2.觸發壓縮：當上下文大小接近“預腐爛閾值”時，系統會首先觸發壓縮操作。這個操作不是全局性的，而是有選擇性的。例如，可以只壓縮歷史記錄中最舊的 50% 的工具調用，同時保持最近的調用記錄為完整格式。這樣做的好處是，模型仍然可以看到新鮮的、完整的工具使用范例（few-shot examples），從而避免模仿緊湊格式輸出不完整的指令

3.評估增益并觸發總結：壓縮后，系統會檢查獲得了多少空閑的上下文空間。如果在多輪壓縮后，每次的增益都變得微乎其微，這意味著上下文即使在緊湊形態下也已非常龐大。此時，系統才會觸發總結操作

4.執行總結：進行總結時，應使用未經壓縮的完整版數據作為輸入，以確保總結的質量。同時，與壓縮類似，始終保留最后幾次的工具調用和結果為完整細節，不進行總結。這能幫助模型清晰地知道它在哪個節點被打斷，從而更平滑地繼續任務，避免因總結導致的行為或風格突變

通過這套精細的流程，Manus 在最大化信息保留和控制上下文成本之間取得了微妙的平衡

管理Agent復雜性：上下文隔離的兩種模式

當任務變得異常復雜時，單一 Agent 的上下文管理壓力會變得巨大。此時，將任務分解給多個子代理（sub-agents）的上下文隔離策略就顯得尤為重要。Cognition AI 在他們的博客中曾警示過多代理設置的風險，因為在它們之間同步信息可能成為一場噩夢。然而，這并非一個新問題，它與計算機科學早期多進程/多線程協調的挑戰異曲同工

Peak Ji 借鑒了 Go 語言社區的一句名言來闡釋解決這個問題的兩種核心模式：Do not communicate by sharing memory; instead, share memory by communicating. (不要通過共享內存來通信；相反，通過通信來共享內存。)

將這里的“內存 (memory)”類比為 AI Agents 的“上下文 (context)”，我們可以得到兩種截然不同的多代理協作模式：

模式一：通過通信 (By Communicating)

這是最經典、最直觀的子代理設置。它適用于那些可以被清晰地分解和委派的任務。

工作流程：

1.主代理（main agent）將一個任務封裝成一個清晰、自包含的指令，就像一個函數調用

2.這個指令被發送給一個子代理

3.子代理的上下文窗口是干凈的，幾乎只包含來自主代理的這條指令。它在自己獨立的上下文中完成任務

4.子代理將最終結果返回給主代理

適用場景：當任務指令簡短明確，且主代理只關心最終產出，不關心實現過程時，這種模式是最佳選擇

例子：在一個代碼庫中搜索特定的代碼片段。主代理只需要告訴子代理“找到包含函數 xyz 的文件”，它不關心子代理是用了 grep 還是其他方法，只需要最終的文件路徑和代碼內容。Claude Code 的 task 工具就是這種模式的典型應用

優點：簡單、隔離性好、上下文開銷小

模式二：通過共享上下文 (By Sharing Context)

與前一種模式相反，這種模式適用于那些子任務嚴重依賴整體歷史背景的復雜場景。

工作流程：

1.子代理能夠看到主代理完整的、之前的全部上下文歷史，包括所有的工具使用記錄和觀察結果

2.但是，這個子代理擁有自己獨特的系統提示和行動空間 。它是在共享的背景知識上，以一個新的“身份”或“能力集”來執行任務

適用場景：當任務的最終產出質量取決于對大量中間過程和發現的理解時，共享上下文是更高效的選擇

例子：進行一項深度研究（deep research）并撰寫報告。最終的報告質量依賴于所有中間的搜索、筆記和分析。如果使用“通信”模式，主代理需要將所有這些中間產物打包成文件，再讓子代理去讀取和理解，這會浪費大量的延遲和 token。而共享上下文模式則讓子代理直接擁有完整的歷史視圖

成本與權衡：這種模式的成本更高

預填充成本：每個子代理都需要處理一個非常大的輸入上下文，這會消耗更多的輸入 token

KV 緩存失效：由于每個子代理的系統提示和行動空間都不同，無法復用之前的 KV 緩存，這意味著每次切換到子代理都需要支付全額的計算成本

在 Q&A 環節，Peak 進一步闡述了 Manus 如何在實踐中實現這兩種模式，尤其是 agent 間的通信：

共享沙箱作為媒介：Manus 的每個會話都運行在一個獨立的虛擬機沙箱中。主代理和子代理可以共享同一個沙箱。因此，信息傳遞可以通過共享文件系統來完成，主代理只需傳遞文件路徑即可

Schema 作為合約：為了解決子代理輸出格式不統一的問題，Manus 采用了一種“合約”機制。當主代理要啟動一個或多個子代理時，它會首先定義一個輸出模式 (output schema)。子代理則有一個特殊的工具叫做 submit_result，通過約束解碼技術，確保子代理提交回主代理的結果嚴格符合主代理預先定義的模式。這就像一個 MapReduce 操作，最終會生成一個格式規整的“電子表格”

通過這兩種模式的靈活運用，可以在保持任務隔離性的同時，高效地處理不同依賴度的復雜協作任務。

超越數據：通過分層行動空間卸載工具

上下文卸載（Context Offloading）通常被理解為將工作數據（如文件內容、搜索結果）移出上下文窗口。然而，隨著 Agent 系統變得越來越復雜，尤其是在集成了像 MCP 這樣的可擴展工具系統后，一個新問題浮現了：工具本身也成為了上下文的主要消耗者

當上下文中存在過多的工具定義時，會導致“上下文混淆 (context confusion)”，模型可能會調用錯誤的工具，甚至是根本不存在的工具。一個常見的解決方案是根據當前任務動態地對工具描述進行 RAG（檢索增強生成），按需加載工具。但這種方法存在兩個弊端：

1.破壞 KV 緩存：工具定義通常位于上下文的開頭。每次更換工具集，都意味著 KV 緩存失效，增加了計算成本

2.誤導模型：即使某個工具被移除了，模型在歷史記錄中仍然能看到對該工具的過往調用。這可能會誤導模型去調用一個當前無效的工具或使用錯誤的參數

為了解決這個問題，Manus 創新性地設計了一種分層的行動空間 (Layered Action Space)。這種架構將 Agent 的能力分解為三個抽象層次，從模型的視角看，所有操作最終都歸結為少數幾個核心函數調用，從而實現了極高的穩定性和可擴展性

第一層：函數調用 (Function Calling)

這是最底層、最核心的一層，也是與模型直接交互的接口。

特點：

原子性與固定性：只包含一小組（在 Manus 中約 10-20 個）固定的、原子性的函數。例如：讀寫文件 (read/write file)、執行 Shell 命令 (execute shell command)、搜索文件和互聯網 (search)，以及一些瀏覽器操作

模式安全：得益于約束解碼，函數調用的格式和參數是嚴格受控的

緩存友好：由于這個函數列表是固定的，KV 緩存可以被長期保持和復用

作用：這些原子函數邊界清晰，并且可以組合起來完成更復雜的工作流。它們是所有上層能力的基礎

第二層：沙箱工具集 (Sandbox Utilities)

這一層將大量的功能從函數調用層卸載到了 Agent 所在的虛擬機沙箱環境中。

特點：

預裝命令行工具：Manus 在其定制的 Linux 系統中預裝了大量為 Agent 開發的命令行工具。例如，格式轉換器、語音識別工具，甚至一個特殊的 MCP CLI（用于調用 MCP 功能的命令行接口）

通過 Shell 調用：Agent 不是通過新的函數來使用這些工具，而是通過第一層的 execute_shell_command 函數來運行它們

優勢：

無限擴展：可以在不修改模型函數調用空間（action space）的情況下，不斷增加新的能力

符合模型心智：對于熟悉 Linux 的模型來說，通過 ls /usr/bin 發現新工具，或者通過 tool_name --help 查看用法，是一種非常自然的行為

處理大數據：這些命令行工具可以處理非常大的輸出，它們可以將結果寫入文件，或進行分頁返回，Agent 可以使用 grep, cat, less 等標準 Linux 工具來處理這些結果

第三層：軟件包與 API (Packages & APIs)

這是最高層的抽象，Agent 通過編寫和執行代碼來與外部世界進行更復雜的交互。

特點：

編寫腳本：Agent 可以編寫 Python 腳本來調用預授權的第三方 API 或自定義的軟件包。例如，使用一個 3D 設計庫進行建模，或調用一個金融 API 獲取市場數據

通過文件和 Shell 執行：Agent 使用第一層的 write_file 函數創建腳本，然后使用 execute_shell_command 函數來運行它

優勢：

處理內存密集型計算：非常適合需要大量計算但又不需要將所有中間數據都塞入模型上下文的任務。例如，分析一只股票一整年的價格數據，腳本可以在運行時內存中完成計算，只將最終的總結（如平均值、波動率）返回給模型

高組合性：代碼和 API 本身具有極強的組合性，可以在一個步驟內完成一系列復雜的操作，這與 CodeAct 等研究論文的思想不謀而合

通過這個三層架構，Manus 巧妙地解決了工具過載的問題。從模型的角度來看，無論它是在使用一個沙箱工具，還是在調用一個復雜的 API，最終都只是在調用那幾個固定的、底層的原子函數。這使得接口保持了極度的簡潔、緩存友好和正交性，為構建一個既強大又穩定的通用 Agent 奠定了基礎

統領全局的設計哲學與一線實戰

在分享了所有精妙的技術細節之后，Peak Ji 提出了一個或許是本次分享中最重要的觀點，它看似與之前所說的背道而馳：請避免上下文過度工程化 (context over-engineering)。

他回顧了 Manus 發布以來的發展歷程，發現那些帶來最大性能飛躍的時刻，并非來自增加了更花哨的上下文管理層或更聰明的檢索技巧，而是來自簡化——來自移除不必要的技巧，并給予模型多一點信任。每一次簡化架構，系統都會變得更快、更穩定、也更智能

這引出了一條核心的設計哲學：上下文工程的目標是讓模型的工作變得更簡單，而不是更復雜。構建得更少，理解得更多 (Build less, understand more)。

在最后的 Q&A 環節，這一哲學思想通過一系列具體的實踐經驗得到了進一步的印證，這些來自一線的智慧為構建高效 Agents 提供了寶貴的參考：

關于評測：

用戶反饋是黃金標準：對 Manus 而言，最重要的評測指標是每次會話結束后用戶給出的 1-5 星評分

內部自動化測試為輔：他們創建了自有數據集，包含可驗證結果的執行型任務，彌補了現有公開基準測試大多為只讀任務的不足

人類評估不可或缺：對于網站生成、數據可視化這類難以用自動化指標衡量的、涉及“品味”的任務，必須依賴大量的人類實習生進行主觀評估。公開的學術基準（如 GAIA）可能與真實用戶需求嚴重脫節

關于模型選擇與架構設計：

優先選擇旗艦模型：盡管開源模型看似成本更低，但對于輸入遠長于輸出的 Agent 任務，KV 緩存至關重要。旗艦模型提供商擁有更成熟的分布式 KV 緩存基礎設施，在規模化部署時可能反而更具成本效益

利用模型差異進行路由：不同的頂尖模型各有千秋（例如 Claude 擅長編碼，Gemini 擅長多模態）。應用層的優勢在于無需綁定單一模型，可以進行任務級甚至步驟級的智能路由

測試架構的“未來兼容性”：一個好的 Agent 架構，應該在從一個較弱模型切換到一個較強模型時，性能有顯著提升。這種測試可以作為架構是否“未來兼容”的早期信號

關于 Agent 設計：

避免角色擬人化：不要強行將人類的組織架構（如設計師、程序員、經理）套用在 Agent 設計上。這種分工是人類上下文限制的產物

采用功能性劃分：Manus 的多代理系統并非按角色劃分，而是按功能。只有少數幾個核心 Agent，如一個通用的“執行者 (Executor)”、一個“規劃者 (Planner)”和一個“知識管理器 (Knowledge Manager)”，以最大限度地降低通信復雜性

從 todo.md 到規劃者 Agent：早期的 Agent 普遍使用 todo.md 文件進行任務規劃，但這會浪費大量 token 在文件的反復讀寫更新上。更優的模式是將其升級為一個獨立的規劃者 Agent，使用“Agent as Tool”的范式進行交互

關于強化學習 (RL) 與工具調用：

謹慎對待 RL：對于一個需要支持開放、可擴展行動空間（如 MCP）的通用 Agent，進行 RL 的難度極高。這相當于在自己構建一個基礎模型。目前階段，將這項工作交給模型公司，而應用層專注于上下文工程是更明智的選擇

總而言之，成功的上下文工程是一場在多個潛在沖突目標（如信息保真度、成本、延遲、可擴展性）之間尋求完美平衡的藝術。它要求開發者不僅要掌握精湛的技術，更要擁有一種化繁為簡、信任模型的深刻洞察力

參考：

Context Engineering for AI Agents with LangChain and Manus