Manus 被 Meta 以 3 億美元收購後，聯同 LangChain 揭示 AI 代理開發核心原則

Meta 以 3 億美元收購 Manus 嘅消息鬧得滿城風雨，但真正值得關注嘅係 Manus 同 LangChain 聯合演講入面透露嘅內容。呢場分享赤裸裸咁攤開咗開發一個真正行得通嘅 AI 代理背後嘅核心原則 - 同時劃清咗初創公司常犯嘅錯誤同真正有效策略之間嘅界線。

上下文腐化嘅悖論

代理需要工具。工具越多，能力越強。但問題嚟喇：代理用嘅工具越多，上下文就越大 - 而效能會因此直接下降。

Manus 將呢個現象稱為上下文腐化（Context Rot）。呢個係代理開發最核心嘅悖論：令你個代理更強大嘅嘢，同時會令佢變得更蠢。

解決方案係上下文工程（Context Engineering） - 每一步只俾模型睇到佢需要嘅資訊，多一分都唔好。

Manus 提出咗六個具體技巧：

• 卸載（Offload） - 將大量消耗 token 嘅數據搬去檔案系統，唔好放喺上下文入面
• 削減（Reduce） - 積極移除過時嘅資訊
• 壓縮（Compact） - 可逆壓縮可復原嘅數據（例如去掉檔案內容但保留路徑）
• 摘要（Summarize） - 不可逆壓縮資訊，但一定要透過結構化 schema 進行
• 檢索（Retrieve） - 透過搜索按需提供資訊
• 隔離（Isolate） - 用擁有獨立上下文嘅子代理處理

關鍵洞察：上下文管理唔係「有就最好」嘅優化。佢係一個核心架構決策，直接決定你個代理係能夠擴展，定係喺自身重量之下崩潰。

搵到 Product-Market Fit 之前唔好做 Fine-Tune

Manus 指出嘅其中一個最常見嘅初創錯誤：喺搵到產品市場契合之前就去做專用模型。

道理好直接。一個通用模型加上強大嘅上下文工程，可以帶嚟快好多嘅迭代周期。如果你太早做 fine-tune，就會將自己鎖死喺一套仲未經過驗證嘅用戶行為假設入面。

更尖銳嘅一點：你改善模型嘅速度，決定咗你產品創新速度嘅上限。Fine-tuning 會拖慢呢個周期。上下文工程可以保持快速迭代。

先證明產品行得通，之後先做 fine-tuning。喺此之前，呢個係最昂貴嘅過早優化。

多代理模式：兩種截然不同嘅做法

Manus 辨識出兩種基本嘅多代理模式，各自適合唔同類型嘅工作：

通訊模式（Communicating Pattern） - 子代理由零開始。主代理發送一個聚焦嘅請求，子代理獨立處理，然後交返結果。最適合低上下文需求、可並行嘅任務，例如程式碼搜索或數據檢索。

共享記憶模式（Shared Memory Pattern） - 子代理共享完整嘅對話歷史，但用唔同嘅提示詞同工具集運作。最適合複雜、互相依賴嘅任務，例如深度研究 - 每一步都建基於之前嘅發現。

揀邊個唔係關於能力 - 而係關於上下文需求。如果子任務係獨立自足嘅，用通訊模式。如果佢需要完整嘅背景資訊，用共享記憶模式。搞錯嘅話，要麼浪費 token 喺唔必要嘅上下文上，要麼就係餓死代理、令佢得唔到所需嘅資訊。

三層行動空間：防止工具過載

工具太多會搞到模型好混亂。Manus 嘅答案係一個分層架構，限制模型喺任何時刻見到嘅工具數量：

原子層（Atomic Layer） - 10 到 20 個核心能力：讀取、寫入、shell、瀏覽器。呢啲永遠可用，模型直接使用。

沙盒工具（Sandbox Utilities） - 預裝嘅 CLI 工具，例如轉換器、linter 同格式化工具。模型透過 shell 嚟調用呢啲工具，而唔係將佢哋設為專用工具。

套件同 API（Packages and APIs） - 帶有預驗證 API 金鑰嘅 Python 腳本。呢啲處理同外部服務嘅互動，唔使將完整嘅 API 介面暴露俾模型。

呢個分層設計令模型嘅決策空間保持可控。佢唔使喺 200 個工具入面揀，而係喺 15 個核心動作入面揀，其餘嘅就 shell out 處理。結果係更可靠嘅工具選擇，更少混亂或幻覺式嘅工具調用。

重新思考評估指標

GAIA 等公開基準測試反映唔到真實用戶偏好。Manus 嘅立場好直接：黃金標準係用戶對已完成會話嘅評分，由 1 到 5 分。

三個評估原則浮現出嚟：

1. 執行測試優先於問答測試 - 代理能唔能夠喺沙盒入面真正完成任務？呢個比佢識唔識回答有關任務嘅問題更加重要。
2. 主觀質素需要人手審查 - 視覺效果、語氣同整體連貫性冇辦法自動評分。需要有人睇實際輸出。
3. 基準分數必要但不足夠 - 佢哋證明咗基本能力。但佢哋唔能夠證明個產品係好嘅。

核心教訓

過度工程係敵人。

最大嘅效能提升唔係來自增加複雜度 - 而係來自移除複雜度。唔好將模型嘅工作搞到更難。要令佢更簡單。

呢個可能就係 Meta 肯俾 3 億美元買 Manus 嘅原因。唔係因為花巧嘅功能，而係因為一套以本質為核心嘅設計哲學。剝走唔需要嘅嘢、毫不留情咁管理上下文、建立一個令模型可以專注於任務而唔係淹沒喺自身狀態嘅系統。

喺生產環境中行得通嘅代理，唔係擁有最多能力嘅嗰啲。而係令每一項能力都發揮到作用嘅嗰啲。