IT之家 7 月 19 日消息，前段時間，IT之家報道了 AI 智能體平臺 Manus 被曝裁員、清空國內多平臺賬號等消息。北京時間今天早些時候，Manus 聯合創始人季逸超通過官方博客發布了上千字的技術解析長文，復盤公司從今年年初爆火至今歷經“起起落落”的開發思路與教訓。

今年 3 月，由國內 Monica 團隊研發推出的 Manus 在海外社交平臺推出，Manus 號稱是全球首款通用智能體（Agent），可獨立解決復雜任務。在通用 AI 助手基準測試 GAIA 的全部難度級別中的評分甚至遠遠超越 OpenAI 的 DeepResearch。Manus 放出的演示視頻中展現出的驚艷表現，瞬間引爆用戶熱情，但是 Manus 僅限邀請體驗，渴望第一時間體驗 Manus 的用戶在海內外各大社區平臺紛紛留言“求邀請碼”，這也讓 Manus 一炮而紅，刷屏社交平臺。

IT之家附博客文章大意如下：

在 Manus 項目的最初階段，我和我的團隊面臨著一個關鍵的決定：我們應該使用開源基礎來訓練一個端到端的 Agentic 模型，還是在前沿模型的上下文學習能力之上構建一個 Agent？ 回想我在 NLP 領域的第一個十年，我們沒有這種選擇的余地。在遙遠的 BERT 時代（是的，已經七年了），模型必須經過微調和評估，才能轉移到新的任務。即使與今天的 LLMs 相比，當時的模型非常小，但這個過程通常每次迭代都需要幾周時間。對于快速發展的應用，尤其是在達到 PMF 之前，如此緩慢的反饋循環是不可接受的。這是我上次創業時的一個慘痛教訓，當時我從頭開始訓練模型，用于開放信息提取和語義搜索。后來出現了 GPT-3 和 Flan-T5，我的內部模型一夜之間變得無關緊要。具有諷刺意味的是，這些模型標志著上下文學習的開始，以及一條全新的前進道路。 那次來之不易的教訓讓我們明確了選擇：Manus 將押注于上下文工程。這使我們能夠在幾個小時內交付改進，而不是幾周，并使我們的產品與底層模型正交：如果模型進步是漲潮，我們希望 Manus 成為船，而不是卡在海底的柱子。 盡管如此，上下文工程的結果遠非簡單。這是一門實驗科學 —— 我們已經重建了四次 Agent 框架，每次都是在發現塑造上下文的更好方法之后。我們親切地將這種架構搜索、提示調整和經驗猜測的手動過程稱為“隨機梯度下降”。它并不優雅，但它有效。 這篇文章分享了我們通過自己的“SGD”達到的局部最優解。如果您正在構建自己的 AI Agent，我希望這些原則能幫助您更快地收斂。圍繞 KV 緩存進行設計 如果我必須選擇一個指標，我會認為 KV 緩存命中率是生產階段 AI Agent 最重要的指標。它直接影響延遲和成本。要理解為什么，讓我們看看一個典型的 Agent 是如何運作的： 在收到用戶輸入后，Agent 會通過一系列工具的使用來完成任務。在每次迭代中，模型都會根據當前上下文從預定義的動作空間中選擇一個動作。然后，該動作在環境（例如，Manus 的虛擬機沙箱）中執行，以產生一個觀察結果。動作和觀察結果被附加到上下文中，形成下一次迭代的輸入。這個循環一直持續到任務完成。 正如你可以想象的那樣，上下文隨著每一步的進行而增長，而輸出 —— 通常是一個結構化的函數調用 —— 則相對較短。這使得與聊天機器人相比，Agent 中的預填充和解碼之間的比例高度傾斜。例如，在 Manus 中，平均輸入與輸出的 token 比例約為 100:1。 幸運的是，具有相同前綴的上下文可以利用 KV 緩存，從而大大減少首個令牌生成時間 (TTFT) 和推理成本 —— 無論您使用的是自托管模型還是調用推理 API。而且我們說的不是小幅節?。豪纾褂?Claude Sonnet，緩存的輸入令牌成本為 0.30 美元 / 百萬令牌，而未緩存的令牌成本為 3 美元 / 百萬令牌 —— 相差 10 倍。 從上下文工程的角度來看，提高 KV 緩存命中率涉及以下幾個關鍵實踐： 1. 保持提示前綴的穩定。由于 LLMs 的自回歸特性，即使是單個令牌的差異也會使從該令牌開始的緩存失效。一個常見的錯誤是在系統提示的開頭包含一個時間戳 —— 尤其是精確到秒的時間戳。當然，它可以讓模型告訴你當前時間，但它也會扼殺你的緩存命中率。 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_ 通過這種方式，我們通過直接屏蔽令牌 logits 來約束動作選擇。例如，當用戶提供新的輸入時，Manus 必須立即回復，而不是采取行動。我們還特意設計了具有一致前綴的動作名稱 —— 例如，所有與瀏覽器相關的工具都以 browser_ 開頭，而命令行工具以 shell_ 開頭。這使我們能夠輕松地強制 Agent 僅從給定狀態下的特定工具組中進行選擇，而無需使用有狀態的 logits 處理器。 這些設計有助于確保 Manus Agent 循環保持穩定 —— 即使在模型驅動的架構下也是如此。將文件系統用作上下文 現代前沿 LLMs 現在提供 128K 令牌或更多的上下文窗口。但在實際的 Agent 場景中，這通常是不夠的，有時甚至是一種負擔。有三個常見的痛點： 1.觀察結果可能非常龐大，尤其是在智能體與非結構化數據（如網頁或 PDF）交互時。很容易超出上下文限制。 2.即使窗口在技術上支持，模型性能也往往會隨著上下文長度的增加而下降。 3.即使使用前綴緩存，長輸入也很昂貴。您仍然需要付費傳輸和預填充每個令牌。 為了解決這個問題，許多智能體系統都實現了上下文截斷或壓縮策略。但過度激進的壓縮不可避免地會導致信息丟失。問題是根本性的：智能體本質上必須根據所有先前的狀態來預測下一個動作 —— 而且您無法可靠地預測哪個觀察結果可能在十步之后變得至關重要。從邏輯角度來看，任何不可逆的壓縮都帶有風險。 這就是為什么我們將文件系統視為 Manus 中的終極上下文：大小不受限制，本質上是持久的，并且可以直接由 Agent 操作。模型學習按需寫入和讀取文件 —— 不僅將文件系統用作存儲，還用作結構化的外部化內存。 我們的壓縮策略始終被設計為可恢復的。例如，只要保留 URL，網頁的內容就可以從上下文中刪除；如果文檔的路徑在沙箱中仍然可用，則可以省略文檔的內容。這使得 Manus 能夠在不永久丟失信息的情況下縮短上下文長度。 在開發此功能時，我發現自己想象著狀態空間模型（SSM）如何在 Agent 環境中有效工作。與 Transformer 不同，SSM 缺乏完全的注意力，并且難以處理長期的向后依賴關系。但是，如果他們能夠掌握基于文件的內存 —— 將長期狀態外部化而不是將其保存在上下文中 —— 那么它們的速度和效率可能會開啟一類新的 Agent。Agent SSM 可能是神經圖靈機的真正繼承者。通過背誦來操縱注意力 如果你使用過 Manus，你可能已經注意到一些奇怪的現象：在處理復雜的任務時，它傾向于創建一個 todo.md 文件，并在任務進行過程中逐步更新它，勾選已完成的項目。 這不僅僅是可愛的行為，而是一種有意的操縱注意力的機制。 Manus 中的一個典型任務平均需要大約 50 個工具調用。這是一個很長的循環 —— 而且由于 Manus 依賴 LLMs 進行決策，因此它很容易偏離主題或忘記早期的目標，尤其是在長上下文或復雜的任務中。 通過不斷重寫待辦事項列表，Manus 會將它的目標復述到上下文的末尾。這會將全局計劃推送到模型的近期注意力范圍內，避免“迷失在中間”的問題，并減少目標錯位。實際上，它是在使用自然語言來使其自身的注意力偏向于任務目標 —— 而無需特殊的架構更改。保留錯誤信息 智能體會犯錯。這不是漏洞，而是現實。語言模型會產生幻覺，環境會返回錯誤，外部工具會運行異常，意想不到的極端情況也總是會出現。在多步驟任務中，失敗不是例外，而是循環的一部分。 然而，一種常見的沖動是隱藏這些錯誤：清理痕跡，重試操作，或者重置模型的狀態，并將其交給神奇的“溫度”。這感覺更安全，更可控。但這是有代價的：消除失敗會移除證據。沒有證據，模型就無法適應。 根據我們的經驗，改進智能體行為最有效的方法之一出奇地簡單：將錯誤的轉彎留在上下文中。當模型看到失敗的操作 —— 以及由此產生的觀察或堆棧跟蹤 —— 它會隱式地更新其內部信念。這會使其先驗概率偏離類似的操作，從而減少重復相同錯誤的可能性。事實上，我們認為錯誤恢復是真正智能體行為最清晰的指標之一。然而，它在大多數學術工作和公共基準測試中仍然代表性不足，這些工作和測試通常側重于理想條件下的任務成功。別被速殺了 少樣本提示是提高 LLM 輸出的常用技術。但在 Agent 系統中，它可能會以微妙的方式適得其反。 語言模型是優秀的模仿者；它們模仿上下文中行為的模式。如果你的上下文充滿了相似的過去行動-觀察對，模型就會傾向于遵循該模式，即使它不再是最優的。 這在涉及重復決策或行動的任務中可能很危險。例如，當使用 Manus 幫助審查一批 20 份簡歷時，Agent 通常會陷入一種節奏 —— 重復類似的操作，僅僅是因為它在上下文中看到了這些操作。這會導致漂移、過度概括，有時甚至會出現幻覺。 解決方法是增加多樣性。Manus 在行動和觀察中引入少量結構化的變化 —— 不同的序列化模板、不同的措辭、順序或格式上的細微噪聲。這種受控的隨機性有助于打破模式并調整模型的注意力。換句話說，不要用少量樣本把自己逼入困境。你的上下文越統一，你的 Agent 就越脆弱。結論 上下文工程仍然是一門新興的科學 —— 但對于 Agent 系統來說，它已經至關重要。模型可能變得更強大、更快、更便宜，但再多的原始能力也無法取代對記憶、環境和反饋的需求。你如何塑造上下文最終決定了你的 Agent 的行為方式：它運行的速度、它恢復的程度以及它的擴展程度。 在 Manus，我們通過反復的重寫、死胡同以及數百萬用戶的真實世界測試中吸取了這些教訓。我們在這里分享的都不是普遍真理 —— 但這些是對我們有效的模式。如果它們能幫助你避免哪怕一次痛苦的迭代，那么這篇文章就完成了它的使命。 能動的未來將通過一個個場景構建。好好設計它們。