用 Zig 从零造一个浏览器：Lightpanda 如何把 2GB 内存压到 123MB
不是代码有 bug，是第 47 个 Chrome 实例把内存吃光了。每个 headless Chrome 吃 400MB，你开 100 个并发就是 40GB——一台 m5.large 只有 8GB。你加机器、加 swap、加 Kubernetes 调度，最后发现赚的钱全花在 AWS 账单上。
目录
用 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 个真实网页。
| 指标 | Lightpanda | Headless Chrome | 差距 |
|---|---|---|---|
| 峰值内存（100 页） | 123MB | 2GB | ~16 倍 |
| 执行时间（100 页） | 5s | 46s | ~9 倍 |
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 账单会让你重新考虑商业模式
它不追求 100% 兼容 Chrome——它追求的是覆盖自动化场景需要的 95% 功能，但用 1/16 的资源。
技术栈选择
Lightpanda 的技术栈值得注意：
- Zig 0.17.0：核心浏览器引擎，显式内存控制
- v8：JavaScript 执行（从 Chrome 借来的只有这一部分）
- Libcurl：HTTP 加载
- html5ever：HTML 解析（来自 Servo 项目）
但浏览器本身是 Zig 写的，不是 Rust。为什么？
Zig 和 Rust 都是系统级语言，但哲学不同。Rust 强调编译时安全（借用检查器），Zig 强调运行时简单性（没有隐藏的控制流、没有隐藏的内存分配）。对于一个需要精确控制内存生命周期的浏览器引擎来说，Zig 的手动内存管理反而更直接——你看到每一块内存在哪里分配、在哪里释放，没有 Rust 借用检查器的心理负担。
这不是说 Zig 比 Rust 好，而是说不同场景需要不同工具。Lightpanda 的作者选择了最适合"从零写一个浏览器"这个任务的语言。
生态兼容性
Lightpanda 支持两种主流浏览器自动化协议：
- CDP（Chrome DevTools Protocol）：Puppeteer、Playwright 用的协议
- WebDriver Bidi：新一代 W3C 标准协议
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 设计的浏览器
这和"离线炼丹线上执行"是同一个哲学的不同应用：不要让生产环境承受开发环境的复杂性。LLM 在原型化阶段是必要的，但在执行阶段是多余的。Chrome 在人类浏览场景下是必要的，但在 agent 自动化场景下是多余的。
工具应该匹配场景，而不是让场景迁就工具。
*项目地址：https://github.com/lightpanda-io/browser* *官网：https://lightpanda.io* *Discord：https://discord.gg/K63XeymfB5*