毫無疑問，上下文工程的優(yōu)化，仍然是 Agent 創(chuàng)業(yè)公司在新一年都在「卷」的重點。

在實際落地開發(fā)中，上下文信息的質(zhì)量，很大程度上決定了 Agent 的表現(xiàn)。

Manus 的首席科學(xué)家季逸超在之前訪談中提到過一個觀點：

初創(chuàng)公司真的應(yīng)該盡可能長時間地依賴通用模型和上下文工程，而不是過早地構(gòu)建專用模型，也包括微調(diào)。上下文工程是應(yīng)用層和模型層之間最清晰、最實用的邊界。

做好上下文工程，開發(fā)者能夠在不觸及模型底層權(quán)重的前提下，靈活駕馭模型，同時還能適應(yīng)快速變化的產(chǎn)品需求。

最近，Cursor 也發(fā)表了一篇文章《Dynamic context discovery》，分享了他們是怎么做上下文管理的。

結(jié)合 Manus、Cursor 這兩家 Agent 領(lǐng)域頭部團隊的思路，我們整理了如何做好上下文工程的一些關(guān)鍵要點。

Cursor 原文：https://cursor.com/cn/blog/dynamic-context-discovery

此前 Founder Park 分享的文章

??關(guān)注 Founder Park，最及時最干貨的創(chuàng)業(yè)分享

超 19000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應(yīng)用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準(zhǔn)的AI產(chǎn)品曝光渠道

01「上下文縮減」是最直接有效的策略

在 Agent 的構(gòu)建過程中，會發(fā)現(xiàn)一個現(xiàn)象：上下文會持續(xù)增長，并且是以一種非常特殊的方式增長。

Agent 每調(diào)用一次工具，就會返回一個工具的觀測結(jié)果，這個結(jié)果會被追加到聊天記錄中。隨著時間的推移，消息列表會越來越長，導(dǎo)致 Agent 在運行時消息數(shù)量出現(xiàn)無限制的爆炸性增長。

Manus 之前提到，典型的任務(wù)大約需要調(diào)用 50 次工具。Anthropic 也提到過類似的情況，生產(chǎn)環(huán)境中的 Agent 可能會進行長達數(shù)百輪的對話。

上下文長度的持續(xù)增長，會導(dǎo)致推理性能斷崖式的下跌。業(yè)內(nèi)叫做「上下文腐爛」（Context Rot），具體表現(xiàn)是：推理變慢、質(zhì)量下降、甚至開始無意義地重復(fù)。

如何解決？業(yè)內(nèi)目前共識的一個方法是「上下文卸載（Context Offloading）」，核心思路是別把所有東西都硬塞進 Agent 的短期記憶里，把它卸載出去。放到上下文窗口之外，但在需要時，又能被精確地檢索回來。

將信息轉(zhuǎn)移到文件系統(tǒng)中，是目前生產(chǎn)級 Agent 中主流、最 Work 的一種做法。

Cursor：萬物皆可文件化

Cursor 把「卸載」這個思路，發(fā)揮到了極致。用文件作為基礎(chǔ)單元，將冗長的工具結(jié)果、終端會話、聊天記錄全部轉(zhuǎn)化成文件。

Cursor 提到，

我們不確定未來 LLM 工具的最佳接口是什么。但文件是一個簡單、強大的基礎(chǔ)單元，比發(fā)明一套新抽象要安全得多。

基于這個思路，Cursor 提出了「動態(tài)上下文發(fā)現(xiàn)」（Dynamic Context Discovery）模式。核心是，別急著把信息塞給模型，而是讓模型在需要的時候自己去找。

Cursor 把這套模式用到了他們的多個實際場景中：

• 將冗長的工具結(jié)果轉(zhuǎn)化為文件

工具調(diào)用，特別是 Shell 命令或第三方 MCP（模型上下文協(xié)議），經(jīng)常返回巨大的 JSON 響應(yīng)，瞬間就能撐爆上下文。目前的編程 Agent 通常采取的簡單粗暴做法是：直接截斷過長的 Shell 命令或 MCP 結(jié)果，但很可能會丟失最關(guān)鍵的信息。

Cursor 的做法是，將這些輸出直接寫入到一個文件，然后在上下文中只告訴 Agent：「結(jié)果在 output.log 里，你自己去看。」Agent 可以先用 tail 命令查看文件末尾，如果需要更多細(xì)節(jié)，再讀取整個文件。

• 在「總結(jié)」階段引用聊天記錄

當(dāng)模型的上下文窗口被填滿，Cursor 會觸發(fā)一個「總結(jié)」步驟，給 Agent 騰出一個新的上下文窗口，其中包含之前工作的摘要。

但 Agent 的知識會在這個過程中「退化」，因為「總結(jié)」本質(zhì)上是對上下文的一種有損壓縮。 Cursor 把完整的聊天歷史記錄也看做是一個文件。當(dāng)觸發(fā)總結(jié)時，Agent 會拿到一份摘要，以及一個指向「歷史記錄文件」的引用。如果 Agent 意識到摘要中缺少某些它需要的細(xì)節(jié)，它就可以通過搜索這份歷史記錄文件來找回這些信息。

• 將所有集成終端的會話視為文件

在 Cursor 中，不再需要手動復(fù)制粘貼滿屏的終端報錯信息，會自動將集成終端的所有會話輸出同步到本地文件系統(tǒng)。 提問「為什么我的命令失敗了？」時，Agent 能直接定位問題，甚至可以使用 grep 這樣的命令，在長篇的服務(wù)器日志中只搜索相關(guān)的錯誤行。這種做法模仿了 CLI Agent 的體驗，擁有之前的 Shell 輸出作為上下文，但不同的是，它是動態(tài)發(fā)現(xiàn)，不是被靜態(tài)注入。

Manus ：一套結(jié)構(gòu)化的可逆、縮減系統(tǒng)

對比 Cursor「簡單粗暴」的解決思路，Manus 的做法是，把「上下文縮減」設(shè)計成了一套有明確觸發(fā)機制、分階段執(zhí)行的結(jié)構(gòu)化流程。

首先，Manus 的系統(tǒng)會持續(xù)監(jiān)控上下文長度，設(shè)定一個遠低于模型硬件極限的「腐爛前閾值」（Pre-rot Threshold）。

季逸超：你的模型有一個硬性的上下文限制，比如說 100 萬個 Token，這在今天是相當(dāng)普遍的。但實際上，大多數(shù)模型在遠低于這個值時性能就開始下降，通?？赡茉?20 萬個 Token 左右，你會開始看到我們所說的「上下文腐爛」，比如重復(fù)、推理變慢、質(zhì)量下降等。 所以，通過大量的評估，識別出那個「腐爛前」的閾值非常重要，通常是 12.8 萬到 20 萬個 Token，并將其作為觸發(fā)上下文縮減的條件。

當(dāng)信號被觸發(fā)后，系統(tǒng)會啟動第一階段的操作：

第一步：緊湊化（Compaction）

這是一種無損、可逆的縮減。核心是，剝離掉任何能從外部狀態(tài)（比如文件系統(tǒng)）重建的信息。

舉個例子，Agent 調(diào)用了一個向文件寫入內(nèi)容的工具，這個操作在歷史記錄中可能包含 path 和 content 兩個字段。一旦執(zhí)行成功，那個可能極其冗長的 content 字段就可以被安全地從上下文中剝離，只保留 path。

信息并沒有丟失，它只是被「外部化」了。如果 Agent 在 10 步之后需要再次讀取該文件，它憑借保留的 path 就能輕易將其檢索回來。

Manus 提到，這種可逆性是非常關(guān)鍵的，因為你永遠不知道哪個過去的動作會成為未來的關(guān)鍵。

通常情況下，緊湊化只會用作最早的 50% 的歷史記錄，來保留最新的、完整的工具調(diào)用作為模型學(xué)習(xí)的范例（Few-shot Examples）。

但緊湊化收益有限。多輪操作后，上下文削減的收益變得微乎其微時，系統(tǒng)會啟動第二階段：

第二步：摘要化（Summarization）

這是一種有損、但帶保險的壓縮。把它當(dāng)做最后手段，在執(zhí)行時需要極其謹(jǐn)慎。

它的「保險」在于：在生成摘要之前，系統(tǒng)會更激進地將整個摘要前的完整上下文，轉(zhuǎn)儲（Dump）到一個文本或日志文件中。 相當(dāng)于給歷史創(chuàng)建了一個完整的快照存檔。如果模型足夠聰明，它甚至能用 grep 或 glob 自己去這個日志里撈數(shù)據(jù)。

季逸超：緊湊化是可逆的，而摘要化不是。兩者都減少了上下文長度，但它們的行為方式非常不同。

在進行摘要化時，總是會使用完整版本的數(shù)據(jù)，不是緊湊版本。

摘要化依然會保留最后幾次完整的工具調(diào)用記錄。 這能讓模型清楚地知道自己從哪中斷，能平滑地繼續(xù)工作，保持風(fēng)格和語氣的連貫性。

兩個步驟下來，通過「緊湊化」（Compaction）剝離可重建信息，以及在「摘要化」（Summarization）之前，將完整的上下文轉(zhuǎn)儲（Dump）到日志文件中。實現(xiàn)上下文縮減。

02給工具搭建一套靈活的行動空間

當(dāng) Agent 能力逐步增強，配備的工具集也越來越豐富。

如果將所有工具的冗長描述，都放到上下文窗口中，會帶來兩個問題：

• 一是出現(xiàn)上下文混淆（Context Confusion）的情況，工具太多，模型直接懵掉?？赡軙{(diào)用錯誤的工具，甚至是幻覺出根本不存在的工具。

• 二是最直接的 Token 浪費，大多數(shù)工具，在絕大多數(shù)時候根本不會被用到。如果，還使用了多個 MCP 服務(wù)器，情況會變得更糟。

工具過載的問題怎么解決？一個核心思路是：動態(tài)發(fā)現(xiàn)，讓 Agent 自己去找要調(diào)用哪些工具。

Cursor：把工具說明書，全部文件化

Cursor 的策略，更簡單、粗暴。把所有 MCP 工具、Agent Skills 的詳細(xì)定義，全部都同步到文件夾里，讓 Agent 在需要時自己去查閱。

在 Cursor 的框架中，分成了索引層和發(fā)現(xiàn)層。

索引層，Agent 的系統(tǒng)提示詞（System Prompt）里只包含一小部分靜態(tài)信息，比如 MCP 工具或 Agent Skills 的名稱列表。

這些工具和技能的詳細(xì)描述、參數(shù)定義、使用方法，則被全部同步到一個本地文件夾中。當(dāng)模型需要時，Agent 會像一個聰明的程序員一樣，進入發(fā)現(xiàn)層，用 grep 或語義搜索，主動去文件夾里查找它需要的工具的詳細(xì)信息，然后拉取到上下文中來處理。

Cursor 做了一次 A/B 測試，結(jié)果發(fā)現(xiàn)，對于調(diào)用了 MCP 工具的運行任務(wù)，這種策略把Token 的總消耗降低了 46.9%。

同時，Cursor 提到，這種全部文件化的方式，還解鎖了一個意想不到的能力：向 Agent 傳達工具的狀態(tài)。

例如，以前如果一個 MCP 服務(wù)器需要重新認(rèn)證，Agent 可能會直接「忘記」這些工具的存在。但現(xiàn)在，Agent 可以主動發(fā)病、告知用戶去重新認(rèn)證。

Manus：設(shè)計了一套分層的行動空間

Manus 認(rèn)為，常見的方法對工具描述進行動態(tài)的 RAG，不可行。 因為動態(tài)加載工具定義，會「干掉」KV 緩存，且歷史記錄里的舊調(diào)用會成為陷阱。

季逸超：目前一個常見的方法是對工具描述進行動態(tài)的 RAG，比如，根據(jù)當(dāng)前任務(wù)或狀態(tài)按需加載工具。 但會導(dǎo)致兩個問題：首先，由于工具定義位于上下文的開頭，每次變動都會導(dǎo)致你的 KV 緩存重置；最重要的是，模型過去對那些已被移除的工具的調(diào)用記錄仍然存在于上下文中，這可能會誤導(dǎo)模型去調(diào)用無效的工具或使用無效的參數(shù)。

為了解決這個問題，Manus 設(shè)計了一套分層行動空間。把 Agent 的能力劃分為三個層次：函數(shù)調(diào)用、沙盒工具、軟件包和 API。

• 第一層：原子函數(shù)調(diào)用（Function Calling）

核心層，只包含極少數(shù)固定的、正交的原子函數(shù)，比如：讀寫文件、執(zhí)行 shell 命令、在文件和互聯(lián)網(wǎng)中搜索。因為這層是固定的，所以對 KV 緩存友好，且功能邊界清晰，不會導(dǎo)致混淆。

• 第二層：沙盒工具（Sandbox Tools）

卸載層。Manus 將絕大多數(shù)工具，格式轉(zhuǎn)換器、語音識別工具，甚至 MCP 調(diào)用本身（通過一個 MCP CLI 命令行工具），都作為預(yù)裝軟件放在一個定制的 Linux 虛擬機沙箱里。 Agent 不在上下文中「看到」這些工具的詳細(xì)定義，更像是一個真正的開發(fā)者，通過第一層的 shell 命令來動態(tài)地與它們交互。比如，它可以用 ls /bin 來查看有哪些可用的工具，或者用 mcp_cli --help 來學(xué)習(xí)如何使用 MCP 命令行工具。

• 第三層：軟件包與API（Packages & APIs）

代碼層。對于需要大量內(nèi)存計算或者需要與復(fù)雜第三方服務(wù)交互的任務(wù)，允許 Agent 編寫并執(zhí)行 Python 腳本。比如，分析一整年的股票數(shù)據(jù)，Agent 不會把原始數(shù)據(jù)加載到上下文中，而是會寫一個腳本去完成計算，只把摘要結(jié)果返回。

季逸超：在這一層，Manus 可以編寫 Python 腳本來調(diào)用預(yù)先授權(quán)的 API 或自定義軟件包。例如，Manus 可能會使用一個 3D 設(shè)計庫進行建模，或者調(diào)用一個金融 API 來獲取市場數(shù)據(jù)。實際上，我們已經(jīng)代表用戶購買了所有這些 API 并支付了費用，這都包含在訂閱里。 所以，我們基本上在 Manus 中預(yù)裝了大量的 API 密鑰，Manus 可以用這些密鑰訪問 API。我認(rèn)為這對于需要大量內(nèi)存計算，但又不需要將所有數(shù)據(jù)都推送到模型上下文的任務(wù)來說是完美的。

這套思路，和 CodeAct *論文類似。

代碼是可組合的，可以在一步內(nèi)做很多事。但它同樣不是模式安全的，在代碼上做約束解碼非常非常困難。所以我們認(rèn)為你應(yīng)該為這些功能找到合適的場景。對我們來說，所有能在一個編譯器或解釋器運行時內(nèi)處理的事情，我們都用代碼來做；否則，我們就用沙箱工具或函數(shù)調(diào)用。

CodeAct *：《Executable Code Actions Elicit Better LLM Agents》：

https://arxiv.org/pdf/2402.01030

Manus 這套分層設(shè)計非常優(yōu)雅，而且高效。從模型的角度看，無論想使用第二層還是第三層的復(fù)雜工具，最終都會通過 L1 的那幾個原子函數(shù)執(zhí)行。這種接口設(shè)計，對模型極度簡潔，且緩存穩(wěn)定。

03多 Agent 協(xié)作，

需要反復(fù)使用模式、結(jié)構(gòu)化輸出

多個 Agent 之間如何協(xié)作，也是個難題。

Cognition 之前在博客中提到：不要濫用多 Agent 設(shè)置，因為當(dāng)你有很多 Agent 時，它們之間的信息同步會成為一場噩夢。

怎么利用多 Agent，實現(xiàn)「上下文隔離」，讓每個子 Agent 都有自己獨立的上下文窗口，從而實現(xiàn)關(guān)注點分離。是一個核心問題。

Manus 的解決思路是，借鑒 Go 語言：不要通過共享內(nèi)存來通信，而是通過通信來共享內(nèi)存。

把這句話里的「內(nèi)存」替換為「上下文」，就是兩種截然不同的 Agent 協(xié)作模式。

兩種 Agent 協(xié)作模式

• 任務(wù)委托模式：「通過通信」實現(xiàn)隔離

這是經(jīng)典的主-子 Agent（Master-Sub-agent）設(shè)置。主 Agent 將一個任務(wù)封裝成一條簡短、清晰的指令，然后發(fā)送給子 Agent。子 Agent 的上下文是完全獨立的，從零開始，只包含這條指令。

簡單來說，主 Agent 發(fā)任務(wù)，子 Agent 交結(jié)果，中間過程免打擾。

這個模式，適用于「過程不重要，只關(guān)心結(jié)果」的任務(wù)。舉個例子，主 Agent 需要在一個大型代碼庫中搜索特定的代碼片段。它只需要委托子 Agent：「在 A 項目中找到所有調(diào)用了 some_function 的地方」，然后等待返回結(jié)果列表即可。主 Agent 不關(guān)心子 Agent 是如何使用 grep 或其他工具完成搜索的。

在內(nèi)部，Manus 將這種模式叫做「Agent 即工具」。從主 Agent 視角，它只是調(diào)用了 advanced_search 函數(shù)，但背后實際上是另一個擁有獨立工作流的子 Agent 在執(zhí)行。

• 信息同步模式：「通過共享上下文」實現(xiàn)協(xié)作

但對于更復(fù)雜、需要完整歷史記錄的場景，簡單的任務(wù)委托是遠遠不夠的。

Manus 的思路是，通過共享上下文來實現(xiàn)協(xié)作。子 Agent 被創(chuàng)建時，能夠看到主 Agent完整的先前上下文，包括所有的歷史工具調(diào)用和觀察。但這個子 Agent 擁有自己獨立的系統(tǒng)提示詞和新的行動空間。

這種模式，更適用于高度依賴歷史信息、需要綜合分析的任務(wù)。比如，在進行一項深度研究任務(wù)時，最終的研究報告需要綜合大量的中間搜索結(jié)果和筆記。

如果使用第一種通信模式，主 Agent 需要將所有中間產(chǎn)物寫入文件，再讓子 Agent 去一一讀取，這會造成巨大的延遲和額外的 Token 消耗。在這種情況下，直接讓子 Agent 繼承完整的上下文反而會更高效。

但 Manus 也提到，共享上下文的模式成本是相當(dāng)昂貴的。因為每個子 Agent 啟動時都需要 Prefill 一個非常大的輸入，并且因為系統(tǒng)提示詞不同，無法復(fù)用主 Agent 的 KV 緩存，所以必須支付全價。

所以，需要根據(jù)任務(wù)的性質(zhì)，靈活地在這兩種模式中間進行選擇。

多 Agent 通信，發(fā)信息不難，難的是收結(jié)果

多 Agent 通信的一個難點是「接收」，如何從多個并行工作的子 Agent 那里，獲得結(jié)構(gòu)一致、內(nèi)容準(zhǔn)確的輸出？

Manus 設(shè)計了一套內(nèi)部代號叫做「Agent 化的 MapReduce」的系統(tǒng)。簡單來說，

• 共享沙箱

每個 Manus 會話都在一個完整的虛擬機沙箱中運行。當(dāng)主 Agent 創(chuàng)建子 Agent 時，共享同一個沙箱。這意味著，共享同一個文件系統(tǒng)，信息的傳遞可以簡單到只傳遞不同的文件路徑，解決了輸入信息同步的問題。

• 輸出模式（Schema）

這是關(guān)鍵。主 Agent 在創(chuàng)建子 Agent 之前，必須先定義一個輸出的 Schema。這個模式就是一份強制執(zhí)行的 API 合同，規(guī)定了子 Agent 最終必須返回什么樣的數(shù)據(jù)結(jié)構(gòu)。

• 約束解碼

子 Agent 有一個專用工具 submit_result。Manus 使用約束解碼（Constrained Decoding）技術(shù)，強制子 Agent 提交的結(jié)果，必須嚴(yán)格符合主 Agent 定義的 Schema。

這套設(shè)計的核心思路是，無論是做摘要還是 Agent 間通信，都反復(fù)使用模式和結(jié)構(gòu)化輸出作為一種「契約」，來保證信息以結(jié)構(gòu)化、完整的方式傳遞。

04最后，聊聊兩家的設(shè)計哲學(xué)

最后，回到原點，聊聊這兩家的上下文工程設(shè)計哲學(xué)。

Cursor 的「Dynamic Context Discovery」，強調(diào)：少即是多。Cursor 認(rèn)為，在最開始提供給模型的細(xì)節(jié)越少，效果反而越好，因為能讓 Agent 更輕松地自行抓取相關(guān)的上下文。

Manus 的思路是：「少構(gòu)建，多理解」，避免上下文的過度工程化。上下文工程的目標(biāo)是讓模型的工作變得更簡單，而不是更難。

季逸超：回顧 Manus 發(fā)布以來的六七個月，我們見過的最大的飛躍，不是來自增加了更多花哨的上下文管理層或巧妙的檢索技巧，它們都來自于簡化，來自于移除不必要的技巧，以及對模型多一點的信任。 每一次我們簡化架構(gòu)，系統(tǒng)都會變得更快、更穩(wěn)定、更智能。上下文工程的目標(biāo)是讓模型的工作變得更簡單，而不是更難。

兩家的實踐大方向都是，從「如何把更多信息塞進上下文」，變成「怎么給 Agent 創(chuàng)建一個信息豐富、易于探索的外部環(huán)境」。

引用寶玉老師的一句話：未來，隨著基模能力的提升，把主動權(quán)交給模型會是一個趨勢。

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker