Modal 的沙箱：給智能體一台可以隨便折騰的整機

給一個 AI 智能體執行程式碼的能力很容易。給它一個安全的地方執行，不容易。2026 年 10 月 1 日，Modal Labs 發布了面向智能體的完整 VM 沙箱，給每個智能體一台可以執行程式碼和工具、又不觸碰任何它不該碰的東西的完整電腦。這是一個基礎設施發布，不是模型發布，而它處理的是智能體故事裡比較頑固的問題之一。

問題很容易講清。一個只會聊天的智能體無害。一個能行動的智能體需要一個行動的地方，而它可能行動的地方，從生產資料庫到開發者自己的機器，恰恰是你最不能讓它搞壞的地方。沙箱試圖解決這個問題，給智能體一個一次性的世界，在那裡犯錯除了重啟之外不花任何代價。

為什麼容器不總是夠

大多數智能體執行時已經以某種形式隔離程式碼，通常是容器。容器很擅長阻止智能體遊蕩到盒子外，但它們與主機共享核心，當盒子裡是不可預測的東西時，可能以要緊的方式洩漏。完整虛擬機更重但更嚴格：智能體得到自己的作業系統、自己的檔案系統、自己的網路視圖，隔離在更低的層次上成立。

對一個做日常工作的智能體，區別可能永遠不顯現。對一個執行任意生成的程式碼、從網際網路抓取東西或安裝依賴的智能體，區別就是全部要點。沙箱不是讓智能體更快，而是在智能體做了意外的事時，讓爆炸半徑是一台一次性機器。

{{INLINE1}}

這個發布背後的趨勢

Modal 的時機反映了一個更廣的轉向。智能體從演示走向流水線，而一旦進入流水線，它們就拿到真實權限。當智能體持有憑據的那一刻，它在哪裡執行就變成一個安全問題而非便利問題。這就是為什麼過去幾個月湧現出一連串沙箱、權限和治理工具。行業在建造讓智能體可部署的那些無聊部分。

有一個值得點名的諷刺。模型拿到頭條，但決定智能體是否可信的層次，卻是由普通工程構成的。跨工作階段保持上下文的記憶系統，容納錯誤的沙箱，記錄使用者同意了什麼的一致協議：這些在演示裡都不驚豔，而它們全都是一台玩具和一家公司真的會跑的東西之間的分別。

採用一個沙箱前該問什麼

不是每個沙箱都一樣，問題很實際。一個啟動有多快，因為慢的冷啟動會把每次智能體呼叫變成等待。智能體能觸及什麼，能否按任務鎖死。任務結束時狀態怎樣，有多少被記錄。它能否可靠地扛住不可信程式碼，還是只為守規矩的腳本調過參。答案決定這個沙箱是一條真正的邊界，還是形式。

最強的沙箱假設裡面的程式碼會是敵意的或壞掉的，並設計成兩種結果都逃不出去。這與一個供人把玩的開發環境是不同的設計目標。對智能體工作來說，假設敵意是正確的，因為生成的程式碼本質不可預測，而智能體從你無法完全控制的來源接收指令。

它與智能體堆疊的其餘部分如何配合

沙箱是關於智能體基礎設施更大論述的一塊。智能體需要記憶以便接著上次繼續，需要權限以便只碰該碰的，需要一個執行的地方以便讓錯誤被容納。每一項都是獨立的關切，每一項在過去一年都催生了自己的一波工具。沙箱是容納那一塊，而隨著智能體獲得更多自主性，它越來越重要。

這就是趨勢線。早期智能體一步一步執行，每一步都由人批准。行進的方向是智能體執行更久、採取更多行動、需要更少監督。一個智能體的自主性越大，它越需要一條不依賴人來及時抓住它的邊界。完整 VM 是比容器更重的工具，而願意付這份重量的理由，正是為了不再依賴監督。

還有一個很少被討論的成本維度。沙箱讓嘗試變便宜，而不只是變安全。一個能啟動一台全新機器、弄壞它、再扔掉它的智能體，把失敗當作免費。這改變了智能體工作的方式：它可以更實驗性，測試更多方法，從死胡同裡恢復而無需人來收拾。容納和實驗，其實是從兩個角度看同一個特性。

對任何沙箱的一個測試

採用之前，先跑一個簡單實驗。給智能體一個需要安裝不熟悉的套件、從網際網路抓取東西並寫磁碟的任務。然後看沙箱能看到什麼。它能否意外觸及你的內部網路。一個崩潰的任務會不會留下東西。一個新實例啟動要多久。這些問題回答起來快，它們揭示隔離是真的還是裝飾性的。

然後故意弄壞它。餵給沙箱試圖逃逸、生成背景程序、陷入迴圈的程式碼。好的沙箱把這一切當作預期並容納它們。弱的沙箱要么掛起、洩漏，要么倒下。願意這樣測試，本身就是認真對待智能體安全的團隊的標誌，而它遠比在生產裡發現極限便宜。

為什麼這比它看起來更重要

對有用智能體的瓶頸已從智能轉向信任。模型已經足夠能幹，能完成很多真實任務，而它們沒有做更多，是因為人們還不放心交出鑰匙。沙箱是改變這種舒適度的工具之一，因為它們讓一個謹慎的操作者能以一種最壞情況被容納的模式執行智能體。

像這樣的發布永遠不會在新聞流裡走紅。它們是決定過去一年雄心勃勃的智能體演示，是否會變成在某個週二無人看著也能執行的東西的管道。如果你在構建智能體，這是值得投入注意力的那層，因為無法被容納的智能體不會被信任，而不被信任的智能體不會被部署。