Architecture Journal

Agent Sandbox：是什麼、為什麼需要、現在大家怎麼做

想像一個 coding agent 正在幫你修 bug。

它先讀 repo，接著跑測試，發現工具缺了就自己安裝，為了讓指令跑通還順手改了 shell 設定、環境變數，甚至把某些套件升級到最新版。結果 bug 可能還沒修好，你的本機環境先被改了。

這時候你真正想問的，通常不是「它會不會寫 Python」或「底下是不是 container」，而是：

當 agent 會自己讀檔、改檔、跑 shell、重試、改 strategy、跨多步保留狀態時，你到底要把這些副作用關在哪個邊界裡？

這才是 sandbox 真正要回答的問題。

如果把這篇文章收成一句話，我會這樣說：

sandbox 不是單純的 code runner，而是 agent 的 execution boundary。

sandbox 到底是什麼？

很多人一看到 sandbox，直覺會想到「把 code 丟進 container 跑」。這個理解不算錯，但不夠完整。

對 agent 來說，sandbox 真正處理的不是單次執行，而是副作用要被放在哪個邊界裡。

因為一個 agent 在工作時，通常不只會跑程式。它還可能會：

  1. 讀寫檔案
  2. 執行 shell
  3. 安裝依賴
  4. 保留工作狀態
  5. 存取 network、secrets 或外部系統

所以真正重要的，不是有沒有一個「盒子」，而是這些能力有沒有被放進同一個 execution contract。

常見會被一起納入這個邊界的東西包括：

  1. command execution
  2. file reads and writes
  3. working directory
  4. environment variables
  5. network access
  6. workspace state persistence

換句話說，當我們說 agent sandbox，比較接近在說：

一個讓 agent 可以做事，但不直接等於拿到整台主機的 execution workspace。

為什麼 agent 特別需要 sandbox？

如果只是單次跑一段程式，很多時候一個普通 code runner 就夠了。但 agent 不一樣。它會自己決定下一步、連續呼叫工具、在失敗後改 strategy，還會在任務過程中累積狀態。

風險模型也因此完全不同。

你擔心的不只是 code 有 bug，而是：

  1. agent 讀到不該讀的檔案
  2. agent 改壞 repo 或 host 狀態
  3. agent 需要 network 時直接對外亂打
  4. agent 把失敗包裝成成功
  5. agent 在限制之內自己找 workaround
  6. agent 的多步副作用很難回放或撤回

所以 sandbox 重要，不只是因為 agent 比一般 script 更危險，而是因為：

agent 是一個會主動尋找可行路徑的 executor。

也因為這樣，成熟一點的 sandbox 設計，通常不只管「能不能跑」，還會一起管：

  1. capability scope
  2. state persistence
  3. approval and escalation
  4. recovery and rollback
  5. audit and observability

Agent 和 Sandbox 常見的兩種組合

目前比較常見的做法，大致可以收斂成兩種 pattern。

Pattern 1：Agent 在 Sandbox 裡

第一種做法，是把 agent loop 本身放進 sandbox。agent、工具、工作目錄、安裝的依賴與檔案狀態，都待在同一個隔離環境裡，外部系統再透過 API、WebSocket 或其他 control plane 跟它溝通。

這種模式的好處是，agent 和工作環境耦合得很緊，很像真的給它一台電腦。對需要長時間保留狀態、依賴特定環境、或希望 production 很像本地開發的場景，這種做法很自然。

代價也很明顯。如果 agent 本身就在 sandbox 裡，那 secrets、agent code、prompt、runtime 狀態往往比較容易一起被放進去，信任邊界會變難切。更新 agent 邏輯、管理 session、恢復執行，也通常比較重。

Pattern 2：Sandbox 當成 Tool

第二種做法，是讓 agent 跑在本地或 trusted server 上。真正需要執行 code、shell 或檔案操作時，再透過 API 呼叫遠端 sandbox。

這種模式的好處是，control plane 和 execution plane 比較容易分開。agent state、API keys、workflow orchestration 可以留在 sandbox 外；sandbox 則專心承接副作用。這通常比較方便快速迭代 agent 邏輯，也比較容易替換 sandbox backend。

代價是每次執行都要跨一次網路邊界，所以延遲和 session lifecycle 會變得更重要。如果工作負載是很多細碎操作，這個成本會被放大。

現成 agent 產品現在怎麼做

如果只看目前官方文件，幾個主流產品其實已經開始收斂到相似的設計框架：權限模式決定要不要先問，sandbox 決定執行後能碰到什麼，workspace 或 project scope 則決定邊界畫在哪裡。

真正的差別，不是有沒有這些概念，而是它們目前做到多成熟，以及是不是預設就開著。

Codex

以 Codex 來看，官方文件已經很明確把 sandbox 放進預設工作流裡。當你使用 default permissions mode 時，sandbox 會自動套用；預設是 workspace-write 搭配 on-request approval。

這代表 sandbox 不是額外加值功能，而是日常本地工作模式的一部分。比較像是在產品層直接把 execution boundary 做成預設，而不是把 sandbox 當成額外選項。

Claude Code

Claude Code 的重點，則是把權限模式和隔離方法分得很清楚。permission modes 決定工具呼叫是否要先提示，isolation 則限制執行後能碰到什麼。

更重要的是，它把不同層級的隔離拆開來講。內建的 Bash sandbox 只限制 Bash 命令本身；如果你要把檔案工具、MCP servers 和 hooks 也放進同一個邊界裡，還需要 sandbox runtime、container 或 VM。

這種切法很清楚地提醒你：不是任何「能跑命令」的機制都等於完整 sandbox。它的特色不在於特別偏哪一種 pattern，而在於把 permission 和 isolation 的責任切得特別細。

GitHub Copilot

GitHub Copilot 也已經明確往這個方向走。官方文件裡有 local sandbox、cloud sandbox、filesystem and network controls，以及 enterprise policy enforcement。

不過它目前仍是 public preview，而且部分能力需要額外 enable，cloud sandbox 也牽涉組織或企業層的 policy 開關。所以從成熟度來看，它比較像是正在把 sandbox 相關控制能力做成更完整的產品功能，而不是已經成為每個使用者的預設工作方式。

如果把這一段收成一句話，我會這樣說：

幾個熱門 agent 產品都在往相似的 sandbox、permissions 與 boundary 架構收斂；差別主要在於 sandbox 是不是預設行為、permission 和 isolation 切得多細，以及整個產品化程度到了哪裡。

如果你自己做 agent，可以看哪些框架

如果從開發者角度看，這裡其實不用把框架內部的抽象切得太細。先知道它們都有在整合 sandbox 或 code execution 相關能力，而且實務上通常都更容易落到 Sandbox as Tool 這種做法，就夠用了。

LangChain / LangGraph

LangChain / LangGraph 很明確把 agent 和 sandbox 的組合整理成兩種 pattern。

Agent in Sandbox 指的是 agent loop 本身就在 VM、container 或 remote workspace 裡執行；Sandbox as Tool 則是 agent loop 留在外部，需要跑檔案或 command 時才呼叫遠端 sandbox。

就 Deep Agents 目前的整合來看，重心明顯還是後者，已經接上 LangSmith、Daytona、Modal、Runloop、AgentCore 這些 remote sandbox。

ADK

ADK 的路徑其實也很像。agent 本身可以直接部署在 VM、container 或 Cloud Run 這類隔離 compute 環境裡，這在部署拓樸上接近 Agent in Sandbox；也可以把程式執行丟到獨立 execution environment，讓 agent 本身的執行環境和實際跑 code 的環境分開，這又接近 Sandbox as Tool。

官方現在的 code integrations 裡，和這條線最相關的例子包括 Environment Toolset、Agent Runtime Code Execution、GKE Code Executor，以及第三方的 Daytona。

換句話說，兩邊都有現成整合；差別主要不在有沒有 sandbox，而在你怎麼把它接進 agent workflow。

總結

sandbox 不是單純的 code runner，而是 agent 的 execution boundary。

它重要，不只是因為 agent 會跑程式，而是因為 agent 會連續使用工具、累積狀態、自己找路徑，最後把副作用留在某個工作環境裡。

從現在主流產品和框架的做法來看，真正的差別已經不在「要不要 sandbox」，而在：

  1. agent 和 sandbox 怎麼組合
  2. control plane 和 execution plane 怎麼切
  3. sandbox 是不是預設行為
  4. permission、isolation、workspace boundary 怎麼一起被治理

這也是為什麼 sandbox 會變成 agent engineering 裡越來越核心的主題。它不是附加安全功能，而是 agent 能不能安全工作、能不能穩定擴展的基礎設計。

參考資料

LangChain

OpenAI

ADK

其他產品