Chrome 能爬网页,但规模化之后就是一场基础设施灾难。
2026 年,Lightpanda 用一个激进思路解决这个问题:不从 Chromium fork,从零用 Zig 写一个只给机器用的浏览器。GitHub 36.1K star,AGPL-3.0,官方宣称内存比 Chrome 少 9 倍、速度快 11 倍。
不是给人类看网页的浏览器,是给 AI agent 和爬虫用的浏览器。
TL;DR
- Lightpanda 是用 Zig 从零写的开源无头浏览器,非 Chromium fork,GitHub 36.1K star
- 官方数据:内存占用比 Chrome headless 少 9 倍,执行速度快 11 倍
- 支持 CDP 端点,现有 Puppeteer/Playwright 脚本改一行就能切换引擎
- 新增原生 MCP server + agent 模式,一次 LLM 调用驱动浏览器,输出 PandaScript 可免 LLM 重放
- 与 Vercel agent-browser 集成,agent 用几百 token 操作页面而非解析原始 HTML
为什么不用 Chrome?
Chrome headless 本质是"关掉显示器的完整桌面浏览器"。渲染引擎、标签页管理、扩展、UI 代码全都在,你为用不到的功能付内存和 CPU 的代价。
Lightpanda 只构建自动化需要的东西:
| 组件 | Chrome headless | Lightpanda |
|---|---|---|
| DOM 树 | ✅ | ✅ |
| JavaScript 执行 | ✅ | ✅(V8) |
| 网络请求 | ✅ | ✅ |
| 渲染引擎 | ✅ | ❌ |
| UI 代码 | ✅ | ❌ |
| 标签页管理 | ✅ | ❌ |
| 扩展系统 | ✅ | ❌ |
结果:内存和 CPU 大幅下降。作者团队前身公司每天爬数百万页面,被 Chrome 的规模化成本折磨多年,最后决定从头重写。
架构拆解:Zig + V8 + CDP
Lightpanda 的技术栈:
| 组件 | 作用 |
|---|---|
| Zig | 浏览器引擎本体(解析、DOM、网络) |
| V8 | JavaScript 执行 |
| CDP | Chrome DevTools Protocol 端点 |
| MCP server | 原生 Model Context Protocol 服务 |
| PandaScript | agent 输出的可复用 JS 脚本 |
关键设计:暴露 CDP 端点意味着任何能连 CDP 的工具都能用。Puppeteer、Playwright 改一行就能切换:
# 从 Chrome 切换到 Lightpanda,只改连接方式
# Chrome:
# const browser = await puppeteer.launch();
# Lightpanda:
const browser = await puppeteer.connect({ browserWSEndpoint: 'ws://127.0.0.1:9222' });
三层自动化:CDP / MCP / Agent 模式
Lightpanda 提供三个自动化层级,适配不同场景:
| 层级 | 方式 | 适合场景 |
|---|---|---|
| CDP | Playwright/Puppeteer 直连 | 已有测试脚本,只想换引擎 |
| 原生 MCP | 外部 agent 通过 MCP 操作 | agent 导航、点击、填表、提取 |
| Agent 模式 | 自然语言驱动,输出 PandaScript | 发现流程 → 保存 → 免 LLM 重放 |
Agent 模式是亮点:用一次 LLM 调用让 agent 探索页面流程,把探索结果保存为 PandaScript(原生 JS),之后重放不再需要 LLM。
# agent 探索后保存脚本
/save
# 之后免 LLM 重放
lightpanda run saved-flow.js
成本意义:探索阶段消耗 token,重放阶段零 token。对于高频重复的爬取任务,成本断崖式下降。
与 Vercel agent-browser 集成
Lightpanda 官方支持与 Vercel 的 agent-browser(一个为 AI agent 设计的浏览器自动化 CLI)配合使用。
agent-browser 通过 CDP 驱动浏览器,把页面返回为紧凑的 accessibility-tree 快照,agent 用几百 token 就能操作页面,而不是解析原始 HTML。
# 用 Lightpanda 作为 agent-browser 的引擎
npx agent-browser --engine lightpanda navigate https://example.com
npx agent-browser --engine lightpanda click "Submit"
npx agent-browser --engine lightpanda extract
对比传统方案:传统 Puppeteer 抓 HTML 返回几万 token,agent-browser 返回 accessibility 快照只需几百 token。对 token 成本敏感的 agent 工作流,这是数量级优化。
实测:Lightpanda vs Chrome headless
以下数据来自社区 benchmark(非官方),仅供参考:
| 指标 | Chrome headless | Lightpanda | 差异 |
|---|---|---|---|
| 单实例内存 | ~350 MB | ~40 MB | 约 9x |
| 页面加载(简单页) | ~1.2s | ~0.11s | 约 11x |
| 页面加载(复杂 SPA) | ~2.5s | ~0.8s | 约 3x |
| 启动时间 | ~800ms | ~100ms | 约 8x |
| CPU 占用(空闲) | 较高 | 极低 | 显著 |
注意:复杂 SPA 场景下优势缩小。Lightpanda 的 DOM/JS 引擎是子集实现,部分现代 Web API 支持仍在完善。对重度前端框架的页面,Chrome 仍是保底选择。
与 Puppeteer/Playwright 的选型对比
| 维度 | Chrome + Puppeteer | Lightpanda + Puppeteer | Lightpanda + MCP |
|---|---|---|---|
| 兼容性 | 最好 | 高(CDP 兼容) | 中(agent 场景) |
| 内存 | 高 | 低 9x | 低 9x |
| 速度 | 中 | 快 3-11x | 快 |
| 现有脚本迁移 | — | 改一行 | 需重写 |
| Agent 友好度 | 低 | 中 | 高 |
| 复杂 SPA 支持 | 最好 | 中 | 中 |
建议:已有 Puppeteer 脚本、想省内存 → 切 Lightpanda;新 agent 工作流 → 直接用 MCP;重度复杂前端 → 保留 Chrome。
争议:Star 数增长异常?
Lightpanda 的 GitHub star 增长引发社区讨论。Reddit r/selfhosted 上有用户质疑其 star 增长曲线异常(创始人账号创建时间、fork 比例等)。
客观看法:技术实力真实(Zig 从零写浏览器、CDP 兼容、MCP 集成都是硬核工程),但 star 增长是否完全自然有待观察。选型时建议以技术验证为准,而非 star 数。
成本账本
Lightpanda 开源版免费(AGPL-3.0),但自托管仍有基础设施成本。官方 Cloud 定价(2026-09 核实):
| 方案 | 价格 | 包含 |
|---|---|---|
| 开源自托管 | $0(服务器成本) | 无限制 |
| Cloud 免费层 | $0 | 10 小时/月 |
| Cloud Builder | $19/月 | 300 小时 + 30 并发 |
| 额外小时 | $0.08/小时 | — |
对比:按 300 小时/月算,Cloud Builder $19 相当于自托管 2C4G VPS($10-20/月)的同等价位,但省去运维。
常见问题
Q1: Lightpanda 能替代 Chrome 吗?
A: 不能完全替代。它支持大多数现代网站的 DOM 和 JS,但部分复杂 Web API 仍在完善。重度前端框架页面建议保留 Chrome 保底。
Q2: 现有 Puppeteer 脚本能直接用吗?
A: 大部分能。把 puppeteer.launch() 换成 puppeteer.connect({browserWSEndpoint}) 即可。个别依赖 Chrome 特有 API 的脚本可能需调整。
Q3: 需要 GPU 吗?
A: 不需要。Lightpanda 无渲染引擎,纯 CPU 运行,内存占用极低。
Q4: 开源协议是 AGPL-3.0,商用有什么限制?
A: AGPL 要求修改后的代码也开源。如果只是调用不改代码,商用无限制。深度定制需评估合规。
Q5: 与 Playwright 兼容性如何?
A: 支持 CDP,Playwright 可通过 CDP 连接。但 Playwright 的部分高级 API 可能未完全覆盖,建议实测。
Q6: MCP server 怎么配?
A: Lightpanda 内置 MCP server,agent 直接连接即可。也可用 Vercel agent-browser 作为中间层。
Q7: 适合哪些场景?
A: 大规模爬取、AI agent 网页操作、E2E 测试、高频重复流程。不适合:需要完整渲染、重度前端框架、需要扩展系统的场景。