NVIDIA OpenShell 是一個開源執行環境，讓 AI Agent 在有檔案、程序和網路邊界的沙箱裡工作。 你先設定它能碰哪些資源，OpenShell 再於執行時施加控制，讓限制不只寫在提示詞裡。它適合需要執行工具、存取工作檔案或呼叫 API 的 Agent；工作結果是否正確、哪些業務動作可以授權，仍須另外判斷。官方概覽
三層架構，分別管什麼？
NVIDIA 原始技術文章用沙箱、政策引擎、隱私路由說明三種分工。現在的文件則把實作拆成 sandbox、可信任的 supervisor、gateway 與 providers；「三層」是理解控制責任的方式，不代表三個依序執行的獨立服務。原始架構文章、目前架構
Gwarket 自製關係圖，2026-11-05。圖示強制執行的拒絕路徑；L7 audit 模式的違規請求只記錄、不阻擋。政策檢查與憑證處理由可信任端負責，不是兩個必須獨立部署的服務。
沙箱：先限制 Agent 能碰到的工作環境
Agent 與工具在受限的工作負載中執行。現在的 Linux 實作以 Landlock 限制檔案存取，並使用程序控制與 seccomp 等機制；網路請求經過受控通道交給沙箱外的 supervisor。隔離把「能讀哪個路徑、能執行哪些動作」變成環境條件。架構與隔離邊界
這對讀取程式碼、產生檔案等工作有意義，但不會替你判斷文件內容是否可信。一份已允許讀取的檔案仍可能含錯誤資訊；這是本文區分「資源存取」與「內容判讀」的理由。
政策引擎：把允許範圍寫成可檢查的設定
YAML 政策可以限制檔案路徑、程序身分、可連線的目的地、呼叫程式與 API 請求。檔案及程序設定在建立或啟動時固定，網路規則可以在執行中更新，因此不要把「政策可更新」理解成所有限制都能隨時熱改。政策欄位與生效時機
還要分清觀察與阻擋。官方安全文件指出，啟用 L7 檢查後，audit 會記錄規則違規但仍轉送；enforce 才阻擋不符合規則的請求。只看到日誌，不足以證明某個寫入動作已被攔下。L7 audit 與 enforce
隱私與推論路由：確認端點與憑證，不等於自動判讀敏感資料
目前推論文件說明：工作負載呼叫供應商原生 API；provider profile 定義允許的端點和程式，attachment 決定哪個沙箱取得存取權，真實憑證只在核准端點替換。模型名稱與 base URL 則由用戶端或工作負載設定，掛上 provider 不會替你挑選或改寫模型。目前推論與憑證機制
我的整理判斷一：先列資料可以去哪裡，再選模型。 原始文章描述的本地／雲端分流方向，不應被延伸成「OpenShell 會自動辨識所有敏感資料並留在本地」。若流程需要客戶名單、原始碼或內部文件，先列可使用的資料、端點與授權人；再確認實際設定符合這份清單。
怎麼開始用：先核對前提，再看官方範例
截至 2026-11-05，GitHub 最新正式 release 為 v0.1.7，發布於台灣時間11月4日（UTC 11月3日）。OpenShell 採 Apache 2.0；這是軟體授權，模型服務與運算資源仍須各自確認費用。v0.1.7、該版本 README
| 先確認 | 官方目前列出的條件 |
|---|---|
| 主機 | Debian／Ubuntu Linux（x86_64／ARM64）；Apple Silicon macOS＋Docker Desktop；Windows 的 WSL 2＋Docker Desktop 路徑標為 experimental |
| 執行基礎設施 | 依部署方式選 Docker、Podman、Kubernetes 或 MicroVM，不能只看 CLI 裝好了沒 |
| Agent | 預設基礎沙箱沒有裝好 Agent；另選包含所需工具的 image |
| 模型與服務 | 準備相應 provider profile、憑證與目的地規則 |
原生 Windows 的 MXC 路徑另在 windows 分支提供，與上表的 WSL 2 路徑不同，需求與限制要依該分支文件核對。
官方 README 的基本範例是先安裝 CLI／本地 gateway，再建立沙箱。下面是官方指令的閱讀示例，完整安裝與相容條件以連結文件為準：
openshell sandbox create --name demo
這個指令建立基礎沙箱，不代表模型、Agent、網路和憑證都已就緒。官方「Run Your First Agent」另以 OpenCode 示範設定 provider、選 image、附加存取權，以及處理新目的地的政策提案。GitHub 起步說明、官方 Agent 範例
哪些工作值得加入這層控制？
我的整理判斷二：從可授權的工作範圍評估，不從 Agent 名稱評估。 如果只是整理一段公開文字，先確認輸出如何核對就很實用；如果 Agent 要長時間讀寫資料夾、安裝工具或連接多個服務，才需要把檔案、程序、目的地與憑證逐項列出，評估 OpenShell 這類執行控制。
例如「讀產品規格，產生提案草稿」可以拆成：規格目錄可讀、草稿目錄可寫、允許哪個模型端點、是否允許對外寄送。把四項分開，才知道哪一項需改政策，哪一項是業務核准；沙箱本身不會決定提案可以寄給誰。這是本文自製的工作拆解例子。
連線被拒絕時，不要先把規則全部放寬
社群回報提供了具體反例：Issue #5093 描述 v0.1.2 上 JVM／Bazel 使用 IPv4-mapped IPv6 位址時，原本允許的端點仍被拒絕。此議題於11月5日已結案；這不等於每個使用中的 release 都含相同修正，應核對版本與關聯變更。官方 repo 回報與狀態
這則回報的用途是縮小排查方向：先看使用版本、目的地的表示方式與拒絕紀錄，再確認政策。單一連線失敗不能直接推成「OpenShell 不支援這個 Agent」，也不值得用允許所有目的地來掩蓋原因。
下一步
- 用 AI Agent 和 Chat 的差別 確認你的工作是否需要工具執行。
- 用 Codex 權限設定 拆開資料夾、網路與人工確認的問題。
資料來源與查證日期
查證日期：2026-11-05。基準為 v0.1.7 release、該 tag README 及當日標為 Latest (v0.1.7) 的官方文件；動態文件和議題狀態可能更新。
- NVIDIA 原始架構文章：三個控制面的概念來源，不作現行安裝清單。
- 官方架構、沙箱政策、推論：目前邊界、設定與憑證責任。
- 支援表、第一個 Agent、安全最佳做法：前提、官方範例與執行模式。
- v0.1.7 release、README、Issue #5093：版本、授權與具體社群回報。
資料去向清單、工作拆解與排查優先序是本站的整理判斷；圖解是本站原創示意。