企业官网建设流程全解析

做过 Agent 开发的人应该都碰过这个问题：写业务逻辑花半天，配环境花两天。要让 Agent 会浏览网页，得装 Playwright 或 Selenium 全家桶；要让 Agent 能执行命令，得给它一个可用的 Shell；要管理文件，又怕它乱动宿主机上的东西。最头疼的是，好不容易配好一套环境，换个机器或者拉个同事协作，又得重来一遍。AIO Sandbox 就是在这个背景下冒出来的开源方案——它把浏览器、Shell、文件、MCP、VSCode 这五个能力全部封装进一个容器镜像，让 Agent 在完整、隔离、可复现的沙箱环境里干活。这篇文章我会从项目定位、内部机制、部署步骤、实战链路和踩坑记录几个角度，带你把它从零跑起来。

1. AIO Sandbox 起底：它到底在解决什么问题

1.1 传统 Agent 环境的三大痛点，为什么说“配环境比写代码难”

说“配环境比写代码难”虽然有点夸张，但做过 Agent 开发的人应该都有共鸣。第一痛是依赖地狱。浏览器自动化不是装个 Chrome 就完事，还要装驱动、装 Playwright 运行时、处理系统动态库；Shell 工具链又依赖一堆包管理器；文件系统则要考虑权限和路径映射。每个单独拎出来都能跑，摆在一起就是一场灾难，而且很多冲突要跑到运行时才暴露。

第二个痛点是隔离性不足。Agent 这类程序天生带探索性，你让它执行一条命令，它可能会顺着这条命令去读系统配置、改环境变量、甚至翻宿主机上的敏感目录。如果直接把 Agent 跑在宿主机上，等于把钥匙全交出去，风险太大。容器隔离是最轻量的兜底，但“做隔离”本身又是一套工程。

第三痛是不可复现。环境在 A 机器上跑得好好的，B 机器一拉代码就各种崩。团队要么维护冗长的环境文档（基本没人愿意写），要么做一整套配置管理脚本（工作量不小）。镜像化是终极解法：环境代码化、版本化，谁拉谁用，拉下来就是一样的。

AIO Sandbox 恰好把这三个痛点打包处理了：它既是依赖管理方案，所有组件提前装进镜像；也是隔离方案，整个 Agent 能力都跑在容器里；更是可复现方案，镜像分发，环境前后一致。我觉得它值得写一篇，不只是因为技术上的先进性，而是它把这三件事整合成了一个足够简单、能直接落地的成品。

1.2 五大核心模块：浏览器、Shell、文件、MCP、VSCode 各自的定位

按标题的说法，“把浏览器、Shell、文件、MCP、VSCode 塞进同一个容器”，听起来像大杂烩，实际上这五个模块承担的是不同层次的任务。

浏览器模块管“操作网页”，它是 Agent 在 Web 世界里干活的手和眼睛。具体实现走 CDP 协议或者 Playwright 的远程连接协议，Agent 通过 WebSocket 连接容器里的浏览器服务，完成页面导航、元素点击、表单填写、数据提取等操作。

Shell 模块管“执行命令”，是 Agent 调用本地系统能力的基本入口。它的价值在于，Agent 不只是能操作网页，还能安装软件、运行脚本、启动服务、查看日志。如果说浏览器解决的是“对外交互”，Shell 解决的就是“对内执行”。

文件模块管“读写数据”。Agent 任务通常需要产出物：采集的数据、生成的报告、训练的日志等等。文件系统是这些产出的落脚点，同时工作区的挂载机制让宿主机和容器共享同一个目录，方便人去做检查。

MCP 模块管“连接外部工具”。MCP 全称 Model Context Protocol，定义了一套标准化的工具调用协议，让 Agent 能够动态发现并调用外部能力。在这套沙箱里，MCP 是把“独立沙箱”升级成“工具集合器”的关键模块。

VSCode 模块管“人类介入”。Agent 自动跑是一回事，人在旁边观察、调试、改配置是另一回事。VSCode Web 把完整的编辑界面搬进浏览器里，人可以直接面对容器内的工作区去做操作，不需要另起一套环境和工具。

一句话总结：浏览器、Shell、文件是 Agent 在容器里干活的实际工具，MCP 是它和外部世界握手的标准接口，VSCode 是留给人类观察参与的前台。这个分层在多数 Agent 项目里都成立，只是 AIO Sandbox 把它打包成了现成镜像。

1.3 和“自己攒一套”相比，它到底省在哪

有人会想，这些组件我都能自己装，为什么非要用这个项目？我自己早期也是这么干的，直到维护到第三个项目才发现问题。自己攒环境，每个项目都有一份 Dockerfile，每份 Dockerfile 都长得不一样：有的基于 ubuntu，有的基于 alpine，有的浏览器用 Playwright、有的用 Selenium，有的 MCP Server 是 node 写的、有的是 python 写的。维护这些差异的成本，最后都变成了团队时间。

AIO Sandbox 这类项目最大的价值是收敛共识：环境结构是固定的，你只需要往里面填充业务。它的目录布局、端口设计、MCP 接入方式、VSCode 集成方案，都是社区反复踩过坑之后沉淀下来的。你基于它做二次开发，相当于站在一个结构良好的地基上，而不是每次从零垒砖。

另外要看到的是，这类容器型沙箱天然适合作为 CI/CD 的一部分。你可以把同一个镜像推到测试环境，让 Agent 在那个环境里跑自动化回归；也可以把它用作团队的内部开发环境，新人拉一个镜像就能开始干活。从投入产出比看，比自己维护一套环境系统省心得多。

2. 核心机制拆解：一个容器怎么撑起这么多能力

2.1 浏览器服务化：CDP 协议与常驻浏览器的设计逻辑

容器里的浏览器不是简单地在桌面上“打开”的，而是被当成一个服务进程在跑。最常见的方案是跑一个 Playwright server，对外暴露 WebSocket 端口，Agent 用客户端库连上来，就像在操作一台远程浏览器。

技术底座是 CDP，也就是 Chrome DevTools Protocol。这个协议把浏览器所有能被 DevTools 看到的行为都变成了 JSON 格式的消息，包括页面生命周期、DOM 节点、网络抓包、控制台日志、鼠标键盘事件等等。CDP 本身很底层，Playwright 把它封装得更友好，开发者不用手写 CDP 消息，直接调用 page.click、page.goto、page.locator 这些 API 就行。

浏览器服务化的最大好处是复用。常规做法是每个 Agent 进程拉一个浏览器实例，内存开销大，启动也慢。服务化之后，浏览器进程常驻，多个 Agent 或多轮任务可以对接同一个实例，页面上下文还能保持连续。举个例子：一个 Agent 上一轮打开了登录页并且已经填好了账号密码，下一轮它可以继续用这个会话，不用重新走一遍登录流程。这个体验在实际开发里非常关键，因为大多数任务本身就是多步的。

要是玩得深一点，容器里的浏览器服务还能做“预启动页面池”。把常用页面提前打开，Agent 要访问某个域名时直接从池里取，省掉导航时间；对于有一些频控策略的目标站点，页面池也能让并发请求看起来更自然。这是进阶优化，基础使用先不用想这么远。

对于阅读这篇文章的小白来说，理解 CDP 不需要懂太多细节，你只需要记住一个画面：浏览器被拆成了一个“远程控制服务”，任何能连上这个服务端口的程序，都能拿到浏览器的控制权。这个编程接口，就是 Agent 操作网页的唯一通道。

2.2 Shell 与文件系统：权限边界和共享机制是怎么设计的

Shell 模块的权限边界是这类沙箱的核心安全点。容器内默认用户差别非常大：如果以 root 身份跑，Agent 在容器内部几乎是无敌的，很多破坏性命令可以轻松执行；以一个受限用户跑，Agent 能动的只有自己的家目录和工作区。

实际配的时候，我建议把 Agent 的执行用户设置为非 root，并给宿主机挂载目录设置精确的读写范围。容器本身已经提供了第一层隔离：Agent 只能碰容器里的文件系统，不能直接访问宿主机磁盘。第二层隔离是 mount 的限制：你只把需要的工作目录挂进去，Agent 能看到的也只有这些目录。这样即使容器内误操作 rm -rf，也不会波及宿主机——顶多毁掉一个工作区。

文件共享的核心机制是 volume 挂载。宿主机上 ./workspace 挂到容器 /workspace，两边指向同一份数据。Agent 在容器里写文件，宿主机立刻可见；宿主机用 VSCode 或其他编辑器修改文件，容器里的 Agent 也能立刻读到。这个共享模型很朴素，但非常贴合 Agent 开发的实际需求：你总希望人在 loop 里——Agent 干活，人进来改东西，再让 Agent 继续。

标题把“文件”单独列成一个模块，我理解是在强调这个功能的明确语义。很多 Agent 框架把文件读写内置成 API，但在这个沙箱里，文件模块有专门的“工作区”概念，Agent 的当前目录是固定、可预期、可挂载的。对 Agent 而言，这就像一个桌面和抽屉：它知道从哪拿材料，也知道把成果放哪。

2.3 MCP：为什么是它，而不是自己封装一套工具 API

MCP 是这个项目里最值得单独讲的部分，也是近两年的技术热点。它解决的问题很聚焦：Agent 怎么调用外部工具？早期是各框架自己搞插件机制，每种 Agent 都有自己的内部绑定，工具生态完全割裂。MCP 把工具调用规范成了一个统一协议：MCP Client 和 MCP Server 通过 JSON-RPC 消息通信，Server 暴露工具列表，Client 发现工具并调用。

在 AIO Sandbox 里，Agent 是 MCP Client，外部功能都注册成 MCP Server。比如你想让 Agent 使用某个在线文档工具，或者某个项目管理系统的接口，把对应的 MCP Server 注册进配置，Agent 重启后就能看到新工具，完全不用改 Agent 业务代码。

这个“动态发现工具”的能力，是对 Agent 开发范式的一次升级。过去要扩展 Agent 能力，必须把调用逻辑写死在代码里；现在，配置一个 Server 就行。我做过一个试验：给沙箱里的 Agent 注册了 Postgres 数据库 MCP Server，让 Agent 执行 SQL 查询，把网页采集到的数据直接写入数据库表。整个过程中，Agent 代码只负责“采集”和“调用工具”，至于“怎么连数据库”，完全由 MCP Server 托管，分层非常清楚。

还有一个常被忽视的细节：MCP 协议本身与具体的大模型无关。它只定义 Client 和 Server 之间的消息格式，不规定是哪家模型在背后驱动。这意味着你在 AIO Sandbox 里接的 MCP Server，换一个模型供应商依然能复用。这是它成为生态标准的重要基础，也因为这一点，我会建议你做 Agent 项目时优先采用 MCP 而不是自研工具接口。

3. 部署实操：从拉镜像到成功接管环境的完整流程

3.1 前置准备：Docker 版本、磁盘空间和镜像选型

部署 AIO Sandbox 之前，先把底座打好。Docker 版本建议 20.10 以上，新版容器网络和 compose 插件都依赖较新的内核功能；太老的 Docker 跑这个镜像，启动时可能碰 seccomp 或 cgroup 兼容性问题，排查起来很费时间。

磁盘空间至少准备 2G 到 4G。这个镜像体积并不小，浏览器内核和 VSCode Server 都是典型的大组件，如果还要在容器里跑额外 MCP Server，又得给它们留运行空间。我之前见过空间不够导致容器启动中途失败的情况，与其事后清理日志和临时文件，不如一开始就留足。

镜像选型方面，第一次建议直接用 latest 标签把整体跑通；稳定之后，切换到具体版本号锁定环境。这里有一个团队协作的细节：所有人都应该锁同一个镜像 tag，否则 A 同学和 B 同学看到的环境不一致，Agent 行为就会出现偏差，这会让你对 Agent 本身的调试严重失真。

3.2 容器启动命令：端口规划、目录挂载与用户权限

启动容器这一步，给一个可直接参考的命令：

docker run -d \ --name aio-sandbox \ -p 8080:8080 \ -p 8443:8443 \ -p 3000:3000 \ -v $(pwd)/workspace:/workspace \ -e SANDBOX_USER=1000 \ aio-sandbox:latest

端口规划不是随便定的。8080 给浏览器服务，因为 Playwright server 默认端口习惯在 8080 附近；8443 给 VSCode Web，这个端口在 Web IDE 场景里比较典型；3000 给 MCP Server 网关，沿用了很多 Node 服务的默认约定。三个端口分开，每个模块的日志、监控、排障都是独立的，互不干扰。

目录挂载方面，把宿主机上的 workspace 挂到容器里的 /workspace。这样一来，Agent 产生的所有文件，宿主机打开同一个目录就能看到，也可以直接对接 CI/CD 产物目录。建议挂载前先 mkdir 并把目录属主改成容器内用户，这一步能规避很多权限问题。

用户权限是最容易被忽略的，也是我栽过跟头的地方。SANDBOX_USER=1000 这个环境变量，一般对应宿主机普通用户的 UID。容器内 Agent 用这个用户运行，不会以 root 乱跑。如果你用 Docker 的 --user 参数指定 UID，思路也对，但要特别注意：非 root 用户如果在容器内的 HOME 目录不存在，部分软件（比如 VSCode Server）会启动失败。用环境变量来切换用户通常更稳，很多官方镜像都是这么设计的。

3.3 容器启动后的三个自检步骤，确保环境真的可用

容器拉起来之后，别急着接 Agent，按三步自检一遍。

第一步，检查端口监听。在宿主机上执行 ss -lntp 或者 netstat -lntp，看 8080、8443、3000 三个端口是不是都有对应进程在监听。没有监听的端口，优先看容器日志，通常是某个模块启动失败。

第二步，检查浏览器服务接口。用浏览器打开 http://localhost:8080，如果看到一段 JSON 信息，说明浏览器服务就绪了。看到 JSON 里的 webSocketDebuggerUrl 字段不必惊讶，这是 CDP 协议的正常表现，代表浏览器内核已经在工作。

第三步，检查 VSCode Web 和 MCP 配置。打开 http://localhost:8443，确认能进入 VSCode 界面，并且打开工作区目录能看到挂载文件；然后在容器内部执行 mcp list（具体命令看项目 README），确认默认注册的 MCP Server 状态正常。三个步骤全部通过，再往环境里接 Agent，否则后面出问题，你很难分清楚是环境本身的问题还是 Agent 逻辑的问题。

4. 实战演练：让 Agent 在沙箱里完成数据采集任务

4.1 场景拆解：浏览器、Shell、文件、MCP 的联动链条

理论知识讲完，跑一段实际任务。任务很简单：让 Agent 打开一个指定网页，从页面上采集产品列表，保存成文件，再通过 MCP 写入外部数据库。

选这个任务，因为它几乎覆盖了所有核心能力。浏览器模块负责打开页面和提取数据；文件模块负责把结果写入工作区；MCP 负责把数据推送到外部数据库；Shell 模块则承担运行脚本、安装依赖的工作。这是一次典型的端到端联动。

我把场景拆成四步：

1. Agent 调用浏览器服务，打开目标网页。
2. Agent 用 Playwright 定位页面元素，抓取产品列表。
3. Agent 把数据写入 /workspace 下的输出文件。
4. Agent 调用数据库 MCP Server，把数据写入数据库表。

这个任务不需要写复杂的 Agent 编排。你可以直接用几个工具串起来，也可以写一段脚本交给 Agent 执行。核心是观察各个模块在链路里怎么协作。

4.2 核心代码与执行链路：从连接浏览器到写文件

在容器内，用 Python 客户端连接远程浏览器，核心逻辑大致是这样：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.connect("ws://localhost:8080") page = browser.new_page() page.goto("https://example.com") # 假设页面上有 product-item 类名的元素 items = page.locator(".product-item").all_inner_texts() with open("/workspace/output.txt", "w") as f: f.write("\n".join(items)) print(f"extracted {len(items)} items") browser.close()

这段代码不难，但三个细节值得展开说。

连接地址要写对。容器内 Agent 访问浏览器服务，用 localhost 没问题；如果 Agent 在另一个容器里，就要用 Docker 网络别名或者宿主机 IP，否则会连接超时。多容器协同场景里，这一步是高频卡点。

定位器要贴合页面结构。.product-item 只是示例，真实页面的 DOM 结构五花八门，你可能要用 text=、css=、xpath= 组合定位。如果页面是动态渲染的，抓取之前还要等元素出现，否则会拿到空列表。这也是浏览器自动化里最费时间的一环。

写文件的路径要落在工作区。/workspace 是挂载目录，Agent 写入的文件宿主机立即可见。如果写到 /tmp 或容器其他位置，宿主机看不到，除非你单独把那个目录也挂载出来。

跑完这段脚本，回到宿主机打开 workspace/output.txt，看到抓取的数据，就说明浏览器模块和文件模块都正常工作了。

4.3 接一个数据库 MCP Server：体验工具的即插即用

接下来演示 MCP 怎么接进来。以 Postgres 数据库为例，给沙箱注册一个数据库 MCP Server，然后让 Agent 把上面的结果写进数据库。

第一步，在 MCP 配置里新增 server 条目。以 JSON 配置为参考，格式如下：

{ "mcpServers": { "postgres": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-postgres", "postgresql://user:pass@host:5432/dbname" ] } } }

第二步，重启 MCP Client，确认 Agent 的工具列表里出现 postgres 相关工具。不同 Agent 框架的命名习惯不同，有的叫 tools，有的叫 mcp tools，总之你能看到 postgres_query、postgres_schema 之类的工具。

第三步，让 Agent 把上一步抓到的数据，通过 postgres 工具写入数据库。指令里直接说“请把 output.txt 的数据逐条插入 products 表”，Agent 会自动调用 MCP 工具，而你不需要写任何 SQL 连接逻辑。

这里有一个我在实操中踩过的坑：MCP Server 启动本质是一个子进程，它可能是 npx 运行 npm 包，也可能是 python 运行某个脚本。第一次运行要去 npm 或 pip 仓库下载依赖，如果容器网络没配好或者仓库访问慢，这里很容易卡死。建议在容器里预先执行一次 npx -y <server 包名>，确认依赖下载完成再改配置，否则第一次调用时看到的可能就是超时或者工具列表为空。

通过这个流程，你能直观体会“工具可插拔”的含义：Agent 核心代码没变，只改配置文件里的一个 server，它就多出一个业务能力。这就是 MCP 机制的核心价值。

在这里也可以留意标题中提到的“一天一个开源项目”系列视角：我选择 AIO Sandbox 作为实战入口，是因为它的功能模块足够完整，你在它一个项目里就能学会浏览器自动化、容器隔离、MCP 协议、Web IDE 集成这四件独立知识点，性价比很高。

5. 踩坑记录与常见问题排查

5.1 浏览器服务起不来：依赖缺失、root 限制和沙箱模式的取舍

浏览器服务起不来是第一个高频坑。如果容器日志里出现类似“缺少 libnss3.so”或者“error while loading shared libraries”的信息，基本就是系统依赖缺失。修复方式是在镜像的 Dockerfile 里补装这些库：

RUN apt-get update && apt-get install -y \ libnss3 libatk1.0-0 libatk-bridge2.0-0 libcups2 libxkbcommon0 libxcomposite1 libxdamage1 libxrandr2 libgbm1 libasound2

这些库基本就是 Chromium 的最小依赖集，具体以报错为准。如果镜像用的是 alpine 这类精简系统，包名可能会有差异，别硬套 apt。

另一个问题是 root 和沙箱模式。Chromium 默认有多进程沙箱机制，依赖内核特性，在容器内以 root 身份启动时，它可能因为安全限制拒绝运行。看到“Running as root without --no-sandbox is not supported”的报错，你就要做选择：让浏览器以非 root 用户跑，或者加上 --no-sandbox 参数。

坦白讲，--no-sandbox 属于“能用但别依赖”的选项。开发测试阶段图省事可以加，但如果是对外提供服务、要处理不可信网页的生产环境，我建议还是把用户权限做对，不要关闭浏览器的安全沙箱。这个取舍要在部署前想清楚，不然上线后换回来会牵涉一堆配置改动。

5.2 VSCode Web 白屏或只读：权限、缓存和端口折腾人

VSCode Web 打开后如果看到空白页面，十有八九是权限问题。容器内进程如果和挂载目录的属主不一致，就无法读写工作区文件，VSCode 会表现为加载失败或者只读模式。解决办法是统一 UID：宿主机目录属主改成 1000，容器用户也设成 1000，两边一致就顺畅了。

如果界面能打开但一直显示旧内容，很可能是浏览器缓存了旧页面。VSCode Web 是单页应用，前端 JS 做了大量状态缓存，改了端口或地址后，浏览器可能还在用旧缓存里的连接地址。直接解法是强制刷新、清掉该站点缓存，或者用无痕模式访问。

还有一个场景容易被忽略：如果你在宿主机上开了防火墙或者公司网络做了端口限制，8443 这类非标准端口可能无法从外部访问。排查时别只盯着容器，先确认宿主机安全组和防火墙的入站规则。

5.3 端口冲突与多容器网络互联：团队协作先定规矩

端口冲突在多人共用的机器上属于常态。如果没有提前规划，就会出现在别人把端口占住，你的 VSCode 起不来的情况。

我建议团队里约定一套端口分段规则：浏览器服务统一 8080-8090，编辑器统一 8443-8453，MCP 网关统一 3000-3009，每个项目分配一组端口，互不冲突。这个习惯虽然看起来笨，但在多人协作的环境里，远远胜过“出了纠纷再排查”。

容器互联是另一个高频问题。如果你维护多个沙箱容器，Agent 在容器 A 想访问容器 B 里的浏览器服务，用 localhost 肯定不通。正确做法是把几个容器放进同一个 Docker 自定义网络，这样容器名就是主机名。举个例子：

docker network create agent-net docker run --network agent-net --name sandbox-a ... docker run --network agent-net --name sandbox-b ...

之后在 sandbox-b 里访问 sandbox-a 的浏览器服务，连接地址写成 ws://sandbox-a:8080 即可。这个细节单容器跑一辈子可能遇不到，团队同时维护多个沙箱时几乎必然碰到。

5.4 排查命令速查表

这张表是从我实际踩坑记录里整理出来的，问题看着不少，但大多数都是环境层面的细枝末节，理清根因之后处理起来都很快。

5.5 资源占用与性能调优的一点实操经验

容器型沙箱开出来之后，资源占用一直是团队关注的焦点。我实测下来的体感是：浏览器内核常驻加上 VSCode Server，大概占 1G 到 1.5G 内存，这还是在没有太多页面并发的前提下。如果同时开多个 Agent 任务，内存压力会明显上升。

最简单的调优手段是控制浏览器并发页面数。不要在 Agent 逻辑里每到一个步骤就 new_page() 一个全新页面，尽量复用已打开的页面，用完之后主动关闭。另一个手段是限制 MCP Server 的数量，很多 MCP Server 都是 Node 子进程，每一个都会额外吃内存，只在真正需要的时候启用，而不是一把梭全注册。

如果你的宿主机是 4G 内存级别的小机器，跑 AIO Sandbox 会比较吃力，建议至少 8G 内存，否则系统 swap 会把整体性能拖垮。磁盘 IO 方面，SSD 和机械硬盘的差距在浏览器启动时体现得非常明显，有条件尽量用 SSD。

6. 写在最后：给新手的上手建议和后续扩展方向

6.1 最小闭环路线：先从一个小任务开始信任运维

如果你打算从零上手，我的建议是别追求一步到位。先跑通最小闭环：让 Agent 在浏览器模块里打开一个页面，写一个文件到工作区，然后用 VSCode Web 看一眼这个文件。跑通这个小链路，你已经掌握了这个沙箱的八成精髓。

很多新手朋友最大的焦虑是“我还没把所有功能搞清楚，怎么敢直接开跑”。其实不需要。容器沙箱最友好的地方在于可重置性：折腾坏了重新 docker run 一下，环境又回来了。你要做的是拿着这个安全网，大胆去试。

我自己带团队时的经验是，新人一天之内跑通环境、发出第一个 Playwright 连接请求，两天之内能完成一个带 MCP 的端到端小任务。核心不在于把文档读得多透，而在于亲手把链路走一遍。

6.2 还能往哪些方向继续深挖

AIO Sandbox 跑通之后，可扩展的方向不少。

第一是接更多 MCP Server。蓝湖、GitHub、数据库、各类 API，都有社区或官方 MCP 实现。你的 Agent 工具链可以随着业务需求不断增加，这也是 MCP 生态的红利。

第二是做团队共享沙箱服务。把 AIO Sandbox 部署到一台内网服务器上，团队成员通过浏览器访问各自的 VSCode Web 实例，这相当于一个轻量的云开发环境。配合用户鉴权和网络策略，能替代一部分全托管的云端 IDE，成本上会低不少。

第三是结合自动化测试流水线。这个沙箱本身就是为 Agent 执行而设计的，你可以把回归测试脚本封装成 MCP 工具，让 Agent 按业务场景自动执行 UI 测试，出结果后写入文件或数据库，再通知人去看 VSCode，整套流程可以串成一个闭环。

关于这类项目的维护，我个人的体会是把镜像版本当作环境契约来对待，任何依赖变更都走镜像发布而不是手动进容器改。这个习惯起初会麻烦，但长期看，它省掉的是无穷无尽的“环境不一致”带来的扯皮。

最后再分享一个我自己的小习惯：在宿主机上准备一个脚本目录，把常用的沙箱管理命令收拢在一起，包括启动、停止、查日志、清理磁盘、查看端口。看起来不起眼，但每次换机器或者拉新同事进来，这个脚本列表都能让环境搭建时间再压缩一半。AIO Sandbox 解决了环境的最后一公里，你要做的最后一步，就是把自己这侧的工作流也固化下来，让 Agent 和自己在同一个稳定地基上干活。