让编码 Agent 去读一个网页，最常见的翻车现场是这样的：curl 拉回来一份干干净净的 HTML，Agent 看了半天告诉你「这个页面没有商品数据」——因为内容是 JavaScript 跑完才渲染的，curl 只拿到了 2.8KB 的空壳。解决办法向来是上 Chrome headless 或者 Playwright 驱动的 Chromium，功能确实全，但代价是 16GB 的 MacBook 一开浏览器进程就少掉两百多兆内存，Agent 再挂几个并行任务，机器立刻开始换气。今天 GitHub Trending 日榜上有个更省的答案：Lightpanda，一个用 Zig 从头写的无头浏览器，不基于 Chromium 也不基于 WebKit，专为 AI Agent 抓网页设计，今天一天涨了 800 多 star，总量已经到 4 万。官方基准报告号称比 Chrome 轻 16 倍、快 9 倍——这种数字我向来不信，所以在自己的 M4 上真刀真枪比了一轮，顺便把它的 MCP 服务器也跑通了。这篇文章记录完整过程：怎么装、第一个坑在哪、和 Chrome 差多少、以及哪些场景我劝你别用它。
它解决什么问题：curl 拿到的是空壳
先看问题本身有多真实。Lightpanda 官方放了一个电商演示页 demo-browser.lightpanda.io/campfire-commerce，我用 curl 直接拉：
curl -s "https://demo-browser.lightpanda.io/campfire-commerce/" | wc -c
# 28322832 字节，里面商品详情区域全是 Loading... 占位——数据是页面加载后用 XHR 拉的。这类页面在真实世界一抓一大把：少数派、掘金、各种 React/Vue 单页应用，全是 curl 的死穴。之前写给 Agent 装联网能力和 DeepSeek 搜索 API 实测的时候，这个「搜索拿得到、正文拿不全」的缝隙就一直存在，浏览器是补上它的最后一块。
安装与第一个坑：默认等待拿不到 SPA 数据
我的环境：macOS 26.5.2，Apple M4 / 16GB，Homebrew。安装一行，装出来 93.2MB：
brew install lightpanda-io/browser/lightpanda
lightpanda version # 1.0.2然后立刻踩到本文最重要的坑。用最直觉的命令抓演示页：
lightpanda fetch --dump markdown "https://demo-browser.lightpanda.io/campfire-commerce/"导出的 markdown 里商品详情、Features、相关商品全是 Loading...——进程 2.44 秒就退出了，内存只占 31.9MB，但内容没等回来。翻官方文档才看明白：默认 --wait-until load，等的是 load 事件；而这个页面的商品数据是 load 之后才发的 XHR，load 一到就走人，数据自然没影。改成 networkidle（网络静默）就对了：
lightpanda fetch --dump markdown \
--wait-until networkidle --wait-ms 15000 \
"https://demo-browser.lightpanda.io/campfire-commerce/"这次 60L 背包的 $244.99 价格、完整 Product Details、四条 Features、相关商品全部出现，Loading 零残留。更稳的做法是用 --wait-selector 等某个具体元素出现，比掐网络静默更精确。一句话总结：拿 SPA 页面，默认参数必翻车，--wait-until networkidle 是起步配置。
和 Chrome headless 真刀真枪比
核心对比来了。同一页面、同一台机器，Chrome 用 --headless=new --dump-dom，Lightpanda 用上面的 networkidle 命令，/usr/bin/time -l 量峰值内存：
/usr/bin/time -l "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
--headless=new --disable-gpu --dump-dom --virtual-time-budget=15000 \
"https://demo-browser.lightpanda.io/campfire-commerce/" > /dev/null
/usr/bin/time -l lightpanda fetch --dump markdown \
--wait-until networkidle --wait-ms 15000 \
"https://demo-browser.lightpanda.io/campfire-commerce/" > /dev/null各跑两次（含冷启动）的实测结果：
同一页面（M4 / 16GB / macOS 26.5.2） Chrome headless Lightpanda 1.0.2
峰值内存（RSS） 254 MB 33 MB
耗时（第一次 / 第二次） 5.03s / 8.00s 2.44s / 1.73s
JS 渲染出的商品数据 ✅ 有 ✅ 有内存差 7.7 倍，耗时快 2 到 4.6 倍。没到官方宣称的 16 倍和 9 倍——我看了一眼他们的基准说明，那是在 AWS EC2 上批量跑 100 个页面的数据（123MB vs 2GB、5s vs 46s），批量场景下 Chrome 的多进程开销被放大，单页对比自然缩水。但对你我这种 16GB 用户来说，33MB 这个数字比倍数更重要：一个 Agent 并行开十个页面，Lightpanda 大概 300 多 MB，Chrome 得吃掉 2.5GB，差距直接决定任务挂不挂。
真实站点也验了一下。少数派首页是 Vue 单页应用，curl 只能拿到骨架；Lightpanda 抓回来 16.7KB 的 markdown，首页文章标题、链接、配图全部齐整，--strip-mode clutter 还能按阅读模式启发式去掉导航页脚等杂讯。注意内存不是恒定的：这个页面的 RSS 涨到 88.9MB——重页面照样吃资源，只是同样吃得更少。
MCP 服务器：32 个工具给 Agent 装上浏览器
比省内存更值得说的是它的定位：Lightpanda 不只是个快的 fetch 工具，它内置了 MCP 服务器（lightpanda mcp），也就是 Model Context Protocol——任何支持 MCP 的 Agent（Claude Code、opencode、Cursor 等）都能直接挂上它，获得完整的浏览器能力。我用一段极简的 JSON-RPC 脚本（无任何第三方依赖）实测了 stdio 模式：
# 运行环境：Python 3.13，macOS，lightpanda 1.0.2（brew 安装），无第三方依赖
import json, subprocess
p = subprocess.Popen(['lightpanda', 'mcp'],
stdin=subprocess.PIPE, stdout=subprocess.PIPE,
stderr=subprocess.DEVNULL, text=True)
def send(obj):
p.stdin.write(json.dumps(obj) + '\n'); p.stdin.flush()
def recv(want_id):
while True:
line = p.stdout.readline().strip()
if line and not line.startswith('$'): # 跳过日志行
m = json.loads(line)
if m.get('id') == want_id: return m
send({'jsonrpc':'2.0','id':1,'method':'initialize','params':{
'protocolVersion':'2024-11-05','capabilities':{},
'clientInfo':{'name':'test','version':'0.1'}}})
recv(1)
send({'jsonrpc':'2.0','method':'notifications/initialized'})
send({'jsonrpc':'2.0','id':2,'method':'tools/list'})
print([t['name'] for t in recv(2)['result']['tools']])输出是 32 个工具：goto、markdown、html、screenshot、links、evaluate、click、fill、scroll、hover、press、waitForSelector、structuredData、detectForms、consoleLogs，还有会话管理（session_new / session_list / session_close）和把操作存成可复用脚本的 save。接着做端到端验证：goto 打开少数派首页返回 Navigated. HTTP 200 OK.，再调 markdown 拿回 14,102 字符的正文，文章标题全在。这条链路意味着你不用再给 Agent 写「先用 requests 再解析」的胶水代码，接上 MCP，Agent 自己会决定什么时候点、什么时候填、什么时候等。它和之前写过的两个方案不冲突也不重复：搜索取数用 DeepSeek 的 Search/Fetch API，屏幕视觉引导用 bigarrow，而完整的页面交互层，Lightpanda 是目前我测过最轻的一块。
别急着全盘替换：四个不建议的场景
测下来它真不错，但有边界，这几类活我劝你别交给它：
- CSS 布局与视觉回归测试。Lightpanda 没有图形渲染引擎，
screenshot工具的说明里写明是「纯文本渲染」——它渲染文字层而不是真实像素（这一条我没有做像素级视觉核对，以官方文档口径为准）。测position: sticky塌没塌、渐变对不对，还是回 Chrome。 - JS 兼容性边缘场景。V8 是原装的，但 DOM/API 层是 Zig 自己实现的 html5ever 加自研栈，年轻。Vue 的少数派跑通了，重 React 应用我没逐一验证——上线前先拿你的目标页面跑一遍
--dump html对比，别直接信。 - 反爬严格的站点。无头浏览器特征识别是场猫鼠游戏，Lightpanda 的指纹和 Chrome 不一样，有些站点反而更容易识别它（它支持自定义 UA 和 Cookie，能缓解但别指望万能）。
- 商用产品内嵌。AGPL-3.0 协议——自用、内部工具没问题，要做闭源商业产品把它编译进去分发，就需要走商业化授权了。这一点官方 README 没放在显眼处，但 LICENSE 文件写得清清楚楚。
另外两个小体验：--dump structured_data 能直接抽 JSON-LD/OpenGraph/meta 成 JSON，做数据管道很顺手（演示页没埋 JSON-LD 所以字段是空的，meta 正常返回）；--adblock-lists 支持 EasyList 过滤，抓公开网页时能省掉广告请求的带宽。CDP 服务器模式（lightpanda serve，默认 9222 端口）可以直接顶替 Puppeteer 的 browserWSEndpoint，存量 Puppeteer 脚本理论上改一行就能切——这部分我这次只验证了进程能起，没跑完整 Puppeteer 用例。
结论
一句话：给 Agent 用的浏览器，Lightpanda 现在就是 16GB Mac 上的最优解——不是因为它功能最强（Chrome 生态仍然无可替代），而是因为它把「Agent 只需要读懂页面、偶尔点几下」这件事做成了 33MB 的常驻成本，还顺手把 MCP 的接入层铺好了。Web 爬取管线、Agent 浏览工具链这两类工作流，值得今天就把 brew install 敲下去。至于渲染级测试、复杂 JS 应用和反爬对抗，留给 Chrome 和 Playwright，它们在那儿待得很好。
有一个事实必须说在最后：官方的 16 倍/9 倍是百页批量基准下的数字，我单页实测是 7.7 倍内存和 2-4.6 倍耗时——数字会缩水，但方向没错，而且对你真正构成约束的那个场景（多页面并行的内存峰值），差距比倍数更致命。