企业官网建设流程全解析

做 Agent 项目的朋友应该都有这种体会：模型推理能力越来越强，代码写得越来越像样，但真正让它“干活”，你反而开始纠结——它在哪干活？它能不能碰我的文件？它会不会把系统搞坏？这种纠结不是矫情，是真实翻车现场给逼出来的。我见过有人在本地跑一个带 Shell 权限的 Agent，结果它顺手把开发目录里的旧备份全删了；也见过 Agent 调浏览器接口去抓页面，因为环境不对，白跑一下午。后来我开始把 Agent 关进容器里，才慢慢从“伺候 Agent”变成“放心把活交给它”。

今天要聊的 AIO Sandbox，就是这类方案里一个相当省心的选择。它用一句话就能说清楚：把浏览器、Shell、文件系统、MCP 和 VSCode 全部塞进同一个容器，给 AI Agent 提供一个集工具、执行和人工观察于一体的隔离工作台。对你来说，它解决三件最实际的事：给 Agent 一个可以放心执行的环境、给它一套足够完整的工具链、再留一个人能插手查看的入口。下文我按自己搭建和使用的实际过程来讲，命令和配置以我用的版本为准，不同版本会有细微差异，但整体思路是通用的。

1. 为什么 Agent 需要一座“带工具的房间”

1.1 直接把 Agent 放宿主机上跑，容易出事

先说一个最基本的认知：Agent 本质上就是一个“会用工具的推理模型”。它不像普通程序，每一步都写死了，它是根据任务目标自己决定下一步做什么。这个能力很强，但也很危险。因为模型在生成工具调用时，偶尔会出现“调用参数填错”“路径写错”“想删 A 目录结果写成了 B 目录”的情况，哪怕概率只有百分之一，放在宿主机上就是一次事故。

我举个实际例子。我早期做自动化测试脚本时，让 Agent 帮忙清理一个临时目录里的缓存文件。它执行的命令是rm -rf /tmp/project-cache，但因为它读取工作目录时发生错位，实际执行变成了rm -rf /tmp/project——最后差了一个字母，整个项目源码被清空。如果不是我做了 Git 提交，那一整天的劳动就全没了。后来我养成了一个习惯：凡是要动文件、跑命令的 Agent，一律送进容器。

除了误删，还有环境污染问题。Agent 要用 Python 就得装包，要用 Node 就得 npm install，这些依赖装在宿主机上，时间长了会把你本机的 Python 环境搞得一团糟。pip 版本冲突、全局包版本被改、各种残留进程，修起来比重新装系统还头疼。容器化之后，Agent 在里面随便折腾，宿主机完全不沾边。

还有一个很多人忽略的点：浏览器的资源占用。Agent 一旦启动浏览器自动化，Chromium 实例可能同时开好几个标签页，内存瞬间吃掉几个 G。如果跑在宿主机上，卡的就是你的开发机；跑在容器里，最多是容器被 OOM Killer 干掉，你电脑还是流畅的。这种“事故边界”的隔离，本身就是沙箱存在的最大价值。

1.2 从“裸奔”到沙箱的三种形态

如果去翻 Agent 的工具链方案，会发现市面上的沙箱大概分成三类，各有各的适用场景：

我最早用的是纯代码沙箱，很快发现满足不了需求。因为 Agent 的真实任务往往是一串连续操作：先查资料、再写脚本、跑出结果、最后整理成报告。纯代码沙箱只能让你“提交一段代码，拿回一个结果”，中间过程全是黑盒。后来我转向自建容器，工具倒是齐了，但配置繁琐：要装 Chromium、要配 code-server、要处理 MCP 桥接、还得自己写入口脚本，折腾了两天，实在不划算。AIO Sandbox 这类一体化的方案，等于把这些东西预装好，我只需要把 Agent 接到入口上。

1.3 AIO Sandbox 到底省了哪些事

这个项目的设计思路很直白：Agent 需要什么，就装什么。它把五个能力打包成同一个容器：

• Shell：容器内的 bash 环境，Agent 可以执行任意命令，安装依赖、跑脚本、做系统管理。
• 浏览器：内置 Chromium 和自动化驱动，Agent 能打开网页、截图、点击、提取内容。
• 文件系统：容器内的工作目录，Agent 可以读、写、移动文件，也可以和宿主机共享一个持久化卷。
• MCP：容器对外暴露标准的 Model Context Protocol 入口，让上层 Agent 通过统一协议调用上述能力。
• VSCode：以 Web 形式提供 code-server，人用浏览器打开就能看到容器内的工作区，随时插手中断或者围观 Agent 干活。

你不需要自己写胶水代码，也不需要在一堆镜像之间做网络互通。跑起容器，把 Agent 客户端的 MCP 地址指过去，工具就齐了。这套设计特别适合两类人：一类是刚开始做 Agent 原型、不想把精力耗在环境搭建上的开发者；另一类是跑偏正式一点的任务、但又不希望 Agent 碰本机敏感资源的个人用户。

2. 拆解五个核心组件：Shell、浏览器、文件、MCP 与 VSCode

2.1 Shell：Agent 的“手”

Shell 是 Agent 从“只能想想”到“真的动手”的关键一层。没有 Shell，Agent 每次执行逻辑都要靠宿主环境给你准备好的 SDK 封装去调，能力边界死死卡在你的代码里。有了 Shell，它就是一个通用的操作系统接口：可以装包、可以跑测试、可以 grep 日志、可以写 crontab。

容器里的 Shell 和宿主机上的 Shell 有几点不一样，使用时要特别注意。

第一，执行环境是全新的。容器里没有你本机的 Python 环境、没有全局安装的命令工具，所有依赖都要现场装。所以你在给 Agent 布置任务时，最好先说清楚“这是一个全新环境，需要先安装 requests 库”。否则 Agent 第一次调用import requests失败，它还得自己摸索排查，浪费时间。

第二，输出有截断风险。Agent 调用 Shell 时，外层通常会对标准输出做截断处理，比如只保留最后 2000 个字符。如果你跑的命令输出特别长，Agent 看不到中间部分，可能会基于不完整的信息做错误判断。我的习惯是让 Agent 把关键结果写进文件，再用tail或者cat分段读取，这比让它直接看一大坨输出靠谱得多。

第三，环境变量和当前目录要显式设置。默认情况下，Agent 开启一个新的 Shell 会话时，工作目录可能不在你期望的位置。我在实践中会让 Agent 自己先执行pwd && ls -la确认当前状态，再开始干活。这个习惯看着啰嗦，但能避免大量“文件跑哪去了”的困惑。

还有一个很多人踩过的坑：Shell 里的“交互式命令”。比如某个命令会进入交互模式等待输入，Agent 一旦执行就卡住了。容器里的 Shell 一般以非交互模式运行，但如果遇到vim、less这类工具，或者某些脚本会等待输入，容易造成任务挂起。最好的做法是在 prompt 里就告诉 Agent：不要使用交互式命令，所有操作都以非交互方式完成，需要编辑文件时用sed、python -c或直接写文件。

2.2 浏览器：Agent 的“眼”

浏览器组件在 AIO Sandbox 里承担的是“看网页”和“操作网页”的职责。它不只是打开一个 URL 拿 HTML 那么简单，而是可以完成一整条链路：导航到页面、等待渲染、点击按钮、填写表单、截图返回给视觉模型判断、再继续下一步。

这里就要提一下 MCP 的作用了。AIO Sandbox 里的浏览器能力通常是通过 Playwright 这类自动化框架暴露成 MCP 工具的，Agent 不需要直接写 Playwright 代码，而是通过工具调用就能完成操作。你可以理解为：MCP 把浏览器变成了一个 Agent 可以“伸手去点”的工具箱，而不是让 Agent 自己去敲代码控制键盘鼠标。

实际使用中，我建议把浏览器任务分成两类来看。

一类是信息获取。比如让 Agent 去抓取某个页面上的数据、查看某篇文档的标题、检查某个按钮是否存在。这种任务用无头浏览器就够了，速度快，资源占用小。

另一类是复杂交互和视觉验证。比如注册账号、填写表单、拖动页面、分析页面样式。这种任务最好让它截图，配合 GPT-4o 这类多模态模型来判断页面状态。我在让 Agent 做表单自动化时，会让它每完成一步就截一张图，然后“看一眼”截图，确认没有弹窗遮挡、没有验证码等问题，再继续下一步。事实证明，这比盲目点击稳得多。

浏览器组件最常见的坑是“容器内无头模式起不来”。常见原因是容器内存太小、Chromium 缺少系统依赖或沙箱权限不足。我在 3.4 里会专门讲资源限制的配置，这里先说一条经验：给浏览器预留至少 2GB 内存，否则打开页面时很容易直接崩溃，Agent 反馈给你的就是一段莫名其妙的“页面加载失败”。

2.3 文件系统：Agent 的“办公桌”

文件系统是 Agent 工作的基础。AIO Sandbox 容器里会有一个工作目录，Agent 所有读写都发生在这个目录里。你可能想问：这和我直接在宿主机上给它一个文件夹有什么区别？

区别在于边界。容器内的文件系统和宿主机是完全隔离的，Agent 只能接触你挂载进去的目录。就算它真的发疯执行了rm -rf /，影响的也只是容器内部，宿主机毫发无损。这种兜底逻辑，让你可以放心大胆地给它“写”权限，而不是像以前那样只读挂载、处处提防。

关于文件操作，我有几个习惯要分享。

第一，持久化挂载很关键。默认情况下容器停止后文件就丢了，所以一定要用-v挂载一个宿主机目录或命名卷到工作目录。这样即使是半夜跑任务，第二天你也能看到产物。我习惯挂载一个专门的项目目录，比如~/agent-work，这样容器内外文件同步，调起来方便。

第二，权限要提前想清楚。容器内运行的用户（比如node用户）和你宿主机用户的 UID 可能不一致，导致容器里创建的文件，在宿主机上无法删除或者修改。解决办法是用--user参数指定 UID，或者直接在容器内chown。这个坑我在第 5 章会详细展开。

第三，Agent 写文件时最好用绝对路径。我给 Agent 下任务时，都会把工作目录的绝对路径写在 prompt 里，比如请把报告保存到 /workspace/report.md。相对路径在多个 Shell 会话之间容易丢失上下文，Agent 可能会把文件写到意料之外的位置，最后你翻遍整个目录都找不到。

2.4 MCP：连接模型与工具的“USB-C 接口”

MCP 是 Model Context Protocol 的缩写。理解它可以用一个类比：你的电脑有各种外设，以前每个外设都要装专属驱动，接口还不一样；后来有了 USB-C，一个口走天下。MCP 就是模型和工具之间的 USB-C——模型通过统一的协议去调用各种工具，工具方只需要实现 MCP 标准，就能被任意兼容模型使用。

AIO Sandbox 的灵魂就在这层。它把 Shell、文件、浏览器这些能力统一封装成 MCP Server，Agent 通过 MCP Client 连接进去，看到的是一组标准的工具列表。你不需要为每个能力单独写适配代码，也不需要管底层是 HTTP 还是 WebSocket，MCP 协议把这些都抽象掉了。

MCP 的传输模式常见有两种：stdio 和 SSE。stdio 模式下，客户端直接拉起一个本地进程，进程的输入输出就是 MCP 通信通道；SSE（Server-Sent Events）模式下，客户端走 HTTP 连接远程的 MCP Server。AIO Sandbox 里能力是容器化的，所以更常见的接入方式是 SSE——Agent 客户端连接容器暴露的 HTTP 端口。

配置 MCP 时最容易出错的是地址和鉴权。很多 Agent 框架里 MCP Server 的 URL 写成http://127.0.0.1:3000/mcp，但你的容器如果是用 Docker 跑的，就要确认这个地址是容器内部的 127.0.0.1，而客户端在宿主机上，需要映射到宿主机的端口。我在第 4 章会给出一个可以直接抄的配置示例。还有鉴权问题，有些 MCP Server 需要 token 或 API Key，配置时不要把密钥写死在代码里，建议通过环境变量注入，避免泄密。

2.5 VSCode：人机协作的“观察窗”

容器里集成一个 Web 版 VSCode，看着像“附赠功能”，实际价值比我预想的大得多。

首先，它解决了调试时的“盲目感”。Agent 在容器里执行命令时，你看不到它到底在干嘛，只能靠日志推断。有了 VSCode，你可以直接打开浏览器访问 code-server 的端口，进入容器内的工作区，实时查看文件变动、手动修改配置，甚至直接在终端里敲命令跟容器交互。这种“看得见”的体验，会让 Agent 工作变得完全不慌。

其次，它是人工干预的入口。Agent 卡住了、方向跑偏了、或者你想中途调整策略，直接在 VSCode 里改文件、停进程，然后给 Agent 发一条新的指令，它就能接着干。我跑一些耗时很长的自动化任务时，经常一边开着 VSCode 盯着，一边在另一个窗口和 Agent 聊天调整方案，体验接近“两个人远程协作写代码”。

code-server 的端口一般映射到宿主机某个端口，比如 9000。首次打开会要求密码，这个密码是通过容器环境变量设置的，默认值最好改掉，不要裸奔。

3. 本地部署 AIO Sandbox 的完整实操

3.1 环境准备：先确认三个基础条件

部署 AIO Sandbox 本身不难，但有几个前置条件需要先勾掉。

• Docker 环境：建议用 Docker 20.10 以上版本，Compose 插件也装好。Windows 用户用 Docker Desktop，Linux 用户用原生 Docker 引擎，macOS 同理。容器比较大，磁盘建议预留 10GB 以上。
• 资源配额：镜像运行起来之后，浏览器和 VSCode 都是吃资源的大户。至少给容器分配 4GB 内存和 2 个 CPU 核心，低于这个配置，跑网页自动化分分钟崩。macOS 用户别忘了在 Docker Desktop 里调大内存上限，默认的 2GB 根本不够。
• 镜像源与网络：拉镜像时如果速度慢，可以配置 Docker 的镜像加速器。容器内部要下载 npm 包、Python 包，可能还需要调慢或失败的问题，建议提前在容器里换好 npm 和 pip 镜像源。

先确认这三件事，再往下走。否则很可能出现“镜像拉下来了，但容器根本跑不起来”的尴尬。

3.2 用 docker run 快速起一个实例

首次体验，直接用docker run跑起来最省事。以我实际使用的参数为例：

docker run -d \ --name aio-sandbox \ -p 3000:3000 \ -p 8080:8080 \ -p 9000:9000 \ -e PASSWORD=your-password \ -v agent-work:/workspace \ --memory=4g \ --cpus=2 \ ghcr.io/mikecarlton/aio-sandbox:latest

简单说一下这几个参数为什么这么写：

• -p 3000:3000：暴露 Agent API 或 MCP 的 HTTP 端口，你的 Agent 客户端就是通过这个端口连接沙箱的。
• -p 8080:8080：浏览器远程调试或桌面访问端口。部分实现会提供一个轻量级桌面，或者让浏览器自动化通过这个端口通信。
• -p 9000:9000：code-server 端口，浏览器访问http://localhost:9000进入容器内的 VSCode。
• -e PASSWORD：设置 VSCode 的访问密码，务必改成你自己的强密码。
• -v agent-work:/workspace：持久化工作目录。我习惯用命名卷，这样容器删了重建，数据还在。
• --memory和--cpus：资源限制。这个加到容器上既是保护宿主机，也是防止 Agent 失控把资源打满。

跑起来之后，先验证几个端口是否正常：浏览器打开 9000 端口看 VSCode 能不能登录，curl 一下 3000 端口看 MCP 接口有没有响应。都通了，说明环境就绪。

3.3 用 docker compose 固化配置，避免每次敲长命令

docker run只是临时方案，真正长期用，我建议写一个docker-compose.yml把配置固化下来。这是我的实际配置文件，可作参考：

version: "3.8" services: sandbox: image: ghcr.io/mikecarlton/aio-sandbox:latest container_name: aio-sandbox restart: unless-stopped ports: - "3000:3000" - "8080:8080" - "9000:9000" environment: - PASSWORD=${SANDBOX_PASSWORD:-changeme} - OPENAI_API_KEY=${OPENAI_API_KEY:-} volumes: - agent-work:/workspace mem_limit: 4g cpus: 2.0 security_opt: - no-new-privileges:true cap_drop: - ALL volumes: agent-work:

用 Compose 的好处很明显：配置可以纳入版本管理，换机器重建环境只需要一条docker compose up -d。更重要的是，你可以在环境变量区域统一管理密钥，避免在命令行直接暴露密码和 API Key。

每次改动配置文件后执行docker compose up -d会增量更新容器，不会从头再来，方便很多。如果你需要升级镜像版本，docker compose pull && docker compose up -d即可。

3.4 安全加固：Agent 容器的资源限制与权限收敛

很多朋友都问：Agent 都进容器了，还需要做安全加固吗？我的答案是：需要，而且比普通容器更必要。普通容器跑的是确定程序，Agent 容器跑的是“会自己编命令”的模型，输出的不确定性更高，所以边界要收得更紧。

下面这几个参数，我建议在没有特殊需求时都加上：

• --cap-drop=ALL：去掉容器内所有 Linux 内核能力。普通 bash、文件读写、网络请求都不受影响，但那些需要特殊权限的操作如 mount、iptables 会被禁止。如果你的任务需要抓包或改网络，再按需加回特定 cap。
• --security-opt no-new-privileges:true：禁止进程获得更高权限。即使容器里有个进程想通过 setuid 提权，也会被阻止。
• --pids-limit：限制容器内进程数量，防止 Agent 跑出大量僵尸进程。我一般设置 256。
• --memory和--cpus：前面提过，既保护宿主机也保证浏览器稳定。
• --read-only配合--tmpfs：把根文件系统设成只读，只允许 /tmp 和挂载卷可写。这个策略很稳，但不是所有镜像都兼容，建议先跑通再开启。

我实际使用的 compose 文件里已经包含了cap_drop和no-new-privileges。这样即使 Agent 被恶意 prompt 诱导，试图做出越界行为，也会在内核层面被卡住。

还有一个容易被忽略的点：不要用 root 用户跑容器。有些镜像默认是 root 用户，Agent 在容器里的执行权限就太大了。尽量用镜像里自带的普通用户，或者通过user: "1000:1000"指定普通 UID。非 root 用户在容器里照样可以装软件、写文件、跑服务，但这些操作的影响范围被限制在用户级，不能随便改系统目录，安全系数高一个档次。

4. 接入 Agent：MCP 配置与真实调用

4.1 理解 Agent 与 MCP 的“握手”过程

现在进入正题：怎么让一个 Agent 客户端真正用上 AIO Sandbox 的能力。

先说概念。MCP 的架构分为三层：MCP Client、MCP Server 和工具本身。Agent 框架（比如 LangChain、Claude Code、自研 Agent）作为 Client，会向 MCP Server 发起tools/list请求，拿到可用工具清单，再根据任务决定调用哪个工具。AIO Sandbox 里的 Shell、文件、浏览器能力都封装成了不同的 MCP Server，Agent 连接上去，看到的就是一组“可以执行的命令”。

通信过程大致是：Agent Client 启动 → 连接 MCP Server 地址 → 拉取工具列表 → 生成工具调用请求 → Server 执行实际命令 → 返回结构化结果 → Agent 决定下一步。整个过程对用户透明，你告诉 Agent “帮我查一下今天的新闻并整理要闻”，它会自己判断先调浏览器工具访问新闻站点，再调文件工具写报告，最后跑一个脚本做格式化。

理解这个概念，你就知道接入 AIO Sandbox 的核心工作其实就一步：把 MCP Server 地址填对。

4.2 MCP 配置示例：一份可以直接抄的 mcp.json

不同的 Agent 框架对 MCP 配置的写法略有不同，但核心结构一致。下面是一份通用化的配置示例，以 Claude Code 风格的mcp.json为例：

{ "mcpServers": { "aio-sandbox": { "type": "sse", "url": "http://localhost:3000/mcp", "headers": { "Authorization": "Bearer ${SANDBOX_TOKEN}" } } } }

解释一下这里的几个字段：

• type：连接类型。sse表示走 HTTP 的 Server-Sent Events，适合远程连接容器化服务。如果你的 Agent 框架支持 stdio，也可以通过docker exec在宿主侧拉起一个客户端进程，但这种模式下不建议，因为 java、Node 等语言的进程管理会复杂一些。
• url：AIO Sandbox 暴露的 MCP 端点，一般是容器 3000 端口对应的宿主机地址。注意是宿主机localhost，不是容器内localhost。如果你是远程服务器，需要把localhost换成服务器公网 IP。
• headers：鉴权信息。有些服务需要在请求头带 token，这个 token 在启动容器时通过环境变量生成。如果你不需要鉴权，header 可以省略。

除了配置，还要注意 Agent 框架是否支持 MCP。很多主流的 Agent 框架目前已经把 MCP 作为一等公民支持，你可以直接读官方文档接入。如果你用的是自研框架，需要实现一个简单的 MCP Client，建议直接基于官方 SDK，别自己造轮子。

4.3 走一遍真实场景：让 Agent 自动收集资料并汇成报告

配置完成之后，我建议按下面这个场景完整跑一遍，验证所有链路是否打通。

任务描述给 Agent：“请打开天气网站，查询北京、上海、广州三地今天的天气，整理成表格，写到 /workspace/weather.md 里。”

Agent 拿到任务后会经历这样几步：

1. 从 MCP 工具列表中选择浏览器相关工具，调用导航函数打开指定的天气网站。
2. 调用截图工具获取页面状态，交给多模态模型识别页面内容。
3. 如果页面复杂，它可能会切换到 Shell 工具，使用 curl 直接抓取接口 JSON 数据，然后用 python 解析。
4. 所有数据到手后，调用文件相关工具，在 /workspace 下创建 weather.md 并写入内容。
5. 你可以打开宿主机上挂载的 agent-work 目录，直接查看生成的 weather.md。

这整个过程里，你只需要在最初下发任务时写清楚需求，中间完全不用干预。如果中途 Agent 跑偏，你可以打开 VSCode 的 9000 端口，看看容器内正在发生什么，甚至可以手动改它正在写的文件。

我推荐新手第一次实验时，就选这种“跨工具链”的任务，而不是单一步骤的任务。因为跨工具任务才能真正检验 MCP 配置、浏览器可用性、文件系统权限、Shell 执行能力是否全部正常。如果这种任务能顺利跑完，你的沙箱就算真的配好了。

5. 实测中踩过的坑与排查技巧

5.1 容器起不来或 Shell 打不开

有时候启动容器后，你发现 VSCode 能访问，但 Agent 执行 Shell 命令时报错，或者直接提示“starting with root...can't open root shell, try again...still not :(”。这通常不是镜像坏了，而是容器入口脚本在初始化时出了问题。

首选的排查路径：先看容器日志。

docker logs aio-sandbox

如果日志里显示某个初始化脚本失败，多半是挂载目录权限不对，导致入口脚本无法写临时文件。我之前遇到过一次，是因为把宿主机的~/agent-work目录挂载进容器时，目录属主是 root，但容器内用户没有写权限，初始化流程直接中断了。解决办法很简单：宿主机上chown -R 1000:1000 ~/agent-work，或者给容器内对应用户开放写入权限。

还有可能是镜像默认的 Shell 入口需要交互式终端，但在 docker run 时没有附加-it。如果只是运行后台服务，不需要交互终端；但如果你通过docker exec -it aio-sandbox bash手动进去发现 Shell 异常，先确认是否用了不支持的命令。我在 2.1 里说过，容器内是精简环境，bash存在但很多增强功能可能没装全，遇到问题先看报错再对症安装。

5.2 容器内网络慢或 DNS 解析失败

Agent 在容器里要下载依赖、调 API，网络是命脉。最常见的坑是 DNS 问题，表现为curl直接报无法解析域名，但宿主机明明能正常上网。

这种问题优先检查容器 DNS 配置。Docker 默认使用宿主机配置的 DNS，但如果宿主机用了某些特殊网络环境，容器内部解析就会失败。解决方法是运行容器时指定 DNS 服务器：

docker run -d --dns 223.5.5.5 --dns 8.8.8.8 ...

或者编辑/etc/docker/daemon.json里加：

{ "dns": ["223.5.5.5", "8.8.8.8"] }

配置完成后重启 Docker 服务再重建容器。

另一个热点问题是包管理工具慢。容器内默认的 npm 源和 pip 源在部分网络环境下速度感人，建议一进容器先把源换掉。npm 换源用npm config set registry，pip 换源用pip config set global.index-url。这个操作可以写进容器启动脚本或 Dockerfile 里，省得每次手动配。

5.3 端口冲突与访问不了

AIO Sandbox 默认占用的 3000、8080、9000 三个端口，如果你本机已经有服务占用了，容器会启动失败。查看端口占用：

lsof -i :3000 netstat -tunlp | grep 3000

解决方式是改宿主机侧映射端口，比如把 3000 换成 3100：

-p 3100:3000

容器内部端口保持 3000 不变，宿主机对外用 3100。然后 Agent 配置里的 MCP 地址也要同步改成http://localhost:3100/mcp。

还有一个访问不了的常见原因：容器跑在远程服务器上，你在本地访问时把localhost当成了服务器地址。正确做法是把localhost换成服务器 IP，同时确认端口没有在云服务商安全组里被挡掉。

5.4 浏览器崩了：资源不足与系统依赖缺失

浏览器起不来，或者跑一半崩掉，是 Agent 沙箱最让人头疼的问题。我遇到过的原因基本可以归成三类：内存不足、系统依赖缺失、沙箱权限被卡。

内存问题最简单也最常被忽略。4GB 内存跑 Chromium 是底线，如果再同时跑 VSCode 和 Node 服务，最好给到 6GB。我在 3.2 里建议的--memory=4g是“起步”，如果觉得容器整体偏卡，先看docker stats，内存接近上限就加大配额。

系统依赖缺失的表现通常是启动 Chromium 时报缺少.so库。AIO Sandbox 镜像一般已经预装好了，但如果出现缺库，可以进容器手动检查：

ldd /usr/bin/chromium | grep "not found"

找到缺了什么再apt-get install对应包。如果连 apt 都装不了，检查/etc/apt/sources.list里的源是不是失效了，先更新源再装。

最后是 Chromium 沙箱问题。容器内以 root 身份跑 Chromium 时经常提示沙箱错误，网上五花八门的参数都有，我最常用的是在启动参数里加--no-sandbox。这只是绕过限制，不是最佳安全实践，但如果你是在容器这种边界里使用，问题不大。优先试试，实在不行再加--disable-dev-shm-usage解决共享内存不足的问题。

5.5 文件权限：容器里写的文件，宿主机删不掉

这个坑我踩得特别深。容器内以 root 或某个特殊 UID 用户创建的文件，拿到宿主机上可能显示“操作权限不足”，删除和修改都要 sudo。尤其是在 macOS 和 Windows 的 Docker Desktop 上，文件权限跨系统之间的行为更诡异。

我总结的排查顺序是：先看文件属主和属组。

ls -la ~/agent-work/weather.md

如果属主是一个很大的 UID，比如1009999，那基本就是权限错位了。解决方案有三种：

1. 容器内手动改归属：docker exec -it aio-sandbox chown -R 1000:1000 /workspace，但每次都要手动执行，治标不治本。
2. 运行容器时指定用户：在 compose 里加user: "1000:1000"，让容器内进程的 UID 和宿主机用户一致，从根本上避免错位。
3. 挂载时不用本地目录，用命名卷：命名卷由 Docker 管理，文件属主不会和宿主机用户冲突，缺点是你在宿主机上直接“看到”不了文件，要用docker cp或进入容器查看。

如果你像我一样希望容器内外文件互通，推荐方案 2。

最后列一个速查表，方便你遇到问题直接对号入座：

说实话，这套东西我用了快两个月，最大的感受就三个：确定性、边界、可视。确定性在于 Agent 的执行环境每次都是全新的，不会因为宿主机状态不同而翻车；边界在于它再怎么折腾，也只是在这个容器里折腾，我不用担心宿主机被弄脏；可视在于我可以随时打开 VSCode 看一眼它到底在干什么，那种“失控感”一下就消解了。如果你也在做 Agent 相关的项目，或者想把 AI 自动化从“玩票”升级成“能放心跑任务”的状态，我建议你拿一个真实的小任务试一遍——比如就让 Agent 去抓一个网页数据、整理成文档。这个容器帮你兜住所有脏活累活，而你只需要在中途给它递个话、提个醒，最后收成果就行。