刊 DailyNews 科技 / AI 每日文摘2026 年 10 月 30 日

每日文摘

深挖 · lightpanda：34.8k star 的 Zig 无渲染浏览器，能不能替掉你的 Chrome CDP

题图

如果你也在用 Playwright connectOverCDP 连一台常驻 Chrome 跑采集，大概率刷到过 lightpanda——GitHub 上 34.8k star 的「AI agent 专用 headless 浏览器」，宣称比 headless Chrome 快 9 倍、省 16 倍内存。它到底是个什么物种、能不能直接替掉你手里那条 CDP 生产线、和最近流行的 agent 专用浏览器（比如 ego-lite）是不是一回事？这篇把源码、官方基准和社区实测翻了一遍，给个落地视角的答案。

是什么

lightpanda 的自我定位是「第一台为机器而不是为人做的浏览器」：不是 Chromium fork，不是 WebKit patch，是一个用 Zig 从零写的新浏览器。创始团队此前做过日均百万页的抓取业务，痛点很具体——云上跑 headless Chrome 又贵又慢，所以他们把「轻」刻进了架构。

技术栈拆开看：JS 引擎是 V8 本体（和 Chrome 同引擎，语言层面兼容性不用怀疑），HTML 解析用 Servo 项目的 html5ever，HTTP 走 libcurl，而 DOM 和 Web API 全部由 Zig 按需实现——官方明说「实现 headless 自动化会用到的那部分，不是整个 Web 平台」。

最关键的设计选择是：它没有图形渲染引擎。不做 CSS 样式计算、不做布局、不做绘制，Page.captureScreenshot 返回的是占位图，元素的坐标是按 DOM 顺序模拟出来的近似值。这是它省内存的根源，也是一堆兼容性问题的根源。

项目现状：0.4.0（2026-08-31 发布），AGPL-3.0，双周发版节奏，Linux/macOS 有预编译二进制，无原生 Windows。

核心机制：CDP 直连的真实边界

对已有 CDP 生产线的人来说，最关心的问题是：我的 connectOverCDP 脚本能不能原样指向它？答案是「能连，但姿势要改，而且有三条硬限制」。

先说能连的部分。 lightpanda 的 serve 模式就是一个标准 CDP 服务器（默认 127.0.0.1:9222），实现了 20 个标准 CDP 域加 2 个私有域，Page 19 个方法、Network 25 个、Runtime 28 个，核心域覆盖不差。官方文档明确演示 chromium.connectOverCDP('ws://127.0.0.1:9222')，JS 和 Python 都有官方维护的示例——只要把连接串从 Chrome 换成 lightpanda，大部分 Puppeteer/Playwright 脚本的骨架可以保留。

限制一：一个进程同时只能开一个页面。 这是源码级的硬约束——CDP.zig 里 createBrowserContext 在已有 context 时直接报 AlreadyExists，createTarget 在已有页面时直接报 TargetAlreadyLoaded。也就是说「常驻浏览器 + newPage() 连续开 tab」的模式在 lightpanda 上不存在，每次都要「开一页 → 采完 → 关掉 → 再开下一页」串行进行。对单页采集无所谓，对多 tab 并发的流水线是架构性不匹配。

限制二：官方连接姿势是显式建 context。 Playwright connectOverCDP 有条 auto-attach 捷径（连上直接拿 page，不用手动建 context），社区有 PR 想支持这条路径，被维护者明确拒绝关闭了。而且 Node 版 Playwright 用 http://127.0.0.1:9222 发现式连接（先 GET /json/version 那种）目前还有 open 的 crash bug，/json 发现端点本身也还在补的 PR 里——现阶段请老老实实用 ws:// 直连加显式 newContext().newPage()。

限制三：UA 恒为 Lightpanda/1.0，且不能伪装。 默认 User-Agent 就是 Lightpanda/1.0，Sec-Ch-Ua 的 brand 也是 Lightpanda；更绝的是 CLI 的 --user_agent 参数有校验器，禁止 UA 里包含 “Mozilla”——想借 lightpanda 过 Chrome 指纹检测这条路被官方在代码层封死了。这是产品哲学：它走「诚实 bot」路线（内置 --obey-robots、支持 WebBotAuth bot 身份认证），不做指纹对抗。创始人被问到 bot detection 时的原话是「No we haven’t worked on bot detection」。

登录态是另一处硬伤。 它没有 Chrome 式的 user-data-dir/profile 机制——官方把「跨任务持久 state/cookies/sessions」当作传统浏览器的缺陷来宣传，会话隔离才是卖点。现有能力是 --cookie（启动时从 JSON 加载，兼容 Playwright context.cookies() 导出格式）和 --cookie-jar（退出时保存），但源码里明确写着：--cookie-jar 只在 fetch 和 mcp 模式下可用，serve 常驻模式不能落盘。localStorage 只做到 session 内跨导航持久，不跨进程重启。也没有任何导入 Chrome profile 的工具。对「常驻一台浏览器、数周保活登录态」的用法，这是断崖式的降级。

顺带一提它的 agent 侧接口：内置标准 MCP server（lightpanda mcp，stdio 或 HTTP），还有内置 LLM agent 模式。开放协议是它和 ego-lite 这类产品的根本分野——后文细说。

怎么跑起来

安装成本确实低。macOS（含 arm64）可以走 Homebrew 第三方 tap 或官方一键脚本；Docker 有官方镜像（75.8MB，amd64 和 arm64 都有），NAS 或服务器上 docker run -d -p 127.0.0.1:9222:9222 lightpanda/browser:nightly 就是一个常驻 CDP 端点。注意三点：headless-only，没有任何 GUI 模式；遥测默认开启（LIGHTPANDA_DISABLE_TELEMETRY 环境变量关闭）；Linux 二进制是 glibc 链接，Alpine 上跑不了。

稳定性方面要打个预防针：2026 年 4 月到 8 月发了 10 个版本，几乎每一版 release notes 都在修 UAF/double-free/挂死——修得勤快，但也说明底层还在密集排雷。更要注意的是连续的破坏性变更：0.3.0 把存储默认改成了非持久的 Blackhole，0.4.0 让 iframe 和 workers 默认不加载。结论是：想用请钉住版本号，别追 nightly。

数据说话：基准的真相

官方基准很漂亮：爬 933 个真实网页，25 并发下 lightpanda 峰值内存 123MB vs headless Chrome 2GB（约 16 倍），100 页执行时间 5s vs 46s（约 9 倍）。但读基准要先读方法学，这份基准的原文自己承认了几件事：爬的是 lightpanda 自家的演示站；对比架构不对等（Chrome 是单实例开 N 个 tab，lightpanda 是 fork N 个进程）；没有和 chrome-headless-shell 或 Playwright 自带的 WebKit driver 对比——HN 上有用户两次指出 WebKit driver 本就比 Chrome 轻得多，官方拿 Chrome 做对比「要么是不知道，要么是有点误导」。ex-Puppeteer 的工程师 JoelEinbinder 直接评价内存基准「deceptive」。

目前唯一做了独立复测的横评（Webfuse，15 个真实站点 vs Chrome 147）给出的数字更接近现实：冷启动 RSS 17MB vs 931MB——这个差距是真的；但峰值内存只有约 4 倍差距（324MB vs 1,365MB），远不是 16 倍；15 个站点里有 1 个（Stripe docs，重 SPA）因为缺 indexedDB 等 API 渲染失败。导航速度中位数 308ms vs 461ms，快但没有量级差。

反面证据还有一批实打实的 open issue：IntersectionObserver 目前「假设所有元素都可见」（重虚拟滚动的 SPA 行为会异常）；走 HTTPS 代理的导航会出现加载后回退 about:blank 的 bug；SAML 多步登录表单提交后页面不更新。反爬方向的定性判断来自一位日抓千万 URL 的从业者：算力从来不是瓶颈，需要浏览器的时候恰恰是为了过反爬，那种场景必须真 Chrome。

三方对比：该不该换

把三方放在 web 自动化的分层里看，事情就清楚了。官方博客自己画过一张六层栈：引擎层（Chromium 垄断）→ CDP 协议层 → 库层（Puppeteer/Playwright）→ AI 框架层（Stagehand/Browser Use 等）→ 云浏览器层（Browserbase 等）→ 数据抽取层。lightpanda 站在引擎层（兼营云层），ego-lite 站在框架层之上的交互层，Chrome 是引擎层的现任霸主。社区横评的共识也是「它不与 Browser-Use/Stagehand 竞争，它是它们底下的 runtime」——Stagehand 和 Vercel 的 agent-browser 都支持把 CDP URL 指向 lightpanda 换掉 Chromium 后端。

落到具体场景逐条核对：

Chrome CDP 常驻（现状 A）ego-lite（现状 B）lightpanda（候选）
形态真浏览器，常驻进程 + profileGUI 浏览器 + 私有 harnessheadless 引擎 + 开放 CDP/MCP 端口
外部 Playwright 直连✓✗（端口封闭）✓（ws:// 直连，http:// 形式还有 bug）
登录态profile 全量持久继承真人登录态serve 模式不能存 cookie，localStorage 不跨重启
多 tab✓Space 内多 tab✗ 单进程单页面
反爬兼容真 Chrome 指纹真 Chromium 内核UA 恒为 Lightpanda，无指纹对抗
资源重（百 MB 到 GB 级）中轻（冷启 17MB，峰值约 Chrome 1/4）
开源闭源内核闭源AGPL-3.0

对 DailyNews 这样的采集生产线（现状 A）：不换。 三个理由都有源码或 issue 级证据：头条采集需要登录态常驻保活，而 lightpanda 的 serve 模式连 cookie 落盘都不支持；头条是重 SPA，IntersectionObserver 的「全部可见」假设和 Web API 缺口是真实风险；UA 不能伪装成 Chrome，对有指纹检测的中文站点是硬伤。资源占用上现有常驻 Chrome 确实重，但个人单机一条流水线，这个成本可接受，换来的兼容性溢价更高。

对 ego-lite 的交互式场景（现状 B）：不构成二选一。 ego-lite 的核心卖点是 agent 复用真人的登录态和 GUI 会话，lightpanda 没有 GUI、不能人工登录、会话隔离是哲学——它们解决的不是同一层的问题。

值得跟的信号：三条落地之前，lightpanda 对个人生产线只是观察对象——①多 browser context/多 target 支持（解除单页面限制）；②serve 模式的 cookie 持久化；③Playwright Test 级兼容（官方 issue #3076 已在追踪）。它真正的甜区是无登录态的批量文本抓取和给 agent 框架当轻量引擎，等 1.0 临近时再看一眼，届时它可能真的是那台「为机器做的浏览器」。

参考阅读