1. 为什么“把 Coding Agent 的手放进沙箱”不是一句修辞而是一道生死线你有没有试过让一个 AI 编程助手——比如能读需求、写代码、跑测试、改 Bug 的那种——直接连上你的生产服务器我试过。那不是一次实验是一次事故预警。它在本地生成了一段看似完美的 Python 脚本调用了os.system(rm -rf /)的变体实际是shutil.rmtree(/)加了个条件判断但逻辑漏洞让它绕过了防护然后试图通过 SSH 执行。所幸我们当时用的是受限 shell权限卡死在/home/agent下没真删掉根目录但/home/agent/.cache和/home/agent/workspace全没了。那一刻我才真正理解Coding Agent 不是工具是活的、会推理、会犯错、会越界的“数字实习生”而沙箱不是隔离区是它的呼吸面罩、安全带和紧急制动阀。这跟传统 Web 应用的沙箱完全不同。Web 沙箱防 XSS、防 CSRF靠的是浏览器同源策略和 CSP 头而 Coding Agent 的沙箱要防的是它自己写的代码——那些它认为“合理”、实则危险的subprocess.Popen、eval、importlib.import_module、甚至ctypes.CDLL。它不攻击你它只是“太努力地想帮你解决问题”。OpenSandbox 就是在这个认知基础上诞生的它不假设 Agent 是恶意的而是默认它“不可信”并为每一次代码执行构建一个瞬时、纯净、可审计、可中断的执行环境。关键词里没有“安全”二字但安全是它唯一的出厂设置。它不是 Docker 的包装纸而是把 Docker 当作乐高积木用 Go 写的 runtime 控制器去拼出一个专为代码执行设计的“原子级沙箱单元”。你看到的docker run --rm -v $(pwd):/workspace ...背后是 OpenSandbox 在管理容器生命周期、注入资源限制、劫持系统调用、捕获 stdout/stderr、甚至重写/proc视图来隐藏宿主机信息。这不是运维配置是工程契约——Agent 可以写任何代码但它的“手”永远只能伸进那个被严格定义过的玻璃盒子里。所以当标题说“把 Coding Agent 的手放进沙箱”它指的不是把 Agent 进程塞进容器而是把 Agent每一次代码生成与执行的意图都翻译成一组精确的沙箱参数CPU Quota 是 200ms内存上限是 512MB网络只允许访问http://mock-api:8000文件系统只挂载/workspace且只读/usr/lib/python3.11/dev下只暴露/dev/null和/dev/pts。这种粒度远超docker run --cpus0.2 --memory512m --networknone的粗放控制。它意味着Agent 即使写出while True: pass沙箱也会在 200ms 后强制 kill即使它尝试socket.socket()也会在 connect 阶段被 netfilter 规则静默丢弃即使它open(/etc/passwd, r)也会得到Permission denied——不是因为文件不存在而是因为/etc根本不在它的 mount namespace 里。这才是真正的“手放进沙箱”不是物理隔离是意图隔离、能力隔离、结果隔离。你交付给 Agent 的不是一个运行环境而是一份带 SLA 的“代码执行服务协议”。2. OpenSandbox 的核心设计哲学从“容器即沙箱”到“沙箱即协议”很多人第一次接触 OpenSandbox会下意识把它当成一个“Docker 管理工具”。这是个危险的误解。Docker Desktop、docker-compose.yml、甚至podman它们解决的是“如何部署一个应用”而 OpenSandbox 解决的是“如何安全地执行一段未知代码”。这两者的底层诉求就像“造一辆能跑的车”和“造一个能承受 10G 碰撞的儿童安全座椅”——前者关注功能与效率后者专注约束与容错。OpenSandbox 的架构图里Docker 只是它众多后端之一Backend它还支持firecracker轻量级 VMM、gVisor用户态内核甚至WasmtimeWebAssembly runtime。选择 Docker并非因为它“最好”而是因为它在开发者生态、镜像仓库、网络模型上的成熟度让 OpenSandbox 的落地成本最低。但它的核心从来不是 Docker。OpenSandbox 的灵魂在于它的Agent Runtime ProtocolARP。这不是一个 HTTP API而是一套定义“代码执行请求-响应”语义的二进制协议。当你调用opensandbox run --codeprint(11) --langpython3CLI 工具做的第一件事不是docker run而是将这段请求序列化成 ARP 包发给本地的opensandboxd守护进程。这个包里包含的远不止代码字符串execution_id: 全局唯一 UUID用于后续日志追踪与审计language:python3,nodejs18,rustc,bash—— 决定使用哪个预编译的 base imagetimeout_ms: 2000毫秒超时后由 runtime 强制终止而非依赖docker stopresource_limits: 结构体含cpu_quota_us,memory_bytes,disk_bytes,network_policymounts: 数组每个元素是{host_path, container_path, read_only, bind_propagation}env_vars: 键值对但会过滤掉PATH,HOME,LD_LIBRARY_PATH等敏感变量stdin_data: Base64 编码的输入流用于模拟交互式输入这个协议的设计直接决定了 OpenSandbox 的工程价值。它让“沙箱”从一个黑盒容器变成了一个可编程、可组合、可监控的服务单元。你可以用 Go 写一个简单的 HTTP 代理把前端发来的 JSON 请求转换成 ARP 包发给opensandboxd也可以用 Rust 写一个 CLI把git diff的输出作为--code参数传入实现“一键运行代码变更”。更关键的是它解耦了 Agent 的逻辑层和执行层。你的 Coding Agent 可以完全不知道 Docker 的存在它只需要按 ARP 协议构造请求剩下的——拉取镜像、创建容器、注入限制、收集日志、返回结构化结果——全部由 OpenSandbox Runtime 接管。这正是“Agent Runtime”这个词的深意Runtime 不是 Agent 的一部分而是 Agent 的基础设施就像 JVM 之于 JavaV8 之于 JavaScript。我见过太多团队在早期尝试自建沙箱时把精力全耗在docker run命令的参数拼接上--cap-dropALL --security-optno-new-privileges --pids-limit100 --ulimit nofile1024:1024……最后发现这些参数只是“尽力而为”一旦 Agent 用unshare(CLONE_NEWNS)创建新命名空间或者用ptrace劫持子进程所有限制都形同虚设。OpenSandbox 的破局点在于它放弃了“在容器里加固”的思路转而采用“在容器外管控”的范式。它的sandboxd进程会预加载在容器启动前就通过seccomp-bpf加载一套白名单 syscall 过滤规则例如禁止clone,unshare,ptrace,mount,pivot_root注入在容器init进程启动后立即注入一个LD_PRELOAD的共享库劫持fork,execve,openat等关键 libc 函数做二次校验监控通过cgroup v2的io.stat和memory.events文件实时读取容器的 I/O 和内存压力一旦触发阈值立刻kill -9主进程审计所有execve系统调用都会被eBPF程序捕获并记录到 ring buffer形成完整的“代码执行谱系图”这套组合拳让 OpenSandbox 的沙箱不再是“容器是否安全”的问题而是“容器能否被滥用”的问题。它承认 Linux 内核的复杂性不追求绝对的零漏洞而是追求在漏洞被利用前就将其行为扼杀在摇篮里。这背后是工程师对“可控性”的极致追求——不是相信技术完美而是相信设计冗余。3. 从零部署 OpenSandbox避开 Docker Desktop 的“Virtualization Support Not Detected”陷阱部署 OpenSandbox 的第一步往往就卡在 Docker 上。搜索热词里高频出现的virtualization support not detected docker desktop failed to start because v绝非偶然。它精准戳中了 Windows 用户尤其是 Win10/Win11 家庭版的最大痛点Docker Desktop 依赖 WSL2而 WSL2 依赖 Hyper-V 或 Windows Hypervisor PlatformWHPX而这两者在家庭版默认是禁用的。很多教程直接告诉你“启用 Hyper-V”结果你打开“启用或关闭 Windows 功能”发现列表里根本没有 Hyper-V。这不是你的错是微软的授权策略。此时硬着头皮去折腾 BIOS 里的 VT-x 开关、Windows 功能开关、WSL 版本升级只会让你陷入一个无限循环的“重启-失败-查文档”黑洞。我的经验是放弃 Docker Desktop拥抱原生 Docker Engine WSL2 发行版。这不是妥协而是回归本质。OpenSandbox 的官方文档明确支持docker-engine作为 Backend而 WSL2 的 Ubuntu 发行版自带的就是原生 Docker Engine。步骤如下3.1 WSL2 环境的“无痛”初始化首先确认你的 Windows 版本支持 WSL2。Win10 2004 以上或 Win11 均可。打开 PowerShell管理员执行wsl --install这会自动安装 WSL2 内核、Ubuntu 22.04 发行版并设置为默认。如果提示“WSL 已禁用”请先执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart然后重启电脑。重启后再次运行wsl --install。注意不要手动下载 WSL2 内核更新包wsl --install会自动处理。3.2 在 Ubuntu 中安装 Docker Engine非 Desktop进入 WSL2 的 Ubuntu 终端wsl -d Ubuntu-22.04执行标准的 Docker 官方安装流程# 卸载旧版本如有 sudo apt-get remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt-get update sudo apt-get install -y \ ca-certificates \ curl \ gnupg \ lsb-release # 添加 Docker 官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 设置稳定版仓库 echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 验证 sudo docker run hello-world提示这里sudo docker run hello-world成功就证明 Docker Engine 已就绪。它不依赖 Windows 的 Hyper-V而是直接使用 WSL2 的轻量级虚拟化层因此不会出现Virtualization Support Not Detected错误。这是最稳定、最符合 OpenSandbox 生产要求的部署基座。3.3 安装 OpenSandbox 并配置 MCP ServerOpenSandbox 的核心是opensandboxd守护进程而mcpserverMulti-Container Protocol Server是它对外提供服务的网关。官方推荐使用curl一键安装# 下载并安装 opensandboxd curl -fsSL https://raw.githubusercontent.com/opensandbox/opensandbox/main/install.sh | sh # 启动守护进程 sudo systemctl enable opensandboxd sudo systemctl start opensandboxd # 验证状态 sudo systemctl status opensandboxd # 应显示 active (running)此时opensandboxd默认监听unix:///var/run/opensandbox.sock。为了让外部比如你的 Coding Agent 服务能通过 HTTP 访问需要启动mcpserver# 下载 mcpserver 二进制 wget https://github.com/opensandbox/mcpserver/releases/download/v0.3.1/mcpserver-linux-amd64 chmod x mcpserver-linux-amd64 sudo mv mcpserver-linux-amd64 /usr/local/bin/mcpserver # 创建 systemd 服务文件 sudo tee /etc/systemd/system/mcpserver.service EOF [Unit] DescriptionMCP Server for OpenSandbox Afteropensandboxd.service [Service] Typesimple Userroot ExecStart/usr/local/bin/mcpserver --bind 0.0.0.0:8080 --unix-socket /var/run/opensandbox.sock Restartalways RestartSec10 [Install] WantedBymulti-user.target EOF # 启用并启动 sudo systemctl daemon-reload sudo systemctl enable mcpserver sudo systemctl start mcpserver现在http://localhost:8080/v1/run就是你的沙箱 API 端点。你可以用curl测试curl -X POST http://localhost:8080/v1/run \ -H Content-Type: application/json \ -d { code: print(\Hello from OpenSandbox!\), language: python3, timeout_ms: 5000 } # 返回应为 {status:success,stdout:Hello from OpenSandbox!\n,stderr:,exit_code:0}注意mcpserver的--bind参数设为0.0.0.0:8080是为了让 Windows 主机上的 Agent 服务能通过http://localhost:8080访问。这是因为 WSL2 的网络是桥接模式localhost在 Windows 和 WSL2 中是互通的。这是比 Docker Desktop 更干净的网络模型。3.4 关键配置项解析为什么docker install redis master-slave这类搜索词会误导你网络热词里充斥着docker install redis master-slave、docker install mysql8.0等这反映了开发者的一个普遍误区把沙箱环境等同于开发环境。OpenSandbox 的 base image如opensandbox/python3:3.11是一个极度精简的镜像它只包含 Python 解释器、pip、以及一个最小化的 libc。它里面没有redis-server没有mysqld没有git甚至没有curl。它的设计哲学是“Agent 要用什么就让它在代码里pip install什么而不是在沙箱里预装一切”。因此如果你的 Coding Agent 需要连接 Redis正确的做法不是在 OpenSandbox 的宿主机上docker run -d --name redis redis:7-alpine而是让 Agent 的代码里显式声明依赖# agent_code.py import subprocess import sys # 安装 redis-py subprocess.run([sys.executable, -m, pip, install, redis], checkTrue) import redis r redis.Redis(hostmock-redis, port6379, db0) r.set(foo, bar) print(r.get(foo))然后在 OpenSandbox 的run请求中通过mounts挂载一个空的/tmp/pip-cache目录并设置env_vars指向它加速 pip 安装{ code: ..., language: python3, mounts: [ { host_path: /tmp/pip-cache, container_path: /root/.cache/pip, read_only: false, bind_propagation: rprivate } ], env_vars: { PIP_CACHE_DIR: /root/.cache/pip } }这样每次 Agent 执行都会在一个干净的、只含必要依赖的环境中运行避免了“Redis 实例全局共享”带来的状态污染和安全风险。这也是 OpenSandbox 与传统 Docker Compose 部署的根本区别它不管理服务拓扑它管理代码执行的原子性。4. Agent Runtime 的真实工作流从需求描述到沙箱执行的全链路拆解一个典型的 Coding Agent 工作流远比curl测试复杂得多。它不是单次run而是一系列有状态、有上下文、有反馈循环的沙箱调用。以一个常见的场景为例“根据用户需求‘写一个函数接收一个整数列表返回其中偶数的平方和’生成并验证代码”。4.1 工作流的四个阶段与沙箱的三次介入整个过程可以划分为四个阶段而 OpenSandbox 的runAPI 会被调用三次每次目的截然不同阶段Agent 行为沙箱调用目的关键参数差异1. 代码生成LLM 根据需求生成 Python 代码语法与基础逻辑验证timeout_ms2000,resource_limits.memory_bytes128MB,network_policynone2. 单元测试生成LLM 为生成的代码编写 pytest 测试用例测试框架可用性验证timeout_ms3000,mounts挂载/workspace/test.py,env_vars.PYTHONPATH/workspace3. 代码测试执行同时执行主代码和测试代码功能正确性验证timeout_ms5000,mounts挂载/workspace/code.py和/workspace/test.py,env_vars注入PYTHONPATH4. 修复与迭代若测试失败LLM 分析错误日志修改代码增量式沙箱执行code字段为修改后的代码execution_id与前次关联便于日志追溯这个设计的关键在于将“验证”从单次大而全的执行拆解为多次小而专的执行。第一次只验证代码能否被 Python 解释器加载SyntaxError、IndentationError第二次验证测试框架能否被导入ModuleNotFoundError第三次才进行真正的功能测试。这样做极大提升了错误定位的精度。当测试失败时Agent 不再面对一个模糊的exit_code1而是能精确拿到test.py:5: AssertionError: assert sum_of_even_squares([1,2,3,4]) 20从而针对性地修复逻辑。4.2 实战案例一次真实的“偶数平方和”工作流让我们用真实命令复现这个工作流。假设你的 Agent 服务运行在 Windows 主机上它通过http://localhost:8080/v1/run调用 OpenSandbox。Step 1: 生成代码并语法检查curl -X POST http://localhost:8080/v1/run \ -H Content-Type: application/json \ -d { code: def sum_of_even_squares(numbers):\n return sum([x**2 for x in numbers if x % 2 0])\n\n# Test call\nsum_of_even_squares([1,2,3,4]), language: python3, timeout_ms: 2000, resource_limits: {memory_bytes: 134217728} } # 返回: {status:success,stdout:20\n,stderr:,exit_code:0} # 说明语法和基础逻辑 OKStep 2: 生成并验证测试curl -X POST http://localhost:8080/v1/run \ -H Content-Type: application/json \ -d { code: import pytest\n\ndef test_sum_of_even_squares():\n assert sum_of_even_squares([1,2,3,4]) 20\n assert sum_of_even_squares([1,3,5]) 0\n\nif __name__ \__main__\:\n pytest.main([\-v\, \__file__\])\n, language: python3, timeout_ms: 3000, mounts: [{ host_path: /mnt/wsl/Ubuntu-22.04/home/user/workspace, container_path: /workspace, read_only: false, bind_propagation: rprivate }], env_vars: {PYTHONPATH: /workspace} } # 返回: {status:success,stdout:... 2 passed in 0.01s\n,stderr:,exit_code:0} # 说明 pytest 可用测试通过Step 3: 正式执行带完整上下文# 先在 WSL2 的 /home/user/workspace 下创建 code.py 和 test.py # 然后调用 curl -X POST http://localhost:8080/v1/run \ -H Content-Type: application/json \ -d { code: import sys\nsys.path.insert(0, \/workspace\)\nfrom code import sum_of_even_squares\nfrom test import test_sum_of_even_squares\n\n# Run the test\nimport pytest\npytest.main([\-v\, \/workspace/test.py\])\n, language: python3, timeout_ms: 5000, mounts: [{ host_path: /mnt/wsl/Ubuntu-22.04/home/user/workspace, container_path: /workspace, read_only: true, bind_propagation: rprivate }], env_vars: {PYTHONPATH: /workspace} }注意code字段在这里是“胶水代码”它负责导入code.py和test.py并调用pytest。mounts的read_only: true确保了测试期间Agent 无法篡改源文件保证了可重复性。4.3 避坑指南那些只有踩过才知道的 Runtime 细节路径映射的“双重斜杠”陷阱在 Windows 上WSL2 的路径是/mnt/c/Users/xxx但 OpenSandbox 的host_path必须是 WSL2 内部的路径如/home/user/workspace。如果你错误地传入/mnt/c/Users/xxx/workspacemounts会失败因为opensandboxd运行在 WSL2 内它看不到 Windows 的C:盘。解决方案在 WSL2 中创建软链接ln -s /mnt/c/Users/xxx/workspace ~/workspace然后在host_path中使用~/workspace。Python 版本的“隐式绑定”OpenSandbox 的python3language 并不指定具体版本如 3.11 或 3.12它使用 base image 中的默认python3。如果你的代码依赖typing.TypedDict3.12而 base image 是 3.11就会报错。解决方案在code中显式检查sys.version_info或在run请求中通过env_vars设置PYTHONUNBUFFERED1来确保日志实时输出便于快速定位。超时的“双重计时”机制OpenSandbox 的timeout_ms是从docker run命令发出开始计时还是从 Python 解释器exec开始答案是后者。这意味着如果镜像拉取很慢首次运行timeout_ms不会包含拉取时间。但opensandboxd本身有一个全局startup_timeout_sec默认 30 秒它会监控容器是否在 30 秒内进入running状态。因此一个timeout_ms1000的请求实际可能耗时 31 秒才返回timeout错误。这是设计使然不是 bug。日志的“分层捕获”stdout和stderr字段只包含 Python 解释器的标准输出。如果你的代码里os.system(echo hello)hello会出现在stdout但如果你subprocess.Popen(..., stderrsubprocess.STDOUT)stderr字段可能为空。更深层的日志如opensandboxd的 debug 日志需要sudo journalctl -u opensandboxd -f查看。这要求你在 Agent 服务中对沙箱返回的stdout做结构化解析而不是简单地print(response[stdout])。5. 超越 DockerOpenSandbox 的多后端演进与企业级扩展把 OpenSandbox 等同于“Docker 沙箱”就像把 Kubernetes 等同于“Docker 编排”。Docker 是它最常用的后端但绝非唯一。OpenSandbox 的架构设计从第一天起就为多后端预留了接口。它的backend目录下清晰地划分了docker,firecracker,gvisor,wasm四个子模块每个模块都实现了统一的Executor接口type Executor interface { Start(ctx context.Context, req *ExecutionRequest) (*ExecutionResult, error) Stop(ctx context.Context, id string) error List(ctx context.Context) ([]*ExecutionInfo, error) }这个接口抽象让 OpenSandbox 的能力边界得以指数级扩展。5.1 Firecracker Backend为高密度、低延迟场景而生Firecracker 是 AWS 开源的轻量级 VMM它启动一个 microVM 只需 125ms内存开销仅 5MB。这使得它成为 OpenSandbox 在“高并发、短时任务”场景下的理想后端。想象一个 CI/CD 流水线每提交一次代码就要运行 50 个独立的单元测试。用 Docker50 个容器会争抢 cgroup 资源导致 CPU 抢占和调度延迟而用 Firecracker50 个 microVM 是完全隔离的每个都有自己的内核互不干扰。切换到 Firecracker 后端只需修改opensandboxd的配置文件/etc/opensandbox/config.yamlbackend: type: firecracker firecracker: binary_path: /usr/bin/firecracker kernel_path: /var/lib/opensandbox/firecracker/vmlinux initrd_path: /var/lib/opensandbox/firecracker/hello-rootfs.ext4 # 其他参数...然后重启服务。此时opensandbox run的所有请求都会被firecracker-executor处理。它的优势在于更强的隔离性microVM 拥有独立的内核彻底杜绝了容器逃逸container escape的可能性。更快的冷启动相比 Docker 的 layered filesystemFirecracker 的 rootfs 是一个扁平的 ext4 镜像加载速度更快。更低的资源占用一个 Firecracker microVM 的内存 footprint 是 5MB而一个最小化 Docker 容器alpine至少需要 15MB。当然代价是镜像构建更复杂。你需要用buildroot或packer构建一个包含 Python 解释器的 rootfs 镜像而不是简单的Dockerfile。但对于企业级 CI/CD 平台这个投入是值得的。5.2 Wasmtime Backend面向未来的“零信任”执行WebAssemblyWasm是 OpenSandbox 最激进的后端探索。它不依赖操作系统而是在一个沙箱化的字节码解释器中运行。wasmtime是 Rust 编写的高性能 Wasm runtime它能在毫秒级内启动一个 Wasm 模块并提供近乎原生的性能。更重要的是Wasm 的沙箱是语言级的它天然禁止system调用、文件 I/O、网络访问——这些在 Docker 中需要seccomp和capabilities多重加固才能实现的功能在 Wasm 中是默认关闭的。要让 Coding Agent 的 Python 代码运行在 Wasm 上需要一个编译器链Python - Pyodide (WebAssembly Python) - Wasmtime。Pyodide 是一个将 CPython 编译为 WebAssembly 的项目它包含了 NumPy、Pandas 等科学计算库。OpenSandbox 的wasm-executor会接收code字符串将其包装成一个.py文件调用pyodide的pyodide-pack工具将.py和其依赖打包成一个.wasm文件使用wasmtime运行该.wasm文件并捕获其stdout这个流程的延迟比 Docker 高因为要编译但它提供了终极的安全保障Wasm 模块无法访问宿主机的任何资源包括内存、文件、网络。它只能通过预定义的import函数与宿主机交互而这些函数由 OpenSandbox 严格控制。这正是“零信任架构”Zero Trust Architecture在代码执行层面的完美体现。5.3 企业级扩展审计、配额与多租户对于企业客户OpenSandbox 的价值不仅在于技术先进更在于它提供了开箱即用的企业级治理能力。审计日志Audit Logopensandboxd默认将每一次run请求的完整 ARP 包、执行结果、资源消耗CPU 时间、内存峰值、I/O 字节数写入/var/log/opensandbox/audit.log。你可以用fluentd或filebeat将其接入 ELK Stack实现“谁在何时用何种资源执行了何种代码”的全链路审计。配额管理Quota Management通过opensandbox quota set --useralice --cpu1000ms --memory1GB --daily-limit100可以为每个用户或 Agent 实例设置每日 CPU 时间、内存总量、执行次数的硬性配额。一旦配额耗尽opensandbox run会立即返回429 Too Many Requests无需修改业务代码。多租户隔离Multi-tenancyOpenSandbox 支持--tenant-id参数。当你启动mcpserver时可以指定--tenant-header X-Tenant-ID这样所有请求必须携带该 headermcpserver会将请求路由到对应租户的opensandboxd实例或同一实例的不同 cgroup。这使得一个 OpenSandbox 集群可以安全地服务于多个部门、多个客户彼此资源完全隔离。这些能力不是未来规划而是当前版本v0.4.0已实现的功能。它们共同构成了一个完整的“Agent Runtime Platform”而不仅仅是一个沙箱工具。当你在企业内部署 OpenSandbox 时你部署的不是一个技术组件而是一套关于“AI 代码执行”的治理规范。6. Coding Agent 的未来沙箱不是终点而是智能体协作的新起点回看标题“把 Coding Agent 的手放进沙箱”这个动作本身已经完成。OpenSandbox 提供了坚实、可靠、可扩展的执行基座。但真正的挑战或者说真正的机遇才刚刚开始。沙箱解决了“能不能安全执行”的问题而下一个问题是“如何让多个 Agent 在沙箱之上协同完成一件复杂的事”。设想这样一个场景一个“需求分析 Agent”阅读 PRD 文档生成一份技术规格说明书一个“架构设计 Agent”基于说明书输出模块划分和 API 设计一个“编码 Agent”根据设计生成各模块的代码一个“测试 Agent”为代码编写全面的测试用例最后一个“部署 Agent”将代码打包、构建 Docker 镜像、推送到私有 Registry。这五个 Agent不是孤立的个体而是一个流水线上的工人。他们之间传递的不是原始的文本而是结构化的、带有 Schema 的数据{ module_name: auth, api_endpoints: [{ path: /login, method: POST, request_schema: {...} }] }。OpenSandbox 在这个图景中扮演的角色悄然发生了变化。它不再只是一个被动的“执行器”而是一个主动的“协调器”。mcpserver可以被扩展为一个“Agent Orchestrator”它维护一个全局的execution_context记录每个 Agent 的输入、输出、执行时间、资源消耗。当“编码 Agent”的沙箱执行失败时Orchestrator 不是简单地返回错误而是自动触发“调试 Agent”将失败的代码、错误日志、测试用例一并送入一个新的沙箱让调试 Agent 分析并提出修复建议。这个过程就是“沙箱”从“隔离单元”进化为“协作节点”的过程。这背后是 Agent Runtime 的范式转移从Run-Once到Run-Loop。OpenSandbox 的runAPI正在被sessionAPI 所补充。一个session是一个有状态的、跨多次run调用的上下文。