今天凌晨，網友 @jianxliao 在 X 平臺上分享了其與 Manus AI 的互動經歷，并迅速引來了近百萬網友的圍觀。

據用戶描述，他僅通過簡單的請求（如訪問 /opt/.manus/ 文件夾）便成功獲取了 Manus 的沙盒運行時代碼。

并揭示了 Manus 使用 Claude Sonnet 模型等技術細節。 一時間，關于 Manus 被成功「越獄」的消息甚囂塵上。

就在剛剛，Manus 聯合創始人 @peakji（季逸超）作出了回應，他表示， 這并非意外或漏洞，而是 Manus 設計的一部分。

其實，這并不復雜——每個用戶都可以直接訪問沙盒。

簡單來說，沙盒是一個被嚴格限制的環境，開發者可以在沙盒里測試新功能，不用擔心代碼出錯會破壞整個系統。

據介紹，Manus 的沙盒機制具有以下特點：

每個會話都有獨立的沙盒環境，與其他會話完全隔離。用戶可以通過 Manus 的界面直接進入沙盒。

沙盒中的代碼主要用于接收 agent 發出的指令，因此僅被輕微混淆處理。

即使用戶獲取了沙盒代碼，也不會對系統的整體安全構成威脅。

Peak 強調，Manus 的設計并不神秘，其行動空間的設計與學術界常見的方法類似。

且由于采用了檢索增強生成（RAG）機制，工具描述會根據任務的不同而動態變化。這意味著，即使通過「越獄」手段獲取工具信息，也無法得到一致的結果。

Peak 表示 Manus 采用多 agent 協作的架構設計。 用戶在與 Manus 交互時，實際上只與執行 agent 通信，而執行 agnet 本身并不掌握其他 agent 的詳細信息。

這種設計不僅有助于控制上下文長度，還能有效避免因過多信息導致性能下降。 「這也是為什么通過『越獄』獲得的提示大多是幻覺的原因。 」Peak 解釋道。

Peak 坦言，團隊使用了許多開源技術。與此同時也一直秉持開源傳統，「在不久的將來，我們將開源不少好東西。」

他本人也長期在 Hugging Face 上分享訓練后的模型。

當被問及 Manus 的基礎模型時，Peak 稱目前使用的是 Claude 和 Qwen 微調模型。團隊早期只能使用 Claude 3.5 Sonnet v1（不支持長鏈推理），因此需要大量輔助模型來彌補不足。

Peak 還表示正在內部測試 Claude 3.7，并將盡快發布更新。

值得一提的是，Peak 也談到了 Manus 是否使用 MCP（Model Context Protocol，模型上下文協議）的熱議話題。

簡單來說，你可以把 MCP 想象成一個「萬能接口」，就像電腦上的 USB-C 接口一樣。這個接口讓 AI 模型能夠輕松地連接到各種外部資源，比如文件、數據庫、在線服務等。

通過 MCP，AI 助手不僅能獲取數據，還能直接對數據進行操作，比如讀取文件內容、更新數據庫記錄等。

對此， Peak 回應該網友稱：

「 實際上，Manus 并沒有使用 MCP。我們更多地受到了我的朋友王星堯（ @xingyaow_ ）的研究工作的啟發。」

名為《Executable Code Actions Elicit Better LLM Agents》的研究論文，引入可執行 Python 代碼（CodeAct），提出了一種新的方法來增強大型語言模型（LLM）agent 的能力。

該方法使得 LLM agent 能夠直接執行代碼行為，從而將多種行為統一到一個更加靈活和強大的動作空間中。

附上論文鏈接：
https://openreview.net/forum?id=jJ9BoXAfFa

盡管 Manus 研究團隊并未完全采用 CodeAct，但這項研究提供了三個關鍵見解：

1?? 編寫代碼并不是最終目標，而是一種通用的解決問題的方法。

3?? 由于 LLM 在編程方面表現出色，因此讓智能體執行與其訓練分布最接近的任務是合理的。

3?? 這種方法大大減少了上下文長度，并且能夠組合復雜的操作。

當被問及為啥不使用 MCP 時，Peak 無奈地表示：「因為……Manus 早在 Model Context Protocol 推出之前就已經開始開發了」

APPSO 也曾實測 Manus，歡迎回看此前文章

附上參考鏈接：
https://x.com/peakji/status/1898994802194346408

我們正在招募伙伴

簡歷投遞郵箱
hr@ifanr.com

?? 郵件標題
「姓名+崗位名稱」（請隨簡歷附上項目/作品或相關鏈接）