1. Overview and Shared Model

2. opencli

3. web-access

4. agent-browser

5. Detailed Comparison Matrix

6. Decision Flow and Composition

7. Sources

Browser Agent Tools Architecture Comparison

对比对象

opencli
web-access
agent-browser

一句话结论

opencli 是 站点命令产品层。
web-access 是 agent 联网策略层。
agent-browser 是 浏览器自动化 runtime 层。

它们不是简单替代关系，而是位于不同抽象层。

这张图的观察轴

入口形态：用户调用的是现成命令、skill，还是浏览器 runtime
核心抽象：站点适配、策略路由、还是 DOM/AX/ref
状态模型：一次性请求、浏览器代理态、还是强持久会话
最强场景：公开抓取、登录态探索、UI 自动化
主要代价：维护站点适配、依赖本机 Chrome、环境复杂度

共同分层模型

User / Agent intent → Task framing → Tool selection → Browser or HTTP execution → State persistence → Result serialization

三者最大的区别，不是“能不能抓网页”，而是它们分别把复杂度放在哪一层。

opencli：把复杂度放在 网站命令适配
web-access：把复杂度放在 agent 决策与浏览策略
agent-browser：把复杂度放在 本地浏览器控制内核

三者共享的基本原语

页面打开
页面等待
DOM / 内容读取
点击 / 输入 / 滚动
截图 / 证据采集
cookie / storage / 登录态
多步任务串联

但它们对这些原语的封装方式完全不同。

核心 trade-off

抽象越高，上手越快，但可控性越低
抽象越底层，表达力越强，但环境要求越高
站点级产品抽象最适合稳定公开源
浏览器 runtime 最适合交互和登录态
策略 skill 最适合让 agent 自己选择路径

所以这不是单维度“谁更强”，而是 层级职责不同。

opencli 的本体

本质：website -> subcommand 的命令产品。

用户看到的是：

opencli hackernews top
opencli wikipedia summary OpenAI
opencli reddit ...

它把网站能力预先做成一个统一 CLI 面。

重点不是“浏览器怎么控制”，而是“这个网站对外暴露什么命令最顺手”。

opencli 的运行结构

CLI entry → 站点命令树 → 该站点的 provider / adapter → 调用公开 API、抓公开页面，或在必要时接浏览器桥 → 返回结构化文本结果

你测出来的关键现象：

公开接口命令可以立刻工作
内置 daemon 存在，但扩展未连接时浏览器型能力不可用
也就是说它先是“命令产品”，其次才是“浏览器联机层”

opencli 的强项

开箱快，公共数据直接拿结果
子命令面清晰，适合脚本和人工调用
站点结果已经做过整理，输出很像“API 响应”
对不想自己设计浏览策略的人很友好
适合新闻、百科、社区、论文搜索这类公开信息入口

在你的机器上：HN、Wikipedia 都直接跑通。

opencli 的限制

能力边界取决于它有没有内置该站点命令
对未适配站点，通用性不如浏览器 runtime
真正的登录态交互依赖 Browser Bridge 扩展
高度动态、复杂表单、连续 UI 流，不是它最自然的抽象层
维护成本在“很多站点命令要持续跟站点变化”

所以它最像一个“网站操作工具箱”，不是浏览器操作系统。

最佳定位

公开站点信息查询 + 结构化命令输出。如果你的目标是“快速拿到 HN 热门、Wiki 摘要、某公开站搜索结果”，它通常是三个里阻力最小的。

web-access 的本体

本质：一个要求 agent 接管所有联网任务的 skill。

它不是命令产品，而是：

规定 agent 在联网时如何思考
让 agent 在 WebSearch / WebFetch / curl / Jina / CDP 间自己选
提供一个轻量 CDP proxy 作为真实浏览器入口

它卖点是 决策框架，不是命令树。

web-access 的决策流

用户目标 → 先定义成功标准 → 判断静态抓取是否足够 → 不足时升级到真实浏览器 → 必要时处理登录、弹窗、滚动、媒体 → 结束后关闭自己开的 tab

这个 skill 的核心哲学是：

不迷信某一种工具
不在错误方法上重复尝试
像人一样在过程中不断修正路径

web-access 的 CDP 层

通过 scripts/check-deps.mjs 检查 Node 和 Chrome 调试端口
用 scripts/cdp-proxy.mjs 暴露本地 HTTP API
API 是 /new /eval /click /clickAt /setFiles /screenshot /scroll /close
直接连用户日常 Chrome，因此天然携带登录态

也就是说，它的浏览器层很薄，主要职责是： 把 Chrome 变成 agent 可用的远程手和眼。

web-access 的附加能力

按域名积累 site patterns
鼓励并行子 agent 分治调研
强调一手来源核实
允许 DOM 直取媒体 URL、视频 seek + screenshot
明确 GUI 交互和程序化操作各自的 trade-off

这些都属于“agent 工作方法论”，不是底层浏览器内核创新。

web-access 的强项

非常适合 agent 驱动的真实联网任务
动态站、社交平台、登录后页面，比纯 WebFetch 更自然
skill 层把浏览哲学写清楚，能提升 agent 的联网决策质量
用用户自己的 Chrome，很多站天然已经登录

web-access 的限制

它不是一个完整 CLI 产品，更多依赖 agent 执行 skill 约定
对环境有要求：Chrome remote debugging 必须可用
浏览器代理功能有，但状态管理、元素抽象、稳定引用模型不如 agent-browser 深
维护成本在“skill 提示词 + 脚本 + agent 行为一致性”

所以它强在策略，不强在底层 runtime 丰富度。

agent-browser 的本体

本质：一个 Rust 写的本地浏览器自动化 runtime。

核心不是 skill，而是原生二进制 agent-browser：

启浏览器
常驻 daemon
通过 CDP 控制页面
给页面生成 @e1/@e2 refs
维持 session / tab / storage / streaming

这个项目的重点是 浏览器控制内核。

agent-browser 的 daemon 架构

CLI command → 连接 Unix socket / TCP → 若无 daemon 则启动 → daemon 内部持有 DaemonState → BrowserManager 持有 CDP client、页面列表、active tab、下载路径、访问过的 origin → 后续每次命令复用同一会话

重要含义：

浏览器状态跨命令保留
CLI 看起来是一次一条命令，底层其实是长生命周期 runtime
这比临时脚本式 CDP proxy 更接近“浏览器操作系统”

agent-browser 的关键创新：snapshot refs

snapshot -i 读取 accessibility tree
给可交互元素分配 @e1/@e2/...
ref 缓存 backend_node_id + role + name + nth + frame context
后续 click @e7、fill @e9 直接用 ref 解析目标
若 DOM 变化导致节点失效，会按 role/name/nth 再解析

这大幅减少 token 消耗，也减少 selector 脆弱性。

iframe / frame 处理

snapshot 会把 iframe 内容内联到输出里
ref 带 frame context
交互时会自动切到正确 frame session

这点很关键：在很多真实支付、登录、嵌入页面场景里，iframe 是主难点之一。agent-browser 把它做进了底层元素解析流程，而不是把 frame 复杂度丢给上层 agent。

state / auth / persistence

--profile 复用用户浏览器 profile
state save/load 保存 cookie + origin-scoped localStorage + sessionStorage
--session 做多会话隔离
--session-name 做自动保存恢复
支持 auth vault、加密 key、下载目录、代理、headers 等

这已经不是“能不能登录”，而是把登录态作为 runtime 一等能力。

附加 runtime 能力

stream server
network requests / HAR 记录
route interception
screenshot / annotated screenshot
diff snapshot / diff screenshot / diff url
dialog handling
clipboard
PDF
device emulation

所以它不是只会点按钮，而是形成了完整的浏览器观测与控制面。

最佳定位

复杂真实 UI 自动化、稳定多步浏览器操作、登录态会话复用、QA 和测试执行。如果你的任务核心是“操作浏览器本身”，它是三者里底层能力最完整的。

比较方法

下面不是泛泛而谈，而是按真正影响使用体验的维度拆开：

用户入口
最核心抽象
浏览器依赖
状态持久化
站点覆盖方式
最强用例
主要风险
组合关系

你可以把这一块当成“选型基线”。

1. 用户入口

opencli

入口是子命令
用户显式指定网站和动作

web-access

入口是 skill 语义请求
agent 负责决定怎么联网

agent-browser

入口是浏览器动作命令
用户或 agent 显式编排页面交互

结论：

opencli 最像产品
web-access 最像策略插件
agent-browser 最像引擎

2. 核心抽象单位

opencli：站点命令

hackernews top
wikipedia summary

web-access：任务导向策略

搜索、抓取、升级到 CDP、处理站点障碍

agent-browser：页面元素与会话状态

@e1 refs
tab
session
storage
network log

抽象越往右，越接近浏览器底层，也越适合复杂交互。

3. 对浏览器的依赖

opencli

公共命令可不依赖浏览器桥
某些能力依赖 Browser Bridge 扩展

web-access

轻浏览器层，强依赖 Chrome remote debugging
本质是给 agent 一条进 Chrome 的路

agent-browser

浏览器就是产品本体
本地 Chrome / Chrome for Testing / CDP 都是一等依赖

浏览器越居中，说明它越不是“附加功能”，而是主执行面。

4. 状态管理深度

opencli

对公开命令，通常更像无状态调用
浏览器态是附加层

web-access

使用用户现有 Chrome 登录态
但状态管理更多靠浏览器本身，不是 skill 内部强建模

agent-browser

daemon 持续存活
多 session 隔离
state save/load
profile / auth vault / stream / tab list

这一项 agent-browser 明显最深。

5. 覆盖面的来源

opencli：覆盖面来自“支持了多少站点命令”

优点：单站点体验好
缺点：长尾站点要等适配

web-access：覆盖面来自“agent 可把任意网站当任务处理”

优点：长尾站点适配力强
缺点：效果更依赖 agent 判断

agent-browser：覆盖面来自“任何能在浏览器里操作的站点理论上都能处理”

优点：通用性最强
缺点：实现工作量要你自己编排

6. 各自的最强用例

opencli

公共信息抓取
内容站、社区站、百科、榜单、搜索结果
想快速拿结构化结果

web-access

agent 研究类任务
从搜索到网页再到登录态页面的混合流程
需要让 agent 自己切换工具

agent-browser

表单自动化
真实 UI 交互
已登录后台操作
QA / E2E / 截图 / diff / network 证据采集

7. 主要风险和成本

opencli

站点命令漂移
你依赖的是维护者的站点适配质量

web-access

环境配置不通就完全卡住
skill 强依赖 agent 是否真正遵守哲学和流程

agent-browser

环境和能力都最重
需要更明确地编排交互步骤
但一旦建好，长期复用价值最高

换句话说：

左边是“产品维护成本”
中间是“skill 约束成本”
右边是“runtime 工程成本”

Bottom Line

如果你把三者放到同一平面比较，会误判。更准确的看法是：

opencli 解决“我想立刻用命令拿到某站结果”
web-access 解决“我想让 agent 更聪明地联网”
agent-browser 解决“我需要一个稳定、可编排、可持久化的浏览器自动化内核”

任务选型决策流

只是公开信息查询？
- 是 → 先试 opencli
查询过程需要 agent 自己搜索、切换抓取方式、核实来源？
- 是 → web-access
需要登录、点击、填表、下载、看 console/network、复用 session？
- 是 → agent-browser
需要组合？
- 先 opencli 找候选目标
- 再 web-access 做 research routing
- 最后 agent-browser 执行需要浏览器的重步骤