AIO Sandbox：把浏览器、Shell、MCP 装进一个容器的 Agent 开发沙箱

做 AI Agent 开发的都会懂一种痛苦环境是散的工具是碎的。想给 Agent 开个浏览器要单独起 Playwright 服务想让它跑命令得提心吊胆怕把宿主机环境搞乱再算上 MCP Server 那一堆配置一个任务还没开始环境搭建占了大半时间。AIO Sandbox 这个开源项目就是冲着这个问题来的——它把浏览器、Shell、文件系统、MCP、VSCode 全部装进同一个容器给 Agent 搭好了一个自带全套工具的沙箱。这篇文章我从项目设计、核心组件到部署实操拆开讲一遍适合正在做 Agent 开发、或者被本地环境折腾到头大的朋友参考。1. 先说清楚AIO Sandbox 到底是个什么东西1.1 为什么 Agent 开发者需要沙箱先聊一个背景。2025 年之后做 Agent几乎没有一个正经项目能绕开浏览器操作、命令行执行和文件读写这三件事。你让 Agent 查一个网页它得能打开浏览器你让 Agent 改代码它得有 Shell 能跑命令你让 Agent 写报告它得有地方落盘。问题是这三件事分散在不同环境里一旦哪个环节配置不对联调起来就是连环坑。更头疼的是安全边界。直接在本机跑 Shell 的 Agent 等于给了它一把万能钥匙遇到不可信的指令后果想都不敢想。而 AIO Sandbox 的思路非常直接所有能力全部装进 Docker 容器Agent 在容器内部随便折腾宿主机一点都不受影响。跑崩了就重建容器三秒钟又是一条好汉。1.2 它和传统 Docker 开发容器有什么不同你可能会问Docker 容器我自己也会写docker run起一个容器装点工具不就完事了吗这话对但 AIO Sandbox 的关键不是容器而是一体化封装。传统容器方案里你需要自己处理一堆琐碎问题Chromium 依赖装不全、无头浏览器起不来、Shell 工具和文件工具每个都要单独写接口、MCP Server 配置五花八门。AIO Sandbox 把这些全给你收拾好了容器起来之后浏览器能直接控制Shell 能直接调用文件系统能直接读写并且全部以工具Tools的形式暴露给 Agent——不管你的 Agent 用的是 OpenAI SDK、Claude SDK还是其他支持 MCP 协议的框架都能接进来直接用。它的参考实现默认是一个 WebSocket HTTP 服务客户端把 Agent 要执行的工具调用请求发进来容器内部调度给对应的浏览器、Shell 或文件工具执行完把结果返回。整个过程对客户端来说就是一个标准接口完全不用关心背后是哪个浏览器、哪个命令行解释器。1.3 适合谁用的项目说实话这不是给刚学编程几天的人准备的玩具但对三类人非常有用一是做 Agent 框架开发的需要一个标准、可复现的执行环境做测试基座二是做 RPA 或浏览器自动化应用的想把网页操作、命令行、文件处理收拢到一个服务里三是自己和团队做内部工具、需要给 Agent 一个受控工作区的不想让 Agent 在生产机器上乱跑。如果你之前已经用过 Playwright 控制浏览器、或者折腾过 MCP那上手成本就更低了因为 AIO Sandbox 里这些核心概念全都能对应上。2. 五个核心组件逐个拆浏览器、Shell、文件、MCP、VSCode2.1 浏览器给 Agent 一双会看的眼睛浏览器是 Agent 能力里最重的一块也是 AIO Sandbox 里最亮眼的部分。它内置了基于 Playwright 的 Chromium 控制能力Agent 可以通过工具调用实现打开页面、点击元素、填写表单、截图、滚动等操作cover 了绝大多数网页自动化场景。我实测下来最爽的一点是它把原来 Playwright 那套需要维护浏览器实例、处理上下文、管理页面生命周期的麻烦全抹平了。Agent 这边只需要发一个browser工具调用指定动作剩下的交给沙箱。举个例子你想让 Agent 打开一个页面然后截图工具调用大概是{ name: browser, arguments: { action: navigate, url: https://example.com } }然后再发一个截图动作结果直接返回 base64 图片。整个过程跟用遥控器一样简单。背后有个容易踩坑的点是Chromium 在容器里的依赖非常碎字体库、GPU 库、动态链接库缺一个都可能起不来。AIO Sandbox 把这些坑填平了但如果你自己改镜像务必注意保留 Playwright 的install-deps步骤不然容器起来浏览器大概率是哑的。2.2 ShellAgent 的双手能干所有脏活Shell 工具给 Agent 提供了在容器内执行任意命令的能力。你可以在指定工作目录下跑ls、cat、pip install、npm run build甚至启动一个本地服务。AIO Sandbox 的 Shell 工具设计里有一个很实用的细节支持设置workdir这样 Agent 就能在特定目录内操作避免把整个文件系统搞乱。注意这个 Shell 不是常见的只读审计 Shell而是真真切切的执行环境。用网络热词里的说法这就是echo 反弹 Shell那一类能力的安全版本——在容器里Agent 就是 root但它拿不到宿主机的东西。这种能力给满、边界锁死的设计是 Agent 沙箱的核心理念。实际开发中 Shell 工具特别适合做思维链补全Agent 不确定某个包的版本跑一下pip show就知道了想确认文件结构跑一下find . -type f就清楚了比傻猜靠谱一万倍。2.3 文件系统让 Agent 有记忆和作品Agent 干完活总得有产出。AIO Sandbox 的文件系统工具支持在容器内读写文件、创建目录、列出目录结构。这个组件看着不起眼实际上是 Agent 完成长任务的关键——没有文件系统Agent 的操作都是无状态的一次对话结束所有中间结果归零。我推荐你在实际使用中把文件系统当Agent 的便签来用让 Agent 每一步的中间结果落到指定目录之后哪个环节出问题直接去看文件思路清晰排查也容易。比如写代码任务让 Agent 先写 TODO 文件再动手效率反而更高。文件持久化的问题稍后单独说这里先提一句默认容器重启后文件会丢如果你要让 Agent 长期记忆必须挂载宿主机目录。2.4 MCP工具生态的标准化插槽MCPModel Context Protocol模型上下文协议现在是 Agent 工具接入的事实标准了。AIO Sandbox 把浏览器、Shell、文件系统全部封装成了 MCP 工具这意味着任何支持 MCP 的客户端——不管你是用 Codex、Claude、Cline 还是自研框架——都能通过标准接口直接调用沙箱能力。MCP 采用 JSON-RPC 2.0 格式进行通信Agent 发tools/call请求MCP Server 响应结果。AIO Sandbox 在这里做了一个很聪明的分层它本身是一个 MCP Server 的实现里面挂载了多个子工具集browser、shell、file、vscode 等可以看作一个MCP 路由器。这带来的好处非常实际你再也不用为每个工具单独写 HTTP 接口、维护独立的回调逻辑了。MCP 就是那个万能插座AIO Sandbox 是一个自带多插孔的排插Agent 插上就能用。2.5 VSCode留给人类的事后检查入口这大概是 AIO Sandbox 最有心机的一个组件。Agent 跑完任务你想看看它到底改了什么总不能每次都用命令行 cat 文件、然后又去截图。AIO Sandbox 内置了 VSCode 服务容器起来之后你可以直接在浏览器里打开一个 Web 版 VSCode像用本地 IDE 一样检查 Agent 的产出。在实际工作流里这个设计很救场Agent 自动写完代码人直接打开 VSCode 做 code review改完再让 Agent 继续跑测试。人机协作的路径非常顺滑而不是 Agent 干完活、人还得手动去另一个环境里找文件。3. 架构与原理一切皆工具的设计哲学3.1 进程模型与端口规划AIO Sandbox 整体上跑在一个 Docker 容器里内部由几个核心进程协作WebSocket/HTTP 服务进程负责接收外部工具调用请求MCP Server 进程负责路由和调用具体工具Playwright 的浏览器进程负责页面渲染VSCode Server 负责 IDE 页面服务。你启动容器之后主要会用到几个端口WebSocket 服务端口用于 Agent 客户端连接MCP 服务端口用于标准 MCP 协议请求VSCode 端口用于浏览器打开 IDE 界面。默认情况下这些端口都绑定在127.0.0.1上避免直接暴露到公网。这一点很重要Agent 工具接口一旦暴露到公网等于给了全世界一个执行 Shell 的入口安全风险非常大。3.2 工具请求的流转路径理清请求流转路径你就明白了这个系统是怎么工作的。假设 Agent 想执行一条 Shell 命令完整链路是这样的Agent 客户端通过 WebSocket 发送tools/call请求携带工具名shell和参数command。WebSocket 服务进程收到请求校验连接和上下文。请求转发给 MCP ServerMCP Server 根据工具名做路由。shell工具在容器内的目标目录执行命令捕获标准输出和退出码。结果序列化为 JSON走原路返回给 Agent。这条链路完全可以自己写代码复现调试起来也方便。比如你不想用 SDK直接用 Python 的websockets库就能手动调用import asyncio from websockets.asyncio.client import connect async def call_shell(command: str, workdir: str /): async with connect(ws://localhost:8080/ws) as ws: await ws.send({ id: 1, method: tools/call, params: { name: shell, arguments: { command: command, workdir: workdir } } }) response await ws.recv() print(response) asyncio.run(call_shell(uname -a))跑通这一步你就对这个系统脱敏了后面换什么客户端都不怵。提示如果你接的是 OpenAI 的 SDK 或 Codex 这类框架它们有自己更便捷的工具调用方式不需要手写 WebSocket 客户端。但理解了上面这条路排障时会清楚很多。3.3 安全边界设计网络、权限与资源限制安全设计是这个项目最值得学的地方甚至比它的功能更值得研究。Agent 沙箱的安全核心理念是隔离能力但不阉割能力第一层是容器隔离。所有指令在容器内执行宿主机文件系统、网络、进程空间全部不可见。即使 Agent 干了坏事影响范围也限制在容器里。第二层是网络边界。默认只监听回环地址外部网络无法直接访问 Agent 接口你要在生产环境用必须自己加一层网关做鉴权。第三层是资源限制。通过 Docker 的 CPU、内存、磁盘限制参数防止 Agent 任务失控跑死整台机器。我自己补充一句如果你要用这个沙箱处理真实业务强烈建议把数据挂载目录和容器网络都做最小化处理——容器里没有宿主机密钥、没有数据库密码Agent 工作目录只挂载任务相关的文件夹。这样就算任务数据泄露影响面也是可控的。4. 实操部署在本地把这套容器跑起来4.1 环境准备与项目获取实操之前先确认环境Linux 或 macOS 都可以Windows 上建议开 WSL2 再用 Docker。需要安装 Docker Desktop 或 Podman版本不用太新能用 Docker Compose 就行。项目代码直接在 GitHub 上拿git clone https://github.com/openai/aio-sandbox.git cd aio-sandbox目录里有docker-compose.yml、Dockerfile以及服务端代码。如果你想改配置或者加自定义工具改完直接重新构建即可流程比想象中省事。提示首次构建镜像会拉不少依赖尤其是 Playwright 的浏览器下载和 VSCode Server 的下载体积不小。网络一般的情况下建议留出足够时间别中途掐断。4.2 启动配置与参数说明启动命令非常简单docker compose up --build第一次启动会做几件事构建服务镜像、下载 Chromium 和 Playwright 依赖、启动 WebSocket 服务、启动 MCP Server、启动 VSCode Server。镜像构建完成后屏幕会打印出各个服务的监听地址看到这些基本上是起来了。如果你想按自己的需求调整docker-compose.yml里几个关键设置在文档里有详细说明容器资源限制CPU/内存、数据挂载目录宿主机某个文件夹映射到容器内的 working dir、端口映射逻辑、沙箱超时时间。我最常改的是数据挂载因为默认情况下容器一重启文件就全没了这对真实任务来说太致命。改成挂载宿主机目录后Agent 写出来的文件就能留下。还有几个可选环境变量PROCS控制内部进程数量、SANDBOX_TIMEOUT控制单个工具调用的超时时间这些按需调整。默认配置对开发环境完全够用不用一上来就折腾。4.3 验证 Agent 是否真的会用浏览器和 Shell容器起来之后先别急着让 Agent 干活做几个快速验证确保每一层都通。先验证 WebSocket 服务是否在线。在容器外访问健康检查接口curl http://localhost:8080/health返回 JSON 状态信息基本就通了。然后验证浏览器工具用之前那段 Python 脚本调一个browser工具让它打开一个简单页面看返回是否正常。注意看返回结果里有没有截图数据如果截图为空大概率是 Chromium 没起来或者没有授权。再验证 Shell 工具调shell工具执行echo hello能拿到输出说明 Shell 链路是通的。如果只是 Agent 层接不进来问题通常出在客户端配置不在沙箱本体。把这几个基础验证跑通后面用各种 Agent 框架去接都会顺畅很多。5. 实战实录让 Agent 在一个容器里完成一整个任务5.1 场景设定与目标拆解光说原理不够我拿一个实际的场景串一遍全流程。任务是这样的让 Agent 自己在容器里生成一个 HTML 文件然后用浏览器打开它并截图保存最后把截图路径告诉我们。这个任务设计得比较有心机因为它同时覆盖了 AIO Sandbox 的三个核心能力文件系统写 HTML、浏览器打开页面并截图、文件系统再加 Shell确认结果落地。一步一步来。5.2 Agent 实际操作流程记录Agent 接到任务后首先肯定调用file工具在工作目录下创建test.html写入一段简单的 HTML 内容。如果你是自己调用等价于import asyncio from websockets.asyncio.client import connect async def write_file(path: str, content: str): async with connect(ws://localhost:8080/ws) as ws: await ws.send({ id: 2, method: tools/call, params: { name: file, arguments: { path: path, content: content } } }) print(await ws.recv()) asyncio.run(write_file(/workspace/test.html, htmlbodyh1Hello/h1/body/html))文件写好后Agent 调用shell工具在当前目录启动一个极简 HTTP 服务方便浏览器访问文件python3 -m http.server 8000 --directory /workspace然后调用browser工具打开页面{ name: browser, arguments: { action: navigate, url: http://localhost:8000/test.html } }接着调用截图动作并保存到文件。截图成功之后Agent 最后再用file工具或shell工具确认文件已生成。一个完整的多工具任务就这么串起来了。5.3 资源占用与性能观察跑完上面这个流程我顺手观察了一下容器资源消耗镜像构建完大约 2GB 多主要是 Chromium 和 VSCode Server 占大头运行状态下内存占用大概 500MB 到 700MBCPU 在空闲时几乎可以忽略。这个体量对现代开发机器基本无感跑在服务器上也完全没问题。性能方面浏览器每次操作的响应时间大概在几百毫秒到一两秒之间主要开销在页面渲染。Shell 命令的执行速度取决于命令本身的耗时。整体交互的延迟感知主要来自 Agent 模型本身的推理时间而不是沙箱执行时间。所以从性能角度说这个方案做 Agent 开发基座是合格的。6. 常见问题与排查技巧实录6.1 问题速查表我把实测中遇到的高频问题按现象、原因、解决思路整理成了表格方便你直接对着查。现象常见原因处理建议浏览器工具返回空截图Chromium 用户数据目录权限异常或未正常启动检查容器内 chromium 进程清理挂载目录残留数据后重启容器内无法解析域名Docker 网络 DNS 配置被宿主机策略覆盖在 compose 文件的 dns 配置里显式设置为8.8.8.8WebSocket 连接一建立就被断开鉴权 token 不匹配或 Origin 头校验失败核对客户端连接参数与容器环境变量一致MCP 工具调用长时间无响应MCP Server 内部线程卡死或扩了PROCS但资源不足调大超时参数重启容器适当降低并发Shell 执行结果乱码容器内 locale 未配置默认非 UTF-8在 Dockerfile 或环境变量里显式设置LANGC.UTF-8Agent 改的文件重启后丢失没有挂载宿主机数据卷修改 compose 文件把宿主机目录映射进容器工作目录VSCode 打不开或白屏VSCode Server 首次下载依赖失败查看容器日志重新构建镜像确认网络可访问下载源6.2 三个值得展开的排查手记第一个是 Chromium 无法启动的问题。在容器里跑 Playwright 和本机不一样缺系统依赖很常见。AIO Sandbox 的镜像里已经装了大部分依赖但如果你改过基础镜像很可能碰上libnss3 未安装这类错误。快速验证方法是直接进入容器执行python3 -m playwright install-deps能解决绝大部分浏览器启动问题。第二个是 VSCode Server 的端口冲突。如果你本机同时跑着其他服务占用了相关端口VSCode 白屏非常常见。用docker compose ps看端口映射有没有成功再docker logs看 VSCode 进程有没有报错八成能找到答案。第三个是网络隔离造成的自我访问问题。Agent 在容器内启动 HTTP 服务然后用浏览器访问localhost:8000这个路径本身没问题。但如果你改过网络模式、或者容器里跑的不是那个 Python 服务就会出现浏览器能打开页面但访问被拒的情况。先确认容器内服务在不在再确认访问端口对不对。7. 边界与扩展哪些任务不适合后续能玩出什么花7.1 什么任务不建议硬套 AIO Sandbox工具再顺手也有边界先帮你排除两类不适合的场景。第一类是 GPU 重负载任务。这个沙箱定位是浏览器、Shell、文件的通用执行环境不是为训练模型或跑大模型推理设计的容器内没有 GPU 透传和 CUDA 环境你非要把推理塞进去只会自找麻烦。第二类是高并发低延迟的生产级服务。沙箱本身是单容器的实现请求并发上升时工具执行是串行的吞吐量上不去。生产环境做高并发需要横向扩容和负载均衡这不是它现在的定位。还有一种情况也建议慎重任务需要访问宿主机上的内部服务或私有数据库。沙箱的隔离设计决定了它默认接触不到这些强行打通安全边界就破坏了沙箱的意义。遇到这种需求不如把任务拆成沙箱内执行 宿主机服务通过受控接口暴露的模式。7.2 可以扩展的方向自定义工具与集成AIO Sandbox 最大的扩展空间在 MCP 生态。因为一切皆工具、工具皆 MCP你完全可以自己写一个 MCP Server 挂进去给 Agent 增加专有能力。比如团队内部有个部署系统写一个deploy_tool的 MCP Server沙箱里的 Agent 就能直接调用部署接口。注意这类工具会暴露真实操作能力务必做权限校验别让 Agent 拿到未授权的部署权限。另一个扩展方向是数据持久化和任务编排深度结合。把 Agent 的任务记录、中间产物、最终结果统一落到挂载目录配合文件索引你就能搭一个Agent 工作痕迹时间线复查起来非常方便。还可以把多个沙箱组合成 Agent 集群一个容器专门跑浏览器操作一个专门跑数据清洗通过 MCP 互相调用。理论上整个 Agent 团队的工作室都能用这一套思路搭起来。7.3 我对这个项目的整体评估用了两周多我的感受是AIO Sandbox 最大的价值不是多了一个 Docker 镜像而是把 Agent 开发中那堆约定俗称但没人标准化的执行环境问题收拢成了一个标准答案。以前每个团队各自维护一套 Playwright 脚本、一套文件工具、一套 Shell 工具现在有一个现成的、理念一致的基座团队交接成本低很多。我自己最满意的是 VSCode 集成。之前 Agent 干完活我得跑去看日志、翻文件、拼截图现在直接浏览器打开 VSCode像检查同事的 Pull Request 一样审查产出体验完全不同。如果你正在搭建团队的 Agent 基础设施建议从这个项目开始改而不是从零写沙箱。最后分享一个小技巧把你自己常用的工具封装成一个小 MCP Server挂到沙箱里比每次都改 Agent 的系统提示词靠谱得多。工具即接口Agent 会自己找路径你只需要把路修好。