Z Talk 是真格分享認(rèn)知的欄目。

在《》中，Manus 聯(lián)合創(chuàng)始人、首席科學(xué)家 Peak（季逸超）提到，每當(dāng)團(tuán)隊(duì)在討論某個(gè)功能的技術(shù)實(shí)現(xiàn)時(shí)，他會(huì)習(xí)慣性地思考：這個(gè)功能，能不能在產(chǎn)品里形成網(wǎng)絡(luò)效應(yīng)？

作為一個(gè)通用 Agent，Manus 每增加一項(xiàng)能力，團(tuán)隊(duì)就希望它能和已有功能之間產(chǎn)生意想不到的耦合效應(yīng)。比如在加入圖像讀取功能后，他們發(fā)現(xiàn) Manus 能自行調(diào)試生成的數(shù)據(jù)可視化代碼，甚至能神奇地修復(fù)其他模塊的問題。這正是他們所看重的復(fù)合效應(yīng)。

昨天，Manus 官網(wǎng)發(fā)布了一篇新文章，Peak 分享了他們在搭建上下文工程過程中踩過的坑和總結(jié)出的經(jīng)驗(yàn)。這是一篇真誠、深入、極具實(shí)戰(zhàn)價(jià)值的記錄。Peak 把團(tuán)隊(duì)在一次次試錯(cuò)中淬煉出的經(jīng)驗(yàn)系統(tǒng)梳理，為正在構(gòu)建 AI Agent 的開發(fā)者們提供了一套可借鑒的路徑，也帶我們重新走了一遍 Manus 從零到一的探索過程。

Manus 還在前行。正如 Peak 在文中所說：「如果模型進(jìn)步是上漲的潮水，我們希望 Manus 是船，而不是釘在海床上的柱子。」

如果你也在打造自己的 Agent，希望這些總結(jié)能幫你更快找到方向。本文轉(zhuǎn)自 Founder Park，基于 Kimi K2 翻譯，以下為編譯原文：

在 Manus 項(xiàng)目伊始，我和團(tuán)隊(duì)就面臨一個(gè)關(guān)鍵抉擇：是利用開源基礎(chǔ)模型訓(xùn)練一個(gè)端到端的智能體，還是依托前沿模型的上下文學(xué)習(xí)能力，在其之上構(gòu)建智能體？

在我投身 NLP 的第一個(gè)十年里，我們并沒有這種奢侈的選擇。遙想當(dāng)年 BERT 問世（沒錯(cuò)，那已是七年前），模型必須先經(jīng)過微調(diào)——還要評估——才能遷移到新任務(wù)。每次迭代往往耗時(shí)數(shù)周，盡管那時(shí)的模型體積與今日的 LLMs 相比微不足道。對于快速迭代的應(yīng)用，尤其是 PMF 之前的階段，如此緩慢的反饋循環(huán)幾乎是致命的。這是我上一家初創(chuàng)公司留下的慘痛教訓(xùn)：當(dāng)時(shí)我從零開始訓(xùn)練模型，用于開放信息抽取和語義搜索。隨后 GPT-3 與 Flan-T5 橫空出世，我那些自研模型一夜之間便失去了意義。頗具諷刺意味的是，正是這些新模型開啟了上下文學(xué)習(xí)的大門，也為我們指明了一條全新的道路。

這個(gè)來之不易的教訓(xùn)讓選擇變得清晰：Manus 將押注于上下文工程。這讓我們能在幾小時(shí)內(nèi)發(fā)布改進(jìn)，而非幾周，同時(shí)也讓我們的產(chǎn)品與底層模型保持正交：如果模型進(jìn)步是上漲的潮水，我們希望 Manus 是船，而不是釘在海床上的柱子。

然而，上下文工程遠(yuǎn)非一帆風(fēng)順。它是一門實(shí)驗(yàn)科學(xué)。我們已經(jīng)四次重構(gòu)了智能體框架，每一次都是在發(fā)現(xiàn)更好的上下文塑造方式之后。我們親切地把這個(gè)手動(dòng)進(jìn)行架構(gòu)搜索、提示微調(diào)和經(jīng)驗(yàn)猜測的過程稱為「隨機(jī)梯度下降」（Stochastic Graduate Descent）。它并不優(yōu)雅，但確實(shí)有效。

這篇文章分享了我們通過自身「SGD」抵達(dá)的局部最優(yōu)解。如果你正在構(gòu)建自己的 AI 智能體，希望這些原則能幫助你更快收斂。

圍繞 KV-Cache 進(jìn)行設(shè)計(jì)

如果只能選一個(gè)指標(biāo)，我會(huì)說 KV 緩存命中率是生產(chǎn)級 AI 智能體最重要的單一指標(biāo)，它直接影響延遲和成本。要理解原因，我們先看一個(gè)典型智能體的工作流程：

收到用戶輸入后，智能體通過一連串工具調(diào)用來完成任務(wù)。每一次迭代，模型都會(huì)根據(jù)當(dāng)前上下文從預(yù)定義的動(dòng)作空間中選擇一個(gè)動(dòng)作，然后在環(huán)境（如 Manus 的虛擬機(jī)沙箱）里執(zhí)行該動(dòng)作并產(chǎn)生觀察結(jié)果。動(dòng)作和觀察結(jié)果被追加到上下文中，成為下一次迭代的輸入。這個(gè)循環(huán)持續(xù)進(jìn)行，直到任務(wù)完成。

可以想象，上下文在每一步都會(huì)增長，而輸出——通常是一個(gè)結(jié)構(gòu)化的函數(shù)調(diào)用——相對較短。這使得智能體的預(yù)填充與解碼比例相比聊天機(jī)器人嚴(yán)重失衡。以 Manus 為例，平均輸入與輸出 token 的比例約為 100:1。

幸運(yùn)的是，具有相同前綴的上下文可以利用 KV 緩存，從而顯著降低首 token 延遲（TTFT）和推理成本，無論你是使用自托管模型還是調(diào)用推理 API。這可不是小打小鬧的節(jié)省：以 Claude Sonnet 為例，緩存的輸入 token 價(jià)格為 0.30 美元/百萬 token，而未緩存的則高達(dá) 3 美元/百萬 token，相差 10 倍。

從上下文工程的角度來看，提高 KV 緩存命中率需要遵循幾個(gè)關(guān)鍵實(shí)踐：

1. 保持提示前綴穩(wěn)定。由于 LLMs 的自回歸特性，即使只有一個(gè) token 的差異，也可能從該 token 開始使整個(gè)緩存失效。一個(gè)常見錯(cuò)誤是在系統(tǒng)提示開頭加入時(shí)間戳——尤其是精確到秒的那種。雖然這讓模型能告訴你當(dāng)前時(shí)間，但也會(huì)讓你的緩存命中率歸零。

2. 讓上下文保持追加式。避免修改之前的動(dòng)作或觀察結(jié)果。確保序列化是確定性的。許多編程語言和庫在序列化 JSON 對象時(shí)并不保證鍵的順序穩(wěn)定，這會(huì)在無聲無息中破壞緩存。

3. 在需要時(shí)明確標(biāo)記緩存斷點(diǎn)。某些模型提供方或推理框架不支持自動(dòng)增量前綴緩存，而是要求手動(dòng)在上下文中插入緩存斷點(diǎn)。設(shè)置這些斷點(diǎn)時(shí)，要考慮潛在的緩存過期，并至少確保斷點(diǎn)包含系統(tǒng)提示的結(jié)尾。

此外，如果你使用 vLLM 等框架自行托管模型，請確保啟用了前綴/提示緩存，并使用會(huì)話 ID 等技術(shù)在分布式工作節(jié)點(diǎn)間一致地路由請求。

通過掩碼而非移除的方式約束行為選擇

隨著你的智能體承擔(dān)更多能力，其行動(dòng)空間自然會(huì)變得更加復(fù)雜。直白地說，工具數(shù)量會(huì)爆炸式增長。最近 MCP 的流行更是火上澆油。如果你允許用戶自行配置工具，相信我：一定會(huì)有人把上百個(gè)神秘工具插進(jìn)你精心策劃的行動(dòng)空間。結(jié)果，模型更容易選錯(cuò)動(dòng)作，或走上低效的路線。簡而言之，全副武裝的智能體反而變得更笨。

一種自然的想法是設(shè)計(jì)一個(gè)動(dòng)態(tài)的動(dòng)作空間——也許用類似 RAG 的方式按需加載工具。我們在 Manus 中也嘗試過。但實(shí)驗(yàn)結(jié)果給出了一個(gè)明確的規(guī)則：除非絕對必要，否則避免在迭代過程中動(dòng)態(tài)增刪工具。主要原因有兩點(diǎn)：

1. 在大多數(shù) LLMs 中，工具定義在序列化后通常位于上下文的前部，一般在系統(tǒng)提示之前或之后。因此，任何變動(dòng)都會(huì)使后續(xù)所有動(dòng)作與觀察的 KV-cache 失效。

2. 當(dāng)之前的動(dòng)作和觀察仍引用當(dāng)前上下文中已不存在的工具時(shí)，模型會(huì)陷入混亂。在沒有約束解碼的情況下，這往往導(dǎo)致模式違規(guī)或幻覺動(dòng)作。

為了在提升動(dòng)作選擇的同時(shí)解決這一問題，Manus 使用了一個(gè)上下文感知的狀態(tài)機(jī)來管理工具可用性。它并不真正移除工具，而是在解碼階段屏蔽相應(yīng) token 的 logits，從而根據(jù)當(dāng)前上下文阻止（或強(qiáng)制）選擇某些動(dòng)作。

在實(shí)踐中，大多數(shù)模型提供商和推理框架都支持某種形式的響應(yīng)預(yù)填充，這讓你無需修改工具定義即可約束動(dòng)作空間。函數(shù)調(diào)用通常有三種模式（我們以 NousResearch 的 Hermes 格式為例）：

• Auto – 模型可以選擇是否調(diào)用函數(shù)。實(shí)現(xiàn)方式：僅預(yù)填充回復(fù)前綴：<|im_start|>assistant

• Required – 模型必須調(diào)用函數(shù)，但具體調(diào)用哪個(gè)函數(shù)不受限制。實(shí)現(xiàn)方式：預(yù)填充到工具調(diào)用標(biāo)記：<|im_start|>assistant

• Specified – 模型必須從特定子集中調(diào)用函數(shù)。實(shí)現(xiàn)方式：預(yù)填充到函數(shù)名開頭：<|im_start|>assistant {"name":「browser\_

我們利用這一點(diǎn)，直接在 token logits 上施加掩碼來限制動(dòng)作選擇。例如，當(dāng)用戶提供新的輸入時(shí)，Manus 必須立即回復(fù)，而不能執(zhí)行任何動(dòng)作。我們還特意為動(dòng)作名稱設(shè)計(jì)了統(tǒng)一的前綴——例如，所有與瀏覽器相關(guān)的工具都以 browser\_ 開頭，命令行工具則以 shell\_ 開頭。這樣一來，我們就能輕松地在給定狀態(tài)下限定智能體只能從某一組工具中選擇，而無需依賴有狀態(tài)的 logits 處理器。

這些設(shè)計(jì)有助于確保 Manus 智能體循環(huán)保持穩(wěn)定，即使在以模型為驅(qū)動(dòng)的架構(gòu)下也是如此。

將文件系統(tǒng)作為上下文

現(xiàn)代前沿 LLMs 現(xiàn)已支持 128K 乃至更大的上下文窗口。但在真實(shí)的智能體場景中，這往往仍不夠用，有時(shí)甚至反而成為負(fù)擔(dān)。常見痛點(diǎn)有三：

1. 觀測結(jié)果可能非常龐大，尤其是當(dāng)智能體與網(wǎng)頁或 PDF 這類非結(jié)構(gòu)化數(shù)據(jù)交互時(shí)。很容易就會(huì)超出上下文限制。

2. 模型性能在超過某個(gè)上下文長度后往往會(huì)下降，即使窗口技術(shù)層面仍支持。

3. 長輸入成本高昂，即使有前綴緩存，你仍需為傳輸和預(yù)填充每個(gè) token 付費(fèi)。

為了應(yīng)對這一問題，許多智能體系統(tǒng)實(shí)現(xiàn)了上下文截?cái)嗷驂嚎s策略。但過度激進(jìn)的壓縮必然導(dǎo)致信息丟失。問題本質(zhì)在于：智能體本質(zhì)上必須基于所有先前狀態(tài)來預(yù)測下一步行動(dòng)。你無法可靠地預(yù)測哪條觀測在十步之后會(huì)變得至關(guān)重要。從邏輯角度看，任何不可逆的壓縮都伴隨風(fēng)險(xiǎn)。

正因如此，我們在 Manus 中將文件系統(tǒng)視為終極上下文：容量無限、天然持久，并且代理可直接操作。模型學(xué)會(huì)按需讀寫文件，把文件系統(tǒng)不僅當(dāng)作存儲(chǔ)，更當(dāng)作結(jié)構(gòu)化、外化的記憶。

我們的壓縮策略始終保證可還原。例如，只要保留 URL，網(wǎng)頁內(nèi)容即可從上下文中移除；只要路徑仍在沙盒中可用，文檔內(nèi)容也可省略。這讓 Manus 能在不永久丟失信息的前提下縮短上下文長度。

在開發(fā)這一功能的過程中，我開始設(shè)想要讓狀態(tài)空間模型（SSM）在代理環(huán)境中高效運(yùn)作需要哪些條件。與 Transformer 不同，SSM 缺乏完整的注意力機(jī)制，難以處理長距離的反向依賴。然而，如果它們能夠掌握基于文件的記憶——將長期狀態(tài)外部化，而非保存在上下文里——那么它們的速度與效率或許就能催生一類全新的代理。代理化的 SSM 可能成為神經(jīng)圖靈機(jī)的真正繼承者。

通過復(fù)述操控注意力

如果你用過 Manus，可能會(huì)注意到一個(gè)有趣的現(xiàn)象：在處理復(fù)雜任務(wù)時(shí)，它往往會(huì)創(chuàng)建一個(gè) todo.md 文件，并在任務(wù)推進(jìn)過程中逐步更新，把已完成的項(xiàng)逐一勾選。

這可不是賣萌的小動(dòng)作，而是一種刻意設(shè)計(jì)的注意力操控機(jī)制。

在 Manus 中，一個(gè)典型任務(wù)平均需要約 50 次工具調(diào)用。這是一個(gè)很長的循環(huán)。由于 Manus 依賴 LLMs 做決策，它很容易在冗長上下文或復(fù)雜任務(wù)中偏離主題或遺忘早期目標(biāo)。

通過不斷重寫待辦清單，Manus 把目標(biāo)「背誦」到上下文的末尾。這樣一來，全局計(jì)劃就被推入模型的近期注意力范圍，避免「中間丟失」問題，減少目標(biāo)錯(cuò)位。實(shí)際上，它是在用自然語言把自己的注意力偏向任務(wù)目標(biāo)，無需任何特殊架構(gòu)改動(dòng)。

保留錯(cuò)誤內(nèi)容

智能體會(huì)犯錯(cuò)。這不是缺陷，而是現(xiàn)實(shí)。語言模型會(huì)產(chǎn)生幻覺，環(huán)境會(huì)返回錯(cuò)誤，外部工具會(huì)出故障，意外的邊緣情況也層出不窮。在多步驟任務(wù)中，失敗并非例外，而是循環(huán)的一部分。

然而，一種常見的沖動(dòng)是掩蓋這些錯(cuò)誤：清理追蹤記錄、重試操作，或重置模型狀態(tài)，然后寄希望于神秘的「溫度」參數(shù)。這看似更安全、更可控，卻付出了代價(jià)：抹除失敗就等于抹除證據(jù)。而沒有證據(jù)，模型就無法適應(yīng)。

根據(jù)我們的經(jīng)驗(yàn)，提升智能體行為最有效的方法之一看似簡單卻極具欺騙性：把走錯(cuò)的路留在上下文中。

當(dāng)模型看到一次失敗的行動(dòng)，以及隨之而來的觀察結(jié)果或堆棧跟蹤，它會(huì)潛移默化地更新內(nèi)部信念。這會(huì)把先驗(yàn)從類似行動(dòng)上移開，降低重蹈覆轍的概率。事實(shí)上，我們認(rèn)為錯(cuò)誤恢復(fù)是真正具備智能體行為的最清晰指標(biāo)之一。然而，在大多數(shù)學(xué)術(shù)研究和公開基準(zhǔn)中，它仍然被低估，這些研究和基準(zhǔn)往往聚焦于理想條件下的任務(wù)成功。

不要被 Few-Shot 反噬

少樣本提示（Few-Shot Prompting）是一種提升 LLM 輸出的常用技術(shù)，但在智能體系統(tǒng)中，它可能以微妙的方式適得其反。

語言模型是出色的模仿者；它們會(huì)模仿上下文中的行為模式。如果你的上下文里充斥著大量相似的動(dòng)作-觀察對，模型就會(huì)傾向于沿用這一模式，即便該模式已不再最優(yōu)。

這在涉及重復(fù)性決策或任務(wù)的場景中可能很危險(xiǎn)。例如，當(dāng)使用 Manus 協(xié)助審閱一批 20 份簡歷時(shí)，代理往往會(huì)陷入一種節(jié)奏——僅僅因?yàn)樯舷挛睦锍霈F(xiàn)了類似操作就不斷重復(fù)。這會(huì)導(dǎo)致漂移、過度泛化，甚至有時(shí)產(chǎn)生幻覺。

解決方法是增加多樣性。Manus 在動(dòng)作和觀察中引入少量結(jié)構(gòu)化變化，像不同的序列化模板、替代表述方式、順序或格式上的輕微擾動(dòng)。這種受控的隨機(jī)性有助于打破固定模式，微調(diào)模型的注意力。換句話說，不要把自己困死在少量示例里。上下文越單一，Agent 就越脆弱。

結(jié)論

上下文工程仍是一門新興學(xué)科。但對智能體系統(tǒng)而言，它已是不可或缺。模型可能變得更強(qiáng)大、更快速、更便宜，但再強(qiáng)的原生能力也無法取代記憶、環(huán)境與反饋。你如何塑造上下文，最終決定了智能體的行為：運(yùn)行速度、恢復(fù)能力，以及可擴(kuò)展的極限。

在 Manus，我們通過一次次重寫、走進(jìn)死胡同，以及在數(shù)百萬用戶中的真實(shí)測試，才悟出這些經(jīng)驗(yàn)。我們在此分享的內(nèi)容并非放之四海而皆準(zhǔn)的真理，但它們是我們驗(yàn)證有效的模式。如果它們能幫你少走哪怕一次痛苦的迭代，這篇帖子就值了。

智能體的未來，將靠一個(gè)個(gè)上下文逐步構(gòu)建。請把它們設(shè)計(jì)好。