用 Zig 从零造一个浏览器：Lightpanda 如何把 2GB 内存压到 123MB

研究对象：lightpanda-io/browser
抓取日期：2026-10-30 ｜ 当日 stars：559
许可证：开源 ｜ 语言：Zig

场景开篇

凌晨两点，你的爬虫集群又挂了。

不是代码有 bug，是第 47 个 Chrome 实例把内存吃光了。每个 headless Chrome 吃 400MB，你开 100 个并发就是 40GB——一台 m5.large 只有 8GB。你加机器、加 swap、加 Kubernetes 调度，最后发现赚的钱全花在 AWS 账单上。

更荒唐的是，你根本不需要 Chrome 的全部功能。你不需要 WebGL 渲染、不需要 GPU 加速、不需要扩展商店、不需要用户界面。你只需要：加载页面、执行 JavaScript、读 DOM、点按钮、填表单。但 Chrome 是一个桌面浏览器被强行拉去服务器上当工具用——它不是为这个场景设计的。

2026 年 10 月，一个用 Zig 写的新浏览器出现在 GitHub Trending 上。它不是 Chromium 的 fork，不是 WebKit 的补丁，是从零开始写的。100 个页面峰值内存 123MB，Chrome 是 2GB。100 个页面执行时间 5 秒，Chrome 是 46 秒。

它叫 Lightpanda。

不是又一个 Chrome 替代品

先说清楚它不是什么。

它不是 Brave、Arc、Ladybird 那种给人类用的浏览器。它没有地址栏、没有标签页、没有收藏夹。它是一个headless browser——没有图形界面的浏览器，专门给程序和 AI agent 用。

它也不是 Puppeteer 或 Playwright。那两个是控制浏览器的客户端库，它们背后还是需要一个真的 Chrome。Lightpanda 自己就是浏览器本身，Puppeteer/Playwright 只是它的一个前端。

它更不是 Chromium 的精简版。Chromium 是一个有 3000 万行代码的巨型项目，fork 它然后减肥的尝试（比如 ungoogled-chromium）本质上还是在维护一个巨型代码库。Lightpanda 的代码库小到一个人能读完。

它的定位很精确：为 AI agent 和自动化场景从零设计的浏览器。不是改造桌面浏览器，是重新思考"浏览器"在这个场景下应该长什么样。

16 倍是怎么来的

数据来自一个公开 benchmark：在 AWS EC2 m5.large 上请求 933 个真实网页。

16 倍的内存差距不是靠某个魔法优化，而是架构选择的结果。

Chrome 的架构是多进程的：每个标签页一个渲染进程，加上浏览器进程、GPU 进程、网络进程、插件进程。这个设计是为了安全隔离和稳定性——一个标签页崩溃不会拖垮整个浏览器。但在 headless 自动化场景下，你根本不需要这种隔离，你只有一个程序在控制一切。每个进程的固定开销（V8 堆、渲染管线、IPC 通道）在 100 个实例下就是灾难。

Lightpanda 是单进程的。没有进程间通信开销，没有重复的 V8 堆，没有渲染管线。它用 v8 执行 JavaScript（这是必须的，现代网站离不开 JS），但不做任何图形渲染。

用 Zig 写是另一个关键。Zig 是一门没有垃圾回收的系统级语言，内存分配完全由程序员控制。这意味着 Lightpanda 可以精确控制每一块内存的生命周期——页面加载完、数据提取完、内存就释放。没有 GC 停顿，没有内存碎片，没有意外的内存泄漏。

这让我想起字节跳动的 LLM-BlockFE：不靠更快的线上 LLM，而是设计一个不需要线上 LLM 的架构。Lightpanda 也是同样的思路：不靠更高效的 Chrome 调度，而是设计一个不需要 Chrome 多进程架构的浏览器。换层面解决问题。

PandaScript：LLM 炼丹，脚本执行

这是 Lightpanda 最有意思的设计。

它有一个 agent 模式，你可以用自然语言描述任务：

./lightpanda agent --task "top story on news.ycombinator.com?"

Agent 会调用 LLM（支持 Anthropic、OpenAI、Gemini、Vertex、Mistral、Ollama 本地模型等），理解任务，控制浏览器导航、点击、提取数据。

但关键来了：agent 的输出不是一个答案，而是一个 PandaScript。

PandaScript 是 vanilla JavaScript 加上一组浏览器原语（Page、goto、extract 等）。你可以用 /save 把当前 session 的操作导出成脚本，然后用 lightpanda run script.js 重放。

重放时不需要 LLM。

这个设计的意义在于：LLM 是"写程序的人"，不是"跑程序的人"。你用 LLM 原型化一个爬虫逻辑——"去这个网站、点这个按钮、等这个元素出现、提取这些字段"——然后导出成确定性的 JavaScript 脚本，放到生产环境跑。没有 LLM 调用成本，没有 token 消耗，没有不确定性。

这正是"离线炼丹线上执行"的模式。LLM 在开发阶段生成特征代码，线上推理时零 LLM 调用。字节跳动用这个模式把坏账率从 8.0% 降到 7.7%，Lightpanda 用这个模式让爬虫从"每次都要调 GPT"变成"调一次 GPT，之后免费重放"。

生产环境不需要智能，需要确定性。LLM 的价值在原型化阶段，不在执行阶段。

MCP 服务器：每个 Agent 一个浏览会话

Lightpanda 内置了 MCP（Model Context Protocol）服务器。这意味着任何支持 MCP 的 AI agent 都可以把 Lightpanda 当成一个工具使用。

但更有意思的是它的会话隔离设计。

启动 HTTP 模式的 MCP 服务器：

lightpanda mcp --port 9223

每个客户端连接时，如果不带 Mcp-Session-Id，服务器会分配一个新的浏览会话——独立的页面、独立的 cookie、独立的存储。两个 agent 不会互相踩对方的页面。

如果多个 agent 需要协作同一个页面呢？它们可以共享同一个 Mcp-Session-Id，在同一个浏览上下文里工作。

这个设计解决了一个真实问题：当你有多个 AI agent 同时在跑——一个在填表单、一个在读数据、一个在截图——如果它们共享一个 Chrome 实例，就会互相干扰。一个 agent 切换了标签页，另一个 agent 的脚本就崩了。

Lightpanda 的方案是：每个 agent 一个工作区。不是更大的上下文窗口，而是更持久、更隔离的工作环境。从 chat 到 workspace 的范式转变。

为什么不用 Playwright + Chrome

有人会问：Playwright 已经很成熟了，Chrome headless 也很好用，为什么要换？

答案取决于你的场景。

如果你是做 CI/CD 里的端到端测试，需要 100% 还原用户浏览器行为，Chrome 是对的——你需要完整的渲染、完整的 CSS、完整的 Web API 兼容性。

但如果你是做大规模网页抓取或 AI agent 自动化，需求完全不同：

• 你不需要渲染：你要的是 DOM 结构和数据，不是像素
• 你需要并发：同时处理几百个页面，Chrome 的多进程架构是瓶颈
• 你需要确定性：同一个脚本跑两次结果要一样，Chrome 的各种后台任务和随机调度做不到
• 你需要低成本：100 个 Chrome 实例的 AWS 账单会让你重新考虑商业模式

Lightpanda 的 Web Platform Tests 结果是公开的，它实现了现代网页自动化需要的核心 API：DOM 操作、XHR/Fetch、Cookies、CDP 协议、点击/输入表单、网络拦截、自定义 HTTP 头、代理支持。它甚至内置了 adblocker 和 robots.txt 遵守。

它不追求 100% 兼容 Chrome——它追求的是覆盖自动化场景需要的 95% 功能，但用 1/16 的资源。

技术栈选择

Lightpanda 的技术栈值得注意：

• Zig 0.17.0：核心浏览器引擎，显式内存控制
• v8：JavaScript 执行（从 Chrome 借来的只有这一部分）
• Libcurl：HTTP 加载
• html5ever：HTML 解析（来自 Servo 项目）

这个组合很精妙。v8 是 Chrome 的 JavaScript 引擎，意味着 JS 执行行为和 Chrome 一致——你的 Playwright 脚本不需要改。html5ever 来自 Servo（Mozilla 的实验性浏览器引擎），用 Rust 写的，意味着 HTML 解析的容错性和标准兼容性都很好。

但浏览器本身是 Zig 写的，不是 Rust。为什么？

Zig 和 Rust 都是系统级语言，但哲学不同。Rust 强调编译时安全（借用检查器），Zig 强调运行时简单性（没有隐藏的控制流、没有隐藏的内存分配）。对于一个需要精确控制内存生命周期的浏览器引擎来说，Zig 的手动内存管理反而更直接——你看到每一块内存在哪里分配、在哪里释放，没有 Rust 借用检查器的心理负担。

这不是说 Zig 比 Rust 好，而是说不同场景需要不同工具。Lightpanda 的作者选择了最适合"从零写一个浏览器"这个任务的语言。

生态兼容性

Lightpanda 支持两种主流浏览器自动化协议：

• CDP（Chrome DevTools Protocol）：Puppeteer、Playwright 用的协议
• WebDriver Bidi：新一代 W3C 标准协议

这意味着你现有的 Puppeteer/Playwright 脚本几乎不需要改，只需要把 browserWSEndpoint 指向 Lightpanda 的 CDP 服务器：

const browser = await puppeteer.connect({
  browserWSEndpoint: "ws://127.0.0.1:9222",
});

这是很聪明的兼容策略。不要求用户重写代码，只要求换一个后端。降低迁移成本是开源项目能否被采用的关键。

一个值得关注的趋势

Lightpanda 不是孤立现象。2026 年下半年，"为 AI agent 重新设计基础设施"成为一个明显趋势：

• OpenBot 给每个 AI agent 一台电脑（浏览器+文件+工具）
• ego-lite 把浏览器自动化从遥控机器人变成共享工作台
• Lightpanda 从零写一个为 AI 设计的浏览器

它们的共同思路是：AI agent 的需求和人类用户不一样，不应该硬塞进为人类设计的工具里。Chrome 是为人类设计的浏览器，多进程架构是为了安全隔离人类浏览的不同网站。但 AI agent 不需要这种隔离——它需要的是并发、确定性、低资源消耗。

这和"离线炼丹线上执行"是同一个哲学的不同应用：不要让生产环境承受开发环境的复杂性。LLM 在原型化阶段是必要的，但在执行阶段是多余的。Chrome 在人类浏览场景下是必要的，但在 agent 自动化场景下是多余的。

工具应该匹配场景，而不是让场景迁就工具。

项目地址：https://github.com/lightpanda-io/browser
官网：https://lightpanda.io
Discord：https://discord.gg/K63XeymfB5