1. 首頁 > 生活百科 > >

Manus“刪博、裁員、跑路新加坡”后，創始人首次復盤經驗教訓

斷點新加坡裁員manus

Manus“刪博、裁員、跑路新加坡”后，創始人首次復盤經驗教訓

文章圖片

Manus“刪博、裁員、跑路新加坡”后，創始人首次復盤經驗教訓

文章圖片

Manus“刪博、裁員、跑路新加坡”后，創始人首次復盤經驗教訓

文章圖片

Manus“刪博、裁員、跑路新加坡”后，創始人首次復盤經驗教訓

文章圖片

Manus“刪博、裁員、跑路新加坡”后，創始人首次復盤經驗教訓



作者 林易
編輯 重點君
從全球爆火 ， 到成功融資 ， 再到被曝刪博、裁員、跑路新加坡 ， Manus僅僅用了四個月 ， 就把一條新興賽道的創業演示了個遍 。
有人認為Manus開了一個很壞的頭 ， 利用中國工程師資源打造產品 ， 迅速融資 ， 裁員跑路......
在一片爭議聲中 ， 今天凌晨 ， 這家公司的聯合創始人季逸超罕見發聲 ， 發布了長達數千字的博客 ， 試圖把輿論拉回到產品和技術本身 ， 也第一次公開回應了這場起落背后的關鍵教訓 。

四個月從爆火到爭議
我們先簡單回顧一下 。 今年3月 ， Manus因“全球首個通用Agent”概念走紅 ， 當時有人說這是中國的“第二個DeepSeek時刻” 。
5月 ， Manus很快完成由硅谷頂級風投Benchmark領投的7500萬美元B輪融資 ， 估值飆升至5億美元 。 外界對它的一度期待極高 。
但6月底 ， Manus突然被媒體曝出多起爭議事件：部分員工稱被無預警裁員、創始團隊在社交平臺上大規模刪博、公司主體搬到新加坡 ， 輿論嘩然 。
一時間 ， 刪博、裁員、跑路 ， 成了這家明星Agent創業公司的主要標簽 。

聯合創始人凌晨發長文
面對外界質疑 ， 季逸超這次選擇用一篇技術向的長文作答 ， 首次系統總結了團隊對Agent產品和技術的核心認知：
1、選擇上下文工程 ， 而非端到端自研大模型 。 Manus創始人上一家公司曾嘗試從零訓練NLP模型 ， 結果被GPT-3等大模型淘汰 。 這次復盤后 ， 他們選擇不再自研底層模型 ， 而是專注于如何基于開源或商業大模型 ， 做“上下文工程” ， 把現有能力最大化發揮出來 。
2、KV緩存命中率是代理系統的核心指標 。 多輪智能代理與單輪聊天不同 ， 輸入輸出比可能高達100:1 ， 長輸入會極大影響延遲和推理成本 。 上下文設計的目標是最大化KV緩存命中率 ， 這要求提示要穩定、上下文只追加不修改、保證前綴可重復利用 。
3、工具管理避免動態增減 ， 用遮蔽代替刪除 。 代理功能多 ， 動作空間會迅速擴大 ， 模型更易選錯 。 動態添加或刪除工具會導致緩存失效 。 Manus的實踐是用上下文狀態機管理工具可用性：通過屏蔽Token概率 ， 而非直接從上下文移除 ， 既保證靈活性 ， 又保留緩存 。
4、把文件系統當作無限上下文 。 大模型上下文窗口再大也有限 ， 且超長上下文會拉低推理速度、抬高成本 。 Manus做法是把文件系統當作代理的外部記憶 ， 信息可隨時存取 ， 保證歷史狀態可查、可讀寫、可恢復 。
5、用顯式“背誦”機制操控模型注意力 。 在長任務中 ， Manus會自動生成todo.md ， 把任務拆解成可執行清單 ， 并不斷更新 ， 把目標重復寫到上下文末尾 ， 相當于“反復提醒模型” ， 避免任務中途跑偏 。
6、不抹掉錯誤 ， 保留失敗信息以幫助模型自我修正 。 智能體必然會出錯 ， 與其隱藏錯誤、重新開始 ， 不如把失敗信息留在上下文里 ， 讓模型“看到”失敗路徑 ， 形成負面示例 ， 從而減少同類錯誤 。
7、一句話總結就是：上下文工程是一門新興的實驗科學 ， Manus想用上下文塑造代理的行為和能力：不是比拼模型多聰明 ， 而是比拼怎么讓模型更有用 。

復盤之外 ， 爭議未平息
從這篇博客看得出 ， Manus并非完全是個“PPT項目” 。 它確實做了不少面向Agent場景的底層探索 ， 也踩過不少坑 。
但這篇長文沒提到外界最關心的問題：公司為什么要搬去新加坡？國內被裁員工如何善后？等等 。
這些問題 ， 季逸超沒有回答 ， 博客里也沒提 。
季逸超在結尾寫道：“智能代理的未來將由一個個情境逐步構建 。 精心設計每一個情境 。 ”
當下的現實是 ， Manus是否還有機會把這些“情境”從技術文檔帶回真正的用戶手里？
一切仍未有定論 。
博文鏈接：
https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus


以下為Manus 聯合創始人季逸博客原文（由GPT翻譯）：
面向AI 代理的上下文工程：構建 Manus 的經驗教訓
2025 年 7 月 18 日 季逸超
在Manus 項目伊始 ， 我和團隊面臨一個關鍵抉擇：是使用開源基礎模型訓練一個端到端的代理模型 ， 還是基于前沿模型的上下文學習能力構建代理？
回想我在自然語言處理領域的最初十年 ， 我們沒有這樣的選擇余地 。 在BERT 的遠古時代（是的 ， 已經七年了） ， 模型必須經過微調并評估后才能遷移到新任務 。 即使當時的模型遠小于如今的 LLMs ， 這一過程每次迭代往往也需數周 。 對于快速發展的應用 ， 尤其是產品市場匹配前期 ， 這樣緩慢的反饋周期是致命的 。 這是我上一家創業公司的慘痛教訓 ， 當時我從零開始訓練模型用于開放信息抽取和語義搜索 。 隨后 GPT-3 和 Flan-T5 的出現 ， 讓我自研的模型一夜之間變得無關緊要 。 諷刺的是 ， 正是這些模型開啟了上下文學習的新紀元——也為我們開辟了一條全新的前進道路 。
這個來之不易的教訓讓選擇變得清晰：Manus 將押注于上下文工程 。 這使我們能夠在數小時內發布改進 ， 而不是數周 ， 同時保持我們的產品與底層模型正交：如果模型進步是漲潮 ， 我們希望 Manus 是船 ， 而不是固定在海床上的柱子 。
然而 ， 上下文工程遠非簡單 。 這是一門實驗科學——我們已經重建了四次代理框架 ， 每次都是在發現了更好的上下文塑造方法之后 。 我們親切地稱這種手動的架構搜索、提示調整和經驗猜測過程為“隨機梯度下降” 。 它不優雅 ， 但有效 。
這篇文章分享了我們通過自己的“SGD”達到的局部最優解 。 如果你正在構建自己的 AI 代理 ， 希望這些原則能幫助你更快收斂 。

圍繞KV 緩存設計
如果只能選擇一個指標 ， 我認為KV 緩存命中率是生產階段 AI 代理最重要的指標 。 它直接影響延遲和成本 。 要理解原因 ， 我們先看看典型代理的工作方式：
在接收到用戶輸入后 ， 代理通過一系列工具調用來完成任務 。 在每次迭代中 ， 模型根據當前上下文從預定義的動作空間中選擇一個動作 。 然后在環境中執行該動作（例如Manus 的虛擬機沙箱） ， 以產生觀察結果 。 動作和觀察結果被追加到上下文中 ， 形成下一次迭代的輸入 。 這個循環持續進行 ， 直到任務完成 。
正如你所想象的 ， 上下文隨著每一步增長 ， 而輸出——通常是結構化的函數調用——則相對較短 。 這使得預填充與解碼之間的比例在代理中遠遠偏高 ， 區別于聊天機器人 。 例如 ， 在 Manus 中 ， 平均輸入與輸出的Token比約為100:1 。
幸運的是 ， 具有相同前綴的上下文可以利用KV 緩存 ， 這大大減少了首次生成標記時間（TTFT）和推理成本——無論你是使用自托管模型還是調用推理 API 。 這里的節省可不是小數目：以 Claude Sonnet 為例 ， 緩存的輸入標記費用為 0.30 美元/千標記 ， 而未緩存的則為 3 美元/千標記——相差 10 倍 。

從上下文工程的角度來看 ， 提高KV 緩存命中率涉及幾個關鍵做法：
保持提示前綴穩定 。 由于LLMs 的自回歸特性 ， 即使是單個標記的差異也會使該標記及其之后的緩存失效 。 一個常見錯誤是在系統提示開頭包含時間戳——尤其是精確到秒的時間戳 。 雖然這樣可以讓模型告訴你當前時間 ， 但也會大幅降低緩存命中率 。
使你的上下文僅追加 。 避免修改之前的操作或觀察 。 確保你的序列化是確定性的 。 許多編程語言和庫在序列化JSON 對象時不保證鍵的順序穩定 ， 這可能會悄無聲息地破壞緩存 。
在需要時明確標記緩存斷點 。 一些模型提供商或推理框架不支持自動增量前綴緩存 ， 而是需要在上下文中手動插入緩存斷點 。 設置這些斷點時 ， 應考慮緩存可能過期的情況 ， 至少確保斷點包含系統提示的結尾部分 。
此外 ， 如果你使用像vLLM 這樣的框架自托管模型 ， 確保啟用了前綴/提示緩存 ， 并且使用會話 ID 等技術在分布式工作節點間一致地路由請求 。

遮蔽 ， 而非移除
隨著你的智能體功能不斷增強 ， 其動作空間自然變得更加復雜——簡單來說 ， 就是工具數量激增 。 最近 MCP 的流行更是火上澆油 。 如果允許用戶自定義工具 ， 相信我：總會有人將數百個神秘工具接入你精心策劃的動作空間 。 結果 ， 模型更可能選擇錯誤的動作或走低效路徑 。 簡而言之 ， 你的重裝智能體反而變得更笨 。
一種自然的反應是設計動態動作空間——或許使用類似 RAG 的方式按需加載工具 。 我們在 Manus 中也嘗試過 。 但實驗表明一個明確的規則：除非絕對必要 ， 避免在迭代過程中動態添加或移除工具 。 主要有兩個原因：
在大多數LLMs 中 ， 工具定義在序列化后通常位于上下文的前部 ， 通常在系統提示之前或之后 。 因此 ， 任何更改都會使所有后續操作和觀察的 KV 緩存失效 。
當之前的操作和觀察仍然引用當前上下文中不再定義的工具時 ， 模型會感到困惑 。 如果沒有受限解碼 ， 這通常會導致模式違規或幻覺操作 。
為了解決這一問題 ， 同時提升動作選擇的效果 ， Manus 使用了一個上下文感知的狀態機來管理工具的可用性 。 它不是移除工具 ， 而是在解碼過程中屏蔽Token的對數概率 ， 以根據當前上下文防止（或強制）選擇某些動作 。

在實際操作中 ， 大多數模型提供商和推理框架都支持某種形式的響應預填充 ， 這使你可以在不修改工具定義的情況下限制動作空間 。 函數調用通常有三種模式（我們以NousResearch 的 Hermes 格式為例）：
自動– 模型可以選擇是否調用函數 。 通過僅預填回復前綴實現：|im_start|assistant
【Manus“刪博、裁員、跑路新加坡”后，創始人首次復盤經驗教訓】必需——模型必須調用一個函數 ， 但選擇不受限制 。 通過預填充到工具調用標記實現：|im_start|assistanttool_call
指定——模型必須從特定子集中調用函數 。 通過預填充到函數名開頭實現：|im_start|assistanttool_call{\"name\": “browser_
利用此方法 ， 我們通過直接屏蔽標記的對數概率來限制動作選擇 。 例如 ， 當用戶提供新輸入時 ， Manus 必須立即回復 ， 而不是執行動作 。 我們還特意設計了具有一致前綴的動作名稱——例如 ， 所有與瀏覽器相關的工具都以 browser_開頭 ， 命令行工具以 shell_開頭 。 這使我們能夠輕松確保代理在特定狀態下僅從某一組工具中選擇 ， 而無需使用有狀態的對數概率處理器 。
這些設計有助于確保Manus 代理循環保持穩定——即使在模型驅動架構下也是如此 。

將文件系統用作上下文
現代前沿的LLMs 現在提供 128K Token或更多的上下文窗口 。 但在現實世界的智能代理場景中 ， 這通常不夠 ， 有時甚至成為負擔 。 有三個常見的痛點：
觀察內容可能非常龐大 ， 尤其是當代理與網頁或PDF 等非結構化數據交互時 。 很容易超出上下文限制 。
即使窗口技術上支持 ， 模型性能在超過某個上下文長度后往往會下降 。
長輸入代價高昂 ， 即使使用前綴緩存也是如此 。 你仍然需要為傳輸和預填充每個標記付費 。
為了解決這個問題 ， 許多智能體系統實施了上下文截斷或壓縮策略 。 但過度壓縮不可避免地導致信息丟失 。 問題是根本性的：智能體本質上必須基于所有先前狀態來預測下一步動作——而你無法可靠地預測哪條觀察在十步之后可能變得關鍵 。 從邏輯角度看 ， 任何不可逆的壓縮都存在風險 。
這就是為什么我們將文件系統視為Manus 中的終極上下文：大小無限 ， 天生持久 ， 并且可以由智能體自身直接操作 。 模型學會按需寫入和讀取文件——不僅將文件系統用作存儲 ， 更作為結構化的外部記憶 。

我們的壓縮策略始終設計為可恢復的 。 例如 ， 只要保留網址 ， 網頁內容就可以從上下文中刪除；只要沙盒中仍有文檔路徑 ， 文檔內容也可以省略 。 這使得Manus 能夠縮短上下文長度而不永久丟失信息 。
在開發此功能時 ， 我不禁想象 ， 狀態空間模型（SSM）要在具代理性的環境中有效工作需要什么條件 。 與 Transformer 不同 ， SSM 缺乏完全的注意力機制 ， 難以處理長距離的向后依賴 。 但如果它們能掌握基于文件的記憶——將長期狀態外部化而非保存在上下文中——那么它們的速度和效率可能會開啟新一代代理 。 具代理性的 SSM 或許才是神經圖靈機的真正繼任者 。

通過背誦操控注意力
如果你使用過Manus ， 可能會注意到一個有趣的現象：在處理復雜任務時 ， 它傾向于創建一個 todo.md 文件 ， 并隨著任務的推進逐步更新 ， 勾選已完成的事項 。
這不僅僅是可愛的行為——這是一種有意操控注意力的機制 。

Manus 中的一個典型任務平均需要大約 50 次工具調用 。 這是一個較長的循環——由于 Manus 依賴 LLMs 進行決策 ， 因此在長上下文或復雜任務中 ， 容易偏離主題或忘記之前的目標 。
通過不斷重寫待辦事項清單 ， Manus 將其目標反復寫入上下文末尾 。 這將全局計劃推入模型的近期注意力范圍 ， 避免了“中途丟失”問題 ， 減少了目標不一致的情況 。 實際上 ， 它利用自然語言來引導自身關注任務目標——無需特殊的架構改動 。

保留錯誤信息
智能體會犯錯 。 這不是漏洞——這是現實 。 語言模型會產生幻覺 ， 環境會返回錯誤 ， 外部工具會出現異常 ， 意外的邊緣情況時常發生 。 在多步驟任務中 ， 失敗不是例外；它是循環的一部分 。
然而 ， 一個常見的沖動是隱藏這些錯誤：清理痕跡 ， 重試操作 ， 或重置模型狀態 ， 寄希望于神奇的“溫度”參數 。 這看起來更安全、更可控 。 但這付出了代價：抹去失敗就抹去了證據 。 沒有證據 ， 模型就無法適應 。

根據我們的經驗 ， 改善智能體行為的最有效方法之一看似簡單：在上下文中保留錯誤的路徑 。 當模型看到失敗的操作及其產生的觀察結果或堆棧跟蹤時 ， 它會隱式地更新內部信念 。 這會使其先驗偏離類似的操作 ， 從而減少重復同樣錯誤的可能性 。
事實上 ， 我們認為錯誤恢復是衡量真正智能體行為的最明確指標之一 。 然而 ， 在大多數學術研究和公開基準測試中 ， 這一指標仍然被忽視 ， 這些研究和測試通常側重于理想條件下的任務成功率 。

避免被少量示例限制
少量示例提示是提升LLM 輸出的常用技巧 。 但在智能體系統中 ， 它可能以微妙的方式適得其反 。
語言模型擅長模仿；它們會復制上下文中的行為模式 。 如果你的上下文充滿了類似的過去動作-觀察對 ， 模型往往會遵循這種模式 ， 即使這已不再是最優選擇 。
在涉及重復決策或操作的任務中 ， 這可能會帶來危險 。 例如 ， 在使用Manus 幫助審查一批 20 份簡歷時 ， 代理經常陷入一種節奏——僅僅因為上下文中出現了類似內容 ， 就重復執行相似的操作 。 這會導致偏離、過度泛化 ， 甚至有時產生幻覺 。

解決方法是增加多樣性 。 Manus 在動作和觀察中引入少量結構化的變化——不同的序列化模板、替代表達、順序或格式上的細微噪聲 。 這種受控的隨機性有助于打破模式 ， 調整模型的注意力 。
換句話說 ， 不要讓少量示例把自己限制在固定模式中 。 上下文越統一 ， 代理就越脆弱 。
結論
上下文工程仍是一門新興科學——但對于代理系統來說 ， 它已經至關重要 。 模型可能變得更強大、更快速、更廉價 ， 但再強的原始能力也無法替代記憶、環境和反饋的需求 。 你如何塑造上下文 ， 最終決定了代理的行為：運行速度、恢復能力以及擴展范圍 。
在Manus ， 我們通過反復重寫、走過死胡同以及在數百萬用戶中的實際測試 ， 學到了這些經驗 。 我們在這里分享的內容并非普遍真理 ， 但這些是對我們有效的模式 。 如果它們能幫助你避免哪怕一次痛苦的迭代 ， 那么這篇文章就達到了它的目的 。
智能代理的未來將由一個個情境逐步構建 。 精心設計每一個情境 。

    推薦閱讀