在爆火僅四個月后，Manus AI 突然幾乎全面撤出中國市場，不僅清空全部社交賬號內容，而且國行版本的 Manus 也疑似暫停推進。

早在上個月，Manus 聯合創始人張濤便曾宣布，公司已將全球總部遷至新加坡，并在東京和加州設有辦公室。盡管官方未正面回應，只稱是「基于經營效率的調整」，但出海所引發裁員等一連串爭議問題，也讓外界普遍猜測其是否正在「跑路」。

風波之中，今天凌晨，Manus 聯合創始人季逸超發布了一篇技術博客，試圖將外界關注點重新拉回產品技術本身。

經過四次重構和數百萬真實交互，他在文中坦誠地總結了團隊在構建 Manus 過程中積累的經驗教訓。內容既有實操干貨，也不乏反思，對業內同行與普通用戶來說，都不失為一份值得一讀的參考材料。

技術博客地址：https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

省流版：

1. 押注上下文，不再訓練模型
與其耗時訓練，不如圍繞大模型構造「記憶」和流程。上下文工程讓你在幾小時而不是幾周內發布產品更新。

2. KV-Cache 命中率至關重要
輸入越穩定，緩存命中率越高，成本和延遲越低。三條實戰建議：
- 避免提示中使用時間戳；
- 只追加上下文，避免修改歷史記錄；
- 手動標記緩存斷點，保障前綴一致性。

3. 工具不要動態添加，而是用「遮蔽」法控制選擇
動態修改工具列表會讓緩存失效、模型混亂。Manus 使用「遮蔽 token logits」的方法，讓模型「看不見」不應調用的工具。

4. 用文件系統承載持久上下文
大模型上下文再長也會被打滿。Manus 讓模型把長期記憶寫入虛擬文件系統，按需讀寫，實現「外部記憶」，規避信息丟失。

5. 重寫 ToDo 清單，是操控注意力的重要方法
模型容易「中途忘記目標」。Manus 會不斷用自然語言更新并重述 todo.md 文件，把全局目標拉回注意力焦點，防止任務跑偏。

6. 錯誤不是要掩蓋，而是要保留
失敗是構建 Agent 過程中的一部分。保留錯誤日志（如失敗的操作、堆棧信息），能幫助模型更新內部信念，減少重復錯誤。

7. 少樣本提示不是靈丹妙藥，要防「同質化陷阱」
模型會盲目模仿上下文中的行為模式。Manus 通過引入結構化變化（如不同措辭或順序），避免模型在長任務中陷入復制粘貼式幻覺。

AI Agent 的上下文工程：從構建 Manus 中學到的經驗

在 Manus 項目的最初階段，我和我的團隊面臨一個關鍵決定：我們應該使用開源基礎模型訓練一個端到端的 Agent，還是基于前沿模型的上下文學習能力構建一個 Agent？

在我從事 NLP 的第一個十年，我們沒有這種選擇的奢侈。在遙遠的 BERT 時代（是的，已經過去七年了），模型必須先進行微調——并評估——才能轉移到新任務。這個過程通常每次迭代需要數周時間，即使與今天的 LLM 相比，這些模型都很小。對于快速發展的應用，特別是在產品市場契合度（PMF）之前，這種緩慢的反饋循環是一個致命問題。

這是我上一個創業公司的慘痛教訓，我從頭開始為開放信息提取和語義搜索訓練模型。然后 GPT-3 和 Flan-T5 出現了，我的內部模型一夜之間變得無關緊要。諷刺的是，這些相同的模型標志著上下文學習的開始——以及一條全新的前進道路。

這個來之不易的教訓使選擇變得明確：Manus 將押注于上下文工程。這使我們能夠在幾小時內而非幾周內推出改進，并使我們的產品與底層模型保持正交：如果模型進步是上漲的潮水，我們希望 Manus 成為那條船，而不是固定在海床上的柱子。

然而，上下文工程證明并非那么直截了當。它是一門實驗科學——我們已經重建了我們的 Agent 框架四次，每次都是在發現了更好的塑造上下文的方式之后。我們親切地將這種手動架構搜索、提示調整和經驗猜測的過程稱為「隨機研究生下降法」。它不夠優雅，但很有效。

這篇文章分享了我們通過自己的「SGD」所達到的局部最優解。如果你正在構建自己的 AI Agent，我希望這些原則能幫助你更快地收斂。

圍繞 KV-Cache 進行設計

如果我必須選擇僅一個指標，我認為 KV-cache 命中率是生產階段 AI Agent最重要的單一指標。它直接影響延遲和成本。為了理解原因，讓我們看看典型 Agent 如何運作：

在接收用戶輸入后，Agent 通過一系列工具使用來完成任務。在每次迭代中，模型根據當前上下文從預定義的動作空間中選擇一個動作。然后該動作在環境（例如，Manus 的虛擬機沙盒）中執行以產生觀察結果。動作和觀察結果被附加到上下文中，形成下一次迭代的輸入。這個循環持續直到任務完成。

正如你可以想像，上下文隨著每一步而增長，而輸出——通常是結構化的函數調用——保持相對簡短。這使得Agent 程序中的預填充和解碼比例與聊天機器人相比高度傾斜。例如，在 Manus 中，平均輸入與輸出 token 比率約為 100:1。

幸運的是，具有相同前綴的上下文可以利用 KV-cache，這大大減少了首個 token 的時間 (TTFT) 和推理成本——無論你使用的是自托管模型還是調用推理 API。我們談論的不是小額節省：以 Claude Sonnet 為例，緩存的輸入 token 成本為 0.30 美元/MTok(每百萬 token)，而未緩存的成本為 3 美元/MTok——相差 10 倍。

從上下文工程的角度來看，提高 KV-緩存命中率涉及幾個關鍵實踐：

1.

保持提示前綴穩定。 由于 LLM 的自回歸特性，即使單個標記的差異也會使該標記之后的緩存失效。一個常見的錯誤是在系統提示的開頭包含時間戳——尤其是精確到秒的時間戳。沒錯，它可以讓模型告訴你當前時間，但它也會降低你的緩存命中率。

2.

使你的上下文僅追加。 避免修改先前的操作或觀察。確保你的序列化是確定性的。許多程式語言和庫在序列化 JSON 對象時不保證穩定的鍵排序，這可能會悄悄破壞緩存。

3.

在需要時明確標記緩存斷點。 某些模型提供商或推理框架不支持自動增量前綴緩存，而是需要在上下文中手動插入緩存斷點。在分配這些斷點時，要考慮潛在的緩存過期，并至少確保斷點包含系統提示的結尾。

此外，如果你正在使用 vLLM 等框架自托管模型，請確保啟用前綴/提示緩存，并且你正在使用會話 ID 等技術來一致地路由分布式工作節點間的請求。

遮蔽，而非移除

隨著你的 Agent 獲得更多能力，其行動空間自然變得更加復雜——簡單來說，工具數量爆炸性增長。最近流行的 MCP 只會火上澆油。如果你允許用戶配置工具，相信我：總會有人不可避免地將數百個神秘工具插入到你精心策劃的行動空間中。結果，模型更可能選擇錯誤的行動或采取低效的路徑。簡而言之，你的全副武裝的 Agent 變得更笨了。

一個自然的反應是設計一個動態行動空間——也許使用類似 RAG 的東西按需加載工具。我們在 Manus 中也嘗試過這種方法。但我們的實驗表明一個明確的規則：除非絕對必要，避免在迭代過程中動態添加或移除工具。這主要有兩個原因：

1. 在大多數 LLMs 中，工具定義在序列化后位于上下文的前部，通常在系統提示之前或之后。因此，任何更改都將使所有后續操作和觀察的 KV-緩存失效。

2. 當先前的操作和觀察仍然引用在當前上下文中不再定義的工具時，模型會變得困惑。沒有約束解碼，這通常會導致模式違規或幻覺行為。

為了解決這個問題，同時仍然改進行動選擇，Manus 使用上下文感知的狀態機來管理工具可用性。它不是移除工具，而是遮蔽 token logits，在解碼過程中防止（或強制）基于當前上下文選擇某些行動。

在實踐中，大多數模型提供者和推理框架支持某種形式的回應前綴預填充，這允許你在不修改工具定義的情況下限制動作空間。通常有三種函數調用模式（我們將使用來自 NousResearch 的 Hermes 格式作為例子）：

?自動 – 模型可以選擇調用函數或不調用。通過僅預填充回復前綴來實現：

<|im_start|>assistant

?必需 – 模型必須調用函數，但選擇不受限制。通過預填充到工具調用標記來實現：

<|im_start|>assistant

?指定 – 模型必須從特定子集中調用函數。通過預填充到函數名稱的開頭來實現：

<|im_start|>assistant{「name」: "browser_

使用這個，我們通過直接遮蔽 token 的 logits 來限制動作選擇。例如，當用戶提供新輸入時，Manus 必須立即回復而不是采取動作。我們還特意設計了具有一致前綴的動作名稱——例如，所有與瀏覽器相關的工具都以 browser_開頭，命令行工具則以 shell_開頭。這使我們能夠輕松地強制 Agent 在給定狀態下只從某個特定工具組中進行選擇，而無需使用有狀態的 logits 處理器。

這些設計有助于確保 ManusAgent 循環保持穩定——即使在模型驅動的架構下。

使用文件系統作為上下文

現代前沿大語言模型現在提供 128K 個 token 或更多的上下文窗口。但在真實世界的 Agent 場景中，這通常不夠，有時甚至是一種負擔。有三個常見的痛點：

1. 觀察可能非常龐大，尤其是當 Agent 與網頁或 PDF 等非結構化數據互動時。很容易超過上下文限制。

2. 模型性能往往會下降，超過一定的上下文長度后，即使技術上支援該窗口大小。

3. 長輸入成本高昂，即使使用前綴緩存。你仍需要為傳輸和預填充每個標記付費。

為了解決這個問題，許多 Agent 系統實現了上下文截斷或壓縮策略。但過度激進的壓縮不可避免地導致信息丟失。這個問題是根本性的：Agent 本質上必須基于所有先前狀態預測下一個動作——而你無法可靠地預測哪個觀察可能在十步之后變得至關重要。從邏輯角度看，任何不可逆的壓縮都帶有風險。

這就是為什么我們在 Manus 中將文件系統視為最終上下文：大小不受限制，本質上持久存在，并且可由 Agent 自身直接操作。模型學會按需寫入和讀取文件——不僅將文件系統用作儲存，還用作結構化的外部記憶。

我們的壓縮策略始終設計為可恢復的。例如，只要保留 URL，網頁的內容就可以從上下文中刪除，如果沙盒中仍然有文件路徑，則可以省略文件的內容。這使 Manus 能夠縮短上下文長度而不會永久丟失信息。

在開發這個功能時，我發現自己在想像狀態空間模型 (SSM)要在 Agent 環境中有效運作需要什么條件。與 Transformers 不同，SSMs 缺乏完整的注意力機制，并且在處理長距離的向后依賴關系時表現不佳。但如果它們能夠掌握基于文件的記憶——將長期狀態外部化而不是保持在上下文中——那么它們的速度和效率可能會開啟一種新型Agent。基于 Agent 的 SSMs 可能是神經圖靈機的真正繼承者。

通過復述操控注意力

如果你使用過 Manus，你可能注意到一個有趣的現象：在處理復雜任務時，它傾向于創建一個 todo.md 文件——并在任務進行過程中逐步更新它，勾選已完成的項目。

這不僅僅是可愛的行為——這是一種操控注意力的刻意機制。

Manus 中的典型任務平均需要大約 50 次工具調用。這是一個很長的循環——由于 Manus 依賴 LLM 進行決策，它很容易偏離主題或忘記早期目標，尤其是在長上下文或復雜任務中。

通過不斷重寫待辦事項列表，Manus 將其目標重述到上下文的末尾。這將全局計劃推入模型的近期注意力范圍，避免了「迷失在中間」的問題，并減少了目標錯位。實際上，它正在使用自然語言來使自己的焦點偏向任務目標——而無需特殊的架構更改。

保留錯誤的內容

Agent 會犯錯。這不是一個錯誤—這是現實。語言模型會產生幻覺，環境會返回錯誤，外部工具會出現異常，而意外的邊緣情況隨時都會出現。在多步驟任務中，失敗不是例外；它是循環的一部分。

然而，一個常見的沖動是隱藏這些錯誤：清理追蹤記錄，重試動作，或重置模型的狀態，并將其留給神奇的「溫度」。這感覺更安全，更受控制。但這是有代價的：抹去失敗會移除證據。而沒有證據，模型就無法適應。

在我們的經驗中，改善 Agent 行為最有效的方法之一出奇地簡單：將錯誤嘗試保留在上下文中。當模型看到失敗的行動——以及由此產生的觀察結果或堆棧跟蹤——它會隱式地更新其內部信念。這會使其先驗遠離類似的行動，減少重復相同錯誤的可能性。

事實上，我們相信錯誤恢復是真正 Agent 行為的最清晰指標之一。然而，在大多數學術工作和公開基準測試中，這一點仍然代表性不足，這些測試通常關注理想條件下的任務成功。

不要被少樣本提示所困

少樣本提示是提高 LLM 輸出的常見技術。但在 Agent 系統中，它可能以微妙的方式適得其反。

語言模型是優秀的模仿者；它們模仿上下文中的行為模式。如果你的上下文充滿了類似的過去行動-觀察對，模型將傾向于遵循該模式，即使它不再是最優的。

這在涉及重復決策或行動的任務中可能很危險。例如，當使用 Manus 幫助審查 20 份簡歷時，Agent 常常會陷入一種節奏——僅僅因為這是它在上下文中看到的內容而重復類似的行動。這導致偏移、過度泛化，或有時出現幻覺。

解決方法是增加多樣性。Manus 在行動和觀察中引入少量的結構化變化——不同的序列化模板、替代措辭、順序或格式的微小噪聲。這種受控的隨機性有助于打破模式并調整模型的注意力。

換句話說，不要讓自己陷入少量樣本的窠臼。你的上下文越統一，你的 Agent 就越脆弱。

結論

上下文工程仍然是一門新興科學——但對于 Agent 系統來說，它已經是必不可少的。模型可能變得更強大、更快速、更便宜，但再多的原始能力也無法取代對記憶、環境和反饋的需求。你如何塑造上下文最終定義了你的 Agent 的行為方式：它運行的速度、恢復的效果以及擴展的程度。

在 Manus，我們通過反復重寫、死胡同和跨數百萬用戶的真實世界測試學到了這些教訓。我們在這里分享的內容并非普遍真理——但這些是對我們有效的模式。如果它們能幫助你避免哪怕一次痛苦的迭代，那么這篇文章就達到了它的目的。

Agent 化的未來將取決于一次次對上下文的精雕細琢。好好設計它們吧。

歡迎加入 APPSO AI 社群，一起暢聊 AI 產品，獲取，解鎖更多 AI 新知

我們正在招募伙伴

簡歷投遞郵箱hr@ifanr.com

?? 郵件標題「姓名+崗位名稱」（請隨簡歷附上項目/作品或相關鏈接）