lijianfei.com

在大模型与自主智能体（AI Agent）席卷技术栈的今天，浏览器的角色发生了根本性的位移。我们曾习以为常的 Chromium，本质上是一台为人类肉眼以 60Hz 乃至 120Hz 刷新率呈现精美像素的“重装工业复合体”；然而，当坐在屏幕对面的使用者从碳基生物变成硅基智能体时，这套庞大的图形渲染架构瞬间显露出巨大的结构性错配。

开源项目 Moli（由团队 lexmount 主导并在 GitHub 开源）给出了极具革命性的回答：它用 Rust 重构了一款面向 AI 智能体的生产级无头浏览器，提出了 “结构优先，按需生成像素”（Structure first. Pixels on demand） 的核心架构哲学。它既没有像传统轻量无头工具那样牺牲现代 Web API 兼容性，也没有盲目背负 Chromium 动辄 700 MiB 内存与 11 个并发进程的沉重底噪。在这篇文章中，我将深入其 Rust 底层源码，全景剖析 Moli 如何通过原生 DOM 分离管线、按需销毁的冻结布局树、零拷贝 Markdown 栈机以及原生的 WebMCP 表单工具协议，为 Agentic Web 树立全新的工程标杆。

1. 结构性错配：人类浏览器与智能体浏览器的代际鸿沟

在过去数年构建自主智能体、网页信息萃取与自动化管线的实战中，我反复撞上一堵让人极度沮丧的算力高墙：为什么仅仅为了让大模型读取一个网页的正文，我就必须在后台拉起一个动辄占用 700 MiB 内存的 Chromium 实例？

追本溯源，现代 Chromium 架构的核心驱动力是“人类视觉感知”：

1. 多级像素光栅化与 GPU 合成：为了保证平滑滚动与流畅动画，Chromium 维护着庞大的图层树（cc::LayerTreeHost）、分块光栅化（Raster Tiling）、跨进程 GPU IPC 通信以及双缓冲交换链路；
2. 重型多进程沙盒隔离：浏览器主进程（Browser Process）、渲染进程（Renderer Process）、GPU 进程、网络服务进程（Network Service）、音频服务进程……一次普通的页面加载动辄衍生出 11 个系统进程与 120 多个系统线程；
3. 高昂的会话自举时延：启动一个 headless Chromium 并建立 CDP（Chrome DevTools Protocol）连接，中位耗时通常在 170ms 以上。

然而，AI 智能体与 Web 的交互范式截然不同：

flowchart LR
    subgraph HumanBrowser ["人类视角（Human Browser）"]
        H1["HTML/CSS/JS"] --> H2["DOM + CSSOM"]
        H2 --> H3["永久 RenderTree"]
        H3 --> H4["分块光栅化 (Tiling)"]
        H4 --> H5["GPU 渲染合成"]
        H5 --> H6["60/120fps 显示器光斑"]
    end

    subgraph AgentBrowser ["智能体视角（Moli Agent Browser）"]
        A1["HTML/CSS/JS"] --> A2["原生 DOM + Stylo"]
        A2 --> A3["V8 脚本执行与事件回环"]
        A3 --> A4{"是否需要坐标/像素？"}
        A4 -- "否 (90% 场景)" --> A5["零拷贝 Markdown / 语义树"]
        A4 -- "是 (10% 场景)" --> A6["按需 Taffy 布局与 CPU 快照"]
        A6 --> A7["坐标返回即刻销毁布局缓存"]
    end

如上图所示，智能体在 90% 以上的工作负载中，核心诉求只有三个：

• 执行客户端 JavaScript：驱动现代 SPA（React、Next.js、Vue）完成数据脱水与页面动态注水；
• 感知网络静默与 DOM 稳定：获知页面何时真正加载完成；
• 抽取高密度语义结构：获取干净且保留标题层级、表格与外链的 Markdown 或可访问性语义树（Semantic Tree），作为上下文注入 LLM 上下文窗口。

智能体根本不在乎这一帧动画是否平滑，也不需要 GPU 显存为它缓存多级视口图块。

以往开源界曾出现过 Lightpanda（基于 Zig/JS）或 Obscura（基于 Go）等极轻量方案，内存虽然降到了 40 MiB 左右，但在真实复杂的现代网页上，由于缺失了庞大 Web API 与前沿 JavaScript 标准的支持，综合通过率暴跌至 30%~50%，难以支撑工业级生产。

Moli 的突破点在于：在底层完整嵌入真正的 V8 引擎与 Servo Stylo 样式计算，保障严苛 Web 标准兼容度的前提下，对布局与绘制管线实施彻底的按需惰性重构。

2. 架构全景：分层模块与双管线运转机制

纵观 Moli 的代码仓库，整个工作区由 70 多个精细拆分的 Rust Crate 协同运转。为了在单进程内实现高内聚与极低开销，它构建起了一套清晰的分层流水线：

flowchart TD
    subgraph Ingress ["输入接入层 (Protocols & CLI)"]
        CLI["moli CLI (fetch / serve / import)"]
        CDP["moli-protocol-cdp (CDP 9222 兼容端点)"]
        WebDriver["WebDriver Classic & BiDi"]
    end

    subgraph CoreEngine ["核心运行时驱动层 (Single Process Core)"]
        FetchEngine["moli-fetch (基于 curl-rust 与 AWS-LC)"]
        NativeDOM["moli-dom (纯 Rust 原生 DOM 树)"]
        StyloEngine["Stylo (Mozilla Servo 样式计算引擎)"]
        V8Runtime["moli-renderer-v8 (嵌入式 V8 运行时)"]
        WebAPIs["Web API 矩阵 (IndexedDB / OPFS / WebCrypto / Workers)"]
    end

    subgraph DualPipeline ["双轨分流执行管线"]
        DOMFirst["DOM-first 极速路径 (默认无布局、无绘制)"]
        OnDemand["On-demand 按需几何路径 (按需激活)"]
    end

    subgraph OutputLayer ["智能体适配输出层"]
        Html2Md["moli-html2md (直接操作 DOM 的栈机)"]
        SemanticTree["Accessibility 紧凑语义树"]
        WebMCP["moli-webmcp (原生表单自动 Tool 化)"]
        FrozenTree["FrozenLayoutTree (Taffy 几何快照)"]
        VelloFrame["CPU 单帧光栅截图 / PDF (Vello + Glifo)"]
    end

    Ingress --> CoreEngine
    CoreEngine --> DualPipeline
    DOMFirst --> Html2Md
    DOMFirst --> SemanticTree
    DOMFirst --> WebMCP
    OnDemand --> FrozenTree
    OnDemand --> VelloFrame

2.1 架构核心选型矩阵

Moli 没有重复发明轮子，而是站在现代开源图形与浏览器基础设施的巨人之肩上，完成了严丝合缝的 Rust 原生集成：

3. 双轨管线：DOM-first 路径与按需布局的极致平衡

Moli 最核心的架构创新，在于彻底打破了传统浏览器中“解析 -> 样式 -> 布局 -> 绘制 -> 合成”的线性强绑定。

3.1 DOM-first 极速路径：零几何开销

当智能体通过命令行执行：

moli fetch --dump markdown --wait-until done https://example.com

整个执行链路完全工作在 DOM-first 路径 上：

1. 页面 HTML 通过 moli-parser 流式解析为 moli-dom 的原生节点；
2. V8 运行时挂载并执行页面脚本，网络请求由底层的异步事件循环调度驱动；
3. MutationCoordinator 与任务队列监控页面生命周期。当满足指定的等待条件（如 domstable 或 networkidle）时，生命周期判定完成；
4. 此时，Moli 压根不会调用任何布局计算算法，也绝不分配任何图块缓存！控制权直接交由 moli-html2md 模块，直接在内存中的 Rust DOM 树上遍历生成 Markdown。

这种架构下，传统的视口重排、回流（Reflow）、重绘（Repaint）与 GPU 纹理显存分配全部降为零，CPU 与内存开销仅为 Chromium 的极小零头。

3.2 On-demand 路径：几何快照与即刻销毁

如果智能体需要进行视觉断言（Visual Verification）、全页长截图、或者需要计算某个按钮的具体点击坐标 (x, y) 呢？

此时，系统通过显式参数（如 --layout 或 CDP 协议的 DOM.getBoxModel）按需激活 On-demand 路径：

//! 摘自 moli-layout/src/lib.rs 的架构设计说明
//! One-shot CSS box construction, numeric layout, and owned paint projection.
//!
//! The crate knows Stylo and Taffy but never knows Moli's live DOM or V8
//! runtime. Renderer-owned adapters lend a canonical source view and resolve
//! styles; all source/style borrows and per-pass caches are gone before the
//! returned FrozenLayoutTree or PaintSnapshot crosses into a consumer.

pub(crate) const LAYOUT_SUBPIXELS_PER_CSS_PIXEL: f32 = 64.0;

其工程精髓包括：

1. 彻底解耦的只读视图：moli-layout 并不直接持有活动的活体 DOM 或 V8 垃圾回收句柄，它只通过适配器短暂借用（Borrow）一份标准化的样式与节点只读切片；
2. 高精度定点数布局：对齐 Blink 的 LayoutUnit 精度，采用每个 CSS 像素 64 个固定子像素（Subpixels）的数值精度，确保盒模型尺寸与 Chrome 行为完全兼容；
3. 不可变快照与缓存即刻释放：布局计算完成后，生成一个紧凑的不可变快照 FrozenLayoutTree 返回给调用方。所有在计算过程中创建的临时 Taffy 求解树、排版工作队列与中间缓存，在函数退出的一瞬间全部 Drop 销毁！

这种“用完即扔”的无状态单次布局策略，彻底杜绝了长期运行无头浏览器时最容易出现的图层内存泄漏与堆积失控。

4. 深度拆解 moli-html2md：直接跑在活体 DOM 上的栈机

许多开发者在用 Puppeteer 或 Playwright 做正文提取时，惯常的做法是将整个页面序列化：
document.documentElement.outerHTML $\to$ 通过 CDP IPC 发送到 Node.js 进程 $\to$ Node 端用 cheerio/JSDOM 重新构建 DOM $\to$ 传给 Readability 清洗 $\to$ 再传给 Turndown 转为 Markdown。

这一套链条存在巨大的缺陷：

• 巨幅字符串跨进程拷贝与多次序列化/反序列化；
• 在 Node.js 堆内存中频繁触发 V8 的垃圾回收（GC STW）；
• 极其容易把前端页面注入在隐藏 <script> 中的几十万字符 JSON 状态数据（如 Next.js 的 __NEXT_DATA__）误判为正文，白白浪费成千上万个 LLM Token。

Moli 的 moli-html2md 模块展现了 Rust 系统级编程的纯粹之美：它直接以只读借用方式操作活体 Rust DOM，利用显式状态栈机实现零拷贝转换。

// 摘自 moli-html2md/src/converter.rs
pub struct Converter {
    options: Options,
}

impl Converter {
    pub fn convert<D: Dom + ?Sized>(&self, dom: &D, root: D::NodeId) -> String {
        machine::convert(dom, root, &self.options)
    }
}

4.1 显式栈机防堆栈溢出

DOM 树的嵌套层级在某些极端前端页面（如深层嵌套的 <div> 容器）上可能达到数百层。如果采用常规的递归函数遍历，极易导致线程调用栈溢出（Stack Overflow）。moli-html2md 在内部用显式堆栈（Explicit Stack）维护代码块、列表嵌套、引用块与表格状态，使得 DOM 树的物理深度永远不会转化为 Rust 的系统调用栈深度。

4.2 智能状态剪枝：识破 SPA 的 JSON 巨幕

在现代 Web 抓取中，最隐蔽的“Token 刺客”是单页应用的离线序列化状态。Moli 在转换器底层实现了一套极其精巧的启发式剪枝逻辑：

// 摘自 moli-html2md/src/visibility.rs
pub(crate) fn nonrendered_serialized_state<D: Dom + ?Sized>(dom: &D, node: D::NodeId) -> bool {
    if !matches!(dom.node_kind(node), NodeKind::Element(_)) {
        return false;
    }
    let hidden = dom.attribute(node, "hidden").is_some()
        || dom.attribute(node, "style").is_some_and(inline_display_none);
    if !hidden {
        return false;
    }
    let Some(child) = dom.first_child(node) else {
        return false;
    };
    if dom.next_sibling(child).is_some() {
        return false;
    }
    let NodeKind::Text(text) = dom.node_kind(child) else {
        return false;
    };
    let trimmed = text.trim();
    trimmed.len() >= 512
        && ((trimmed.starts_with('{') && trimmed.ends_with('}'))
            || (trimmed.starts_with('[') && trimmed.ends_with(']')))
}

这段逻辑深刻体现了工程细节的洞察力：

• 如果一个节点带有 hidden 属性或行内 display: none，且内部包裹着超过 512 字节的大括号 {} 或中括号 [] 纯文本，Moli 会精准将其判定为“未渲染的序列化应用状态”，直接从 Markdown 输出流中剥除；
• 但与粗暴过滤隐藏节点的脚本不同，对于折叠在 <details> 内部或处于非激活 Tab 标签页内的普通文本，Moli 依然会完整保留在结构化 Dump 中——因为这些内容极大概率是网页核心知识库的组成部分，模型需要完整获知！

5. WebMCP 原生表单自动化：告别脆弱的视觉点选

在多模态 Agent（VLM Agent）兴起后，业界曾刮起一阵“端到端截图 + 坐标预测”的风潮：模型看着截图推测“用户名输入框在 (x: 420, y: 310)”，然后调用系统驱动去点击并打字。

这种方式在真实环境中的翻车率居高不下：屏幕缩放抖动、动态弹窗遮挡、滚动条位移都会让坐标发生偏差；而在传统的无头自动化中，靠前端工程师手写的 CSS 选择器又极易因构建哈希（如 .btn_x7a9k）的重编译而失效。

Moli 给出了一个更为高维且稳健的原生解法：内置 WebMCP 协议引擎（moli-webmcp），把网页表单直接在 DOM 级编译为结构化的大模型工具定义（Tool Calling Schema）。

sequenceDiagram
    autonumber
    participant LLM as "AI 智能体 (LLM)"
    participant Moli as "Moli 浏览器 (Rust Native)"
    participant DOM as "页面活体 DOM 树"

    Note over Moli,DOM: 1. 扫描表单控件与约束
    Moli->>DOM: 遍历 Form 树 (input, select, textarea)
    DOM-->>Moli: 提取 Label 归属、DOM 顺序与校验约束 (required, pattern, min, max)
    
    Note over Moli,LLM: 2. 动态生成标准 MCP Tool
    Moli->>LLM: 提供原生 JSONSchema 工具定义 (WebMCP Tool)
    
    Note over LLM: 3. 模型直接依据 Schema 生成强类型参数
    LLM->>Moli: 发起工具调用: fill_form({ username: "jeffery", plan: "pro" })
    
    Note over Moli,DOM: 4. 原子级批量写入与事件分发
    Moli->>DOM: prepare_fill(): 触发 input/change 事件并校准脏状态
    Moli-->>LLM: 返回标准化导航/提交结果

在 moli-webmcp/src/schema.rs 中，Moli 实现了原生的表单所有权与校验规则解析：

• 自动沿着 DOM 树推导控件的文字语义标签（无论是通过 <label for="id"> 还是外层容器包裹）；
• 原生识别 HTML5 表单约束属性：required、min、max、step、正则 pattern；
• 将符合条件的交互控件，以严格的 DOM 物理顺序，直接组装成合规的 JSONSchema properties 与 required 列表；
• 接收到智能体的填充计划（Fill Plan）后，直接在 Rust 原生 DOM 层原子化更新状态，并精准触发关联的 JavaScript input 与 change 事件回环。

Agent 不再需要像无头苍蝇一样猜测坐标，而是直接与一个“自带类型安全契约”的网页交互！

6. 横向基准对决：在严苛测试集中的硬核指标

衡量一款无头浏览器的终极标准，永远是工业级场景下的硬核数据。在开源基准评测平台 Lexbench-Headless-Browser 中，Moli 面对由 1,308 道涵盖 CDP、Playwright、Puppeteer 与真实 Web 平台语义的综合测试集，展现出了震撼的性能对比。

6.1 综合任务通过率对比（1,308 项可比任务）

在完全相同的任务判定标准下（页面不仅要返回 HTTP 200，还必须执行完客户端 JS 并生成有实际意义的内容）：

在独立第三方极简无头引擎阵营中，以往方案的成功率均徘徊在 40%~60% 的及格线边缘；而 Moli 一举将非 Chromium 轻量引擎的通过率拉升到了 81.88%。

6.2 资源消耗与运行时开销对比（557 道四引擎共同完成任务）

针对四个本地可观测引擎，在共同跑完的基准测试中所消耗的 CPU 耗时与峰值内存（RSS/PSS）进行中位数统计：

[!NOTE] 真实全网 192 个主流复杂网站实测抓取
在包含登录墙、反爬质询、重度客户端 SPA 渲染的 192 个中外主流真实网站实测中，Moli 以 73 MiB 的内存中位数和 1.43 秒 的中位耗时，成功获取了 103 个有效页面（成功率 53.6%），成功率甚至微幅超越了 Chrome Headless 的 101 个页面（52.6%，但 Chrome 消耗了高达 773 MiB 的中位内存）。

7. 实操上手：让你的智能体管线直接提速

在日常工程实践中，无论是给本地编码助手装配网页浏览 Skill，还是在生产环境通过 Playwright 驱动大规模爬虫集群，接入 Moli 都极为顺滑。

7.1 极速命令行获取精准 Markdown

无需编写复杂的脚本，直接通过 CLI 抓取动态渲染后的页面并输出干净的 Markdown：

# 自动等待 DOM 突变彻底平息，并以 Markdown 结构输出
moli fetch \
  --dump markdown \
  --wait-until domstable \
  "https://example.com/dynamic-spa"

如果你正在抓取某些滚动加载或轮询列表，可以指定特定选择器就绪：

moli fetch \
  --dump markdown \
  --wait-selector "article.main-content" \
  "https://example.com/news"

7.2 无缝替换 Playwright 的本地 Chromium

Moli 提供了原生的 CDP 服务端。我们只需在后台启动 moli serve，现有的 Node.js / Python 自动化脚本即可零成本迁移：

# 启动 Moli CDP 服务，监听 9222 端口
moli serve --port 9222

在 Playwright 代码中，直接使用 connectOverCDP 挂载：

import { chromium } from "playwright";

// 直连 Moli 高性能无头端点，无需本地唤起重型 Chrome
const browser = await chromium.connectOverCDP("http://127.0.0.1:9222");
const context = browser.contexts()[0];
const page = context.pages()[0] ?? await context.newPage();

await page.goto("https://example.com");

// 获取页面文本内容
const content = await page.locator("body").innerText();
console.log(content);

await browser.close();

通过这一改动，原本部署在 4 核 8G 云主机上只能跑 5 个并发 Playwright 实例的爬虫集群，瞬间能够轻松并发承载 30~40 个实例，服务器成本直降 70% 以上。

8. 工程权衡与客观边界

没有任何架构是万能的银弹。在深读其源码并进行实机验证后，我认为开发者在选型时必须清晰理解 Moli 的 设计取舍（Design Trade-offs） 与有意保留的边界：

1. 不追求与 Chrome 的像素级光栅化一致：Moli 明确声明放弃了 GPU 保留式多帧合成与高保真 WebGL/Canvas 物理加速渲染。如果你需要测试网页游戏引擎的着色器（Shader）兼容性，或者验证复杂 CSS 3D 变换动画的逐帧渲染，Chromium 仍然是不可替代的唯一参照；
2. 坦诚透明的报错哲学（Fail-Fast）：许多轻量级无头工具为了虚高的通过率，在遇到未实现的 CDP 命令时会选择静默返回假数据（Mocking）。Moli 采取了绝对严苛的透明原则——不支持的协议或功能直接抛出明确的错误，绝不假装某个视觉渲染或网络拦截已经发生。这种确定性对于依赖真实反馈做出决策的自主 Agent 而言至关重要；
3. 环境模拟支持边界：目前 Moli 支持网络 offline 离线状态的无缝切换，但暂未实现完整的 CPU 降频仿真、网络丢包率注入以及细粒度带宽节流。

9. 总结

在智能体驱动的新一轮计算革命中，软件基础设施正在经历深度的“脱水与重构”。

以往我们不得不把为人类视网膜量身定制的重型浏览器塞进容器，忍受高昂的内存账单与冷启动延迟；而 Moli 凭借 Rust 的系统级掌控力，交出了一份惊艳的答卷：

• 以原生 DOM 与 Stylo 为单一真相源，将几何布局与像素绘制降级为按需临时计算；
• 利用零拷贝栈机重塑 Markdown 转换，在内存层彻底杜绝无效序列化与 Token 浪费；
• 原生拥抱 WebMCP，将混乱的前端表单降维为确定性的类型安全契约。

当无头浏览器不再需要为人类的肉眼渲染屏幕，真正的硅基极速之门才刚刚开启。

原文链接与参考资料

• 项目主仓库：lexmount/moli on GitHub
• 官方多语言文档：Moli Documentation (简体中文)
• 权威测试基准仓库：Lexbench-Headless-Browser on GitHub
• 五引擎基准评测报告：Lexbench Five Engine Evaluation Report
• 单题资源开销报告：Lexbench Headless Browser Resource Card
• WebMainBench 545 页面数据集：OpenDataLab WebMainBench on HuggingFace