agent-browser Daemon 基准测试：Node.js 守护进程与 Rust 原生守护进程的全面对比

agent-browser Daemon 基准测试Node.js 守护进程与 Rust 原生守护进程的全面对比【免费下载链接】agent-browserBrowser automation CLI for AI agents项目地址: https://gitcode.com/GitHub_Trending/agen/agent-browseragent-browser 是面向 AI Agent 的浏览器自动化 CLI。为了量化其守护进程架构的两种实现——已发布的 npm 版Node.js daemon与从源码编译的Rust native daemon——仓库提供了benchmarks/目录下的一套端到端基准测试体系在 Vercel Sandbox 微虚拟机中运行真实命令、采集命令延迟与系统指标并用表格输出对比结果。读完本文你将掌握该基准测试的完整原理、八大场景的构建方式、全部 CLI 参数与结果解读方法并能基于 benchmarks/bench.ts 与 benchmarks/scenarios.ts 理解守护进程 vs Chrome在延迟与资源占用上的真实分工。一、基准测试要回答的问题agent-browser 采用守护进程daemon架构CLI 每次调用并不直接启动浏览器而是通过环境变量指定的会话session连接到一个常驻的agent-browser进程由它统一管理 Chrome。该架构的直接收益是 AI Agent 反复执行snapshot、click、fill等命令时无需反复冷启动浏览器。历史上这个守护进程用 Node.js 实现随 npm 包发布后续仓库引入了纯 Rust 的原生实现见 cli/src/native/daemon.rs。基准测试的目的就是用同一套场景、同一个沙箱环境公平比较两种实现命令延迟每次命令从发起到完成的往返耗时冷启动守护进程拉起 浏览器启动的总时间资源占用守护进程自身与浏览器进程的 RSS 内存、CPU 时间、进程数分发体积二进制大小与包含浏览器下载的完整分发体积。需要强调的是这套基准不是压测浏览器而是衡量守护进程作为 CLI 与 Chrome 之间薄中继层的开销。正如 benchmarks/README.md 明确指出的命令延迟主要由 ChromeCDP 往返主导两个守护进程都只是薄中继因此逐命令的提速通常很小Rust 原生实现的真正优势集中在冷启动、守护进程内存与分发体积上。二、测量什么场景矩阵与系统指标2.1 八大命令场景benchmarks/scenarios.ts 定义了Scenario接口与八个场景。每个场景包含name、description、可选的setup/teardown各执行一次、不计时和核心的commands数组按 N 次迭代计时。场景说明计时的命令序列navigate页面加载往返open about:blanksnapshot可访问性树生成snapshotscreenshot视口截图screenshotevaluateJavaScript 执行eval读取标题与列表项数量click元素交互click #linkfill表单输入fill #name Benchmark Useragent-loop典型 AI Agent 循环snapshot→click #link→snapshotfull-workflow真实 7 命令工作流open→eval(注入表单) →snapshot→click→fill→eval→screenshot其中agent-loop复现了 AI Agent 最常见的读屏 → 点击 → 读屏循环是最能代表实际使用的场景full-workflow则串联了导航、注入表单、快照、点击、填写、取值、截图七个步骤模拟一次完整的自动化任务。被测页由INJECT_FORM_SCRIPT通过document.open(); document.write(...)动态注入包含文本框、邮箱框、下拉框、复选框、文本域、按钮、可点击链接和一个 20 项的列表覆盖了快照、点击、填写与取值所需的各种 DOM 元素。2.2 系统指标在守护进程运行期间benchmarks/bench.ts 的collectDaemonMetrics通过pgrep/ps//proc/pid/status采集以下指标冷启动时间首次执行open about:blank的耗时守护进程拉起 浏览器启动二进制大小通过stat -L跟随符号链接得到的真实可执行文件大小分发体积Node 模式为 npm 全局包 ~/.cache/ms-playwright中的 Playwright 浏览器Rust 模式为二进制 Chrome for Testing依次探测~/.cache/agent-browser、~/.cache/ms-playwright、~/.agent-browser/chrome守护进程 RSS 与峰值 RSS通过ps的rss列和/proc/pid/status的VmHWM获取并与浏览器进程内存分离统计浏览器 RSSChrome 相关进程按comm匹配chrome|chromium的内存两个守护进程连接的是同一个 Chrome因此该项应基本一致守护进程 CPU 时间将ps输出的cputimeHH:MM:SS或MM:SS格式解析为秒并求和进程数量守护进程进程数与浏览器子进程数。进程识别上有一个值得注意的实现细节由于会话/守护标志通过环境变量而非命令行参数传递无法用ps的args直接 grepbenchmarks/bench.ts 采用pgrep -x agent-browser精确匹配进程名再通过pgrep -P递归收集全部后代进程从而把守护进程树与 Chrome 子进程树完整地区分开。三、环境准备与安装3.1 前置条件Node.js 18pnpmVercel Sandbox 凭证token、team ID、project ID3.2 初始化cd benchmarks pnpm install cp .env.example .env在.env中填入 Vercel Sandbox 凭证对应 benchmarks/.env.exampleSANDBOX_VERCEL_TOKENyour_token SANDBOX_VERCEL_TEAM_IDyour_team_id SANDBOX_VERCEL_PROJECT_IDyour_project_id这三个环境变量是硬性要求若缺失bench.ts会在启动时直接报错并退出Missing credentials...。凭证解析逻辑位于 benchmarks/bench.ts支持#注释、KEYVALUE与带引号的值。依赖只有两个vercel/sandbox沙箱客户端与tsx直接运行 TypeScript见 benchmarks/package.json。四、运行方式全部 CLI 参数入口命令为pnpm bench即tsx bench.ts。所有参数需放在--之后pnpm bench # 10 次迭代1 次预热8 vCPU pnpm bench -- --iterations 20 # 更多迭代以获得更紧凑的统计 pnpm bench -- --warmup 2 # 额外预热迭代 pnpm bench -- --json # 写入 results.json pnpm bench -- --branch main # 用不同分支构建原生版本 pnpm bench -- --vcpus 16 # 更多 vCPU加快 Rust 编译参数解析位于 benchmarks/bench.ts默认值与作用如下参数默认值说明--iterations10每个场景的计时迭代次数--warmup1计时前的预热轮数不计入统计--jsonfalse将完整结果写入results.json--branchctate/native-2构建 Rust 原生守护进程所用的 Git 分支--vcpus8沙箱 vCPU 数越高 Rust 编译越快每个场景在计时前会先执行warmup轮预热命令再按iterations轮计时每轮将场景内所有命令的耗时求和作为一个样本。统计计算位于computeStatsbenchmarks/bench.ts对样本排序后计算平均值四舍五入到毫秒、标准差、最小值、最大值与 p50。五、基准测试的执行流程main()benchmarks/bench.ts按以下顺序执行完整流程创建沙箱Sandbox.create使用凭证创建 Vercel Sandbox 微虚拟机运行时为node22网络策略allow-allvCPU 取--vcpus配置超时 30 分钟安装 Chromium 系统依赖通过dnf安装 nss、gtk3、cairo、mesa 等一整套 Chromium 运行库完整清单见 benchmarks/bench.ts 的CHROMIUM_SYSTEM_DEPS常量随后执行ldconfigPhase 1 — Node.js 守护进程npm install -g agent-browser安装最后一个带 Node 守护进程的 npm 版本再执行npx agent-browser install完成浏览器安装运行全部场景并采集指标Phase 2 — Rust 原生守护进程dnf安装 gcc、openssl-devel 等构建工具通过 rustup 安装 Rust 工具链git clone --depth 1 --branch branch克隆仓库进入cli/执行cargo build --release然后用sudo cp将编译产物覆盖替换全局agent-browser可执行文件运行同一套场景并采集指标输出对比打印命令延迟表与系统指标表若指定--json则把包含时间戳、分支、vCPU、迭代次数、两套场景统计与指标的结构化结果写入results.json收尾无论成败在finally中调用sandbox.stop()停止沙箱。每个模式node/native运行命令时都会注入AGENT_BROWSER_SESSIONbench-mode环境变量见 benchmarks/bench.ts这保证了两个守护进程使用独立的会话不会互相干扰。这与源码中的会话机制一致AGENT_BROWSER_SESSION是守护进程会话的默认命名环境变量在 cli/src/flags.rs 中被读取cli/src/connection.rs 在拉起守护进程时会注入AGENT_BROWSER_DAEMON1与AGENT_BROWSER_SESSION。基准脚本中的命令行open、snapshot、click、fill、eval、screenshot、close都能在 cli/src/commands.rs 找到对应的命令分发分支。六、结果解读如何区分真实差异与噪声6.1 命令延迟差异通常很小printResultsbenchmarks/bench.ts输出两张表格。第一张是命令延迟表列为场景名、Node 平均值±标准差、Rust 平均值±标准差与 Speedup 倍率。README 给出的核心结论是命令延迟主要由 ChromeCDP 往返主导而非守护进程。两个守护进程都是 CLI 与 Chrome 之间的薄中继因此逐命令的提速通常很小。stddev 列有助于区分真实差异与噪声。也就是说如果某个场景的 Node 与 Rust 差异在 1 个标准差以内应当视为噪声而非结论。只有agent-loop、full-workflow这类多命令场景薄中继层的细微差异才可能累积出可观察的差距。6.2 系统指标原生守护进程的主场第二张是系统指标表包含冷启动、二进制大小、分发体积、守护进程 RSS、守护进程峰值 RSS、浏览器 RSS、守护进程 CPU 时间、守护进程进程数、浏览器进程数九项每项给出 Node 值、Rust 值与 Ratio 倍率。README 明确指出原生守护进程的优势集中在这三处冷启动无需启动 Node.js 运行时守护进程内存单个 Rust 二进制 vs V8 堆分发体积无 Playwright 依赖。其中守护进程 RSS 是最公平的苹果对苹果比较两个守护进程连接的是同一个 Chrome浏览器内存开销完全相同但 Node.js 大约额外占用~140 MB 的 V8 堆而 Rust 守护进程仅约~7 MB。而分发体积的差异来自组成Node 版本 npm 包 Playwright 内置 ChromiumRust 版本 单个二进制 Chrome for Testing。ratio计算方式为 Node 值 ÷ Rust 值如2.00x表示 Rust 是 Node 的一半当 Rust 值为 0 或缺失时显示--场景失败时对应列显示FAILED且 Speedup 为--。七、扩展与注意事项分支构建默认--branch ctate/native-2是仓库中携带 Rust 原生守护进程的分支切换到main或任意含cli/的分支即可对比不同版本编译产物来自cli/target/release/agent-browser。构建耗时Rust 首次全量cargo build --release较慢--vcpus 16或更高可以显著缩短构建时间完整构建流程见installNativeDaemonbenchmarks/bench.ts。进程统计兜底若pgrep -x agent-browser找不到守护进程例如命令名不精确匹配脚本会先回退到pgrep -f agent-browser再回退到按ps -eo pid,comm过滤agent-browser|chrome的宽泛匹配benchmarks/bench.ts。冷启动定义coldStartMs计时的是首次open about:blank从发起到返回的完整时间即守护进程生成daemon spawn与浏览器启动之和而非单纯的二进制启动时间。结果持久化加--json后results.json会同时包含两套守护进程每个场景的avgMs/stddevMs/minMs/maxMs/p50Ms/samples失败场景带error与全部系统指标便于后续脚本化分析与版本间对比。八、从基准回到架构为什么 daemon 是关键理解这套基准需要回到 agent-browser 的架构本质CLI 与 Chrome 之间的通信经由常驻守护进程转发CDP 协议。cli/src/native/daemon.rs 的run_daemon展示了原生守护进程的实现要点——在 Unix 上通过 Unix domain socketsession.sock监听写入session.pid与session.version文件AGENT_BROWSER_DEBUG开启时把 stderr 重定向到session.log便于排查否则重定向到/dev/null以避免父进程退出后管道破裂导致守护进程崩溃。基准测试里 Node 与 Rust 两种守护进程跑着完全相同的命令与页面正是因为这套架构下命令延迟几乎被 Chrome 占满真正拉开差距的只有守护进程自身带来的运行时成本与分发成本。这也是该基准最有价值的一点它用可复现的实验把架构差异导致的真实收益从浏览器本身的延迟噪声中剥离出来为 Agent 场景下的部署形态选择提供了直接依据。若需复现或扩展直接基于 benchmarks/bench.ts 与 benchmarks/scenarios.ts 修改场景或参数即可。【免费下载链接】agent-browserBrowser automation CLI for AI agents项目地址: https://gitcode.com/GitHub_Trending/agen/agent-browser创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考