Moli：给 AI 智能体用的 Rust 无头浏览器

一句话定位

Moli 是 Lexmount 用 Rust 写的开源无头浏览器，目标用户不是人，而是人工智能智能体。仓库在 2026 年 8 月公开，星标已过九千，采用 Apache 2.0 与 MIT 双许可。它最需要被强调的一点是：这不是一个把 Chromium 包一层接口的壳，而是一个独立实现的浏览器内核——流式超文本解析、原生文档对象模型、脚本引擎、样式层叠、网络栈、绘制，都在它自己手里，有自己的所有权与生命周期规则。

它对外提供三种用法：命令行直接抓取与抽取、作为常驻自动化服务器、以及供已有的自动化客户端接入。三种方式共用同一个内核。

按需布局与绘制：把浏览器拆成两档成本

Moli 的设计核心写在它自己的口号里——结构优先，像素按需。它对「浏览器该在什么时候干活」这件事做了明确切分，默认档位是 LayoutPolicy::Mock：几何数据是确定性生成的兼容格式，但不做真实布局，也不做绘制。加上 --layout 才切到 LayoutPolicy::OnDemand，此时才有真实布局、命中测试、坐标输入、截图与低频截屏帧。

这样切的理由是：绝大多数自动化请求要的是页面结构，不是一个持续渲染的视觉世界。官方给出的对应关系如下。

智能体请求	Moli 实际做什么
抽取超文本或 Markdown、查询文档对象模型、执行脚本、检查网络与存储	直接读运行时状态，不触发布局与绘制
读取元素盒子、坐标命中测试、发送坐标输入	跑一次布局计算，只保留最新那份冻结布局树
截图	从当前文档与样式重建，替换冻结树，渲染一帧，用完即弃
轮询截屏流	只比对生成元数据，状态没变就不出帧，变了才重建出一帧

实现上，第一次几何请求会从当前文档与样式构建一份工作树，把规范几何冻结成一个与文档解耦的不可变 FrozenLayoutTree，然后只保留这一棵树，把工作树、样式借用、布局缓存、诊断与绘制状态全部丢弃。截屏订阅只记住一个不透明的可视状态令牌，绘制结果从不复用。系统里没有增量维护的布局树、没有损伤图、没有保留的显示列表、没有图形处理器合成器，也没有常驻窗口。

这个成本模型对抓取、检索管道、评测环境和强化学习负载特别合适——这些场景里一万个请求可能只有一个真的要看图。

三种协议一个内核，不装驱动

Chrome 开发者工具协议、经典 WebDriver、以及双向 WebDriver 共用同一套内核与调度器，因此不需要单独安装浏览器驱动，也不需要另装一个浏览器。现有的自动化库可以直接连过来，走开发者工具协议接入即可；命令行里 moli serve 起基础服务，加 --layout 打开真实几何与截图表面，再加 --resource 才去抓图片、字体、音视频这些可选资源。

命令行一侧，moli fetch 可以直接产出超文本、Markdown、JSON、语义文本树等输出，配合选择器等待、脚本等待、响应等待与网络追踪。视觉输出同样按需：视口图、整页图、分页文档都在需要时才生成。

它站在这些构件上：网络传输用 libcurl，超文本解析用 html5ever，脚本执行用 rusty_v8 绑定的 V8 引擎，选择器与样式计算用来自 Servo 的 Stylo，盒与文本布局用 Taffy 与 Parley，软件渲染走 AnyRender 与 Vello 的处理器端实现。文档与样式只有一个真相来源——原生文档对象模型及其样式集成。

官方基准：读数字之前先看它测了什么

官方给了三组数据，全部来自它自己或同组织的基准仓库，我们没有复现，这一档记为待复现。先看覆盖面最直观的一组：192 个真实站点的混合抓取，只有脚本跑完还能拿到有意义内容才算成功。

浏览器	有效页面	成功率	中位耗时	中位常驻内存
Moli	103	53.6%	1.43 秒	73 兆字节
无头 Chrome	101	52.6%	1.43 秒	773 兆字节
Lightpanda	85	44.3%	0.97 秒	40 兆字节
Obscura	57	29.7%	1.30 秒	39 兆字节

这组数字最该被读出的不是「谁更快」——四家耗时在同一量级——而是「同样的可用率，内存差了一个数量级」。Moli 的成功率只比无头 Chrome 高一个百分点，但常驻内存是它的约十分之一。

第二组是单个智能体负载：协议就绪耗时 34.85 毫秒对 169.37 毫秒，回合中位耗时 33.40 对 57.13 毫秒，峰值内存 102.46 对 348.82 兆字节，进程与线程数 1 与 24 对 11 与 123。进程数这一栏解释了内存差从哪来：它就是一个进程。

第三组是能力覆盖。在 Lexbench 无头浏览器基准的一千三百零八项可比任务上，Moli 0.1.1 通过一千零七十一项，成功率 81.88%，领先 Kitesurf 的 62.08%、Lightpanda 的 53.29% 与 Obscura 的 44.88%，而无头 Chrome 作为参照引擎是 99.85%。另有一轮五百五十七项任务的资源对比，它的中位处理器时间是 100.6 毫秒、中位峰值内存 92 兆字节，Chrome 是 687 毫秒与 697 兆字节，约为其百分之十五与百分之十三。网页平台测试的一次全量跑通过了一百六十一点二万项。

把三组放在一起看，结论要说得准：Moli 卖的不是「比 Chrome 更准」——81.88% 对 99.85% 是实打实差十八个百分点，意味着仍有近五分之一的任务会失败，而且这是它自己公布的数字。它卖的是「用约十分之一的资源，拿到接近 Chrome 的可用率」。对批量跑的智能体负载，这个交换是否划算取决于失败重试的成本。

它诚实划出的边界

README 里专门写了一节当前有意为之的边界：没有图形界面浏览器、没有常驻窗口、没有图形处理器合成器、没有保留多帧的绘制架构；不追求与 Chrome 的像素级一致，也不提供高保真的画布、WebGL 与媒体播放；--layout 支持软件截图与栅格化文档导出，但没有实现 Chrome 的全部截图与打印模式。

更值得称道的是它对失败的态度：不支持的协议路径会返回显式错误，绝不假装某个浏览器动作、事件、网络观察或视觉结果发生过。对智能体来说这一条比性能数字更重要——静默失败的自动化会一路产出看起来正常的错误结论，显式报错至少能被上层捕获与重试。

它在本板块里的位置

浏览器是智能体的工具接口层。同板块里，Pi 解决的是运行时怎么分层，DeepSeek Harness 解决的是工具与界面怎么全插件挂载，Hermes 解决的是技能怎么自我改进；Moli 解决的是其中具体的一支——智能体伸手去拿网页时，这一支怎么既便宜又可控。它是下游，不是框架本身，但没有它，上游那几层的能力在网页场景里就要付十倍内存去买。

它也把自己做成了可被智能体直接消费的形态：仓库里的 skills/ 目录给了安装技能，README 直接写「把这段提示词交给你的智能体」，让智能体自己下载预编译二进制并完成首次抓取。仓库另带一个 WebMCP 演示场，可以用命令行列出并调用站点原生的网页模型上下文协议工具。

与商业产品的关系也讲清楚了：Moli 是开源内核，Lexmount Browser 是围绕它建的托管云运行时与控制面，官方明确写出开源无头浏览器在不接入后者的情况下完全可用。

待复现

我们未对 Moli 做过任何基准或复现测试，上述数据全部引自官方仓库与同组织的 Lexbench 基准仓库。星标与更新活跃度（公开两个月、仍在每日提交）说明它是这条工具链上值得收录的一层，但能力水位记为待复现。