对比 / Comparison
对比其他方案
浏览器自动化 / AI 浏览器方案很多。这一页把传统框架、agent 浏览器、云端和消费级产品放在一起诚实对比。 数据能实测的就实测；结论随每一轮实测更新。
一句话
chrome-use 驱动你现有的真 Chrome：你的 profile、扩展、登录都在，不用装新浏览器。
它是给 AI agent 用的原生 CLI，无障碍树快照 + 紧凑 @ref，能跑 shell 的 agent 都能用，自带隐身反检测。
别的方案要么另开一个浏览器，要么要你换浏览器；chrome-use 用你手上这个。
全景矩阵
横轴是对 AI agent 最要紧的几个维度，纵轴是有代表性的方案。绿=在该维度更强。
| 方案 | 形态 | 装什么 | 用谁的登录 | 接口 | 隐身 | 开源 |
|---|---|---|---|---|---|---|
| chrome-use | 扩展 + CLI 驱动你现有的 Chrome | 零（用你已有的 Chrome） | 你真 Chrome 的登录 | shell 命令（任意 agent） | 核心能力 | 是 |
| ego-lite | 自建 Chromium 浏览器 | 装一个新浏览器 | Space 继承登录 | 页面内 JS 运行时 | 非重点 | MIT |
| browser-relay | 扩展 + 本地 relay 驱动你现有的 Chrome | npm 全局 + 加载解压扩展（开发者模式） | 你真 Chrome 的登录 | CLI / MCP / HTTP | 非重点 | MIT |
| browser-use | Python 框架（底层 CDP，cdp-use） | 框架 + 受控浏览器 | 默认另开，需重登 | Python API | 非重点 | MIT |
| Playwright / MCP | 自动化框架（+ agent MCP） | 框架 + 一个受控浏览器 | 全新 context，无登录 | JS/Py/.NET/Java（MCP） | 易被检测 | Apache-2.0 |
| Puppeteer / Selenium | 经典自动化框架 | 框架 + 一个受控浏览器 | 全新 profile，无登录 | JS / 多语言 | 易被检测 | Apache-2.0 |
| Browserbase / Stagehand | 云端 headless 浏览器（+ AI 动作） | 云服务（付费） | 云端会话，需自己带登录 | SDK / API | 反检测（付费） | SaaS / 部分开源 |
| 消费级 agent 浏览器 (ChatGPT Atlas · Comet) |
厂商自己的浏览器 / 内置 agent | 换浏览器 | 你在该浏览器里的登录 | 自然语言（无 API） | 非重点 | 闭源 |
按类型选
🌐 驱动你的真浏览器
chrome-use · ego-lite · browser-relay
用你已登录的会话，不必重新登录。chrome-use 和 browser-relay 都用你现有的 Chrome（扩展 + relay）；ego-lite 让你换成它的浏览器（结构性隔离）。chrome-use 与 browser-relay 的逐项对比见下。
🧰 自动化框架
Playwright · Puppeteer · Selenium · browser-use · Stagehand
另开一个受控浏览器来驱动。成熟、跨语言，但登录搬不干净、默认易被反爬识别，需要自己拼 LLM 循环。
☁️ 云端浏览器
Browserbase · Steel · Hyperbrowser
浏览器跑在云上，适合无状态大规模抓取。要按量付费，登录态要自己注入，本机的真实会话用不上。
💬 消费级 agent 浏览器
ChatGPT Atlas · Perplexity Comet · Gemini-in-Chrome
厂商把 agent 内建进浏览器，面向终端用户、对话驱动，没有给开发者的可编程 API，也不做隐身。
怎么选
| 你的情况 | 选 |
|---|---|
| 要用你已登录的真账号、不想装新浏览器、要过反爬 | chrome-use |
| 愿意换一个专为 agent 做的新浏览器、要最干净的隔离 | ego-lite |
| 也要用真登录的 Chrome，但需要从另一台机器远程驱动 | browser-relay（跨机远程） |
| 写传统自动化脚本、跨语言、CI 里跑 | Playwright / Puppeteer |
| 无状态大规模云抓取 | Browserbase / Steel |
| 只是终端用户想让浏览器帮点忙 | ChatGPT Atlas / Comet |
最接近的对手：chrome-use vs ego-lite（实测深挖）
ego-lite 的定位和我们最像（都用真登录、不抢用户标签），README 还直接点名 agent-browser。 我们两边各跑同一任务，实测性能和 token，核对它"更快、更省 token"的说法：一个半真，一个恰好相反。
Token（喂给大模型的观察，真正花钱的地方）
| 页面 | chrome-use snapshot -i | ego snapshotText | 谁更省 |
|---|---|---|---|
| example.com | 102 字节 | 438 字节 | 省 ~4.3× |
| Hacker News | 12.6 KB | 46.7 KB | 省 ~3.7× |
| GitHub 仓库页 （两边都登录态） | 26.6 KB | 112 KB | 省 ~4.2× |
两边在同一时刻、同一登录态、各自默认设置下实测（2026-07 复现）：example.com / HN 登出态，GitHub 两边登录同一账号。旧数字（456 / 33.6K 等）来自旧版本或登录态错配，已替换为独立复现值。
snapshot -i 只列交互元素，比 ego 默认的全结构树 省 ~3.7–4.3×（同登录态独立复现）。token 才是 agent 花钱的地方，更省的是我们。
性能（墙钟时间）
| 场景 | chrome-use | ego |
|---|---|---|
| 导航 / 单次快照 | ≈ 持平 | ≈ 持平（受页面加载 + CDP 限制） |
| 6 微操作 · 每条一个 CLI 进程 | 1.00s（0.17s/op 启动开销） | — |
6 微操作 · chrome-use batch | 0.19s | — |
| 6 微操作 · ego 常驻运行时 | — | ≈0.00s |
原始浏览器操作两边一样快。ego 赢在常驻运行时，省掉每条命令的进程启动；chrome-use 默认「一命令一进程」，每条约 0.15–0.17s。
微操作密集的任务里 ego 更快（"快 3 倍"多半来自这类任务）。典型任务（open+快照+抽取）实测两边都 ~3s；chrome-use 用 batch（一个进程复用常驻守护进程）6 操作 0.19s 追平，另有 WebSocket 流做实时驱动。
他们官网的宣传语 vs 我们的证据
取自 lite.ego.app 的原文（英文照录），逐条给证据。方法见页末 workflow，可复现。
| ego 官网原文 | 我们的证据 | 结论 |
|---|---|---|
| "3.45x faster" · "Fastest browser for AI agents" | HN 抽取任务两边都 ~3s；6 微操作：chrome-use 各自进程 1.00s，batch 0.19s，ego 常驻运行时 ≈0s。 |
半真：只在微操作密集时成立（常驻运行时省进程启动）；典型任务持平，batch/流即可追平。 |
| "Same automation, fewer tokens" | 同页默认快照体量（同登录态独立复现）：chrome-use snapshot -i 102 B / 12.6K / 26.6K vs ego snapshotText 438 B / 46.7K / 112K。 |
反了：默认工作流下我们省 ~3.7–4.3×。 |
| "not a JS shim on stock Chrome … reach into cross-origin iframes, shadow DOM, third-party SDK widgets like Stripe, Salesforce, Intercom, React portals … JS shims usually give up … burning tokens for nothing" | chrome-use 走 CDP（非 JS shim）。reCAPTCHA demo 实测：frames 列出全部 5 个跨域 frame；eval --frame 1 读到勾选框 role=checkbox「I'm not a robot」。默认 snapshot -i 此前没把它并进顶层，现已修复（#92 已合并 presentation-role / AX-stripped 跨域 iframe）。 |
已追平：我们不是 JS shim、能触达 OOPIF/SDK widget，默认快照现在也把它们并入了（#92 已修）。ego 说的是通用 JS shim 的毛病，套不到我们头上。 |
| "your AI agents will never get stuck on captchas, 2FA, and SSO redirects"（因为你登录态用它） | chrome-use 也驱动你真实已登录的 Chrome → SSO/2FA 天然已完成。验证码两边都需人工，我们有 session handoff 兜底。 |
持平：同样的登录态优势（我们直接用你现有的 Chrome）。 |
| "Zero cost, zero config (yes, free)" | chrome-use 也免费开源，一条 curl … | sh 装好 + 一次扩展安装。 |
持平：都免费；它要你下一个新浏览器，我们用你现有的。 |
| 交接 / 接管 UI（用户可随时从 agent 手里接管 Space） | chrome-use 已实现 session handoff / resume / status / list。（注：ego 该功能确有，但未见 "Take over/Stop" 逐字标签，故不作原文引用。） |
持平，已对齐。 |
| "installs as a skill in every agent（Claude Code / Codex / Cursor / Kiro / Hermes / OpenClaw）" | chrome-use 是原生 CLI/skill，任何能跑 shell 的 agent 都能用（Claude Code / Cursor / Codex / Continue / Windsurf…）。 | 持平。 |
反超的一项：单次成型脚本（chrome-use script）
ego 的核心卖点是 “code base, not CLI base”：写一段 JS 把整个任务一次跑完。这一项我们已 ship 并反超：
chrome-use script 同样写一段 JS（ego 原样 idiom），用 cu.snapshot/eval/click/fill/find/waitFor/extract
直接驱动，带控制流，一次往返返回结构化结果；JSON op-list 形式亦可（可 dry-run、可机器生成）。
反超点在引擎位置：JS 引擎跑在守护进程里、不在页面里，扛得住硬跳转， 而多页翻页正是 ego 赢、页面内运行时输的地方。实测 HN 翻 3 页收集 ≥100 分故事 = 一次 tool call（旧 per-verb 要 13+）， 跑在你已登录的真 Chrome + 隐身传输，跨平台（ego 仅 macOS）。 用法与两种写法详见 单次成型脚本。
我们从 ego-lite 学到 & 已搬的
逐项试用对比后，把真缺口用 chrome-use 原生的方式搬过来（进度在 issue #89）：
- 所有权 + 交接（已实现）：
session handoff/resume/status/list，交接给用户后 agent 对该会话的驱动命令全被拒绝。这是逃生口，留给 agent 真做不了的一步（比如解不了的验证码）；不改变自主登录，默认 agent 自己登录、自己驱动，零影响。 - 富文本 write-probe 纪律（已搬）：见 Canvas / WebGL 页末。
- 登录继承 / 隔离上下文 / 按名复用 / token 经济（已具备）：relay 天然带登录、每会话标签组隔离、
session list、--session-name、更省 token。 - 定位（locating）（持平）：
@ref（backendNodeId 跨调用稳定）+ CSS + XPath + 坐标 + 语义find role button --name+box几何 +-s作用域，对齐 ego 的loc=/@N。 - 群组（groups）（持平）：每个
--session一个彩色 Chrome 标签组、group-scoped 隔离（#40）、多 agent 互不串、只拥有自己建的标签。等价 ego 的 Task Space，只是发生在你的真 Chrome 里，不用换浏览器。
另一个近亲：browser-relay
browser-relay（@linsoai/browser-relay，MIT）架构上和我们几乎是同一个思路：
扩展 + 本地 relay 驱动你真实已登录的 Chrome，走 chrome.debugger / CDP，本地绑 127.0.0.1，
提供 CLI + MCP + HTTP，快照带交互元素标注，不开新浏览器、不用一次性 profile。核心理念持平。差异在这几处：
| 维度 | browser-relay | chrome-use |
|---|---|---|
| 跨机远程 | Remote Relay：浏览器往外连公共/自建（Cloudflare）relay，Device ID 鉴权，从另一台机器驱动 | 纯本地（127.0.0.1 relay + WebSocket 流） |
| 安装 | npm 全局 + 开发者模式加载解压扩展（不走商店，不自动更新） | 一条 curl … | sh + Web Store 一键「添加至 Chrome」 |
| 调试横幅 | 会显示；靠 10 分钟空闲自动解绑缓解，或用 --silent-debugger-extension-api 启动（削弱所有 debugger 扩展的安全防护） | 只 attach agent 自己的标签，你的标签永不弹横幅，无安全折衷 |
| 隐身 / 反检测 | 非重点 | 核心能力：CreepJS 0% bot、--humanize 过行为检测、--launch 原生覆盖 |
| 多 agent | 按 --tab id 定位，无会话隔离模型 | 每 --session 一个彩色标签组，多 agent 互不串 |
| 复杂多步 | 逐条 verb + eval + stdin | 单次成型脚本：值总线 + 循环 + 断言，一次往返 |
| 定位 | CSS 选择器 + 快照标注 | AX 树 @ref（backendNodeId 稳定）+ 语义 find role/name + --heal |
| 运行时 | Node（npm 包 + launchd/systemd 服务） | 单一 Rust 二进制，无需 Node，macOS/Linux/Windows |
为什么这里没有性能 / token 实测表（不像上面 ego 那节）：两者是同一个机制——扩展 → relay → CDP 驱动同一个真 Chrome，
原始浏览器操作两边必然一样快（都受页面加载 + CDP 限制），性能不构成差异，唯一能差的只有 CLI 启动开销（我们 Rust 二进制 vs 它 Node 起进程）和我们的
batch/script。token 上，我们默认 snapshot -i 是交互树（AX，只列可交互元素）、它是整页标注文本，按 ego 的经验多半我们更省——但要拿确切字节数得把它的
chrome.debugger 扩展装进你的真 Chrome，而同一个标签只能有一个 debugger 客户端，会和 chrome-use 直接冲突。本页纪律是能测才写数字，测不了就不硬写，所以这里只做定性对照。
对比 workflow
这一页是活文档。每评估一个方案，走同一套流程，保证对比诚实、可复现：
- 试用：同一个真实任务，两边各跑一遍，记录命令、结果、耗时、token。
- 对比：判断「已有」「持平」还是「真缺口」；持平就如实标注，不硬搬。
- 搬：真缺口用 chrome-use 原生方式实现（守住护城河），回填 issue #89 并更新本页。