Moli vs. Obscura：如何为 AI Agent 选择无头浏览器
Chromium 几乎是浏览器自动化的默认答案：兼容性最好、工具链最成熟，遇到复杂网页时也最省心。但它的代价同样明显——进程多、内存占用高、冷启动慢。对需要同时运行大量会话的 AI Agent、网页检索系统和爬虫来说，这些成本会被迅速放大。
Moli 和 Obscura 都试图解决这个问题。它们都使用 Rust 构建，也都不依赖 Chromium，却走出了两条不同的路线：Moli 优先保证任务成功率与复杂页面兼容性，Obscura 则把轻量、并发抓取和隐身能力放在更靠前的位置。
本文数据整理于 2026 年 9 月。浏览器引擎仍在快速迭代，性能数字与兼容性结论都应结合具体版本、测试环境和目标网站理解。
先说结论
如果只需要一个简化版答案：
- 通用 AI Agent、复杂 SPA、微前端、交互式自动化：优先 Moli。
- 海量 URL 抓取、资源受限环境、需要内置隐身和 MCP：优先 Obscura。
- 目标网站必须稳定可用，或依赖完整 Web API、Canvas、WebGL、媒体能力：继续使用 Chromium。
Moli 和 Obscura 都不是“更小的 Chrome”。它们有意放弃了一部分面向人类浏览体验的能力，以换取更低的 CPU、内存和启动成本。真正需要权衡的不是哪个项目跑分更高，而是你的任务能否落在它们已经实现的 Web 平台能力范围内。
两个项目的核心定位
Moli：结构优先，像素按需生成
Moli 将自己定位为面向 AI Agent 的生产级无头浏览器。它最关键的设计是 按需布局与渲染（on-demand layout and rendering）。
多数 Agent 任务只需要读取 DOM、提取 Markdown、查询元素、执行 JavaScript 或观察网络请求，并不需要持续维护一棵完整布局树，更不需要每一帧都绘制像素。Moli 因此把 DOM 和样式状态作为事实来源，仅在任务真正需要几何信息、坐标点击、截图或 PDF 时计算布局与绘制结果。
其核心组件包括：
- V8：执行 JavaScript；
- html5ever：解析 HTML；
- Servo/Stylo：处理选择器、级联与计算样式；
- Taffy 与 Parley：处理盒模型和文本排版；
- AnyRender/Vello：完成软件渲染。
Moli 同时支持 CDP、WebDriver Classic 和 WebDriver BiDi。对已经使用 Playwright、Puppeteer、Selenium 或其他自动化客户端的项目，这种协议覆盖意味着更低的迁移成本。
Obscura：轻量抓取与隐身优先
Obscura 同样是用 Rust 编写的独立无头浏览器，通过 V8 运行 JavaScript，并通过 CDP 兼容 Puppeteer 和 Playwright。它更强调三件事：低资源占用、并发抓取和隐身能力。
Obscura 的 --stealth 模式会使用带浏览器 TLS 指纹的网络客户端，加载追踪器拦截列表，并提供一致的 User-Agent、平台、时区和地理位置配置。它无法绕过交互式挑战、CAPTCHA 或基于 IP 的限流，但对基础 TLS 指纹和第三方追踪检测提供了开箱即用的处理。
此外，Obscura 直接提供并行 scrape 命令和 MCP Server，适合把浏览器作为一个轻量工具嵌入 Agent 工作流，而不必额外搭建协议适配层。
性能数据应该怎样看
Moli 的 README 引用了 Lexbench-Headless-Browser 的两组测试。第一组使用 1,308 个可比较任务，覆盖原生 CDP、13 种自动化工具和 Web 平台语义测试：
| 浏览器 | 通过任务数 | 任务成功率 |
|---|---|---|
| Chrome | 1,306 / 1,308 | 99.85% |
| Moli | 1,071 / 1,308 | 81.88% |
| Lightpanda | 697 / 1,308 | 53.29% |
| Obscura | 587 / 1,308 | 44.88% |
这组数据最重要的信息不是 Moli“比 Obscura 快多少”，而是它在同一任务集合上完成了更多自动化动作。对 Agent 来说，失败通常意味着重试、降级到 Chromium，甚至整个任务中断，因此任务成功率往往比单次请求的极限耗时更重要。
第二组资源测试只统计四个本地引擎都成功完成的 1,045 次任务尝试：
| 浏览器 | CPU 中位时间 | 峰值 PSS 中位数 |
|---|---|---|
| Chrome | 686.95 ms | 697.14 MiB |
| Moli | 100.61 ms | 92.12 MiB |
| Lightpanda | 36.48 ms | 33.55 MiB |
| Obscura | 38.44 ms | 38.74 MiB |
这里能看到清晰的取舍：Obscura 在共同成功的任务上更省资源，但 Moli 在完整任务集上的覆盖率明显更高。换句话说，Obscura 更轻，Moli 更有可能把任务做完。
需要注意，这些数据由 Moli 所属项目维护的基准提供。测试代码和报告是公开的，但结果仍不能替代你针对自身网站、脚本和部署环境做的验证。
公开网站抓取表现
Moli 还提供了一组覆盖 192 个中英文公开网站的爬取测试。页面只有在 JavaScript 执行后产生有意义的内容才算成功；仅返回 HTTP 200、挑战页、登录墙、空响应或应用空壳都不计入成功。
| 浏览器 | 有效页面 | 成功率 | 中位耗时 | 中位 RSS |
|---|---|---|---|---|
| Moli | 103 | 53.6% | 1.43 s | 73 MiB |
| Chrome Headless | 101 | 52.6% | 1.43 s | 773 MiB |
| Lightpanda | 85 | 44.3% | 0.97 s | 40 MiB |
| Obscura | 57 | 29.7% | 1.30 s | 39 MiB |
这组结果说明，资源占用低不等于抓取吞吐一定高。如果一个引擎频繁拿到空壳页面、无法执行关键脚本，后续重试和回退会抵消单次运行节省的资源。
它也不能证明 Moli 在所有真实网站上都比 Chrome 更兼容。样本只有 192 个 URL，且结果高度依赖网站状态、网络环境和判定标准。更合理的解读是：在该测试集合中，Moli 以约十分之一的内存获得了接近 Chrome 的有效页面数量。
复杂页面兼容性
浏览器兼容性最难的部分通常不是解析 HTML，而是现代前端框架和大量 Web API 组合后的长尾行为：
- SPA 的挂载与路由切换；
- 微前端沙箱和跨 Frame 通信；
- 无限滚动、懒加载与观察器；
- 动态样式、字体、布局和坐标点击；
- Cookie、IndexedDB、OPFS 等状态能力；
- 自动化客户端依赖的 CDP 事件顺序与字段语义。
Moli 的优势主要体现在这里。它提供完整的 DOM、CSS、布局、存储和网络运行时，并在当前选定的 Web Platform Tests 范围内通过了约 161.2 万个测试。Lexbench 中约 37 个百分点的成功率差距，也说明它对自动化工具和 Web 平台语义的覆盖更广。
但 Moli 仍然不追求与 Chrome 像素级一致，也没有 GPU 合成器，不适合高保真 Canvas、WebGL、视频播放或依赖完整 Chrome 打印行为的任务。
Obscura 已支持原生截图、滚动感知布局、screencast 和 PDF，但其长尾 Web API 与 CSS 行为仍可能和 Chromium 不同。若目标网站主要是结构清晰的内容页、商品页或列表页，这种差异可能无关紧要；若页面依赖复杂前端运行时，则必须先做站点级兼容性测试。
功能对比
| 维度 | Moli | Obscura |
|---|---|---|
| 核心取向 | 兼容性与任务成功率 | 轻量、并发抓取与隐身 |
| JavaScript | V8 | V8 |
| 自动化协议 | CDP、WebDriver Classic、WebDriver BiDi | CDP |
| 布局与渲染 | 默认结构优先；使用 --layout 启用真实布局、截图和 PDF |
原生渲染；支持截图、PDF 与 screencast |
| 提取输出 | HTML、Markdown、JSON、语义树等 | Markdown、结构化提取等 |
| 隐身能力 | 支持代理、User-Agent 等控制，未将隐身作为核心卖点 | --stealth 提供 TLS 指纹、身份配置与追踪器拦截 |
| 并行能力 | serve 可承载自动化客户端 |
serve --workers 与 scrape --concurrency |
| MCP | 官方 README 未提供内置 MCP Server | 内置 MCP Server，覆盖导航、提取、交互、截图、存储和标签页工具 |
| 容器部署 | 可自行容器化 | 提供基于 distroless 的非 root 镜像 |
此前资料中常见“Obscura MCP 提供 14 个工具”的说法已经过时。当前官方文档列出的工具明显更多，因此更稳妥的表述是：它已内置覆盖浏览器生命周期、读取、交互、诊断、视觉输出、存储和标签页管理的 MCP 工具集。
如何选择
选择 Moli，如果你更在意任务完成率
适合以下场景：
- 构建通用浏览器 Agent，需要面对未知网站；
- 目标站点包含复杂 SPA、微前端或大量动态交互；
- 已经使用 Playwright、Puppeteer、Selenium 或 WebDriver BiDi；
- 希望显著降低 Chrome 的资源消耗，但不愿过度牺牲兼容性；
- 需要 DOM、网络、存储、布局和截图能力在同一个运行时中协同工作。
代价是：它的内存占用高于 Obscura 和 Lightpanda，而且仍不能替代 Chrome 的全部视觉与媒体能力。
选择 Obscura，如果你更在意单位资源吞吐
适合以下场景：
- 批量抓取大量结构相对标准的页面；
- 容器或边缘节点的内存预算非常紧张；
- 希望直接用
scrape --concurrency分发 URL； - 需要内置 MCP Server，快速接入 Claude Code 等客户端；
- 需要基础 TLS 指纹伪装、浏览器身份配置与追踪器拦截。
代价是：复杂站点和自动化工具的兼容性更弱，最好在上线前建立目标 URL 样本集，并准备回退到 Chromium 的路径。
继续使用 Chromium，如果失败成本最高
以下情况不值得为了节省几十或几百 MiB 内存而更换引擎：
- 需要尽可能完整的 Web API 与浏览器行为；
- 依赖高保真截图、Canvas、WebGL、音视频或 GPU 合成；
- 目标网站频繁变化，且没有维护兼容性回归集的能力；
- 单个会话价值很高，任何一次兼容性失败都比资源成本更贵；
- 依赖浏览器扩展、Chrome 专属能力或长时间保持的认证会话。
更稳妥的工程方案：分层路由
在生产系统中，Moli、Obscura 和 Chromium 不一定是三选一。更实用的方案是按任务复杂度分层：
- 静态 HTML 先用普通 HTTP 客户端与正文提取器处理；
- 需要 JavaScript 的标准页面交给 Obscura；
- 复杂交互任务交给 Moli；
- 遇到不支持的 Web API、视觉任务或连续失败时回退到 Chromium。
这样既能控制资源成本，也不会把所有兼容性风险押在一个新浏览器引擎上。关键是定义明确的成功条件，例如正文长度、关键元素存在、页面不是挑战页、目标动作确实产生了状态变化，而不是只检查 HTTP 200。
其他值得关注的选择
Lightpanda
Lightpanda 使用 Zig 从零构建，官方基准宣称抓取 100 个页面时峰值内存约为 Chrome 的 1/16、执行时间快约 9 倍。它支持 CDP 和 WebDriver BiDi，当前版本也已支持面向文本的 PNG/PDF 输出，因此“完全不支持截图”的旧说法已经不准确。
它的优势是极致资源效率，风险则与其他新引擎相同：复杂网站、长尾 Web API 和自动化客户端兼容性需要逐站验证。
Kitesurf
Kitesurf 是 Cloudflare 面向 Agent 构建的无状态浏览器，运行在 Workers 上，目前通过 Browser Run 提供 Beta 服务。它适合突发式、一次性的 HTML 提取、PDF 和截图任务，但不提供本地可执行文件，也不适合视频、WebGL、真实 TLS 指纹挑战或需要长期持久状态的会话。
Cloudflare 公布的 14 URL 测试中，Kitesurf 相比预热的 Chromium 消耗更少的 CPU 和内存，但墙钟时间更长。这再次说明“更省资源”和“单次响应更快”是两个不同指标。
最终建议
Moli 和 Obscura 代表了两种清晰的工程取舍：
- Moli 用适度增加的资源占用，换取更高的任务成功率、更广的协议支持和更好的复杂页面兼容性。
- Obscura 把轻量、并发与隐身能力放在首位，更适合目标明确、页面结构相对标准的大规模抓取。
如果你的目标是“让 Agent 尽可能可靠地完成未知网页任务”，Moli 是更稳妥的起点；如果目标是“用尽可能少的资源抓取大量已知页面”，Obscura 更合适。无论选择哪一个，都应该用自己的 URL 样本和真实自动化脚本做基准，而不是直接把项目 README 中的数字当作生产承诺。