用 Docker 承接 AI agent 的程式執行，直覺上很合理：便宜、熟悉、啟動快，工程師也知道怎麼掛 volume、限制 image、跑測試。問題是，很多團隊會在這一步偷偷把「容器隔離」升級成「安全沙盒」，這就是坑。

Docker 適合的場景，是你已經能控制輸入、任務短、權限窄，而且主要目的只是避免 agent 把工作目錄弄髒。例如讓 coding agent 在臨時 checkout 裡跑單元測試，或讓資料助理處理一份非敏感 CSV，跑完就丟。這種用法很務實，成本也比一開始就上雲端 sandbox 平台低。

但 Docker 不適合被拿來安撫所有安全焦慮。agent 一旦能安裝套件、連外、掛 host volume、讀內部檔案、呼叫公司 API，真正的風險就不只在 container 裡。你要回答的是：網路能去哪裡？檔案能看到哪裡？secret 怎麼注入？任務結果保留多久？使用者之間怎麼隔離？失敗後誰能重播與稽核？

最常見的錯誤，是把 host 的專案目錄直接掛進去，再給 agent 很寬的 shell 權限。這樣看起來像 sandbox，實際上只是把風險換了一個 process 跑。第二個錯誤，是沒有網路策略。惡意套件、prompt injection、被污染的 repo script，都可能把執行路徑帶去你沒預期的地方。

採用判斷很簡單：如果你只是做內部原型，Docker 是合理的第一步；如果你要處理陌生使用者上傳資料、多租戶任務、瀏覽器操作、或會接觸正式憑證的 agent，就不要把 Docker 當終點。這時候至少要補上 ephemeral workspace、唯讀掛載、egress allowlist、資源上限、secret 最小化、完整 log，必要時再看 E2B、Firecracker、Kubernetes sandbox 或受管執行環境。

一句話：Docker 可以是 agent 執行層的腳踏車，不該被當成保險箱。它讓你快，但不會自動讓你安全；越早把「能跑」和「能承擔事故」分開，越不容易在 demo 成功後被正式環境反咬一口。