* 本文原創發佈於差評孵化的商業財經類帳號 「 知危 」
就在前天，manus 在國內媒體間爆火，其號稱 「 全球首個通用 ai 智能體 」。
官方也曬出了幾十個demo，供大家玩賞。
網友們驚艷於其效果後當然躍躍欲試，卻發現試用需要邀請碼。我們問了一圈 ai 專家，都說沒用過，也沒聽自己哪個同行用過，「 目前都是媒體在用吧？」
到這裡就需要謹慎了，沒有較大規模公開測試、沒有專家實名自發背書過的技術或產品（ chatgpt、notebooklm、deepseek 等都是有的 ），實力終歸是存疑的。
從產品體驗來看，manus 雖然效果驚艷，但是很多人其實不買賬，因為寫 ppt、寫 html、python 數據分析、生成 excel、搜索等功能目前各個通用模型都能做。即便 manus 說自己比 openai 的 deepresearch 更厲害，但這和 cursor 說自己比 claude 更厲害有什麼區別？兩者的可比性是相對錯位的。
功能上，manus 是整合了 computer use、虛擬機、multi agent 協同的套殼產品。技術實現上是基於 claude 模型生成能力、開源模型後訓練增強的規劃能力，再結合各種預製的 agent，按照設定好的工作流：構建 todo 清單、新建虛擬機環境、調用工具、結果整合、自我檢查、輸出結果，來解決任務。
所以，manus 技術上有其複雜性，但沒有太多創新，當然，其功能多樣性導致工程量極大，業內專家認為很有可能是基於 mcp 協議的聚合模式。
過去 agent 更多是在專業領域做深耕，而 manus 通過工程上極致整合、酷炫低門檻的 ui 交互套殼產品想讓 agent 直接出圈了。
總有人說，套殼到極致就是勝利，就是價值，確實，至少從 manus 的演示視頻來看，是這樣。
既然有價值，那麼很快就會有人跟上，這不，為了實現 manus 的價值，metagpt 團隊花費了 3 小時開發了 openmanus 並開源，無需邀請碼就能使用。
項目地址：
https://github.com/mannaandpoem/openmanus
在項目的演示視頻中，輸入提示詞：「對 karpathy 的網站（ https://karpathy.ai/ ）進行全面的 seo 審核，並提供詳細的優化報告，包括可操作的改進建議。」
接下來，openmanus 會展開思考，拆分執行步驟：
•檢查網站，收集基本信息；
•分析關鍵seo要素；
•檢查 seo 技術方面的問題；
•整理優化建議；
接下來就是一步一步地執行任務了。
可以看到，演示視頻展示的結果遠不如 manus 那麼細緻和豐富，openmanus 目前功能還很初級，但團隊還公開了後續的開發路線，照這個路線，基本上全面復刻 manus 不是問題：
• 更優的規劃系統
• 實時演示功能
• 運行回放
• 強化學習微調模型
• 全面的性能基準測試
：openmanus 是怎麼來的？
：
兩個月前的一次邊吃飯邊頭腦風暴的過程中，我們想到，一個極簡的 agent 框架，應該是可插拔的 tools 和 system prompt 的組合，之後我們沿著這個思路，寫了一個完整的 agent 迷你框架。
前天晚上看到 manus 時，凌晨就和同事商量，下班後的晚上就可以搞一個，應該 3 小時夠了。
：為什麼要採用可插拔的 tools 和 system prompt？
：決定一個 react agent（ reasoning and action agent，一種結合了反應和行動規劃能力的智能體 ）的效果的關鍵是 prompt（ 提示信息 ）和 action（ 行動 ），prompt 控制了 agent 整體的行為邏輯，tools 給定了 agent 的行動空間，二者被定義就能完整詮釋一個 react agent。
可插拔的優點是可組合，我可以把幾個不同場景下的 tools 組合到一起來創造一個新的 agent，定義也很方便，不需要單獨寫內部邏輯，只需要修改動作空間（ tools ）。tools 本身就該是可組合的，我們的工作是把抽象做得更乾淨，目前 huggingface 的 smolagents 也是類似的思路了。
manus 效果上讓大家覺得很新奇，實際上主要是由於 browser use 和 computer use 的使用，所以只要給了 agent 這兩個工具，那它就都能做到。
：openmanus 在實現中，有哪些關鍵技術挑戰？
：在 openmanus 的實現中，前端界面的實現很關鍵。manus 很出彩的地方是產品展示很漂亮，我當時打算用 streamlit 寫前端，方便做類似的展示，但 streamlit 的底層和 browser use 衝突，後來就換了 gradio，但信息展示有一些問題，當時沒辦法做到實時更新，最後還是改成了 log，直接在命令行里做展示。
如何有效復現和優化 planningtool 的使用也是非常重要的一環，這樣才能充分發揮 agent 的規劃和工具調用能力，探索其能力上限。manus 的用例展示了 agent 在線性任務規劃中的強大表現，而 openmanus 需要解決如何設計更複雜的規劃結構（ 如使用 dag 有向無環圖表示任務依賴關係 ），以及如何讓 agent 動態更新規劃以適應變化的需求，這不僅考驗技術實現，還涉及演算法設計和智能體的自適應能力。
目前 openmanus 的規劃設計與 manus 保持一致，都是線性的，而dag規劃對於處理現實世界中更複雜的任務，在一定程度上會更準確，data interpreter 就是一個很好的例子。
：聽起來 openmanus 的規劃已經有要超越 manus 的苗頭了，你們對這個產品有什麼期望嗎？
：openmanus 前期目標打算達到原始 manus 的相同的效果，後續會不斷優化 computer use、browser use 和 planning use，以及工具調用的能力，從而超越 manus。
manus 產品交互做的挺好的，有很多技術也值得學習，比如對後訓練技術的結合，流程設計上比如規劃、multi agent 系統也是很優秀的，具體細節我們還在研究。至於 openmanus 我們沒有單獨調效果，目前達到的效果其實很一般。後續主要靠開源社區小夥伴來貢獻，我們希望開源協作能帶來更高的智能湧現～
好了，到這裡知危編輯部與 metagpt 團隊的溝通就到這裡了，我們也可以期待一波 openmanus 未來的效果。
最後，或許我們可以探討一下到底什麼應該是好的 agent ？
manus 有優點、有亮點，但有誇大之嫌。人們在試用的時候，還是能發現 manus 有不少毛病，用錯了假數據、來源引用錯誤、表格讀取錯誤等等毛病一個不落，幻覺問題還是不小。
agent 應用的一大通病是，自動化執行過程越複雜，錯誤發現和查找原因就越困難，而且 agent 的執行需要經過多個 llm，每個 llm 的幻覺一路累積下來的誤差將是巨大的，比如 95% 的準確率，連續經過 10 個 llm，最後準確率能直接降到約 60% 。
在全面擁抱 agent 之前，我們首先還是得多關注一下，目前市面上的通用大模型，它們的幻覺率仍然不是一般的高。
所以，想實現真正好用的 agent，我們仍然要攻克大模型底層能力的提升。里子不夠好，套太多的殼也沒用。
與此同時，我們還需要強調的一點是，追求 agent 的過程中，我們一定是要回歸實用主義的：不是所有問題都需要用 agent 來做。
devin 前不久還被爆出出錯率極高並且出錯方式沒有規律可循，還不如用 cursor 一步一步來，加上之前的演示造假事件，過於激進的 agent 產品越來越受到質疑。
與此同時，agent 的一大通病是，步驟拆解越多，token 消耗量越大，對所有任務一律無腦使用 agent，對於企業的成本控制而言具有極大的風險。
agent 的最關鍵的作用就是工作流編排，簡單的任務其實並不需要 agent 的參與，反而會導致客戶等待時間過長。
anthropic 就曾經分享過構建智能體的基本原則，就是 「 簡單為王，實用至上 」，能用 api 就不要用工作流，能用工作流就不要用智能體。
這些都是手段，哪個不能交付結果呢？
agent 終究是一個產品概念，不像 llm 有無法預測的潛在價值（ 比如推理能力的發現和增強 ）值得冒極大風險押注。
所以回過頭來看，我們應該更多關注開源社區的新技術，比如阿里在 manus 發布同一天剛開源的 qwq-32b 模型，就像前文講的那樣，在追求 agent 的路上，我們更應該關注模型的突破。
