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

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

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

讓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等）而不觸及開發者機器；針對當前程式碼狀態執行測試套件、讀取失敗輸出、嘗試修復、重新執行測試並交付已驗證的補丁；處理多個並行分支，每個分支都有自己的沙箱，比較不同方法的結果；安裝和測試依賴項，而無需在本地機器上安裝包。

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