2026 年 8 月底,HN 上集中出现了三个独立项目,目标都是把"AI Agent 用的浏览器"做对:纯 Rust 写的无头浏览器 H5i(作者 syumei),Rust 写的单二进制爬虫 Draco(ccheshirecat),以及 Skyvern(YC S23)开源的 Rustwright——把 Playwright 的 Node driver 直接换成 Rust 写的 in-process
2026 年 8 月底,HN 上集中出现了三个独立项目,目标都是把"AI Agent 用的浏览器"做对:纯 Rust 写的无头浏览器 H5i(作者 syumei),Rust 写的单二进制爬虫 Draco(ccheshirecat),以及 Skyvern(YC S23)开源的 Rustwright——把 Playwright 的 Node driver 直接换成 Rust 写的 in-process CDP 引擎,内存省 70%,启动快 2.55 倍。这三个项目分别踩在不同工程取舍上:H5i 选择完全绕开 Chromium 和 V8,自研一个面向 Agent 的浏览器;Draco 选择大部分情况下不打浏览器,只在需要时升级到 in-process V8 或 fallback 到真浏览器;Rustwright 则选择保留 Chrome,但把驱动层从 Node 换成 Rust。它们加在一起,把"Agent 用浏览器"这件事从"借一个 Chromium"推进到"重新设计 Agent 时代的浏览器栈"。标题里的 5 倍速度 / 80% 内存节省,正是 H5i 在这种取舍下给出的具体数字。把这件事放在一张图里看,可以落几条判断:第一,浏览器正在从"给人看的工具"分裂出"给 Agent 用的栈";第二,瓶颈不在引擎,而在驱动层和内存占用;第三,Agent 时代需要的不是更快的 Chromium,而是更小、更可控、可审计、能精准模拟网络指纹的浏览器。这三条合在一起,构成了 2026 年 8 月这次浏览器栈分化的总背景。
一、H5i:纯 Rust、无 Chromium、无 V8,目标就是 AI Agent
H5i 在 HN 上的多次更新轨迹很清晰:从 "A Pure-Rust, Sandboxed, Local-First Browser for AI Agents: H5i-Browser-Light",到 "I Built a Headless Browser for AI Agents in Rust. No Chromium, No V8",再到 "Pure-Rust Headless Browser: 5× Faster, 80% Less Memory Compared to Chromium"——同一作者在 8 月份连发三帖,核心主张始终一致:不用 Chromium、不用 V8,直接用 Rust 写一个面向 AI Agent 的浏览器,GitHub 仓库在 9 月初已超过 636 stars,2026 年 9 月 11 日还在活跃 commit。它的设计动机从 GitHub 描述里看得很清楚:这是一个"fast, red-teaming browser built for AI agents, with direct HTTP traffic control, sandboxed execution, and auditable sessions. Pure Rust."——重点不是渲染速度,而是给 Agent 三件东西:直接的 HTTP 流量控制、沙盒执行、可审计的会话。这三件事在传统 Chromium 上要么不暴露,要么要装扩展才能勉强拿到,H5i 把它们做成了一等公民。性能数字 5× 和 80% 来自作者在 HN 上对 Chromium 的对比基准。这个数字不是孤立宣传,因为同一时间段 Rustwright 也给出了和 Chromium 相近体量下的对比:内存减 70%,启动快 2.55 倍。两个独立项目的不同基准同时给出相近数量级的改进,说明浏览器栈在 Agent 场景下的瓶颈是真实的,不是个别项目的渲染问题。
二、Draco:大部分情况下不打浏览器,只在需要时升级
Draco(ccheshirecat)给出的另一条路更激进:默认完全不打浏览器。它用的是"分级升级引擎":Tier 1 是 stealth fetch——用自定义的 TLS/JA4 指纹,在包级完美模拟真实浏览器的网络签名。很多反爬虫墙只要 handshake 看着对就放行。在对 Cloudflare、Target 这类网站的测试里,Playwright 要 500MB 内存还会超时,Draco 用 20MB 内存在 1 秒内绕过。Tier 2 是 V8 Isolate——如果碰到 React/Next.js 这种必须渲染的 SPA,Draco 在几毫秒内启动一个 in-process V8 引擎,把 DOM hydrate 起来,截获页面在调的隐藏 JSON API,直接拿到原始数据,不需要图形浏览器。Tier 3 是真浏览器 fallback——如果碰到实在绕不开的墙,无缝 fallback 到本机真实浏览器驱动。这套分级解决了 Agent 时代一个具体痛点:大量"看似要浏览器"的网页其实只要拿数据,真正需要完整浏览器渲染的比例很低。Draco 在 8 个 Cloudflare/Target/Glassdoor/Hacker News 等测试站点上的对比表里跑出 769.7 分(8/8 通过,平均 3.45s,平均 216.50MB 内存),第二名 Obscura 只有 384.5 分(4/8 通过),Playwright 342.2 分(4/8 通过,535.07MB 内存)。
三、Rustwright:不重写浏览器,只重写驱动
Skyvern(Suchintan, YC S23)开源的 Rustwright 走第三条路——不重写浏览器,只重写驱动。它把 Playwright 的 Node driver 替换成 Rust 写的 in-process CDP 引擎,核心改动是:playwright-python 模式下,代码要走 Node driver → CDP → Chrome 这条管道,中间多了一层进程和 pipe 通信。Rustwright 模式下,代码直接 raw CDP → Chrome,绕开了那层中间开销。三条具体收益:第一,内存减 70%,启动快 2.55 倍,因为少了一层抽象;第二,没有 Playwright 的浏览器指纹——传统 Playwright 在很多网站上很明显的 "__playwright__binding__ globals"、Runtime.enable 泄露这些特征,都没了。注意作者明确说这不是"不可检测",只是"不主动泄露 Playwright 签名";第三,迁移成本极低——一行 import 替换:
所有 click/type 事件还是走真 CDP 调用,不是合成的 DOM 调用。复杂场景比如跨域 iframe 也能自动 attach,frame_locator() 跨域路由正常工作。底层用 Tokio(支持 WebSocket 和可选 Unix-pipe 传输),PyO3 提供 Python 绑定、napi-rs 提供 Node 绑定。 这条路的商业理由很直白:Skyvern 自己在跑大量浏览器自动化,性能调优时发现 Playwright 的 Node driver 是浪费内存和 CPU 的元凶。把这条路开源出来,对生态是低成本的性能收益。 ## 四、三条路的工程取舍:为什么不是简单分胜负 把这三条路放在一起,工程取舍很清楚。 H5i 的取舍:接受最大工作量,换一个完全为 Agent 设计的浏览器。优势是控制力——HTTP 流量、sandbox、审计会话都是一等公民。代价是没法直接用 Chromium 的渲染能力,复杂的现代网页可能跑不动。 Draco 的取舍:接受"渲染不全"的代价,把"打不打浏览器"做成运行时决策。优势是绝大多数网页能直接拿数据,内存占用最低。代价是分级逻辑要维护,碰到边界场景时升级路径要可靠。 Rustwright 的取舍:保留 Chromium 的全部能力,只换驱动。优势是兼容性最好,迁移成本几乎为零。代价是 Chromium 本身的内存占用依然存在——减 70% 的 driver 内存不等于减 70% 的总内存。 这三条路不互斥,而是互补:H5i 适合"必须自己控制 HTTP 流量和会话可审计"的 Agent 场景(比如 red-team / 安全研究);Draco 适合"爬取数据"为主的 Agent 场景;Rustwright 适合"已经有 Playwright 脚本、要降内存"的场景。它们的同时出现,本身就说明浏览器栈正在从"一个 Chromium 包打天下"分裂成多层、多种取舍的生态。 ## 五、为什么浏览器要在 2026 年被重新设计 更深一层的问题是:为什么 2026 年 8 月这个时间点会集中出现这类项目?驱动这件事的不是渲染引擎本身够不够,而是 Agent 用浏览器的方式和人类不同。 人类用浏览器:点开页面、看、滚动、点击,最后离开。整个过程是会话式的,人和浏览器之间有自然的反馈回路。 Agent 用浏览器:启动、拿数据、解析、判断、行动。整个过程是任务式的,中间没有人的反馈,而且 Agent 会同时启动很多浏览器实例。每个实例都要占内存、要可被审计、要可被重放。这种用法放大了 Chromium 的几个特定问题:内存过大(每实例 GB 级)、没有直接的 HTTP 控制、缺审计日志、缺可重放机制。 把这三个放大点连起来,就知道 H5i、Draco、Rustwright 不是在解决"渲染慢"的问题,而是在解决"Agent 用浏览器"的工作流问题。H5i 提供 HTTP 流量控制和审计会话,直接对应"可重放"和"可审计";Draco 提供 stealth fetch 和分级升级,直接对应"小内存跑大量实例";Rustwright 提供低内存驱动,直接对应"已有脚本不用改就能降内存"。 ## 六、对企业 Agent 落地的几条具体判断 把这三条独立信息合起来,企业 Agent 落地可以落几条具体判断。 第一,选浏览器栈时,不要问"用不用 Chromium",要问"Agent 怎么用浏览器"。如果 Agent 是做数据采集,Draco 那种分级方案最经济;如果 Agent 做大量 Playwright 脚本,直接换 Rustwright 一行 import 拿 70% 内存节省;如果 Agent 做敏感操作需要审计,H5i 那种自研方向更合适。 第二,内存占用会成为 Agent 规模化的瓶颈。一个 Chromium 实例 1GB,100 个实例就是 100GB;如果用 Rustwright 或 Draco,这个数字可以降到 10-30GB。Agent 跑得越多,内存占用的边际收益越明显。 第三,可审计性会从"加分项"变成"硬要求"。Agent 跑浏览器拿数据,合规、审计、回溯是绕不开的。H5i 直接把"auditable sessions"列为一等公民,说明这条线在 2026 年下半年已经从工程偏好升级成了产品要求。 第四,浏览器栈的多样化是好事。H5i、Draco、Rustwright 的并存意味着不同场景可以选不同栈,而不是所有人挤在同一个 Chromium 上。这意味着 Agent 中台设计时要把浏览器作为可插拔组件,而不是绑死某个单一方案。 第五,留意"绕过 Chromium"的代价。H5i 和 Draco 的方案能省内存,但要付出兼容性代价——某些复杂 SPA、某些反爬虫机制、某些浏览器指纹严格的服务,可能仍然需要真浏览器。企业 Agent 平台设计时,要给"真浏览器 fallback"留位置,不要把赌注全押在"不打浏览器"上。 H5i、Draco、Rustwright 在 2026 年 8 月留下的最重要一条经验:Agent 时代的浏览器栈不是把 Chromium 调快,而是从 HTTP 流量、内存占用、可审计性、driver 层等多条线同时重新设计。这件事的本质是工作流变了——从"人点击"变成"Agent 调用"——浏览器栈要随之重新洗牌。5 倍速度 / 80% 内存节省这些数字,只是这次重新设计的副产品,真正的信号是"浏览器栈正在分裂成多个 Agent 友好的形态"。