本文要點
- 獨立開發者:準備把程式碼執行型 Agent 從 Demo 推向可重複執行的任務。
- AI 應用工程師:需要安裝依賴、讀寫檔案,並呼叫業務 API。
- 平台工程師:負責沙箱、密鑰、網路出口、日誌與稽核邊界。
症狀:Agent 能讀寫檔案,卻在安裝套件、呼叫 API 或連線內部服務時失敗。 最快解法:先按「無網路」設計;只有任務確實需要時才開放有限出口,若涉及私有 API、資料庫或內部服務,優先改用受控閘道或自託管環境。
官方 Sandbox Agent 指南 已將程式碼執行、檔案處理與依賴設定列為核心工作流程,但這不代表每個 Hosted Sandbox 都應直接連上整個網際網路。本文把部署問題拆成四類任務:本地檔案計算、安裝依賴、公共 API 存取,以及私有服務操作,讓你在使用 OpenAI Hosted Sandboxes 網路配置 前先決定正確的安全邊界。
這篇文章適合三類讀者:
- 獨立開發者:準備把程式碼執行型 Agent 從 Demo 推向可重複執行的任務。
- AI 應用工程師:需要安裝依賴、讀寫檔案,並呼叫業務 API。
- 平台工程師:負責沙箱、密鑰、網路出口、日誌與稽核邊界。
先判斷任務需要哪一種網路邊界
你不應從「怎樣把網路打開」開始,而要先問 Agent 是否真的需要對外連線。以 OpenAI Agents API 建立的程式碼執行工作,很多其實只需要輸入檔案、固定套件和輸出產物;這類任務若開放網路,反而增加下載惡意套件、外傳資料或讀取未授權內容的風險。
| 任務類型 | 建議網路狀態 | 主要限制 | 適合的部署路徑 |
|---|---|---|---|
| 本地檔案計算、格式轉換 | 保持無網路 | 只掛載必要工作目錄 | Hosted Sandbox |
| 安裝 Python、Node.js 或系統套件 | 啟動階段有限出口 | 固定套件來源與版本 | Hosted Sandbox 或自託管 |
| 呼叫公共 API、下載公開資料 | 允許指定出口 | 限制網域、方法與請求頻率 | Hosted Sandbox,先做連線驗證 |
| 操作企業 API、資料庫或內部 webhook | 不直接暴露內網 | 使用受控後端代理 | 自託管或受控閘道 |
| 長時間執行、需要持久工作區 | 依需求配置 | 明確處理工作區、日誌和復原 | 自託管或雲端工作區 |
判斷可採用以下條件分支:
- 若任務只處理已上傳檔案,選無網路沙箱;不要為了「方便除錯」先開放公共出口。
- 若任務只需要安裝固定依賴或呼叫一個公共 API,選有限出口,並把允許的網域與請求用途寫進部署設定。
- 若任務需要讀取企業內網、資料庫或內部檔案,回退到自託管環境,或讓沙箱只能呼叫一個不暴露內網的後端代理。
- 若任務需要長期工作區、完整網路規則或特殊系統權限,不要勉強擴大 Hosted Sandbox 權限,改評估可完整管理的雲端工作區。
官方 Agents API 介紹 說明 Agent 可組合模型、工具和工作流程;這個能力邊界不等於你的業務 API、資料庫或宿主環境會自動被安全隔離。網路策略仍然要以當前 Hosted Sandbox 開發者文件實際支援的欄位和環境狀態為準。
注意: 社群討論中的「即將支援網路白名單」或未正式公布的安全保證,不可當成目前已發布能力。設定完成後,必須用可觀察的 DNS、TLS、HTTP 回應和檔案存取結果驗證。
工作目錄與依賴配置會如何影響 Agent
網路配置不是獨立開關。工作目錄、啟動命令、套件管理器和輸入檔案位置互相牽制;其中任何一項未固定,Agent 都可能在看似成功的環境中產生不可重現的結果。
第一,工作目錄應只包含當前任務需要的檔案。不要把宿主環境的家目錄、整個專案母目錄或含有設定檔的路徑直接掛載給模型。輸入檔、暫存檔和最終產物最好分開,並明確規定 Agent 可以寫入的位置。
第二,Python、Node.js 和系統套件應在環境啟動階段安裝。把版本、來源和安裝順序寫入 setup commands 或等效初始化流程,避免模型依當下錯誤訊息臨時選擇另一個版本。官方 Sandbox Agents 文件 可作為確認 Agent 與沙箱整合方式的基礎,但具體套件來源仍應由你的部署流程鎖定。
第三,必須用最小任務驗證「真的可用」,而不是只看安裝命令回傳成功。建議依序執行:
- 建立乾淨的 Hosted Sandbox,確認環境狀態為可用。
- 檢查工作目錄,只列出預期的檔案和資料夾。
- 執行 Python、Node.js 版本查詢,以及一個最小匯入測試。
- 讀取一個測試檔、寫入暫存位置,再驗證輸出檔內容。
- 在需要外部連線時,測試指定網域的 DNS、TLS 和最小 HTTP 請求。
- 重新建立相同環境,確認依賴和結果不依賴上一個工作階段殘留內容。
| 配置項目 | 應在啟動階段固定的內容 | 觀察證據 |
|---|---|---|
| 工作目錄 | 輸入、暫存、輸出路徑 | 目錄清單與檔案權限 |
| Python 依賴 | 套件名稱、版本、來源 | 安裝輸出與匯入測試 |
| Node.js 依賴 | package manifest、鎖定檔 | 安裝結果與最小執行 |
| 系統依賴 | 必要命令、套件來源 | 命令版本與退出狀態 |
| 網路出口 | 允許網域、連接埠、用途 | DNS、TLS、HTTP 回應 |
| 任務產物 | 可下載檔案和清理規則 | 雜湊、檔案清單和下載紀錄 |
如果一個套件只能在任務中途下載,先問它是否真的屬於執行時需求;若答案是肯定的,應把它移到可審查的初始化流程。否則,每一次模型重試都可能得到不同版本或不同錯誤。
外部 API、資料庫與私有服務應分層接入
公共 API、企業內網、資料庫和 webhook 不是同一種風險。公共 API 主要涉及出口限制、憑據和回應內容;資料庫還涉及查詢權限、資料列範圍和長期連線;webhook 則可能把 Agent 產生的內容送入不可逆的業務流程。
較穩妥的架構是:
- Agent 只呼叫一個受控後端代理。
- 代理驗證任務身分、允許的方法和目標資源。
- 代理在伺服器端取得短期憑據,不把長期 API Key 傳入提示詞或工作目錄。
- 代理只回傳任務需要的欄位,並遮罩敏感資料。
- 代理記錄請求、回應狀態、操作者和任務識別碼,讓平台工程師可以追查。
對公共 API,可以採用限定網域與路徑的出口;對企業服務,則不要以「沙箱能連到內網」作為安全設計。資料庫帳戶應只允許必要的唯讀查詢,寫入操作最好改成需要人工確認或由固定後端函式執行。webhook 也應使用一次性或短時效簽章,避免模型取得可以重複觸發業務流程的長期密鑰。
| 接入方式 | 沙箱可見內容 | 建議憑據方式 | 不應採用的做法 |
|---|---|---|---|
| 公共 API | 必要回應欄位 | 短期 Token、網域限制 | 把長期 Key 寫入提示詞 |
| 企業 API | 代理回傳的最小資料 | 後端代取憑據 | 直接暴露內網路由 |
| 資料庫 | 固定查詢結果 | 唯讀、最小資料範圍 | 讓 Agent 取得完整連線字串 |
| webhook | 代理產生的請求 | 短效簽章、方法限制 | 直接把管理權杖放入檔案 |
| 檔案服務 | 任務所需檔案 | 受限物件識別碼 | 掛載整個共享硬碟 |
OpenAI 的 工具文件 可用來確認工具如何被 Agent 呼叫,但工具定義本身不會替你的業務權限模型作決策。你仍需在工具背後的服務層實作驗證、限流、欄位過濾與稽核。
FAQ:網路、依賴與密鑰的常見判斷
OpenAI Hosted Sandboxes 預設可以直接存取網際網路嗎?
不要把網際網路連線視為理所當然的預設能力。你應先依目前官方 Sandbox 文件確認環境的網路欄位與限制;在未驗證前,將 Agent 按無網路設計,只用本地檔案與已配置依賴完成測試,確實需要外部服務時再開放最小出口。
Hosted Sandbox 如何安裝 Python、Node.js 和系統依賴?
把固定版本的 Python 套件、npm 套件和必要系統套件放在環境啟動階段的 setup commands 或等效初始化流程中,並以一個最小匯入、版本查詢與實際執行測試驗證。不要讓模型在任務中自行決定套件來源或版本。
Agent 沙箱呼叫外部 API 時,應該採用哪種網路架構?
公共 API 可以透過受限出口使用,但企業內網、資料庫與 webhook 不應直接暴露給沙箱。較穩妥的做法是由受控後端代理轉發請求,採用短期憑據、允許的方法與路徑清單,並把回應資料限制在該任務真正需要的範圍。
OpenAI Hosted Sandboxes 如何避免洩露 API Key?
不要把 API Key 放進提示詞、輸入檔、工作目錄或模型可讀的日誌。改由受控服務在伺服器端注入短期憑據,限制權限、來源與有效時間;同時遮罩命令輸出、錯誤事件和下載產物中的敏感欄位,並定期檢查 Agent 是否能讀取不相關檔案。
Hosted Sandbox 網路存取失敗時,應該先檢查哪些地方?
先確認環境是否成功建立,再查看目標主機、DNS、TLS 和出口限制,接著分離依賴安裝錯誤與遠端服務故障。每次排查都應保留環境狀態、命令輸出、錯誤事件、輸入檔案版本與重試結果,避免把 Agent 的錯誤判斷誤認為網路配置問題。
Hosted Sandbox 網路失敗要按照證據排查
網路錯誤不應只交給 Agent 自己重試。你要先把問題分成環境建立、連線拒絕、DNS 或 TLS、依賴安裝,以及任務超時,再按順序保存證據。
| 症狀 | 優先檢查 | 可接受的證據 | 常見誤判 |
|---|---|---|---|
| 環境建立失敗 | 初始化設定、工作目錄、依賴命令 | 建立事件與完整輸出 | 以為是模型沒有遵循指令 |
| 連線被拒絕 | 出口規則、目標連接埠、服務狀態 | 目標、連接埠與錯誤時間 | 只重試而不確認服務是否可用 |
| DNS 失敗 | 網域名稱、解析環境、拼字 | DNS 結果與環境識別 | 把不存在的網域當成網路封鎖 |
| TLS 錯誤 | 憑證鏈、系統時間、代理設定 | TLS 錯誤輸出與目標憑證 | 直接關閉憑證驗證 |
| 套件安裝失敗 | 來源、版本、系統依賴 | 安裝日誌與套件鎖定檔 | 把不相容版本換成任意最新版 |
| 任務超時 | 外部服務、檔案大小、重試策略 | 時間線、輸入版本、請求狀態 | 認定 Agent 一定陷入迴圈 |
排查時應保存環境狀態、錯誤事件、命令輸出、輸入檔案版本和產物雜湊。若同一請求在沙箱外也失敗,問題更可能是外部服務或憑據;若只有沙箱失敗,再檢查出口、DNS、TLS 和工作目錄。這種分層能把配置錯誤、服務故障與 Agent 誤判分開。
官方 Sandbox Clients 文件 可用於核對客戶端和沙箱互動方式;當 OpenAI 更新環境建立、網路欄位或自託管接入方式時,應重新核對介面名稱,不要沿用舊版範例。
經驗: 若錯誤日誌包含完整 URL、Authorization 標頭、環境變數或檔案內容,先停止擴大重試,立即遮罩並輪換憑據。可觀測性不能以洩露秘密為代價。
上線前收縮權限並保留可追查紀錄
從 Demo 走向雲端 AI Agent 生產環境時,至少要驗證以下邊界:
- 網路出口只允許任務必要的網域、方法和連接埠。
- 工作目錄不包含宿主環境、其他使用者或未相關專案的檔案。
- 套件來源和版本可重建,不由模型在執行中任意變更。
- API Key 不出現在提示詞、輸入檔、命令輸出、錯誤事件或下載產物。
- Agent 嘗試讀取無關路徑時會被拒絕,並產生可追查事件。
- 產物下載前會掃描敏感欄位,下載後能對應到任務識別碼與輸入版本。
- 任務失敗時可以重新建立乾淨環境,而不是依賴上一個工作階段的殘留狀態。
你可以先建立一個「越權測試」:讓 Agent 嘗試列出工作目錄以外的路徑、讀取不存在的環境變數,以及向未列入允許清單的網域發出請求。預期結果不是「模型說自己做不到」,而是作業系統、沙箱或代理服務實際拒絕,並留下可查詢的錯誤事件。
如果你的工作需要完整自訂網路、長期工作區、固定遠端連線方式或持續執行的背景服務,雲端 Mac 或其他遠端開發環境可能比 Hosted Sandbox 更合適。這類方案的代價是你必須自行負責修補、帳戶隔離、網路規則、密鑰輪換與長期稽核;但它能提供 Hosted Sandbox 未必提供的自訂程度。你可以先參考 kvmboot 的說明中心 了解遠端環境管理方式,必要時再透過 kvmboot 聯絡頁面確認適合的工作區路徑。
依任務選擇 Hosted Sandbox、自託管或雲端工作區
| 任務 | Hosted Sandbox | 自託管環境 | 雲端工作區 |
|---|---|---|---|
| 結構化資料清洗 | 優先選用,保持無網路 | 當需要內部資料庫時使用 | 當需長期保存工作檔時使用 |
| 程式碼建置與測試 | 適合固定依賴和短任務 | 適合特殊系統套件 | 適合持久專案與互動除錯 |
| 網頁抓取 | 只在出口和目標規則清楚時使用 | 適合自訂代理和排程 | 適合需要瀏覽器狀態保存時使用 |
| 內部系統操作 | 不建議直接打開內網 | 優先使用受控網段 | 適合完整網路和帳戶隔離需求 |
| 長任務 Agent | 先確認狀態、產物和逾時行為 | 適合自行管理復原機制 | 適合需要持久工作區的流程 |
部署前可以用以下清單作最後決策:
- 任務是否可以在完全無網路下完成?
- 若需要網路,能否只允許指定網域和請求用途?
- 私有 API、資料庫或 webhook 是否經過受控後端代理?
- 所有套件是否已在啟動階段固定來源與版本?
- 工作目錄是否只包含必要檔案?
- 憑據是否完全避開提示詞、檔案和模型可讀日誌?
- 網路錯誤、環境狀態和輸入版本是否會被保存?
- 任務失敗後能否用乾淨環境重現,而不是依靠人工猜測?
- 若需要長期工作區或完整網路控制,是否已評估自託管或雲端工作區?
若你目前的方案是直接把 API Key 放進提示詞、把整個專案掛載給 Agent,再用開放網路處理所有錯誤,真正的缺點不只是風險較高,也包括結果難以重現、權限邊界不清,以及出錯後無法分辨是沙箱、外部服務還是模型判斷造成。相較之下,租用 kvmboot 的雲端 Mac 或遠端工作區,可在需要完整自訂網路、持久工作目錄和遠端開發工具時提供更可控的環境;但若你只是執行短期、無網路的檔案任務,Hosted Sandbox 仍可能是更精簡的選擇。你可以先閱讀 kvmboot 的服務介紹,再按照本文的網路與憑據清單,判斷目前應維持托管沙箱,還是遷移到可自行管理的雲端工作區。
為您的 Agent 打造可控的遠端 Mac 執行環境
需要更完整的網路與系統控制權?使用 kvmboot 遠端 Mac,將 Agent 工作負載放在獨立的 macOS 環境中執行。
MCP Server 部署位置:雲端、VPS 與本機的網路出口取捨 · AI Agent 檔案隔離:從路徑白名單到沙箱的安全實務 · 最小權限網路出口:預簽名 URL、短時憑據與 Runner 完整性校驗