森纳映画我把 agent browser（浏览器智能体）装进容器，前后折腾了不下两天。第一天是在自己电脑上直接把官方包装上，跑几个网页自动化任务完全没问题；第二天换到一台干净的服务器上，按同样的步骤来，结果连浏览器都起不来，一会儿缺系统依赖库、一会儿字体目录不对，等把各种包补齐了，又发现Python小版本不一样导致某个API行为悄悄变了。那两天我基本在重复“装环境—跑—崩—重装”的循环。后来我花了一天把整个 agent browser 塞进 Docker 容器，从此换机器只需要一次 docker build，跑起来之后稳定得多。
这篇东西不是官方文档翻译，是我把 agent browser 容器化之后整理的完整过程，包括镜像选型、安装步骤、常见的坑、多实例编排和加固建议。适合想把 agent browser 跑在可靠环境里的开发者，尤其是要接定时任务、挂多实例、团队共用一套环境的场景。如果你只是想在笔记本上临时试一下，裸机装更快；但如果你已经经历过“换台机器就跑不起来”的崩溃，那这篇文章大概率能帮你少走一晚上的弯路。
1. 为什么要费劲把 agent browser 塞进容器
1.1 裸机安装的典型翻车现场
agent browser 这类工具表面上是一个 Python 包或 Node 包，装上就能用，但真正跑起来它要拉起来一个完整浏览器内核，这就把问题复杂化了。浏览器依赖的系统库非常多：libnss3、libatk、libcups、libxkbcommon、fonts-liberation 这些只是其中一部分，而且不同 Linux 发行版包名还不一样，Ubuntu 跟 CentOS 差的不是一星半点。再叠加一个因素：这类工具对 Python/Node 的版本有要求，代码本身可能对某个小版本有隐性依赖，而操作系统自带的包管理器往往不会精确到这一步。
我遇到的翻车现场是这样的：本机跑得好好的任务，复制到服务器上，第一条执行到“打开浏览器”就终止，日志里只有一段含糊的“浏览器进程退出，请检查环境”。后来我用 ldd 逐个检查浏览器的动态库依赖，发现缺了两个共享库，而这两个库又牵扯到几个系统包。把系统包装上之后，浏览器能起来了，但又因为系统中文字体没装，页面上所有中文全是方框，自动化脚本里对按钮文字做的匹配全部失效。这些问题每个单看都不大，但串起来能消耗一个通宵。
1.2 容器给 agent browser 带来的几项硬收益
我后来想明白一件事：agent browser 这个工具的核心价值在业务代码和编排逻辑，而不在“重复安装那一堆底层依赖”。容器恰好把整个应用与其操作系统级别的依赖打包在一起，这带来了几个裸机安装很难做到的收益：
- 环境完全一致。构建出的镜像在开发机、CI、生产服务器上行为一致，不会再出现“我本机能跑”这个经典回答。
- 可回滚。镜像一旦打了 tag，旧版本随时可以拉起来。裸机安装时如果升级了一个依赖把环境搞坏了，想恢复只能靠备份或重装。
- 多实例友好。同一台服务器上可以跑多个版本、多个实例，互不干扰，只要端口和挂载目录不冲突。
- 资源回收干净。容器删掉就什么都没有了，不会在宿主机上留下浏览器残留进程、缓存目录、无用的系统库。
这里多说一句：agent browser 本身是无状态业务居多，特别适合用“不可变基础设施”的思路去管理。把每次代码改动都变成一个新镜像，而不是在运行的机器上手动 patch，长期维护成本会低很多。
1.3 什么场景不适合塞进容器
容器不是万能的，我试过之后也发现有几个场景不适合：
- 纯一次性实验：只是想跑一个脚本验证 idea，裸机
pip install更快，不需要为了一个临时任务去维护 Dockerfile。 - 强依赖本地桌面环境：如果 agent browser 的调试需要你实时看着窗口操作、并且要求 GUI 交互，容器里跑无头浏览器虽然可行，但你把窗口映射出来会非常别扭，不如本地跑。
- 对浏览器底层的特殊裁剪：有些团队会魔改 Chromium 内核，比如打补丁、编译私有版本，这种偏底层的场景更适合放在专用构建机而不是通用容器里。
所以我的判断标准很简单：只要你要在超过两台机器上运行、或者要定时跑、或者有团队协作，就直接容器化；单独一次性的折腾，别折腾。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选镜像和配置底层环境：决定后面是否顺畅
2.1 基础镜像怎么选：Python/Node 还是现成浏览器镜像
容器化 agent browser 的第一步是选基础镜像。我试过三条路线，各有适用场景：
| 路线 | 代表镜像 | 优点 | 缺点 | 推荐场景 |
|---|---|---|---|---|
| 通用 Linux + 自己装依赖 | debian:12-slim | 可控性好、镜像可做到相对干净 | 需要手动安装浏览器和系统库，Dockerfile 较长 | 生产环境定制 |
| 语言官方镜像 | python:3.11-slim / node:20-slim | 语言运行时版本明确，包管理顺手 | 仍要自己处理浏览器和系统依赖 | 大多数安装 agent browser 的场景 |
| 现成浏览器镜像 | chromium 相关开源镜像 | 浏览器已预装，减少踩坑 | 体积大、版本受上游控制 | 快速验证、不关心底层 |
我最常用的是第二条路线：以 python:3.11-slim 为基础，自己装 Chromium 和依赖。原因是 agent browser 通常通过语言 SDK 调用浏览器，语言运行时的版本直接影响 SDK 行为，用官方语言镜像能锁定这一层；浏览器虽然是自己装的，但用 apt 固定版本后也可以做