前幾天我寫了一篇文章分享了Anthropic 上下文工程最佳實(shí)踐，這篇文章分享達(dá)到了1109次，感覺大家對(duì)Context Engineering還是很感興趣的，今天這篇文章更深入和細(xì)節(jié)一些，LangChain 的創(chuàng)始工程師 Lance Martin 和 Manus 的聯(lián)合創(chuàng)始人 Yichao "Peak" Ji（季逸超《麻省理工科技評(píng)論》評(píng)選的 2025 年 35 歲以下創(chuàng)新者之一） 深入探討了上下文工程，分享了他們?cè)谏a(chǎn)環(huán)境中管理上下文窗口、優(yōu)化性能和構(gòu)建可擴(kuò)展代理的實(shí)戰(zhàn)策略

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

強(qiáng)烈建議大家圍觀

上下文工程的興起：為何它對(duì) AI 代理至關(guān)重要

在人工智能領(lǐng)域，我們見證了一個(gè)重要的范式轉(zhuǎn)變。隨著 ChatGPT 的問世，Prompt Engineering（提示工程）在 2022 年底應(yīng)運(yùn)而生，成為與聊天模型交互的核心學(xué)科。然而，進(jìn)入 2023 年，一個(gè)新的、更為關(guān)鍵的領(lǐng)域——Context Engineering（上下文工程）開始嶄露頭角

與簡單的聊天機(jī)器人不同，AI Agents 的核心特征在于它們能夠自主地、循環(huán)地調(diào)用一系列工具來完成復(fù)雜任務(wù)。這個(gè)過程帶來了一個(gè)獨(dú)特的挑戰(zhàn)：上下文的無界爆炸

工作機(jī)制：一個(gè) Agent 通常綁定了一個(gè)或多個(gè)工具。每當(dāng) Agent 調(diào)用一個(gè)工具，它會(huì)收到一個(gè)工具的觀測結(jié)果，這個(gè)結(jié)果會(huì)作為一個(gè)新的消息被追加到對(duì)話歷史中

規(guī)模問題：根據(jù) Manus 的實(shí)踐經(jīng)驗(yàn)，一個(gè)典型的任務(wù)可能需要大約 50 次工具調(diào)用。而 Anthropic 的研究也指出，生產(chǎn)環(huán)境中的代理可能會(huì)進(jìn)行長達(dá)數(shù)百輪的對(duì)話

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

這就形成了一個(gè)核心矛盾：Agents 的強(qiáng)大功能依賴于利用大量上下文信息，但模型的性能卻會(huì)因?yàn)樯舷挛倪^長而受損

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

為了實(shí)現(xiàn)這一目標(biāo)，行業(yè)內(nèi)涌現(xiàn)出了一系列共通的主題和策略，構(gòu)成了上下文工程的支柱：

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

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

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

4.Context Isolation (上下文隔離)：通過將任務(wù)分解給多個(gè)子代理（sub-agents），每個(gè)子代理擁有自己獨(dú)立的、更小的上下文窗口，從而實(shí)現(xiàn)關(guān)注點(diǎn)分離和上下文管理

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

這些策略并非孤立存在，而是相互關(guān)聯(lián)、協(xié)同工作，共同構(gòu)成了現(xiàn)代 AI Agents 架構(gòu)的基石

戰(zhàn)略抉擇：優(yōu)先上下文工程，而非過早模型專業(yè)化

在深入探討上下文工程的具體技術(shù)之前，一個(gè)更根本的問題值得思考：我們?yōu)槭裁葱枰?？尤其是在模型微調(diào)和后訓(xùn)練技術(shù)日益普及的今天。Manus 的聯(lián)合創(chuàng)始人 Peak Ji 分享了他從多年實(shí)踐中得出的深刻見解，認(rèn)為上下文工程是應(yīng)用層和模型層之間最清晰、最實(shí)用的邊界

在創(chuàng)辦 Manus 之前，Peak 擁有超過十年的自然語言處理經(jīng)驗(yàn)，他的上一個(gè)創(chuàng)業(yè)項(xiàng)目就是從零開始訓(xùn)練自己的語言模型。這段經(jīng)歷讓他痛苦地認(rèn)識(shí)到，過早地構(gòu)建專用模型會(huì)帶來巨大風(fēng)險(xiǎn)：

扼殺創(chuàng)新速度：產(chǎn)品的迭代速度完全被模型的迭代速度所限制。一個(gè)訓(xùn)練加評(píng)估的周期可能需要一到兩周，這對(duì)于需要快速驗(yàn)證產(chǎn)品市場契合度的初創(chuàng)公司是致命的

優(yōu)化目標(biāo)錯(cuò)位：在產(chǎn)品方向尚未完全明朗時(shí)，團(tuán)隊(duì)可能會(huì)花費(fèi)大量時(shí)間去提升一些對(duì)產(chǎn)品價(jià)值可能毫無意義的基準(zhǔn)測試分?jǐn)?shù)

因此，初創(chuàng)公司應(yīng)該盡可能長時(shí)間地依賴通用模型和上下文工程。然而，隨著產(chǎn)品成熟和開源基礎(chǔ)模型的崛起，另一個(gè)陷阱也隨之出現(xiàn)：用自有數(shù)據(jù)微調(diào)一個(gè)強(qiáng)大的基礎(chǔ)模型，使其在特定用例上表現(xiàn)出色

Peak 指出這同樣是危險(xiǎn)的，因?yàn)閺?qiáng)化學(xué)習(xí)通常需要固定一個(gè)行動(dòng)空間，并圍繞當(dāng)前的產(chǎn)品行為設(shè)計(jì)獎(jiǎng)勵(lì)函數(shù)。但這在 AI 和 Agents 的早期階段是極其脆弱的，因?yàn)榈讓蛹夹g(shù)可能一夜之間發(fā)生顛覆

一個(gè)典型的例子**：MCP的發(fā)布，徹底改變了 Manus 的設(shè)計(jì)，使其從一個(gè)緊湊、靜態(tài)的行動(dòng)空間，轉(zhuǎn)變?yōu)橐粋€(gè)幾乎無限可擴(kuò)展的系統(tǒng)。如果你已經(jīng)訓(xùn)練了自己的模型，你會(huì)知道這種開放域問題極難優(yōu)化

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

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

上下文精簡：壓縮與總結(jié)

上下文精簡是上下文工程的核心技術(shù)之一，但它并非一個(gè)單一的操作。Manus 在實(shí)踐中將其細(xì)分為兩種截然不同但相輔相成的方法：Compaction (壓縮)和 Summarization (總結(jié))，并建立了一套嚴(yán)謹(jǐn)?shù)墓ぷ髁鞒虂韰f(xié)同使用它們

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

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

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

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

為何可逆性至關(guān)重要：Agents 的決策是鏈?zhǔn)降?，基于之前的行?dòng)和觀察。我們永遠(yuǎn)無法預(yù)知過去的哪個(gè)動(dòng)作會(huì)在十步之后突然變得至關(guān)重要。可逆的壓縮確保了沒有任何信息被真正丟失，只是被暫時(shí)移出了即時(shí)上下文

總結(jié) (Summarization)：一種不可逆的謹(jǐn)慎精煉

當(dāng)僅靠壓縮已無法將上下文大小控制在閾值以下時(shí)，就需要?jiǎng)佑酶鼈鹘y(tǒng)的總結(jié)方法?？偨Y(jié)是不可逆的，意味著信息會(huì)有損失，因此必須非常謹(jǐn)慎地使用

執(zhí)行時(shí)機(jī)：總結(jié)是最后的手段，只有在多輪壓縮后，上下文長度仍然接近性能“腐爛”的臨界點(diǎn)時(shí)才會(huì)觸發(fā)

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

總結(jié)的藝術(shù)：在 Q&A 環(huán)節(jié)中，Peak 補(bǔ)充了一個(gè)關(guān)鍵技巧來提升總結(jié)質(zhì)量：不要使用自由格式的提示。相反，應(yīng)該定義一個(gè)結(jié)構(gòu)化的模式（schema）或表單，讓模型去填充字段，例如“我修改了哪些文件”、“用戶的目標(biāo)是什么”、“我上次進(jìn)行到哪一步”。這種結(jié)構(gòu)化的輸出比自由生成的文本更穩(wěn)定、更可控，也更容易保證關(guān)鍵信息不被遺漏

一套基于閾值的工作流程

為了讓壓縮和總結(jié)能夠和諧共存，Manus 設(shè)計(jì)了一套基于多層上下文長度閾值的自動(dòng)化流程：

1.確定閾值：

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

預(yù)腐爛閾值：模型性能開始顯著下降的實(shí)際閾值。這需要通過大量評(píng)估來確定，通常在 128K 到 200K token 之間。當(dāng)模型開始出現(xiàn)重復(fù)、推理變慢、質(zhì)量下降等“上下文腐爛”現(xiàn)象時(shí)，就接近這個(gè)閾值了

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

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

4.執(zhí)行總結(jié)：進(jìn)行總結(jié)時(shí)，應(yīng)使用未經(jīng)壓縮的完整版數(shù)據(jù)作為輸入，以確?？偨Y(jié)的質(zhì)量。同時(shí)，與壓縮類似，始終保留最后幾次的工具調(diào)用和結(jié)果為完整細(xì)節(jié)，不進(jìn)行總結(jié)。這能幫助模型清晰地知道它在哪個(gè)節(jié)點(diǎn)被打斷，從而更平滑地繼續(xù)任務(wù)，避免因總結(jié)導(dǎo)致的行為或風(fēng)格突變

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

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

當(dāng)任務(wù)變得異常復(fù)雜時(shí)，單一 Agent 的上下文管理壓力會(huì)變得巨大。此時(shí)，將任務(wù)分解給多個(gè)子代理（sub-agents）的上下文隔離策略就顯得尤為重要。Cognition AI 在他們的博客中曾警示過多代理設(shè)置的風(fēng)險(xiǎn)，因?yàn)樵谒鼈冎g同步信息可能成為一場噩夢(mèng)。然而，這并非一個(gè)新問題，它與計(jì)算機(jī)科學(xué)早期多進(jìn)程/多線程協(xié)調(diào)的挑戰(zhàn)異曲同工

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

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

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

這是最經(jīng)典、最直觀的子代理設(shè)置。它適用于那些可以被清晰地分解和委派的任務(wù)。

工作流程：

1.主代理（main agent）將一個(gè)任務(wù)封裝成一個(gè)清晰、自包含的指令，就像一個(gè)函數(shù)調(diào)用

2.這個(gè)指令被發(fā)送給一個(gè)子代理

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

4.子代理將最終結(jié)果返回給主代理

適用場景：當(dāng)任務(wù)指令簡短明確，且主代理只關(guān)心最終產(chǎn)出，不關(guān)心實(shí)現(xiàn)過程時(shí)，這種模式是最佳選擇

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

優(yōu)點(diǎn)：簡單、隔離性好、上下文開銷小

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

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

工作流程：

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

2.但是，這個(gè)子代理擁有自己獨(dú)特的系統(tǒng)提示和行動(dòng)空間 。它是在共享的背景知識(shí)上，以一個(gè)新的“身份”或“能力集”來執(zhí)行任務(wù)

適用場景：當(dāng)任務(wù)的最終產(chǎn)出質(zhì)量取決于對(duì)大量中間過程和發(fā)現(xiàn)的理解時(shí)，共享上下文是更高效的選擇

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

成本與權(quán)衡：這種模式的成本更高

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

KV 緩存失效：由于每個(gè)子代理的系統(tǒng)提示和行動(dòng)空間都不同，無法復(fù)用之前的 KV 緩存，這意味著每次切換到子代理都需要支付全額的計(jì)算成本

在 Q&A 環(huán)節(jié)，Peak 進(jìn)一步闡述了 Manus 如何在實(shí)踐中實(shí)現(xiàn)這兩種模式，尤其是 agent 間的通信：

共享沙箱作為媒介：Manus 的每個(gè)會(huì)話都運(yùn)行在一個(gè)獨(dú)立的虛擬機(jī)沙箱中。主代理和子代理可以共享同一個(gè)沙箱。因此，信息傳遞可以通過共享文件系統(tǒng)來完成，主代理只需傳遞文件路徑即可

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

通過這兩種模式的靈活運(yùn)用，可以在保持任務(wù)隔離性的同時(shí)，高效地處理不同依賴度的復(fù)雜協(xié)作任務(wù)。

超越數(shù)據(jù)：通過分層行動(dòng)空間卸載工具

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

當(dāng)上下文中存在過多的工具定義時(shí)，會(huì)導(dǎo)致“上下文混淆 (context confusion)”，模型可能會(huì)調(diào)用錯(cuò)誤的工具，甚至是根本不存在的工具。一個(gè)常見的解決方案是根據(jù)當(dāng)前任務(wù)動(dòng)態(tài)地對(duì)工具描述進(jìn)行 RAG（檢索增強(qiáng)生成），按需加載工具。但這種方法存在兩個(gè)弊端：

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

2.誤導(dǎo)模型：即使某個(gè)工具被移除了，模型在歷史記錄中仍然能看到對(duì)該工具的過往調(diào)用。這可能會(huì)誤導(dǎo)模型去調(diào)用一個(gè)當(dāng)前無效的工具或使用錯(cuò)誤的參數(shù)

為了解決這個(gè)問題，Manus 創(chuàng)新性地設(shè)計(jì)了一種分層的行動(dòng)空間 (Layered Action Space)。這種架構(gòu)將 Agent 的能力分解為三個(gè)抽象層次，從模型的視角看，所有操作最終都?xì)w結(jié)為少數(shù)幾個(gè)核心函數(shù)調(diào)用，從而實(shí)現(xiàn)了極高的穩(wěn)定性和可擴(kuò)展性

第一層：函數(shù)調(diào)用 (Function Calling)

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

特點(diǎn)：

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

模式安全：得益于約束解碼，函數(shù)調(diào)用的格式和參數(shù)是嚴(yán)格受控的

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

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

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

這一層將大量的功能從函數(shù)調(diào)用層卸載到了 Agent 所在的虛擬機(jī)沙箱環(huán)境中。

特點(diǎn)：

預(yù)裝命令行工具：Manus 在其定制的 Linux 系統(tǒng)中預(yù)裝了大量為 Agent 開發(fā)的命令行工具。例如，格式轉(zhuǎn)換器、語音識(shí)別工具，甚至一個(gè)特殊的 MCP CLI（用于調(diào)用 MCP 功能的命令行接口）

通過 Shell 調(diào)用：Agent 不是通過新的函數(shù)來使用這些工具，而是通過第一層的 execute_shell_command 函數(shù)來運(yùn)行它們

優(yōu)勢(shì)：

無限擴(kuò)展：可以在不修改模型函數(shù)調(diào)用空間（action space）的情況下，不斷增加新的能力

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

處理大數(shù)據(jù)：這些命令行工具可以處理非常大的輸出，它們可以將結(jié)果寫入文件，或進(jìn)行分頁返回，Agent 可以使用 grep, cat, less 等標(biāo)準(zhǔn) Linux 工具來處理這些結(jié)果

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

這是最高層的抽象，Agent 通過編寫和執(zhí)行代碼來與外部世界進(jìn)行更復(fù)雜的交互。

特點(diǎn)：

編寫腳本：Agent 可以編寫 Python 腳本來調(diào)用預(yù)授權(quán)的第三方 API 或自定義的軟件包。例如，使用一個(gè) 3D 設(shè)計(jì)庫進(jìn)行建模，或調(diào)用一個(gè)金融 API 獲取市場數(shù)據(jù)

通過文件和 Shell 執(zhí)行：Agent 使用第一層的 write_file 函數(shù)創(chuàng)建腳本，然后使用 execute_shell_command 函數(shù)來運(yùn)行它

優(yōu)勢(shì)：

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

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

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

統(tǒng)領(lǐng)全局的設(shè)計(jì)哲學(xué)與一線實(shí)戰(zhàn)

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

他回顧了 Manus 發(fā)布以來的發(fā)展歷程，發(fā)現(xiàn)那些帶來最大性能飛躍的時(shí)刻，并非來自增加了更花哨的上下文管理層或更聰明的檢索技巧，而是來自簡化——來自移除不必要的技巧，并給予模型多一點(diǎn)信任。每一次簡化架構(gòu)，系統(tǒng)都會(huì)變得更快、更穩(wěn)定、也更智能

這引出了一條核心的設(shè)計(jì)哲學(xué)：上下文工程的目標(biāo)是讓模型的工作變得更簡單，而不是更復(fù)雜。構(gòu)建得更少，理解得更多 (Build less, understand more)。

在最后的 Q&A 環(huán)節(jié)，這一哲學(xué)思想通過一系列具體的實(shí)踐經(jīng)驗(yàn)得到了進(jìn)一步的印證，這些來自一線的智慧為構(gòu)建高效 Agents 提供了寶貴的參考：

關(guān)于評(píng)測：

用戶反饋是黃金標(biāo)準(zhǔn)：對(duì) Manus 而言，最重要的評(píng)測指標(biāo)是每次會(huì)話結(jié)束后用戶給出的 1-5 星評(píng)分

內(nèi)部自動(dòng)化測試為輔：他們創(chuàng)建了自有數(shù)據(jù)集，包含可驗(yàn)證結(jié)果的執(zhí)行型任務(wù)，彌補(bǔ)了現(xiàn)有公開基準(zhǔn)測試大多為只讀任務(wù)的不足

人類評(píng)估不可或缺：對(duì)于網(wǎng)站生成、數(shù)據(jù)可視化這類難以用自動(dòng)化指標(biāo)衡量的、涉及“品味”的任務(wù)，必須依賴大量的人類實(shí)習(xí)生進(jìn)行主觀評(píng)估。公開的學(xué)術(shù)基準(zhǔn)（如 GAIA）可能與真實(shí)用戶需求嚴(yán)重脫節(jié)

關(guān)于模型選擇與架構(gòu)設(shè)計(jì)：

優(yōu)先選擇旗艦?zāi)Ｐ停罕M管開源模型看似成本更低，但對(duì)于輸入遠(yuǎn)長于輸出的 Agent 任務(wù)，KV 緩存至關(guān)重要。旗艦?zāi)Ｐ吞峁┥虛碛懈墒斓姆植际?KV 緩存基礎(chǔ)設(shè)施，在規(guī)?；渴饡r(shí)可能反而更具成本效益

利用模型差異進(jìn)行路由：不同的頂尖模型各有千秋（例如 Claude 擅長編碼，Gemini 擅長多模態(tài)）。應(yīng)用層的優(yōu)勢(shì)在于無需綁定單一模型，可以進(jìn)行任務(wù)級(jí)甚至步驟級(jí)的智能路由

測試架構(gòu)的“未來兼容性”：一個(gè)好的 Agent 架構(gòu)，應(yīng)該在從一個(gè)較弱模型切換到一個(gè)較強(qiáng)模型時(shí)，性能有顯著提升。這種測試可以作為架構(gòu)是否“未來兼容”的早期信號(hào)

關(guān)于 Agent 設(shè)計(jì)：

避免角色擬人化：不要強(qiáng)行將人類的組織架構(gòu)（如設(shè)計(jì)師、程序員、經(jīng)理）套用在 Agent 設(shè)計(jì)上。這種分工是人類上下文限制的產(chǎn)物

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

從 todo.md 到規(guī)劃者 Agent：早期的 Agent 普遍使用 todo.md 文件進(jìn)行任務(wù)規(guī)劃，但這會(huì)浪費(fèi)大量 token 在文件的反復(fù)讀寫更新上。更優(yōu)的模式是將其升級(jí)為一個(gè)獨(dú)立的規(guī)劃者 Agent，使用“Agent as Tool”的范式進(jìn)行交互

關(guān)于強(qiáng)化學(xué)習(xí) (RL) 與工具調(diào)用：

謹(jǐn)慎對(duì)待 RL：對(duì)于一個(gè)需要支持開放、可擴(kuò)展行動(dòng)空間（如 MCP）的通用 Agent，進(jìn)行 RL 的難度極高。這相當(dāng)于在自己構(gòu)建一個(gè)基礎(chǔ)模型。目前階段，將這項(xiàng)工作交給模型公司，而應(yīng)用層專注于上下文工程是更明智的選擇

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

參考：

Context Engineering for AI Agents with LangChain and Manus