設計目標
這套系統的存在，是為了執行維運者不信任的程式碼 —— 通常是 AI 產生的 —— 同時讓那段程式碼無法傷害宿主、其他工作負載或周邊資料。兩個非功能性特性主導了每個決策：高隔離性與高擴充性。
把每個工作負載都當成有敵意，然後讓「有敵意」變得無聊。
高隔離性
隔離是刻意分層的，因為沒有任何單一機制能獨力做到完整防護：
- Namespace 把系統其餘部分對工作負載隱藏起來（它看得到什麼）。
- Seccomp-BPF 拿掉工作負載根本不該用到的 syscall（它能要求核心做什麼）。
- Cgroup 限制 CPU、記憶體、I/O 與行程數（它能用多少）。
- Timeout 限制它能跑多久（它能霸佔位置多久）。
四者合起來是四道彼此獨立的牆。攻擊者必須同時攻破全部，這比繞過其中任何一道都難得多。
高擴充性
擴充性來自「任務管理器／執行節點」的拆分。控制平面（UI、資料庫、任務管理器）保持精簡、共享；資料平面（執行節點）則是無狀態、可拋棄的。要承受更多負載就加節點 —— 任務管理器只要派送給更多節點即可。
為什麼中間要放資料庫
讓任務、結果與日誌都流經一個共享資料庫，能讓各層解耦：UI 永遠不直接呼叫執行節點，監控也能讀到一切而不碰沙盒。解耦後的各層，可以各自獨立擴充、也各自獨立推理。
業界現況（已查證）
這套設計正落在一個高速演進的領域中。幾個已查證的數據點，說明它的規模：
- 2025 年 Veracode 報告指出約 45% 的 AI 產生程式碼通不過安全測試 —— 沙盒並非選配。
- E2B 回報沙盒 session 從約每月 4 萬次（2024 年 3 月）成長到約每月 1,500 萬次（2025 年 3 月）。
- 比這套設計更強的隔離層級也存在：gVisor 在使用者空間攔截 syscall（只有經審核的子集會到宿主核心）；Firecracker microVM 讓每個工作負載擁有自己的核心，約 125ms 啟動、額外負擔小於 5 MiB。
- 常見的正式環境建議是縱深防禦：namespace + seccomp + cgroup，必要時再用 microVM 包一層硬體邊界。
參考來源
- Linux namespaces — en.wikipedia.org/wiki/Linux_namespaces
- Seccomp BPF — docs.kernel.org/userspace-api/seccomp_filter.html
- Control Group v2 — docs.kernel.org/admin-guide/cgroup-v2.html
- What are namespaces and cgroups — blog.nginx.org
- How to sandbox AI agents — northflank.com/blog/how-to-sandbox-ai-agents
- Sandboxed environments for AI coding — bunnyshell.com