我最早把 AI Agent 落地到業(yè)務(wù)里時(shí)第一件事不是選模型而是先解決一個(gè)看著很小的問題Agent 生成的代碼在哪里跑。當(dāng)時(shí)我用 FastAPI LangGraph 搭了一條工具調(diào)用鏈路圖省事直接 subprocess.Popen 去執(zhí)行模型生成的 Python 腳本來做文件解析。結(jié)果模型在一段清洗 CSV 的代碼里寫了個(gè) while True整個(gè)實(shí)例的 CPU 被打滿我那臺服務(wù)器上其他接口全部超時(shí)。那次事故之后AI Agent 沙箱就成了我架構(gòu)里的默認(rèn)項(xiàng)而不是可選項(xiàng)。這兩年我先后試過 E2B 這種基于 MicroVM 的執(zhí)行沙箱、Modal 這種偏平臺化的云端沙箱也長期維護(hù)過基于 All-in-One 容器思路的自建沙箱。這篇文章不打算做純概念科普我按自己的理解講講這幾條路線各自解決什么問題、適合什么規(guī)模的業(yè)務(wù)以及真正決定選型的那幾個(gè)指標(biāo)。1. 為什么 Agent 需要一個(gè)真正的執(zhí)行沙箱從一次被打爆的實(shí)例說起1.1 Agent 不是只有調(diào)用 API這一個(gè)動作傳統(tǒng)業(yè)務(wù)代碼里的風(fēng)險(xiǎn)是可控的調(diào)用鏈路上的每個(gè)函數(shù)都是我們自己寫的輸入輸出邊界清晰。但 Agent 不一樣它會把任務(wù)拆成多個(gè)工具調(diào)用而這些工具里經(jīng)常包含生成一段代碼并執(zhí)行它這類動作。典型場景就是 Python 代碼解釋器。模型為了完成數(shù)據(jù)清洗、格式轉(zhuǎn)換、文件處理會生成暫時(shí)存在的腳本你沒法在運(yùn)行前逐行審查。更麻煩的是Agent 還會調(diào)用外部命令安裝依賴包、跑 shell 腳本、連接外部服務(wù)。這些動作如果直接在業(yè)務(wù)進(jìn)程里執(zhí)行一旦出現(xiàn)死循環(huán)、內(nèi)存暴漲、惡意讀取系統(tǒng)文件整個(gè)服務(wù)都會被拖下水。我那次被打爆的事故本質(zhì)上就是缺少一層執(zhí)行邊界。subprocess 確實(shí)能啟動一個(gè)新進(jìn)程但這個(gè)進(jìn)程仍然共享宿主的內(nèi)核、文件系統(tǒng)和網(wǎng)絡(luò)棧。進(jìn)程的唯一隔離手段是操作系統(tǒng)賬號和權(quán)限對資源消耗基本沒有硬性限制。1.2 隔離邊界有四個(gè)層級你要知道自己在哪一層我在對比方案之前先把自己腦子里那套隔離坐標(biāo)系理清楚了。從寬松到嚴(yán)格大致分四層子進(jìn)程隔離啟動方便共享內(nèi)核資源不可控適合完全可信代碼。容器隔離借助 Linux namespace 和 cgroup 做資源限制密度高、啟動快但共享宿主內(nèi)核理論上存在內(nèi)核逃逸風(fēng)險(xiǎn)。用戶態(tài)內(nèi)核/輕量虛擬機(jī)像 gVisor 這種給容器加一層用戶態(tài)內(nèi)核攔截系統(tǒng)調(diào)用安全性和性能做了折中。MicroVM像 Firecracker、Cloud Hypervisor 這種基于 KVM 的輕量虛擬化每個(gè)執(zhí)行環(huán)境有獨(dú)立內(nèi)核隔離性最接近傳統(tǒng)虛擬機(jī)但啟動延遲和內(nèi)存開銷都比容器高。這四層不是誰替代誰的關(guān)系。很多做 Agent 執(zhí)行底座的人會同時(shí)保留容器和 MicroVM 兩條路按任務(wù)的信任級別拆分。你首先要搞清楚自己業(yè)務(wù)里執(zhí)行代碼的信任邊界是內(nèi)部同事提交的腳本還是外部用戶隨意輸入的內(nèi)容這兩者的威脅模型完全不同。1.3 你要隔離的不只是代碼還有網(wǎng)絡(luò)和狀態(tài)選沙箱方案時(shí)我見過很多新手只盯著能不能跑代碼忽略了另外兩個(gè)同樣重要的隔離面。第一是網(wǎng)絡(luò)隔離。Agent 執(zhí)行的代碼可能需要訪問公網(wǎng) API但它絕對不應(yīng)該能訪問你的內(nèi)網(wǎng)數(shù)據(jù)庫和管理端口。第二是狀態(tài)隔離。沙箱里的工作目錄、臨時(shí)文件、環(huán)境變量必須和宿主隔離否則上一次任務(wù)殘留的臟數(shù)據(jù)會污染下一次任務(wù)甚至通過磁盤文件把數(shù)據(jù)傳出去。所以我在評估一個(gè)沙箱方案時(shí)會同時(shí)問三個(gè)問題執(zhí)行資源能不能限制死網(wǎng)絡(luò)進(jìn)出口能不能控制文件系統(tǒng)和持久化會不會泄漏這三個(gè)問題的答案基本決定了你最后該選 MicroVM、云端沙箱還是 All-in-One 容器。2. E2B 的 MicroVM 路線用一顆迷你虛擬機(jī)換回安全邊界2.1 E2B 的運(yùn)行模型為一個(gè)執(zhí)行任務(wù)開一臺微型機(jī)器E2B 是我最早接觸的 Agent 專用沙箱方案它在技術(shù)上踩中的路線就是 Firecracker MicroVM。簡單理解每次調(diào)用 SDK 創(chuàng)建一個(gè) Sandbox實(shí)際上是在云端起了一臺只有幾十到幾百 MB 內(nèi)存的微型虛擬機(jī)里面有完整的 Linux 用戶態(tài)、shell、Python/Node 運(yùn)行時(shí)但和宿主之間隔著一層完整的虛擬化邊界。我當(dāng)時(shí)用 Python SDK 寫的調(diào)用大概長這樣from e2b import Sandbox with Sandbox(timeout60, memory_mb256) as sbx: proc sbx.run(python3 -c print(42)) print(proc.stdout)這段代碼背后的邏輯值得展開說Sandbox 對象代表一個(gè)獨(dú)立的執(zhí)行環(huán)境timeout 控制整個(gè)沙箱的存活時(shí)間超過之后會自動銷毀防止任務(wù)卡死燒錢memory_mb 限制內(nèi)存上限防止腳本一個(gè)列表推導(dǎo)式把內(nèi)存撐爆。創(chuàng)建完成后可以往沙箱里傳文件、執(zhí)行 bash 命令、讀取 stdout/stderr甚至可以交互式地起一個(gè) Jupyter Kernel。這套 API 設(shè)計(jì)很明顯是為 Agent tool-use 準(zhǔn)備的模型讓沙箱去執(zhí)行命令沙箱把輸出返回給模型一次工具調(diào)用對應(yīng)一個(gè)短暫的沙箱生命周期。2.2 MicroVM 的強(qiáng)隔離到底強(qiáng)在哪里MicroVM 和容器最本質(zhì)的差別是內(nèi)核邊界。容器里的進(jìn)程雖然被 namespace 隔開但用的還是宿主內(nèi)核一旦某個(gè)系統(tǒng)調(diào)用存在漏洞惡意代碼拿到的就是宿主內(nèi)核權(quán)限。而 E2B 這種基于 Firecracker 的沙箱里面是一個(gè)獨(dú)立的 guest 內(nèi)核代碼再怎么提權(quán)最多也就是把這臺微型虛擬機(jī)的內(nèi)核搞崩宿主毫發(fā)無損。這個(gè)特性決定了它最適合跑什么代碼不可信的、來自外部用戶的、或者模型生成的臨時(shí)腳本。如果你要做的是一個(gè)開放給用戶提交代碼的 AI Code Interpreter或是一個(gè)允許第三方插件運(yùn)行的 Agent 平臺MicroVM 幾乎是唯一能讓人安心的選擇。另一個(gè)值得說透的點(diǎn)是啟動速度。很多人一聽虛擬機(jī)就覺得要等幾十秒但 Firecracker 這類輕量虛擬化把啟動過程優(yōu)化得很極致加上 E2B 用鏡像模板和快照技術(shù)做預(yù)熱冷啟動能壓到秒級甚至更低。這個(gè)秒級和容器預(yù)熱后的百毫秒級依然有差距但在安全收益面前對大多數(shù) Agent 調(diào)用場景完全可接受。2.3 什么時(shí)候不該選 MicroVM性能和密度的真實(shí)成本MicroVM 不是沒有代價(jià)。每個(gè)沙箱都有 guest 內(nèi)核和基礎(chǔ)用戶態(tài)的內(nèi)存開銷同樣一臺物理機(jī)上能容納的沙箱數(shù)量比容器少一個(gè)量級。對信任邊界較高的內(nèi)部腳本執(zhí)行任務(wù)比如跑一些固定的數(shù)據(jù)處理流程上 MicroVM 屬于殺雞用牛刀基礎(chǔ)設(shè)施成本和工作量都會漲上去。E2B 還涉及一個(gè)數(shù)據(jù)邊界問題托管的沙箱默認(rèn)運(yùn)行在它的云上你的業(yè)務(wù)文件和 Agent 腳本要傳到對方環(huán)境里執(zhí)行。如果團(tuán)隊(duì)對數(shù)據(jù)出境和存儲位置有強(qiáng)約束就需要考慮自托管部署自己管理 Firecracker 的虛擬機(jī)模板、鏡像倉庫和沙箱調(diào)度運(yùn)維復(fù)雜度會明顯上升。3. Modal 的云端沙箱一個(gè)平臺級的遠(yuǎn)程執(zhí)行體系3.1 從一次真實(shí)使用看 Modal Sandbox 的工作方式Modal 和 E2B 不是一個(gè)物種。Modal 的核心是云端函數(shù)平臺你可以把 Python 代碼定義成遠(yuǎn)程函數(shù)不需要管服務(wù)器運(yùn)維平臺自動伸縮、按量計(jì)費(fèi)。Sandbox 只是它能力矩陣?yán)锏囊豁?xiàng)更準(zhǔn)確地說它提供了一個(gè)可以任意執(zhí)行命令的遠(yuǎn)程環(huán)境。我當(dāng)時(shí)用 Modal 做沙箱的代碼大概長這樣import modal app modal.App(sbox_demo) sbx modal.Sandbox.create( python:3.11-slim, cmd[python, -c, print(hello modal)], volumes{/workspace: modal.Volume.from_name(my-vol)}, timeout60, ) print(sbx.get_logs())這里有兩個(gè)關(guān)鍵點(diǎn)。第一Modal 允許你在函數(shù)或沙箱里掛載 Volume這個(gè) Volume 是平臺上的持久化存儲多個(gè)沙箱可以共享數(shù)據(jù)卷。第二Modal 天然有 scale-to-zero 能力沒有任務(wù)時(shí)平臺會自動把資源縮掉來任務(wù)時(shí)再拉起來對 AI Agent 這種低頻但單次必需跑的負(fù)載非常友好。3.2 為什么我說 Modal 是工作負(fù)載平臺而不是單純沙箱把 Modal 和 E2B 放在一起對比很容易產(chǎn)生混淆因?yàn)閮蓚€(gè)產(chǎn)品都能執(zhí)行遠(yuǎn)程代碼。但使用體驗(yàn)完全不同E2B 的本體是沙箱SDK 里圍繞 Sandbox 做文章模板、快照、命令執(zhí)行都是服務(wù)于給不可信代碼一個(gè)封閉運(yùn)行環(huán)境這個(gè)目標(biāo)Modal 的本體是工作負(fù)載調(diào)度沙箱只是它支持的運(yùn)行形態(tài)之一同樣的底層能力還能跑批處理任務(wù)、跑 GPU 推理、跑定時(shí)調(diào)度、跑并行數(shù)據(jù)管道。這個(gè)差異決定了一件事如果你的需求只是讓 Agent 安全地執(zhí)行一段不可信代碼直接用 E2B 更順如果你的需求更寬比如還要統(tǒng)一管理 GPU、批量任務(wù)、定時(shí)任務(wù)和數(shù)據(jù)卷那 Modal 這類平臺能把基礎(chǔ)設(shè)施層一次性包圓。說白了E2B 是給你一把鎖Modal 是給你一套帶鎖的房子房子里的項(xiàng)目如果你根本用不上那把鎖就不算優(yōu)勢。3.3 按量付費(fèi)和云端依賴省了運(yùn)維也交出了控制權(quán)Modal 的計(jì)費(fèi)模型是按實(shí)際使用資源計(jì)費(fèi)縮容到零時(shí)沒有任何閑置成本。對個(gè)人開發(fā)者和中小團(tuán)隊(duì)來說這比自托管一臺沙箱服務(wù)器劃算很多。但另一方面你的任務(wù)執(zhí)行變成了對云端服務(wù)的強(qiáng)依賴網(wǎng)絡(luò)延遲、平臺版本變更、配額限制都會直接影響你的業(yè)務(wù)。我自己實(shí)際體驗(yàn)下來Modal 的冷啟動表現(xiàn)已經(jīng)很優(yōu)秀但每次執(zhí)行環(huán)境的下載和容器拉起還是要比本地 Docker 預(yù)熱池慢一個(gè)身位。在數(shù)據(jù)敏感性不高的場景里Modal 這類平臺是很好的選擇。我見過不少團(tuán)隊(duì)把 Agent 工具執(zhí)行的負(fù)載放在 Modal 上跑代碼邏輯和結(jié)果數(shù)據(jù)都通過 Volume 管理既省去了運(yùn)維物理機(jī)的成本又獲得了一個(gè)相當(dāng)不錯(cuò)的并發(fā)伸縮底座。4. All-in-One 容器路線AIO Sandbox 的夠用主義4.1 一體化的含義一個(gè)容器把運(yùn)行時(shí)、依賴和工具鏈全部打進(jìn)去現(xiàn)在我重點(diǎn)聊聊自建方案里最常見的 All-in-One 容器路線標(biāo)題里的 AIO Sandbox 指的就是這種一體化容器沙箱思路。它不是一個(gè)特定產(chǎn)品而是一種工程化范式把 Agent 執(zhí)行環(huán)境需要的所有東西Python 運(yùn)行時(shí)、Node 運(yùn)行時(shí)、常用命令行工具、項(xiàng)目依賴、監(jiān)控 agent、網(wǎng)絡(luò)代理配置全部放進(jìn)一個(gè)可復(fù)現(xiàn)的容器鏡像里。容器就是你的沙箱單元鏡像就是沙箱的模板。一個(gè)最小化但完整的 Dockerfile 大概長這樣FROM python:3.11-slim RUN pip install --no-cache-dir pandas numpy requests \ apt-get update apt-get install -y --no-install-recommends \ ca-certificates curl jq \ rm -rf /var/lib/apt/lists/* WORKDIR /sandbox COPY entrypoint.sh /entrypoint.sh ENTRYPOINT [/entrypoint.sh]這里的關(guān)鍵不是把依賴裝完而是把沙箱的執(zhí)行契約定清楚固定工作目錄、固定入口腳本、固定資源限制。啟動時(shí)再用 docker run 把限制參數(shù)套上docker run --rm \ --cpus0.5 \ --memory512m \ --pids-limit64 \ --networknone \ --read-only \ -v /tmp/workspaces/sbx-001:/workspace:rw \ my-aio-sandbox-image python main.py這一行命令里沒有炫技但每一條 flag 都有明確目的cpus 和 memory 限制 CPU 與內(nèi)存pids-limit 防止 fork 炸彈networknone 直接斷掉外部網(wǎng)絡(luò)read-only 讓根文件系統(tǒng)不能再被寫入volume 只暴露一個(gè)臨時(shí)工作目錄。4.2 容器沙箱的隔離強(qiáng)度夠用和絕對安全之間有一條線容器沙箱最被人詬病的一點(diǎn)是共享宿主內(nèi)核這確實(shí)是真實(shí)的安全短板。但大多數(shù)內(nèi)部 Agent 場景里的威脅模型根本不需要對抗國家級攻擊者。你要防的是模型寫出的死循環(huán)、資源炸掉、誤刪文件、訪問不該訪問的內(nèi)網(wǎng)端口這些用容器限制參數(shù)就能擋掉百分之九十九。如果還想往上補(bǔ)安全等級不需要直接跳到 MicroVM可以在容器運(yùn)行時(shí)層面做文章。比如使用 gVisor 的 runsc 作為 runtime給容器加一層用戶態(tài)內(nèi)核攔截大部分危險(xiǎn)系統(tǒng)調(diào)用再比如疊加 seccomp 去限制可用的 syscall 集合。這些做的復(fù)雜度比維護(hù)一套 MicroVM 模板低得多安全收益卻非常接近。當(dāng)然我必須把話說直白如果你的沙箱要承接的是外部用戶隨意提交的不可信任意代碼而且開放網(wǎng)絡(luò)訪問那容器方案無論怎么加固都建議你再想想。這種場景直接上 MicroVM 路線更穩(wěn)妥。4.3 All-in-One 在 Agent 主流架構(gòu)里為什么這么流行現(xiàn)在很多 Agent 項(xiàng)目都是標(biāo)準(zhǔn)的三件套FastAPI 做 API 層、LangGraph 或 LangChain 做編排、外部沙箱做執(zhí)行層。AIO 容器路線在這個(gè)架構(gòu)里非常絲滑因?yàn)樗恍枰腩~外的云端平臺也不需要學(xué)習(xí)一套新的 SDK所有沙箱就是容器所有調(diào)度就是已有的 Docker/Kubernetes 能力。我在社區(qū)里看到越來越多團(tuán)隊(duì)包括做 Java 生態(tài) Spring AI Agent 的人都在走這條路用一個(gè)通用沙箱容器鏡像讓 Agent 的工具調(diào)用 handler 去啟動它任務(wù)結(jié)束就銷毀。這種模式成本低、可解釋性強(qiáng)、把你對基礎(chǔ)設(shè)施的控制權(quán)留在自己手里對那些Agent 里跑的都是自己團(tuán)隊(duì)寫的、相對可信的腳本的場景是最務(wù)實(shí)的解法。5. 從冷啟動到并發(fā)真實(shí)選型指標(biāo)與決策流程5.1 別先看技術(shù)先回答三個(gè)問題很多熱搜里都在問AI Agent 怎么扛并發(fā)但并發(fā)方案的起點(diǎn)不是技術(shù)而是任務(wù)模型。我一般會先把三個(gè)問題拍死任務(wù)時(shí)長多長一個(gè) bash 命令幾秒跑完和一個(gè)數(shù)據(jù)處理任務(wù)要跑十幾分鐘對沙箱生命周期管理的要求完全不同。調(diào)用方信任級別多高內(nèi)部自動化任務(wù)和外部用戶觸發(fā)的任務(wù)隔離要求差一個(gè)量級。并發(fā)曲線是什么形狀是大量短任務(wù)同時(shí)進(jìn)來還是一批長任務(wù)交錯(cuò)執(zhí)行這三個(gè)問題的答案組合直接決定了你該用哪種方案。短任務(wù)、低信任、高并發(fā)這是 E2B 這類 MicroVM 需要做預(yù)熱池才能抗下來的長任務(wù)、內(nèi)部信任、中流量All-in-One 容器反而更經(jīng)濟(jì)變動劇烈、想省運(yùn)維、低頻高爆發(fā)Modal 的按量付費(fèi)優(yōu)勢最大。5.2 沙箱池化真正幫 AI Agent 扛住并發(fā)的機(jī)制并發(fā)能力的核心不在沙箱本身而在沙箱池化。每個(gè) Agent 任務(wù)如果都從零開始 create 沙箱光環(huán)境加載就會把你的延遲和資源消耗推到高位。正確做法是把沙箱做成一個(gè)預(yù)熱池提前預(yù)啟動 N 個(gè)沙箱任務(wù)到達(dá)后從池子里取一個(gè)跑完再放回去而不是銷毀重建。我的一次實(shí)踐是這樣的在 All-in-One 容器方案里我用消息隊(duì)列把任務(wù)分發(fā)給一組常駐的沙箱 worker每個(gè) worker 內(nèi)部維護(hù)一個(gè)干凈的臨時(shí)目錄任務(wù)執(zhí)行完清理現(xiàn)場回到池子里等待下一個(gè)任務(wù)。只有遇到不可恢復(fù)的臟狀態(tài)比如進(jìn)程被殺、文件系統(tǒng)損壞才銷毀重建。這樣一個(gè) 200MB 的鏡像基礎(chǔ)上單臺 4 核 8GB 的容器實(shí)例可以穩(wěn)穩(wěn)扛住幾十個(gè)并發(fā)沙箱任務(wù)成本比每任務(wù)一個(gè) MicroVM 低得多。5.3 三套方案的關(guān)鍵對比我整理了一張對比表用來在團(tuán)隊(duì)里快速對齊選型思路維度E2B / MicroVM 類Modal 云端沙箱All-in-One 容器隔離級別每沙箱獨(dú)立內(nèi)核最強(qiáng)云平臺托管環(huán)境中等偏強(qiáng)默認(rèn)容器隔離可疊加 gVisor啟動效率秒級需預(yù)熱池秒級平臺自動伸縮百毫秒級鏡像預(yù)熱后內(nèi)存開銷每沙箱有 guest OS 開銷平臺托管按量計(jì)費(fèi)極小純進(jìn)程組開銷運(yùn)維復(fù)雜度較高要管模板與網(wǎng)絡(luò)低平臺接管低依賴容器生態(tài)最佳場景外部不可信代碼多變負(fù)載、不想管運(yùn)維內(nèi)部腳本、數(shù)據(jù)管道表格里沒有絕對的好壞最后還是要回歸到你的信任邊界和成本模型。聊到這里你會發(fā)現(xiàn)AI Agent 怎么扛并發(fā)這個(gè)問題的答案其實(shí)很樸素并發(fā)不靠模型側(cè)優(yōu)化靠執(zhí)行層的池化和伸縮。任務(wù)的彈性和無狀態(tài)化是前提沙箱復(fù)用是手段超時(shí)和資源限制是底線。6. 我在沙箱落地過程中踩過的坑和現(xiàn)在的組合方案6.1 鏡像膨脹、狀態(tài)污染和死循環(huán)三個(gè)最容易燒錢的坑第一坑是鏡像膨脹。All-in-One 容器剛起步時(shí)我圖省事把訓(xùn)練推理用的依賴一股腦裝進(jìn)沙箱鏡像結(jié)果鏡像從 300MB 一路漲到 1.5GB每次冷啟動都要多花十幾秒。后來我把沙箱鏡像拆成 base 層和任務(wù)層base 只裝運(yùn)行時(shí)和基礎(chǔ) CLI按需加載的依賴放到獨(dú)立的層甚至直接用 pip download 緩存來解決啟動時(shí)間明顯降下來。第二坑是狀態(tài)污染。沙箱復(fù)用時(shí)上一次工作目錄里留下的緩存文件、臨時(shí)數(shù)據(jù)會影響這一次任務(wù)的產(chǎn)出。我出現(xiàn)過 A 任務(wù)寫入的文件被 B 任務(wù)誤讀取的烏龍。解決方案是固定契約每任務(wù)用獨(dú)立子目錄跑完強(qiáng)制清理或者干脆用臨時(shí)掛載卷做一次性 workdir。第三坑是死循環(huán)。模型生成的代碼里出現(xiàn) while True 概率并不低尤其是讓 Agent 去爬數(shù)據(jù)、重試接口時(shí)。我第一次只設(shè)了命令級超時(shí)忘了沙箱級 timeout結(jié)果一個(gè)死循環(huán)任務(wù)在后臺跑了半小時(shí)按量計(jì)費(fèi)的賬單非常酸爽?，F(xiàn)在的規(guī)則很簡單任何沙箱創(chuàng)建都必須攜帶 timeout超時(shí)就是 kill沒有例外。6.2 網(wǎng)絡(luò)權(quán)限、持久化卷和日志隔離邊界的黑洞網(wǎng)絡(luò)是我后來才重視的坑。一開始我讓沙箱開了全部網(wǎng)絡(luò)Agent 確實(shí)能訪問外部 API 了但在一次安全演練里沙箱里的腳本居然順利連上了同一個(gè)內(nèi)網(wǎng)段里的 Redis直接讀到了生產(chǎn)緩存數(shù)據(jù)。自那以后我所有自建沙箱都走顯式代理白名單默認(rèn)只放行 Agent 運(yùn)行必需的 API host其他一律拒絕內(nèi)網(wǎng) CIDR 在 iptables 層面直接丟棄。持久化卷也有坑。Modal 的 Volume 和自建的共享卷在多沙箱并發(fā)寫同一個(gè)文件時(shí)會出現(xiàn)競爭。Agent 任務(wù)一旦都有往同路徑寫日志的習(xí)慣你就等著看臟輸出。規(guī)范路徑是唯一的解法每個(gè)沙箱擁有自己的命名空間前綴寫結(jié)果前先確認(rèn)路徑所有權(quán)。日志則是另一個(gè)暗坑。Agent 執(zhí)行命令產(chǎn)生的 stdout/stderr 如果全量收集幾輪工具調(diào)用下來就能把模型的上下文窗口撐爆。我給沙箱輸出加了長度限制默認(rèn)只保留最后幾千字符截?cái)鄷r(shí)附一個(gè)標(biāo)志模型看完結(jié)果也夠用成本卻能壓下一大截。6.3 我現(xiàn)在的默認(rèn)組合雙軌制不搞一家通吃回到標(biāo)題里那個(gè)從 MicroVM 到 All-in-One 容器的認(rèn)知我現(xiàn)在的落地做法是雙軌制。外部用戶觸發(fā)的、代碼不可信的 Agent 執(zhí)行任務(wù)走 MicroVM 路線隔離第一成本第二內(nèi)部自動化、數(shù)據(jù)管道、定時(shí)批處理這類信任度較高的任務(wù)走 All-in-One 容器路線密度第一運(yùn)維第二Modal 這類平臺則留給需要 GPU 或超強(qiáng)伸縮的專項(xiàng)任務(wù)按量用、用完縮。從 E2B 到 Modal 再到自建容器切換過程中最大的收獲不是學(xué)會了哪個(gè)平臺而是想明白了一個(gè)道理沙箱選型本質(zhì)上是在回答你愿意為安全付多少成本、為密度犧牲多少隔離。沒有全能的沙箱只有對得上業(yè)務(wù)模型的沙箱。先想清楚你的 Agent 代碼從哪來、要到哪去再回頭選工具每一步都會好走很多。