不用 Chromium，也不用 V8：h5i 用纯 Rust 为 AI Agent 重做浏览器

编者说明：本文根据 Hideaki Takahashi 的文章 I Built h5i, a Headless Browser for AI Agents Entirely in Rust. No Chromium, No V8 整理并扩展，并参考 h5i 官方仓库、浏览器设计文档与安全说明交叉核对。性能数字采用官方当前版本，因而与原文发表时的早期数字略有不同。

今天所谓的“AI 浏览器”越来越多，但很多产品的底层并没有重新发明浏览器：它们仍然启动 Chromium，运行 V8，再用 Playwright、Puppeteer 或 Chrome DevTools Protocol 驱动页面。

这条路线成熟、兼容性高，也很适合自动化测试。不过，如果浏览器的主要用户不是人，而是 AI Agent，完整 Chromium 可能显得过重。Agent 往往不需要地址栏、标签页动画、视频播放或像素级视觉效果；它更需要的是结构化页面、稳定的元素引用、可控网络访问和清晰审计记录。

h5i 正是从这个问题出发：能不能不用 Chromium，也不用 V8，而是用 Rust 组件为 Agent 构建一个更轻、更可控的浏览器运行时？

为什么不直接使用 Chromium？

Chromium 的优势非常明确：现代网页兼容性极强，JavaScript、CSS、iframe、媒体、WebGL 和复杂登录流程都已经被大量真实场景验证。代价则是启动时间、内存占用、进程数量，以及更复杂的安全边界。

对于“打开文档、提取正文、点击链接、填写普通表单、记录网络请求”这类 Agent 高频任务，h5i 选择只实现真正需要的能力。它不是把 Chrome 隐藏起来，而是建立一套独立的浏览器流水线。

h5i 的核心架构

根据官方设计文档，h5i 的浏览器主要由以下几部分组成：

• Blitz：负责 HTML 解析、DOM、CSS、布局与页面渲染。Blitz 本身建立在 Servo 生态的 Stylo 等组件之上。
• Boa：作为可选 JavaScript 引擎。它同样用 Rust 编写，因此 h5i 不需要 V8。
• 自定义网络与策略层：在请求真正发出之前检查目标、方法和规则，并记录请求与响应信息。
• Agent 接口：把页面转换成紧凑的结构化快照，给可交互元素分配稳定引用，让模型可以用类似 @e3 的标识操作页面。

一个典型流程可以非常简单：

h5i browser open https://example.com
h5i browser snapshot
h5i browser click @e3
h5i browser requests
h5i browser audit

这里最重要的不是命令行语法，而是页面被转换成了面向 Agent 的表示。模型不必反复接收庞大的原始 DOM，也不必猜测坐标；它可以阅读精简后的页面结构，再引用某个元素完成点击或输入。

结构化快照比截图更适合许多 Agent 任务

视觉模型当然可以看截图，但截图通常更消耗 token，而且元素定位容易受窗口尺寸、字体和布局变化影响。h5i 的 snapshot 更像是一个经过筛选的无障碍树：保留文本、角色、状态和交互入口，同时减少装饰性节点。

这种表示对文档网站、后台表单、资料检索和批量工作流尤其有用。Agent 可以先理解页面，再执行确定性的动作；当页面变化时，引用和审计记录也比纯坐标操作更容易调试。

网络策略发生在请求发出之前

传统浏览器自动化通常先启动一个能力完整的浏览器，再在外围添加拦截规则。h5i 则把网络策略放进自己的请求路径：在字节离开机器之前，就可以检查域名、协议、端口和动作是否被允许。

这使它更适合采用“默认拒绝、按需开放”的策略。例如，只允许 Agent 访问指定文档站点和 API，禁止内网地址、未知跳转或任意文件读取。配合 requests 与 audit 命令，开发者能追踪 Agent 看过什么、访问了哪里、执行过哪些操作。

不过，官方安全文档也明确提醒：任何浏览器都不能保证消除提示词注入。h5i 的目标是把网页内容视为不可信输入，并通过网络规则、凭据隔离和沙箱缩小潜在影响范围，而不是宣称问题已经被彻底解决。

性能：当前官方数字约为 3 倍与 86%

原文记录的是项目早期约“5 倍更快、峰值内存减少 80%”的测试。加入 JavaScript 支持并更新基准后，h5i 官方现在给出的概括是：在简单、以文档为主的冷启动读取测试中，相比 headless Chromium，h5i 大约快 3 倍，峰值内存约少 86%。

这组数据来自 aarch64 WSL2 环境、每项七次运行的中位数，并使用本地文件页面。它衡量的是冷启动，不代表长期驻留吞吐量；软件渲染、复杂 CSS 和大量 JavaScript 都可能缩小速度差距。最后一行甚至显示：面对脚本构建的页面时，h5i 的耗时高于 headless_shell，只是内存仍明显较低。

官方的驻留循环测试也更细腻：小型页面快照中 Chromium 更快，大型快照和点击延迟则由 h5i 占优。更准确的结论不是“h5i 永远更快”，而是它在 Agent 常见的文档读取和重复交互中提供了不同的资源曲线。

它还不能替代 Chromium

h5i 官方并没有把项目包装成 Chrome 的完全替代品。目前它最适合内容站点、文档、常见表单和标准交互。遇到依赖复杂前端框架或浏览器平台能力的应用，就要谨慎评估。

• 官方设计文档给出的核心 Web Platform Tests 通过率约为 75.7%。
• 生产级 React 应用仍未被列为完整通过场景。
• iframe、Worker、第二浏览上下文、媒体管线、WebGL 和视频界面等能力尚不完整。
• 复杂 CSS 或大量客户端 JavaScript 可能导致布局差异或性能退化。

因此，现实策略不是强行二选一。常规文档任务可以先走 h5i；遇到不兼容页面，再把 Chromium 放进 h5i 管理的沙箱里执行。

沙箱的不只是浏览器，也可以是整个 Agent

h5i 的另一个重点是执行隔离。它可以限制进程、文件系统、网络、资源和凭据，并提供从工作区隔离、受监督进程、无 root 容器到 microVM 的不同层级。

这一区分很重要：直接运行在宿主机上的 h5i，并不会自动拥有最强隔离。官方最严格的安全主张对应的是 box 模式。登录流程可以交给人类接管，命名凭据也可以在不把明文交给模型的情况下提供给任务。

h5i、Playwright 与 Puppeteer 怎么选？

结语

h5i 最有价值的地方，不只是“用 Rust 写了一个更小的浏览器”。它提出了一个更根本的问题：当浏览器的操作者变成 AI Agent 时，我们是否仍然需要完整复制面向人类的浏览器？

结构化快照、稳定元素引用、请求前策略、审计日志和沙箱隔离，都是从 Agent 工作方式出发重新组合浏览器能力。h5i 目前仍有明显的 Web 兼容性缺口，但它已经展示了一条有吸引力的路线：对于大量不需要完整 Chromium 的任务，浏览器可以更轻、更透明，也更容易被约束。

项目地址：github.com/h5i-dev/h5i（Apache 2.0）

原文作者：Hideaki Takahashi。阅读英文原文。本文为中文整理与扩展版本，性能与安全信息已根据 h5i 官方当前文档更新。