架構報告 ② · OpenManus / Manus 模式
OpenManus 架構把「編排器」放在伺服器，程式碼進隔離沙箱執行
OpenManus 把代理迴圈（編排器）與多代理規劃流程跑在伺服器程序上，工具與生成程式碼丟進隔離沙箱（本機 Docker 或 Daytona 雲端）執行，並能透過 A2A / MCP server 對外暴露成網路服務——這就是 Manus 的託管模式。
編排器位置：伺服器 / 雲端
核心：PlanningFlow + BaseAgent
執行隔離：Docker / Daytona 沙箱
對外：A2A · MCP 服務
01知識圖譜概況
方法：git clone 後以 graphify 建立知識圖譜（AST + 多代理語意擷取），再交叉閱讀核心檔案。
神級節點（連結最多的核心抽象）
互動式知識圖譜：graphify-out/graph.html（瀏覽器直接開，可縮放探索全部社群）。
02架構圖
編排器在中央伺服器；不可信的生成程式碼被關進右側的隔離沙箱；使用者是送任務的薄客戶端。
使用者（薄客戶端）
伺服器 / 編排器
隔離沙箱（執行）
外部 LLM / 雲端
04一次任務的生命週期
任務在伺服器被編排，程式碼在沙箱被執行，結果再回傳給薄客戶端。
05安全模型與擴充 / 對外暴露
🛡 安全邊界 = 容器隔離（而非能力把關）
因為編排器在伺服器跑、可能執行不可信的生成程式碼，OpenManus 用 Docker / Daytona 容器把 shell、程式碼、瀏覽器動作關進隔離環境，並對指令做 sanitize 防注入；SandboxManager 控管容器數量與閒置回收。
相對地，沒有像 Claude Code 那樣的逐工具 allow/deny/ask 權限分層或 Plan Mode 人工核可節點——安全靠「沙箱隔離」，不是「能力暴露控制 + 人工核可」。
🔌 擴充偏「服務 / 協定」層級
A2A 協定把整個 Manus 當成網路代理服務：.well-known/agent.json 的 Agent Card 以 skills 列表廣告能力（Python Execute、Browser use…），用 JSON-RPC message/send 接任務。MCP server 把工具暴露給其他代理；MCP client 反向接入外部工具。
多代理則在 run_flow 的 config.toml 加掛代理（如 DataAnalysis），由 PlanningFlow 編排。注意：這裡的「skill」是服務廣告的能力，不是每位使用者本機、可由 admin 治理的 skill 目錄。
06優勢與限制（對 DGX 場景）
★ 這正是決策的「選項 B：skill 集中在 Spark」的參考實作
本案建議的做法——skill 集中在團隊共享的 Spark、每位 user 用獨立空間（沙箱）隔離、admin 集中指派——OpenManus 就是現成範本：伺服器端編排器（PlanningFlow + 代理迴圈）＋ 每任務／每 user 的隔離沙箱（DockerSandbox / SandboxManager）＋ 集中工具/技能註冊。最快上手、最少維運、skill IP 不外流到裝置。
落地時建議用本機 Docker 沙箱（而非 Daytona 雲端）做 user 間隔離，讓 skill 與資料都留在 Spark 內；並控管單台 Spark 的並發（每 user 資源上限／排隊）。完整對照與行動清單見 ③ 決策報告。