Manus「刪博跑路」後，創始人首次深度覆盤：公開產品細節，總結教訓 2025-07-19 06:24 APPSO 在爆火僅四個月後，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有用功，解鎖更多 AI 新知👇 我們正在招募夥伴 📮 簡歷投遞郵箱[email protected] ✉️ 郵件標題「姓名+崗位名稱」（請隨簡歷附上專案/作品或相關連結） 更多崗位資訊請點選這裡🔗
