Kernel：给 AI 浏览器自动化装上"沙箱护盾"

场景切入

凌晨两点，你正在调试一个网页数据采集脚本。脚本在本地运行正常，但一部署到服务器就因为反爬机制被封 IP。换成无头浏览器后，Chrome 进程又在 Docker 里不断崩溃，内存占用居高不下。更棘手的是——你的 AI Agent 需要实时"看到"浏览器正在做什么，但现有的 Selenium Grid 延迟太高，调试全靠猜。

这正是 Kernel 要解决的问题。

项目背景

Kernel（kernel/kernel-images，Apache-2.0，938★）是一个开源的浏览器即服务（Browsers-as-a-Service）平台，专门为自动化工具和 AI Web Agent 提供隔离、可控的 Chrome 浏览器环境。项目由 @juecd__ 和 @rfgarcia 两位独立开发者维护，官方托管平台为 kernel.sh。

项目诞生于 2024 年，核心驱动力是当时市面上的浏览器自动化方案存在几个痛点：

• 隔离性差：本地浏览器与宿主机共享资源，进程冲突频繁
• 无头模式调试困难：没有可视界面，Agent 出错时无法直观排查
• WebRTC 直播缺失：AI Agent 执行时无法实时监控"浏览器在看什么"
• Unikernel 支持空白：容器启动慢、冷启动耗时，无法满足超低延迟场景

技术架构

Kernel 采用 Docker + Unikraft Unikernel 双轨部署架构，整体分为三层：

第一层：Go 后端 API（server/）

项目核心用 Go 1.25 编写，后端通过 Go-Chi 路由框架提供 REST + WebSocket 接口，API 规范用 OpenAPI 描述（openapi.yaml）。关键依赖包括：

依赖	用途
docker/docker v28	容器生命周期管理
coder/websocket v1.8	WebSocket 实时通信
m1k1o/neko/server	WebRTC 视频流媒体服务
glebarez/sqlite	本地会话状态持久化
s2-streamstore/s2-sdk	录屏文件云存储

API 端点通过 cmd/api 编译为独立二进制 kernel-images-api，chromium-launcher 则负责启动和管理 Chrome 进程。

第二层：Node.js 客户端（client/）

WebRTC 远程 GUI 部分使用 Node.js 22 构建，Vite 打包后嵌入 Docker 镜像，提供 noVNC 和 WebRTC 两种远程访问模式。Dockerfile 中用 node:22-bullseye-slim 多阶段构建，npm install + npm run build 流程完整。

第三层：X.org 桌面环境

容器内运行完整的 X11 桌面栈（xorg-deps 阶段安装 mesa、 Mutter 等组件），Supervisor 管理多个进程：Chrome 主进程、xrdp/VNC、WebRTC 流媒体。

容器化实现

项目提供了两套构建脚本：

Docker 路线（推荐）：

cd images/chromium-headful
IMAGE=kernel-docker ./build-docker.sh
IMAGE=kernel-docker ENABLE_WEBRTC=true ./run-docker.sh

多阶段 Dockerfile 构建出 server + client + xorg-deps 三个阶段，最终镜像基于 ubuntu:22.04，占用约 5GB，支持 amd64/arm64 双架构（BuildKit --platform 参数）。

Unikraft Unikernel 路线：

curl -sSfL https://get.kraftkit.sh | sh
export UKC_METRO=<region>
export UKC_TOKEN=<your-token>
IMAGE=YOUR_USERNAME/chromium-headless:latest images/chromium-headless/build-unikernel.sh

unikernel 路线提供两项 Docker 无法实现的能力：空闲时自动进入"睡眠模式"（零资源占用）和 20ms 内冷启动。代价是需要至少 8GB 内存，部署到 Unikraft Cloud 后 URL 公开可访问（用于非敏感场景）。

CDP 协议集成

Chrome DevTools Protocol 连接方式：

// 1. 获取 WebSocket 端点
const { webSocketDebuggerUrl } = await fetch("http://localhost:9222/json/version").then(r => r.json());

// 2. Puppeteer 连接
const browser = await puppeteer.connect({ browserWSEndpoint: webSocketDebuggerUrl });

// 3. Playwright 连接
const browser = await chromium.connectOverCDP(webSocketDebuggerUrl);

端口 9222 通过 ncat 暴露，WebSocket 路径随每次启动变化，支持断开重连（browser.close() 仅关闭 WebSocket，不关闭实际 Chrome 进程）。

Web Agent 集成

作为 AI Agent 的"眼睛"，Kernel 可与主流框架无缝对接：

• Browser Use：AI Agent 驱动浏览器的主流框架
• Playwright / Puppeteer：标准的浏览器自动化工具
• 自定义 CDP 客户端：任何基于 Chrome DevTools Protocol 的 SDK

Agent 可以在远程浏览器中执行点击、输入、截图等操作，同时通过 WebRTC 实时视频流"看到"浏览器画面，调试体验接近本地运行。

录制回放

内置录制服务器（需启用 WITH_KERNEL_IMAGES_API=true），支持录屏采集并输出为 H.264/MP4 文件：

curl http://localhost:10001/recording/start -d {}
# 执行 Agent 任务...
curl http://localhost:10001/recording/stop -d {}
curl http://localhost:10001/recording/download --output session.mp4

注意：QuickTime 播放器对 H.264 兼容有问题，建议使用 VLC 等播放器。

部署评估

维度	结论
部署难度	中等，需 Docker 基础
预估时间	15 分钟（构建 + 首次拉取镜像）
硬件需求	8GB RAM，5GB 磁盘，无需 GPU
容器化	✅ 完整多阶段 Dockerfile
Web UI	✅ WebRTC + noVNC 双重访问
快速部署	✅ build-docker.sh + run-docker.sh 一键

局限与风险

1. 安全边界：Unikraft 部署后 URL 公开可访问，Chrome 的认证 Cookie 和本地文件均可被访问者操作，官方明确警告"仅用于非敏感交互"
2. WebRTC 音频：目前音频流功能损坏，无法使用
3. TURN 服务器：WebRTC 模式需要 TURN 服务器（UDP 直连暂不支持），增加了部署复杂度
4. 内存占用：全功能镜像需 8GB，资源受限环境不友好
5. 许可合规：Chrome 浏览器本身有 Google 服务条款限制，Unikraft 商业使用需注意

行业意义

Browser-as-a-Service 赛道正在快速增长。随着 Web Agent（用于网页浏览、信息提取、自动化填表的 AI Agent）成为 LLM 应用的重要方向，对可靠浏览器环境的需求急剧上升。Kernel 的差异化在于：

• Unikernel 路线：极快的冷启动和智能休眠，在成本敏感的多租户场景中有独特优势
• 完整视频流：不只是"能用"，还要"能看"，这对 Agent 调试至关重要
• 开箱即用的 CDP：降低 Playwright/Puppeteer 接入门槛，5 行代码即可连接

---

图1：Kernel 仓库 OpenGraph 封面图

图2：Kernel 项目组织头像