Harbor 接上 Docker Sandboxes，agent 評測改在 microVM 裡跑
Docker Blog · 2026-10-14
Agent 評測框架 Harbor 現在能把每個評測任務丟進 Docker Sandboxes 的 microVM 執行，取代過去直接在主機或共用核心的容器裡跑 AI 寫出來的程式碼。Docker 在 2026-10-14 的文章中同時說明，這套組合可以在任務設定階段開放網路、agent 作業階段切斷網路，讓每個 agent 在同樣條件下被評比。
原本的問題
Agent 評測的做法是讓 agent 完成一個真實任務，再檢查結果。過程中 agent 會安裝套件、改檔案、執行指令，也就是把不受信任的 AI 生成程式碼跑上成千上萬次。
另一個麻煩是 reward hacking：文章舉的例子是 agent 動手改測試，或改寫記錄分數的檔案。如果評測環境和主機、或和其他任務共用資源，這類行為不只污染分數，還可能碰到你的機器。
所以跑評測需要兩樣東西：負責派任務、收成果、驗證、記分的評測框架（Harbor，開源，可跑 Terminal-Bench 這類 benchmark），以及每個任務各自乾淨隔離的環境（Docker Sandboxes）。
實務上這代表評測的可信度取決於隔離做得多好。隔離不足時，分數高低可能反映的是 agent 鑽了環境的漏洞，而不是解題能力；隔離太鬆，一次失控的 agent 還可能影響同一台機器上的其他任務，讓重跑的結果無法對照。
採用的方法
Docker Sandboxes 讓每個 agent session 跑在專屬的 microVM 裡，擁有自己的核心與私有的 Docker daemon，以 VM 邊界隔離，沒有路徑回到主機（見 Why MicroVMs）。這點對評測特別重要：agent 常需要自己 build、跑容器，若用容器內再跑 Docker 的做法，需要提升權限，那份文章的說法是這會削弱你一開始設下的隔離。
網路則靠政策控制。檔案存取、網路政策與機密都在 agent 啟動之前定義，而不是由 agent 自己遵守；憑證在 microVM 邊界之外於執行時注入。文章沒有說明政策在內部如何實作。
Harbor 側則是一個旗標的事。安裝並以雲端沙箱跑一個任務：
uv tool install "harbor[sbx]"
export SBX_DOCKER_USERNAME="your-docker-id"
export SBX_DOCKER_PAT="your-personal-access-token"
harbor run -t hello-world/hello-world -a oracle -e sbxPAT 需要 Cloud Sandboxes 權限，而且只會顯示一次。要改在本機跑，先安裝 Docker Sandboxes CLI、執行 sbx login，再在同一行指令加上 --ek target=local。文章說同一組任務在筆電與雲端沙箱之間不需修改。
實際效果
| 面向 | 以前常見做法 | Harbor + Sandboxes |
|---|---|---|
| 隔離邊界 | 主機或共用核心的容器 | 每任務一個 microVM，自有核心 |
| 網路 | 通常全開或全關 | 設定階段可下載依賴，agent 作業時斷網 |
| 並行 | 自行準備機器 | Cloud Sandboxes，作者以 64 個並行 worker 測過 Harbor |
第一列與第二列的「以前常見做法」是對照用的一般描述，不是文章裡的量測；文章也未公布 64 個 worker 下的耗時或成本。Docker 對 microVM 冷啟動只形容為「near-instant」，沒有給數字。
影響範圍
- 維護內部 agent benchmark 的團隊：若目前評測直接跑在 CI runner 上，要檢查 agent 能否碰到 runner 的憑證或網路。改成
-e sbx後這些都被擋在 VM 外。 - 在意分數可比性的人：同一份任務、同一套斷網規則，才能排除「某個 agent 在作業中偷抓外部答案」這種差異。
- 需要 GPU 或多容器任務的人：目前整合只支援單一容器、CPU 任務，GPU 與多容器支援文章標示為「coming soon」，尚無時程。
另外 Harbor 的文件首頁只列出任務、模型、agent、沙箱與 skills 五種輸入，沒有說明任務目錄格式與驗證器細節，要寫自己的任務得再讀它的 Task overview 頁面。