Amazon 研究團隊在一篇論文裡提出 Sandman，一個給生產環境 agentic reinforcement learning 使用的共享 Kubernetes sandbox service。它要處理的不是模型回答得好不好，而是工具執行時很具體、也很容易被忽略的基礎工作：每次呼叫之間保留檔案與程序，面對大量同時建立的 sandbox，等待服務 ready，並在 timeout 或取消後完成清理。論文自述在特定生產環境的兩週期間，支援 122 次 coding agent training runs、310 萬個 sandboxes，峰值 11,858 個；一次 10,000 request burst，半數在 116 秒可用、全部在 308 秒可用。作者也報告，相對於調校過的 agent sandbox，完整交付速度快 44%，no op command 的 median latency 是 2.0 毫秒，對照組為 14.3 與 203.5 毫秒。這些是論文自述、特定系統與部署條件下的實驗結果，不是通用保證。

我覺得這篇真正值得討論的地方，在於它把 AI 的勞動現場攤開來。當代理數量從幾個變成幾千、幾百萬，誰來確認取消的工作真的停止？誰處理殘留程序、孤兒檔案、未釋放的 CPU 與儲存？如果排隊機制只是先到先服務，資源多的團隊會不會更容易把別人的實驗擠到後面？這些看似工程細節，其實都在分配等待、成本與風險。

更重要的是責任不能被「自動化」這個詞沖淡。sandbox 失敗時，可能是平台團隊、模型研究者、使用者，還是負責預算的人要說明原因？若取消後的遺留沒有可追蹤的擁有人，清理工作就會變成某些工程師默默承擔的隱形勞動。長期下來，系統表面上更有效率，維運者卻承受更多待命、排錯與資源爭議。

所以我會把評估問題從「代理能不能大規模跑」改成「大規模運作的代價由誰承擔」。除了延遲與吞吐量，也要公開清理成功率、取消後殘留、資源使用的公平性、排隊規則與責任交接。沒有這些治理資料，再漂亮的 benchmark 也只是在展示系統能把工作推出去，沒有證明它能把後果接住。