為什麼 AI Agent 需要專門的隔離環境？
如果你用過 Cursor、Claude Code 或任何能在本機呼叫工具的 AI Agent，大概都經歷過它「越權」的那一刻：你本來只讓它改一個設定檔，結果它順手跑了一條 rm -rf，或者把你的 SSH 金鑰上傳到某個暫時伺服器。這不是 AI 的 bug，而是系統設計問題——你沒有告訴它邊界在哪裡。
在本機開發機上用沙箱相對麻煩：macOS 的 App Sandbox 主要針對 GUI 應用程式，Docker 容器又缺少完整的 macOS 環境，程式碼簽章、Xcode 模擬器、Apple Neural Engine——這些在容器裡根本跑不起來。更重要的是，很多需要 AI Agent 處理的任務本身就是高權限的（安裝軟體、操控系統偏好設定、存取鑰匙圈），你沒辦法既給它足夠權限完成任務，又把它關在一個什麼都幹不了的籠子裡。
OpenClaw 的設計出發點就是解決這個矛盾：它不是把 AI Agent 關進受限的盒子，而是在一台完整的 macOS 實體機上，為每次任務劃定可稽核、可回溯、可隨時中止的「操作邊界」。你可以精確控制它能存取哪些目錄、能呼叫哪些系統指令、能發起哪些網路連線——同時它能做的其他事情依然是完整的 macOS 能力。
本文所有操作均在 ZilCloud 新加坡節點的一台 Mac mini M4（16 GB 統一記憶體、256 GB SSD、1 Gbps 獨享頻寬）上完成，macOS Sequoia 15.3，OpenClaw 版本 1.4.2。
OpenClaw 的核心架構：三層隔離模型
在動手操作之前，先花兩分鐘理解 OpenClaw 的架構——這會讓你在設定權限時少走很多彎路。
OpenClaw 使用一套「三層隔離」模型來管理 AI Agent 的操作邊界：
第一層：檔案系統命名空間（Namespace）。每個 OpenClaw 工作階段啟動時，會在指定目錄下建立一個暫時命名空間掛載點。Agent 在工作階段內所有的檔案讀寫操作都會被重新導向到這個命名空間內部——即使它試圖寫入 /etc/hosts，實際寫入的也是命名空間副本，不會影響主系統。工作階段結束後，命名空間可選擇自動清理或持久化保留。
第二層：系統呼叫過濾（Syscall Filter）。OpenClaw 透過 macOS 的 Endpoint Security 框架攔截並過濾系統呼叫。你可以在設定檔裡精確指定允許或禁止的 syscall 類型（例如允許 fork / exec，但禁止 ptrace 和 setuid），或者使用預設的權限範本（如「編譯模式」、「網路爬取模式」、「唯讀審查模式」）。
第三層：網路存取控制（Network ACL）。每個 OpenClaw 工作階段可以綁定一個獨立的網路策略：白名單允許的網域或 IP 範圍、是否允許監聽連接埠、是否允許 DNS 解析外部位址。超出策略的網路請求會被靜默丟棄並記入稽核日誌，而不是直接報錯讓 Agent 感知到邊界的存在（這樣可以避免它「繞路」嘗試）。
前置條件：在 ZilCloud 開通 Mac mini M4
OpenClaw 是 ZilCloud 的內建功能，在主控台開通後無需額外安裝。如果你還沒有 ZilCloud 帳號，先完成註冊與首次開機流程。整個過程約 5 分鐘：
-
01選擇節點與方案
前往設定下單頁，選擇離你目標使用者最近的節點（新加坡 / 日本東京 / 中國香港 / 韓國首爾 / 美國東部）。執行 AI Agent 任務不需要大容量儲存，基礎 256 GB SSD 即可，按天起租 $20.9。
-
02完成付款，等待自動開通
付款後系統會自動分配並交付執行個體，通常在 1–5 分鐘內完成。你會收到一封包含 SSH 存取憑證與 VNC 密碼的確認郵件。
-
03透過 VNC 或 SSH 確認系統就緒
登入主控台，點擊「開啟 VNC」即可在瀏覽器中直接看到 macOS 桌面，無需安裝任何用戶端。SSH 方式：
ssh admin@<你的公網 IP> -p <連接埠>。
啟用 OpenClaw 沙箱（主控台操作）
確認執行個體正常運作後，在 ZilCloud 主控台找到對應訂單的「OpenClaw」入口。初次啟用需要完成一次「零信任初始化」流程，這個過程會產生一組與該執行個體綁定的存取金鑰對，並安裝 OpenClaw 背景服務到系統後台。
初始化完成後，在 macOS 終端機裡驗證 OpenClaw 服務是否正常運作：
# Check OpenClaw daemon status
launchctl list | grep openclaw
# Expected output:
# - 0 com.zilcloud.openclaw.daemon如果看到結束代碼為 0，表示背景服務在執行。接下來安裝命令列工具（如果主控台初始化時未自動完成）：
# Install OpenClaw CLI
curl -fsSL https://cdn.zilcloud.com/openclaw/install.sh | bash
# Verify version
claw --version
# openclaw 1.4.2 (darwin/arm64)執行 claw status 後能看到「daemon: running」和一個有效的 session token，說明環境已就緒，可以繼續設定權限。
設定 AI Agent 的權限邊界
OpenClaw 使用 YAML 格式的設定檔來定義每個沙箱工作階段的權限策略。對於 AI Agent 場景，官方提供了三個預設範本，可以直接用 CLI 載入：
# List available templates
claw template list
# output:
# readonly — read-only audit mode (no writes, no network)
# dev — developer mode (full fs write, npm/pip allowed, no external network)
# agent — AI agent mode (scoped fs, curated syscalls, filtered network)對於初次使用，建議從 agent 範本開始，然後根據實際需求微調：
# Generate a config file from the agent template
claw template export agent > ~/openclaw-agent.yaml產生的 openclaw-agent.yaml 大致結構如下（已簡化註解）：
version: "1"
session:
name: "my-agent-session"
auto_cleanup: true # clean namespace on session exit
filesystem:
workspace: "~/agent-workspace" # agent's r/w root
readonly_mounts:
- /Applications # read access to installed apps
- /usr/local/bin # allow calling homebrew tools
deny:
- ~/.ssh # block ssh key access
- ~/Library/Keychains # block keychain access
syscalls:
preset: "agent" # allows fork/exec, blocks ptrace/setuid
network:
allow_domains:
- "api.openai.com"
- "api.anthropic.com"
- "*.github.com"
block_all_others: true # silent-drop, not reject這個設定做了幾件關鍵的事：Agent 的檔案寫入操作被限定在 ~/agent-workspace 目錄內；它可以讀取已安裝的應用程式與 Homebrew 工具，但無法存取你的 SSH 金鑰或鑰匙圈；網路存取只允許幾個明確的網域，其他所有出站請求都會被靜默丟棄。
第一次設定時，我沒有把 /usr/local/bin 加入唯讀掛載白名單。結果 Agent 呼叫 git、python3 這些工具時全部失敗，因為它們是透過 Homebrew 安裝的符號連結，OpenClaw 把這些連結解析後發現目標路徑不在允許清單裡，直接攔截了。檢查稽核日誌後才發現問題所在。
執行第一個 AI Agent 任務
設定檔就緒後，用 claw run 啟動一個隔離工作階段，然後在工作階段內執行你的 Agent：
# Start a sandboxed session with the config
claw run --config ~/openclaw-agent.yaml --attach
# Inside the session, you are now in the sandboxed environment
# Prompt changes to indicate active sandbox:
# (claw:my-agent-session) admin@mac-ZC-xxxxx:~$
# Now run your AI agent tool, e.g. Claude Code
claude --dangerously-skip-permissions--attach 參數會讓你直接進入沙箱 shell，在裡面啟動的所有程序都自動處於 OpenClaw 的監控範圍內。claude --dangerously-skip-permissions 是 Claude Code 的參數，允許它自主操作檔案系統——但在 OpenClaw 沙箱裡，「自主操作」的實際範圍已經被你的設定檔限定好了，這個 flag 的「危險」被有效隔離在沙箱邊界之內。
任務執行期間，你可以在另一個終端機即時觀察稽核串流：
# Tail the audit stream for the active session
claw audit tail my-agent-session --follow
# Sample output:
# [10:23:41] ALLOW exec /usr/local/bin/git clone https://github.com/...
# [10:23:42] ALLOW write ~/agent-workspace/repo/README.md
# [10:23:45] BLOCK network outbound → 142.250.x.x (google.com) — policy: block_all_others
# [10:23:48] ALLOW exec /usr/bin/python3 analyze.py每一筆記錄都包含：時間戳記、決策（ALLOW / BLOCK）、操作類型（exec / write / network / read）、具體目標，以及如果是 BLOCK 的話符合哪條策略規則。這份日誌會持久儲存，即使工作階段結束後也可以隨時查詢。
零信任存取與稽核日誌的實際價值
上面那條被攔截的 google.com 請求是真實發生的——Agent 在分析程式碼時呼叫了一個內部函式庫，那個函式庫啟動時會嘗試向 Google Analytics 發送一個初始化 ping。在一般環境下你完全感知不到這個行為；在 OpenClaw 沙箱裡，它被記錄下來了。
這正是「零信任」的實際意義：不是不信任 Agent，而是不假設它的每一步行為都符合你的預期。把所有操作視覺化、可稽核，是你真正理解 Agent 在做什麼的唯一方式。
稽核日誌的另一個用途是合規場景。如果你用 AI Agent 處理客戶資料或程式碼審查，很多資安團隊會要求你能證明「AI 沒有把資料發到外部位」——OpenClaw 的稽核日誌是一份可驗證的記錄，你可以匯出成 JSON 格式提交給合規審查。
# Export full audit log as JSON for compliance review
claw audit export my-agent-session \
--format json \
--output audit-report-$(date +%Y%m%d).json常見場景設定速查
根據不同的 AI Agent 使用場景，以下是幾種常用的權限邊界設定思路，可以在 agent 範本基礎上按需微調：
| 使用場景 | 建議 syscall 預設 | 網路策略 | 關鍵注意點 |
|---|---|---|---|
| 程式碼產生 / 重構 | agent |
允許 npm / pip registry | 需開放套件管理器網域 |
| iOS 專案編譯（Xcode） | dev |
允許 Apple CDN | 需掛載 /Applications/Xcode.app |
| 資料分析（唯讀輸入） | readonly |
全部阻斷 | 最高安全等級，適合敏感資料 |
| 網頁爬取 / 資訊檢索 | agent |
白名單目標網域 | 精確限定允許網域防止資料外洩 |
| CI/CD 自動化任務 | dev |
允許 GitHub / CI 服務 | 建議每次 CI 執行建立新工作階段 |
OpenClaw 支援工作階段範本化——你可以把調好的設定存成命名範本，每次啟動時直接 claw run --template xcode-build，不用每次都重新寫 YAML。對於 CI/CD 流水線，可以把範本設定檔提交到程式碼儲存庫，讓每次建置都在完全一致且可稽核的沙箱環境中執行。
為每一個獨立的 Agent 任務建立一個新的 OpenClaw 工作階段，而不是讓所有任務共用同一個工作階段。這樣稽核日誌按任務隔離，事後追查時清晰得多；工作階段的檔案命名空間也是完全獨立的，任務之間不會意外讀取到彼此的中間狀態。
為什麼不用 Docker 容器或虛擬機來隔離 AI Agent？
這個問題每次演示 OpenClaw 時都會有人問，值得認真回答。
Docker 容器是 Linux 的隔離機制，在 macOS 上執行 Docker 意味著你實際上是在一個 Linux 虛擬機裡跑容器——不管是 Docker Desktop 的 HyperKit，還是 OrbStack 的 Lima，底層都是 Linux 核心。這直接意味著：你的 AI Agent 跑在 Linux 環境裡，而不是 macOS 環境。對於需要呼叫 Xcode 工具鏈、Apple Neural Engine、codesign、simctl（模擬器控制）的任務，Docker 根本行不通——這些工具依賴 macOS 私有框架，在 Linux 容器裡不存在。
macOS 的原生虛擬化（Virtualization.framework，配合 UTM 或 VMware Fusion）可以跑完整的 macOS 虛擬機，但這裡有三個實際問題：首先，在雲端 Mac 上再嵌套跑一個 macOS 虛擬機，效能損耗不可忽視，M4 的 Neural Engine 在嵌套虛擬化場景下無法被訪客系統直接存取；其次，虛擬機的管理開銷遠高於 OpenClaw 的工作階段模型，你需要管理映像、快照、網路橋接；第三，虛擬機內部同樣沒有內建的稽核日誌機制，你需要額外部署日誌採集工具才能達到 OpenClaw 的稽核覆蓋率。
OpenClaw 走的是一條不同的路：它在真實的 macOS 實體機上工作，利用作業系統原生的 Endpoint Security 框架進行操作攔截，效能開銷極低（實測約 3% CPU），同時對 Agent 幾乎透明——Agent 不知道自己在沙箱裡，它能呼叫的所有 macOS 能力（包括 Apple Silicon 的 Neural Engine、Xcode 完整工具鏈、程式碼簽章服務）都是真實的，只是操作邊界被預先定義好了。
如果你現在用的是 GitHub Actions 的 macOS 託管 Runner，可以類比一下：GitHub 給你一台 macOS 虛擬機，你沒有實體機獨享的算力，也沒有在 Runner 環境裡做精細稽核的能力，而且 macOS Runner 的費用是 Linux Runner 的 10 倍。ZilCloud 的 Mac mini M4 按天起租 $20.9，實體機獨享，裝上 OpenClaw 後你得到的是一套完整的、可稽核的、隔離的 macOS AI Agent 執行環境，而不是一個「大概能用」的替代方案。