智能體需要自己的計算機：如何安全地賦予它們

在計算機歷史的大部分時間裏，開發者環境意味着物理機、虛擬機或容器，每一個都共享工作負載，需要刻意搭建和拆除。為每個智能體提供獨立的計算機——在一秒內啓動並在任務完成後自行清理——在規模化之前並不實用。沙箱為您提供了一種更安全的方式來運行升級的工作流，它提供了一個隔離的環境，用於執行需要迭代、驗證和訪問人類通常使用的工具的任務，而無需人工監督。每個人類開發者都有一台筆記本電腦，每個智能體都可以擁有一台計算機。

為什麼智能體需要自己的計算機

讓LLM調試失敗的測試或清理數據集，它大部分工作都能完成。它可以解釋修復方法、編寫查詢、概述分析。然後它停下來，你必須接手所有剩下的工作。問題在於，一個只能生成文本的系統就像一位承包商，能精確描述如何修理你的水管，但沒有手、沒有工具、沒有卡車。建議可能完美，但總得有人去扳動扳手。

智能體通過獲得“手”來縮小這一差距。讓模型能夠運行代碼、讀取結果並重試，完整的智能體循環使智能體能更自主地執行任務。一個只能建議修復方案的智能體無法知道修復是否有效。這就是智能體需要自己計算機的原因：一個真正的環境，包含文件系統、Shell、包管理器、網絡訪問和跨步驟持久化的狀態。

而當你只有一台筆記本電腦且可能只有你使用時，一個智能體平台可能會同時啓動數千個這樣的環境，每個都需要隔離、可丟棄且安全地交予實際執行能力。

實際上意味着什麼

• 編程智能體可以克隆倉庫、安裝依賴、運行測試套件、讀取失敗信息、修補代碼，並返回已驗證通過的差異。
• 數據分析智能體可以加載原始文件、檢查模式、用Python或SQL編寫轉換、生成圖表，並在向你展示報告前檢查自己的數學。
• 研究智能體可以瀏覽網頁、下載來源、解析並規範化、交叉引用聲明，並彙編帶有引用的完整報告。

在每個例子中，模型都在運行實際步驟並檢查實際結果。這需要一個工作場所，而不僅僅是一個推理的上下文窗口。

為什麼不能直接把基礎設施交給它

那麼為什麼不讓智能體在本地或Docker容器中運行代碼呢？大多數原型從本地開始：快速、熟悉，足以讓演示工作。然後進入生產環境，同樣的設置會在兩個方面開始失效：安全性（智能體要運行的代碼可能由人類未編寫、審查甚至未見）和隔離性（標準容器邊界並非為保存不受信任的模型生成代碼而設計）。

雖然你的智能體沒有惡意，但你不知道代碼來自何處。一行代碼可能來自模型本身、克隆的倉庫或中途安裝的包。智能體執行的代碼可以在運行前幾秒生成，直接受用户輸入影響，並在智能體推理任務過程中產生。中間沒有審查步驟。寫得好的提示詞並不能讓你免於安全顧慮。最安全的姿態是機器級隔離：給智能體一個真實的工作環境，但將該環境與你的筆記本電腦、生產環境以及所有其他智能體的工作空間隔離開。

每個智能體計算機需要做好的四件事

1. 安全執行：2025年，一個自我複製的npm蠕蟲後門了數百個包，並在任何測試運行前在預安裝鈎子中執行。2026年披露的Linux內核CVE可以用732字節的Python腳本在一小時內獲取任何主要發行版的root權限，而容器無法幫助，因為它們與宿主機共享內核。智能體執行的代碼應默認視為不可信，不論來源。每個智能體工作空間應是一個硬件虛擬化的機器，擁有自己的內核、文件系統和網絡邊界。

1. 保持控制：沙箱內的控制保護你免受智能體做出昂貴、意外或泄露憑據的行為。憑據管理：通過代理在網絡層注入憑據，智能體可以調用外部服務而無需看到令牌。資源限制：CPU限制、內存上限和網絡白名單/黑名單讓你為每個任務定義成本上限。生命週期控制：沙箱默認是臨時的，為任務啓動，需要時持久化狀態，空閒時清理。

1. 可觀測性：智能體執行的可觀測性意味着知道哪些命令運行了、哪些文件被創建或修改、哪些網絡調用發出、哪些包被安裝、每一步的輸出是什麼。這本質上是工作流的審計日誌，尤其對於接觸敏感數據或具有真實世界後果的行動。使智能體可靠的是能夠從已知狀態重新運行、比較分支並追溯實際發生情況的能力。

1. 快速構建和迭代：生產要求包括快速配置（熱啓動低於1秒）、可復現環境（由Docker鏡像或藍圖定義）和持久化狀態（文件、已安裝包和會話上下文在智能體輪次間保持）。如果啓動執行環境需要30秒，需要多個環境的智能體任務會感覺緩慢。如果環境不可復現，bug難以隔離。如果狀態不跨會話持久化，長時間運行的任務需要昂貴的重啓。

何時使用託管沙箱與自行構建

你可以DIY方式：在開發者筆記本上運行智能體，升級到Docker容器獲得一定分離，手動配置資源限制和憑據注入。對於只調用固定模式API且從不執行動態代碼的智能體，這通常足夠。當你想擴展到生成腳本、安裝包、運行測試套件或解析文件時，你必須為每個任務啓動虛擬機、安全注入憑據而不接觸運行時、構建快照和分支支持、記錄執行軌跡並將其關聯到智能體軌跡、處理清理、空閒檢測和配額管理。決策標準：如果智能體只調用API且不執行動態代碼，本地或容器化執行可能沒問題。如果智能體執行模型生成的代碼、安裝包或處理任意文件，則需要真正隔離，從頭構建意味着你在構建一個沙箱平台。DIY方法的生產級運營開銷迅速增加。託管沙箱路徑用更簡單的接口和平台處理工作規模來換取工程面。

LangSmith 沙箱：每個智能體一台計算機

每個LangSmith沙箱啓動快（中位時間低於1秒），作為硬件虛擬化的微虛擬機運行，有自己的內核，並在智能體工作會話中持久化狀態（文件、已安裝包、環境）。任務完成後，沙箱空閒並自動清理。容器與宿主機共享內核，而微虛擬機有自己的。在沙箱內，智能體可以安裝任何東西、運行Docker、啓動服務——而你的基礎設施和其他工作負載不受影響。

核心原語包括：微虛擬機隔離（每個沙箱內核隔離，不影響其他）、快照和分支（捕獲運行狀態，寫時複製分支，從快照並行啓動十個分支成本與一個類似）、認證代理（出站請求通過代理注入憑據，憑據不接觸運行時）和服務URL（通過認證HTTP訪問沙箱內運行的任何服務，無需端口轉發）。

一鍵設置示例：

from langsmith.sandbox import SandboxClient
client = SandboxClient()
with client.sandbox() as sb:
    result = sb.run("python my_analysis.py")
    print(result.stdout)

沙箱與Deep Agents、Open SWE、LangSmith Deployment、LangSmith Fleet以及任何自定義代碼兼容。它們使用與LangSmith其餘部分相同的SDK和API密鑰。

沙箱工作流中的提示注入注意事項

沙箱提供了強大的執行隔離，但它們不改變語言模型的一個基本屬性：智能體讀取的任何內容都會影響它下一步做什麼。當沙箱輸出被反饋給模型時，這一點很重要。一個示例擔憂是：研究智能體下載文檔，文檔包含看似給模型指令的文本，模型遵循它。這是LLM應用OWASP Top 10中的#1漏洞，適用於任何處理外部內容的智能體。沙箱不會消除注入威脅，但它們會限制執行爆炸半徑。在沙箱內運行的惡意代碼無法到達宿主機，但如果執行輸出未被質疑地由智能體讀取，輸出中的注入指令仍可能影響下游行為。

緩解措施包括：將沙箱輸出視為不可信數據；對於最敏感的工作流，使用“非智能體讀取”模式，由非模型進程從沙箱檢索成品；限制跨邊界智能體的本地訪問權限；在邊界應用輸出過濾，如結構化輸出模式、內容分類器或格式驗證；不要依賴提示讓模型檢測或忽略注入，對抗性研究一致表明這在規模上不足。這些並非沙箱獨有，任何從網頁讀取、處理上傳文件或調用外部API的智能體都有相同暴露。沙箱的附加價值在於幫助控制執行損害，且兩層都需要。

使用案例：編程智能體

編程智能體是沙箱的流行用例，因為執行隔離非常重要。一個能運行測試套件、檢查失敗、修補代碼並重新運行測試套件的智能體比僅能生成補丁並交回給開發者驗證的智能體有質的不同。沙箱中的編程智能體可以克隆倉庫並運行完整設置腳本（包括npm install、pip install等）而不觸及開發者機器；針對當前代碼狀態運行測試套件、讀取失敗輸出、嘗試修復、重新運行測試並交付已驗證的補丁；處理多個並行分支，每個分支都有自己的沙箱，比較不同方法的結果；安裝和測試依賴項，而無需在本地機器上安裝包。

編程智能體是沙箱工作的典型示例，因為安全邊界直接轉化為開發者信任。如果你相信智能體不能損害你的環境，你就更可能讓它自主運行。