engineering security

macOS 上的 Apple Container:為什麼 NanoClaw 使用 Apple 的新沙箱來隔離 AI Agent

NanoClaws.io

NanoClaws.io

@nanoclaws

2026年2月26日

7 分鐘閱讀

macOS 上的 Apple Container:為什麼 NanoClaw 使用 Apple 的新沙箱來隔離 AI Agent

2024 年底,Apple 做了一件不尋常的事。沒有主題演講、沒有新聞稿、沒有通常伴隨 Apple 平台功能的任何排場,他們在 macOS 上推出了原生 Linux 容器支援。這個專案以「container」的名稱在 GitHub 上開源——全小寫、沒有品牌、沒有行銷。就是一個 Swift 二進位檔,能在 Apple Silicon 上以接近原生的效能運行 OCI 相容的 Linux 容器。

大多數開發者沒有注意到。Docker Desktop 仍然主導著 macOS 的容器生態,少數注意到的人也以為這只是一個不小心公開的內部工具。但對於任何需要在 macOS 上建構輕量、安全隔離的軟體的人來說,Apple Container 是一場靜悄悄的革命——而 NanoClaw 是最早在其上建構的專案之一。

為什麼 Docker 不夠用

要理解 Apple Container 對 AI agent 的意義,你需要先了解 Docker 在 macOS 上實際做了什麼。Docker Desktop 不是原生運行容器的——它運行一個 Linux 虛擬機器,然後在那個 VM 裡面運行容器。你 Mac 上的每個 Docker 容器實際上都在一個由 Docker Desktop 管理的隱藏 Linux VM 中運行。這能用,但有額外開銷:VM 需要記憶體(預設通常 2-4GB)、每個容器操作都會增加延遲,而且需要 Docker Desktop 作為背景服務持續運行。

對於偶爾啟動一個 Postgres 容器的網頁開發者來說,這個開銷感覺不到。但對於 NanoClaw 這種每次對話回合都要啟動一個新容器、回應完成後就銷毀的使用模式來說,這個開銷就是瓶頸。一個因為 VM 開銷而需要 2 秒才能啟動的容器,會把一個反應靈敏的 AI 助理變成一個遲鈍的。使用者會注意到他們的 WhatsApp 訊息多花了 3 秒。

Apple Container 完全消除了 VM 層。它使用 Apple 的 Virtualization.framework 直接在硬體上運行一個輕量的 Linux 核心,容器共享這個核心而不是各自運行自己的 VM。結果是容器啟動時間以毫秒而非秒計算,記憶體開銷以 MB 而非 GB 計算,I/O 效能接近原生。

NanoClaw 如何使用它

NanoClaw 的容器模型簡單但經過深思熟慮。當 WhatsApp 上收到一條訊息時,NanoClaw 啟動一個容器並掛載特定的目錄:專案原始碼(唯讀)、群組的 CLAUDE.md 記憶檔(可讀寫)和一個按群組劃分的可寫工作區。API key 透過 stdin 以 JSON payload 傳遞——它永遠不會碰到容器內的檔案系統或環境變數。 在 macOS 上,NanoClaw 偵測到 Apple Container 後會預設使用它。在 Linux 上則退回使用 Docker。容器內的 agent 程式碼無論哪種方式都是一樣的——都是一個帶有 Agent SDK 的 Claude Code session,在 Linux 環境中運行,不管主機是什麼作業系統。容器映像包含 Chromium 和 agent-browser 用於網頁存取,讓 agent 能夠搜尋網頁和瀏覽頁面,而主機上不需要運行任何瀏覽器。

在 macOS 上的實際差異就是速度。Apple Container 的容器啟動時間大約 200-400 毫秒——快到使用者除了正常的 AI 回應時間外感覺不到任何延遲。用 Docker Desktop 的話,同樣的操作需要 1.5-3 秒,這是感覺得到的。每天幾十條訊息累積下來,這個差異會形成明顯不同的使用體驗。

安全模型

Apple Container 以 Docker Desktop 無法做到的方式繼承了 macOS 的安全原語。容器在 Apple 的沙箱框架下運行,這意味著它受到與任何其他沙箱化 macOS 應用程式相同的安全策略約束。存取明確掛載路徑之外的檔案不只是被容器執行環境拒絕——而是被作業系統本身拒絕。

這對 AI agent 特別重要,因為 prompt injection 的存在。如果惡意 prompt 誘騙 agent 嘗試讀取 ~/.ssh/id_rsa 或 ~/Documents/tax-returns.pdf,這個嘗試會在作業系統層級失敗,而不是在應用程式層級。NanoClaw 的掛載驗證程式碼中不存在可以被利用來繞過限制的 bug,因為限制是由 macOS 的核心強制執行的,不是由 NanoClaw。

網路隔離同樣重要。每個容器都有自己的網路命名空間,這意味著 agent 無法掃描區域網路、無法存取 localhost 上運行的其他服務,也無法與其他 agent 容器通訊。唯一的網路存取是對 AI 供應商和 agent 正在瀏覽的網站的出站 HTTPS。這對於被入侵的 agent 試圖橫向移動到同一台機器上其他服務的攻擊類型來說,是一道有意義的防線。

這對 Mac 使用者意味著什麼

如果你在 Mac 上運行 NanoClaw——這是個人使用最常見的部署方式——Apple Container 給你 Docker 等級的隔離,卻不需要 Docker Desktop。沒有背景 VM 吃掉 2-4GB 的記憶體。不用管理 Docker Desktop 授權。不需要在 NanoClaw 啟動前先運行 Docker daemon。

設定非常簡單。NanoClaw 的啟動腳本會偵測 macOS、檢查 Apple Container,然後自動設定。如果沒有安裝 Apple Container,就退回使用 Docker。如果兩者都沒有,就在沒有容器隔離的情況下運行(會顯示警告)。目標是讓容器隔離成為預設,而不是需要額外設定才能啟用的功能。

對於評估在 macOS 和 Linux 混合環境中部署 NanoClaw 的團隊來說,容器抽象意味著相同的設定在任何地方都能運作。無論是 Apple Container 還是 Docker 提供隔離,agent 的行為都是一樣的。唯一的差異是效能——而在這個指標上,Apple Silicon 上的 Apple Container 很難被超越。

Apple 不是為 AI agent 打造 Container 的。他們是為自己的內部工具和需要在 macOS 上使用輕量 Linux 環境的開發者打造的。但讓它適合那些用途的特性——快速啟動、低開銷、強隔離、原生效能——恰好也是 AI agent 沙箱所需要的特性。有時候,最適合某項工作的工具,是一個為完全不同的工作而打造的工具。

掌握最新動態

取得新版本發布、整合功能與 NanoClaw 開發的最新消息。不發垃圾郵件,隨時可取消訂閱。