Steel Browser：把 Chrome 变成 AI Agent 的远程沙箱
🔥 Open Source Browser API for AI Agents & Apps. Steel Browser is a batteries-included browser sandbox that lets you automate the web without worrying about infrastructure.
秒懂
- 它是什么？
- Steel Browser 是一个开源浏览器 API，用 Docker 一条命令就能拉起带会话管理和代理链的 Chrome 实例。本文拆解它的架构、运行方式，以及为什么它适合原型验证但未必适合所有生产场景。
- 适合谁用？
- Steel Browser 适合两类人：一是想快速给 AI Agent 加上浏览器能力、又不愿自己维护 Chrome 进程和会话状态的开发者；二是需要代理轮换和反检测功能、但不想从零搭建的团队。不适合对浏览器指纹有极致要求、或需要在无 Docker 环境里做轻量嵌入的人，因为它的交付形态就是 Docker 镜像加 Node 服务，本地跑还得依赖系统 Chrome。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 13 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 AI Agent 的浏览器脏活
写 AI Agent 的人很快会遇到一个麻烦：让模型去操作网页，不能只发一个 HTTP 请求。你得启动浏览器、保持登录态、处理弹窗、换 IP、截屏、把页面转成模型能读的文本。这些事单独做都不难，堆在一起就成了基础设施负担。Steel Browser 把这一整层收进一个 Docker 容器，对外暴露 HTTP API。你调用它创建会话、打开页面、执行操作，不用关心 Chrome 进程死没死、cookie 存哪、代理怎么配。它面向的是用 Puppeteer、Playwright 或 Selenium 写自动化脚本的人，也面向那些想给 LLM 一个真实浏览器操作能力的应用开发者。README 里说得很直接：与其自己建自动化基础设施，不如让 Steel 处理复杂度。
从 CDP 到会话管理的分层设计
Steel 的底层机制不难猜：它用 Puppeteer 和 Chrome DevTools Protocol 控制 Chrome 实例。但真正有价值的是它往上叠的几层。第一层是会话管理，浏览器状态、cookie、localStorage 可以在多次请求之间保持，这对需要登录的 Agent 任务很关键。第二层是代理链管理，支持 IP 轮换，免去你自己写代理切换逻辑。第三层是资源管理，自动清理和生命周期控制，避免容器里堆满僵尸 Chrome。它还内置了反检测插件和指纹管理，以及请求日志和调试 UI。README 里提到的浏览器工具包括把页面转成 markdown、readability 格式、截图和 PDF，这些是 AI 应用最常用的输出格式。整个设计像是把浏览器自动化里重复出现的模式做成了服务，而不是单纯暴露一个 CDP 端点。
一条 Docker 命令就能跑起来
最快的启动方式是拉预构建镜像。README 给出的命令是：docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser。跑起来后，API 在 3000 端口，UI 在 http://localhost:3000/ui，9223 端口留给控制台调试器。想分开跑 API 和 UI 可以用 docker compose up。Apple Silicon 用户需要加环境变量 DOCKER_DEFAULT_PLATFORM=linux/arm64。不用 Docker 也可以，前提是你装了 Node.js 和 Chrome，然后 npm install && npm run dev。Chrome 可执行文件的路径有默认检查位置，Linux 是 /usr/bin/google-chrome，macOS 是 /Applications/Google Chrome.app/Contents/MacOS/Google Chrome，Windows 是 Program Files 下的 chrome.exe。自定义路径就设 CHROME_EXECUTABLE_PATH 环境变量。对只想评估的人，Docker 路线最省事，因为它帮你装好了 Chrome 和所有依赖。
Steel Cloud 与自托管的双轨选择
Steel 提供两条使用路径。一条是官方的 Steel Cloud，注册账号就能用，省去部署和维护。另一条是自托管，可以部署到 Railway、Render，或跑在本地 Docker。这种双轨模式在开源项目里不少见，但值得注意：README 里“Getting Started”一节把 Cloud 放在最前面，自托管放在后面，暗示了项目方的优先级。自托管的好处是数据和流量都在自己手里，对隐私敏感的场景更合适。坏处是你得自己承担镜像更新、Chrome 版本升级、代理质量这些运维工作。Cloud 版本省事，但你要把浏览器会话数据交给第三方。选哪条路，取决于你对数据边界的要求，而不是功能差异。
兼容层：Puppeteer、Playwright 还是 Selenium
Steel 说它允许你用 Puppeteer、Playwright 或 Selenium 连接。这意味着它没有锁死客户端库，你现有的自动化脚本理论上可以改改连接目标就迁过来。但 README 没有给出具体怎么连的代码示例，只提到用 Puppeteer 和 CDP 做底层控制。这里有一个需要自己验证的点：Playwright 和 Selenium 的连接是否经过官方维护的适配层，还是只是 CDP 天然兼容所以“能用”。如果是后者，那么遇到 Playwright 特有的 API 或 Selenium 的 WebDriver 协议时，可能会有坑。文档里提到的 Swagger UI 在 http://0.0.0.0:3000/documentation，那里应该有更详细的接口说明。在动手迁移前，值得先确认你的核心操作是否在 Steel 的 API 覆盖范围内，而不是假设所有客户端功能都完整映射。
反检测与指纹管理：能力边界要看清
Steel 把 stealth 插件和指纹管理列为卖点，这对爬虫和 AI Agent 都有吸引力。但反检测是个军备竞赛，没有一劳永逸的方案。README 只说了“includes stealth plugins and fingerprint management”，没提具体用了哪些技术、指纹是随机生成还是可配置、更新频率如何。这些细节决定了它在面对严格反爬站点时的表现。另一个问题是代理链管理，README 说内置了 IP 轮换，但没有说明支持哪些代理协议、认证方式、以及轮换策略是否可定制。如果你要对付的是 Cloudflare 级别的防护，Steel 的默认反检测可能不够，你得自己叠加更专业的指纹库或住宅代理。这个项目目前是 public beta，版本号还在 v0.5.x，功能演进快，但也意味着稳定性可能还没到生产级。
替代方案：Playwright 与 Browserless 的路线差异
如果不想用 Steel，最常见的替代是直接上 Playwright，自己管理浏览器实例。Playwright 是一个库，不是服务，你得自己写会话保持、代理切换和资源清理。它的优势是灵活，你能完全控制浏览器的每个细节，而且没有额外的网络层。Steel 的优势在于是开箱即用的服务，Docker 拉起来就有 HTTP API，适合快速集成。另一个更接近的替代是 Browserless，它也是把浏览器封装成服务，提供类似会话管理和代理功能。Browserless 更成熟一些，但它是商业产品，开源部分有限。Steel 走的是 Apache-2.0 全开源路线，你可以自己改代码。选 Playwright 意味着你接受自己写基础设施，选 Steel 意味着你接受它的抽象和 beta 状态。
编辑结论
Steel Browser 适合两类人：一是想快速给 AI Agent 加上浏览器能力、又不愿自己维护 Chrome 进程和会话状态的开发者；二是需要代理轮换和反检测功能、但不想从零搭建的团队。不适合对浏览器指纹有极致要求、或需要在无 Docker 环境里做轻量嵌入的人，因为它的交付形态就是 Docker 镜像加 Node 服务，本地跑还得依赖系统 Chrome。采用前先验证三件事：你的目标站点能否接受 CDP 驱动的 Chrome 流量，代理链的稳定性是否达标，以及 beta 版本在会话清理和资源回收上有没有已知问题。Steel 的定位是托管式浏览器基础设施，而不是一个可嵌入的库，选型前先确认你愿意接受这种服务化边界。
社区笔记