Agent Browser、Browser Use 与 Computer Use 关系梳理

本文先区分它们所处的层次，再分别说明浏览器自动化、桌面 Computer Use 和 Codex 接入方式。重点是回答：它们来自哪里、谁启动谁、实例如何管理、能观察和控制什么，以及最终怎样把状态交给 LLM。

一、先建立整体地图

这些名称不是同一层的产品：

LLM / Agent
    ↓ 规划下一步
编排层：Codex、Browser Use Agent、其他 Coding Agent
    ↓ 调用 CLI、MCP、API 或 JS runtime
接入层：agent-browser、Chrome DevTools MCP、cua_repl、Computer Tool
    ↓ 观察和执行
控制层：CDP、DOM/AX、Playwright、Cua Driver、Sky runtime、Appium
    ↓
浏览器、原生应用、桌面、虚拟机或云端电脑

先记住几个判断：

• Agent Browser（AB） 是开源的浏览器控制 CLI/daemon，重点是统一操作本地或远程浏览器。
• Chrome DevTools MCP 是 ChromeDevTools 团队维护的浏览器调试 MCP Server，重点是 CDP、DOM、Console、Network 和 Performance，不是通用桌面 CU。
• Browser Use（BU） 既指开源 Python 网页 Agent，也指 Browser Use Cloud；在 AB 中的 browseruse 通常指云浏览器 Provider。
• Computer Use（CU） 是一类能力，不是单个项目：它可以用截图、Accessibility、坐标、脚本或多个通道操作桌面。
• Codex Computer Use 是 OpenAI/Codex 产品的本地 CU 集成，底层 Sky runtime/service 目前不是公开开源实现。
• unified-computer-use 和 cua_repl 是 Codex 的插件和 REPL 接入约定，不是跨产品标准，也不等于 trycua/cua。
• trycua/cua 是独立的开源 Computer Use 平台，可以提供桌面和浏览器控制，但当前没有证据表明 Codex CU 基于它。

来源与归属

二、浏览器自动化路线

浏览器自动化通常有更可靠的结构化信息：DOM、ARIA、Accessibility Tree、CDP、Console 和 Network。它不必每一步都依赖截图，因此与通用桌面 CU 不同。

2.1 Agent Browser（AB）

它是什么

AB 通常由两部分组成：

1. Rust CLI：提供 open、snapshot、click、fill、screenshot 等命令。
2. Rust daemon：保持浏览器连接，通过 CDP 管理页面、Tab、Cookie 和会话。

AB 不负责任务规划。Agent 或上层模型决定下一步，AB 负责把命令转成浏览器操作并返回结果。

Provider 如何分层

Provider 共用 AB 的命令表面，但不代表底层能力完全一致。云 Provider 通常返回远程 CDP 地址，iOS Provider 则走 Appium。

AB 如何管理多实例

AB 的基本实例单位是 session：

CLI 调用
  └─ --session / AGENT_BROWSER_SESSION
       └─ session daemon
            └─ provider backend
                 └─ Chrome、云浏览器或 iOS WebDriver

普通启动时，一个 session 通常对应一个 daemon、一个浏览器实例和一套独立状态：Cookie、Storage、历史记录、Tab 和认证信息。daemon 通过按 session 区分的 socket、PID 等运行时文件通信。

agent-browser --session site-a -p browserbase open https://site-a.com
agent-browser --session site-b -p browseruse open https://site-b.com
agent-browser session list
agent-browser --session site-a session info --json

AB 有“当前 session”的概念，但不是由 AB 全局维护的前台实例指针：

• 每次 CLI 调用通过 --session 或 AGENT_BROWSER_SESSION 选择目标。
• 未指定时使用 default，多个 Agent 共用 default 会互相操作页面。
• agent-browser session 显示当前命令解析出的 session。
• session list 扫描全部活动 daemon，并用箭头标出本次调用的 session；箭头不是所有 Agent 共享的全局状态。
• 推荐每个 Agent 使用稳定的命名 session，例如 session id --scope worktree --prefix <task>。

Provider 是 session daemon 的启动配置，而不是全局实例池。实践上应把“一个 session 固定一个后端”作为规则；需要并行使用不同 Provider 时，使用不同 session。不要在同一个存活 session 上依赖临时切换 -p 完成隔离，必要时先关闭旧 session。

有一个重要例外：使用 --cdp 或 --auto-connect 时，多个 session 可以连接同一个已经运行的 Chrome。这时只隔离 daemon 和 Tab 选择，不隔离 Cookie、Storage 或浏览器进程；并行使用应加 --pin-tab，避免多个 session 操作共享的活动 Tab。

--namespace 进一步隔离 daemon socket 和 restore-state 目录，适合多个 Agent 使用相同 session 名。close 关闭指定 session，close --all 关闭本机发现的 session daemon；云端资源是否完全回收，还取决于 Provider 的关闭实现。

AB 的观察和输出

AB 优先使用结构化网页信息：

DOM / ARIA / Accessibility Tree
            ↓
AB 生成 snapshot 和 @eN 引用
            ↓
Agent 选择 @eN
            ↓
AB 通过 CDP 执行动作

典型输出类似：

- heading "Example Domain" [ref=e1]
- link "More information..." [ref=e2]

机器可读结果大致是：

{
  "success": true,
  "data": {
    "snapshot": "- button \\"Submit\\" [ref=e3]",
    "refs": {
      "e3": { "role": "button", "name": "Submit" }
    }
  }
}

截图是额外的视觉观察，不是每次动作的唯一输入。Canvas、WebGL、复杂图表和视觉遮挡场景才更依赖截图或坐标。

AB 的边界

• 主要是浏览器控制，不是通用原生桌面自动化。
• Accessibility Tree 可能缺失、过时或和像素位置不一致。
• Provider 之间的登录态、延迟、反爬、截图质量和清理行为不同。
• AB 提供控制能力，不保证 Agent 能正确规划长任务。

2.2 Chrome DevTools MCP

Chrome DevTools MCP 是 ChromeDevTools 团队维护的公开 MCP Server，用于把 Chrome DevTools 能力提供给 AI Agent。它本身不负责任务规划，也不是通用桌面 Computer Use：

Agent
    ↓
Chrome DevTools MCP
    ↓ Chrome DevTools Protocol（CDP）
Chrome / Chromium
    ↓
页面、Console、Network、Performance 和调试数据

它通常由 MCP 客户端以 stdio 方式启动，也提供独立 CLI。第一次调用时可以自动启动后台 MCP Server 和 Chrome；后续调用复用同一后台实例，保留页面和浏览器状态。也可以使用 --browser-url 或 CDP endpoint 连接已经运行的 Chrome。

它的能力集中在 Chrome DevTools：

• DOM/页面快照和元素交互。
• Console、Network、Performance trace 和截图。
• 脚本执行、页面诊断，以及部分 Lighthouse 类分析。
• CSS matched styles 和页面布局调试。
• Heap snapshot、对象引用和内存诊断。
• Chrome 扩展、PWA、WebMCP 和第三方 DevTools 工具等 Chrome 专属能力。

它的元素定位主要来自页面 Accessibility Tree 快照和元素 uid，底层走 CDP，不使用 macOS Accessibility API。输出通常是页面快照、结构化调试数据、Console/Network 记录、性能 trace 或截图。

Chrome DevTools MCP 可以执行网页内 JavaScript、点击、输入、拖拽和截图，但只能控制 Chrome 页面，不能直接控制 Finder、Terminal、原生 App 或整个桌面。它的专业优势是“读取和分析浏览器内部状态”，而不是跨应用自动化。

如果连接已有 Chrome 的远程调试端口，该端口会让本机其他进程具备控制浏览器的能力，应使用独立 Profile，避免暴露敏感登录态。

AB 与 Chrome DevTools MCP 的能力交集

两者的共同底层都是 Chrome/Chromium + CDP，所以在“操作网页”这一层有很大的交集；但工具命名、实例模型和返回字段不同，引用不能互换：AB 使用 @eN，Chrome DevTools MCP 使用 pageId + uid。

可以把交集压缩成一句话：两者都能“看页面、找元素、做交互、执行 JS、截图、看 Console 和部分网络信息”；AB 更像浏览器控制操作系统，Chrome DevTools MCP 更像把 DevTools 面板能力工具化。

它们可以连接同一个 Chrome，但不应混用引用或同时无约束地操作同一 Tab：AB 的 @e3 不是 DevTools MCP 的 uid，一个工具导航或刷新页面后，另一套引用也可能失效。

2.3 Browser Use（BU）

Browser Use 容易混淆，因为它同时表示两个东西：

1. 开源 Python 框架：包含 Agent、浏览器会话、LLM 适配和网页动作循环。
2. Browser Use Cloud：托管浏览器基础设施，向 AB 等客户端提供远程会话。

AB 的 -p browseruse 选择的是 Browser Use Cloud，AB 仍负责 open、snapshot、click 等命令；浏览器进程和会话在 Browser Use 云端运行。开源 Python 框架则自己管理 Agent Loop、LLM 调用、页面观察和动作执行。

BU 的优势是网页任务规划、多步流程和网页语义抽取；边界是它仍然主要面向网页，不负责系统权限、Finder、Terminal 或跨原生 App 的桌面操作。

三、Computer Use 路线

3.1 CU 是能力类别，不是统一协议

Computer Use 的基本循环是：

获取界面状态
    ↓
LLM/VLM 判断下一步
    ↓
生成语义动作、脚本或坐标动作
    ↓
控制器执行
    ↓
重新获取状态

底层可以使用 Playwright、PyAutoGUI、Appium、macOS Accessibility、Windows UI Automation、Linux AT-SPI、CDP 或纯坐标输入。因此“Computer Use”本身没有统一的 Provider、进程模型或输出 schema。

3.2 OpenAI API 的两种集成思路

OpenAI API 文档中的 Computer Use 与 Codex Desktop 的 CU runtime 不能直接画等号。API 主要提供两种宿主集成方式：

代码执行

模型调用普通代码工具，宿主在持久浏览器或桌面环境中运行 Playwright、PyAutoGUI 等脚本，脚本返回文本和截图。一次调用可以组合多个动作、条件和恢复逻辑，但沙盒、会话、超时和权限由宿主负责。

Computer Tool 结构化动作

模型返回类似下面的动作：

{
  "type": "computer_call",
  "actions": [
    { "type": "click", "x": 405, "y": 157, "button": "left" },
    { "type": "type", "text": "penguin" }
  ]
}

宿主执行后返回截图或其他观察结果。这个接口偏视觉和坐标动作，但不等于所有 OpenAI 产品内部都使用相同的实现。

3.3 macOS：API 和视觉通常混合

macOS 桌面自动化至少有两类观察方式：

成熟的桌面 CU 通常采用：

AX 树负责“哪个语义元素”
截图负责“视觉确认”
坐标负责 Canvas/WebGL/AX 缺失界面

Accessibility 权限解决语义读取和 UI 操作，Screen Recording 权限解决图像捕获；这些权限不是自动提供的安全审批边界。

3.4 trycua/cua

trycua/cua 是独立的 MIT 开源项目，包含 Cua Driver、云桌面、VM、macOS 控制和评测组件。其 macOS Driver 可把 AX/PX（像素）观察与元素索引、坐标动作组合起来。

它适合原生桌面和浏览器控制，但仍受 AX 树质量、系统权限、应用兼容性和后台动作支持范围限制。

本机曾运行 /Applications/CuaDriver.app，其 socket 是 ~/Library/Caches/cua-driver/cua-driver.sock，bundle identifier 为 com.trycua.driver。当前 Codex 配置没有连接这个 socket，因此 Cua Driver 与 Codex CU 是独立 runtime。

四、Codex 的 Computer Use

4.1 它在整体架构中的位置

Codex CU 是 Codex 产品中的本地 Computer Use 集成，不应直接等同于 OpenAI API 的 computer tool，也不应直接等同于 trycua/cua。

官方产品文档把它描述成可安装的 Computer-use MCP server + skill。macOS 通过 Screen Recording 查看应用，通过 Accessibility 点击、输入和导航；如果应用已经有专用插件、浏览器扩展或结构化 MCP，官方建议优先使用结构化集成。

当前公开 Codex 源码能确认两组入口：

computer-use@openai-bundled
    → node_repl

unified-computer-use@openai-bundled
    → cua_repl

unified-computer-use 是插件、skill 和生命周期路由；cua_repl 是它使用的 Server 名称和 JS REPL 入口。真正的桌面 runtime 不在公开 Codex 仓库中。

4.2 两条实现路线

公开安装路径和故障报告拼出了两条相关但不完全相同的路线：

Codex Desktop
    ↓ 读取 bundled plugin 的 .mcp.json / launcher

┌─ computer-use 路线 ──────────────────────────────┐
│ SkyComputerUseClient mcp → SkyComputerUseService │
└──────────────────────────────────────────────────┘

┌─ unified-computer-use 路线 ──────────────────────┐
│ node_repl / cua_repl → JS runtime → @oai/sky     │
│                                  └→ Sky backend  │
└──────────────────────────────────────────────────┘

                         ↓ 原生系统控制和权限边界
                 macOS 应用、窗口、鼠标、键盘、截图

能确认或高度可信的部分：

• SkyComputerUseClient mcp 是 Codex 与本地 CU runtime 之间的 MCP 边界，公开配置中通过 SkyComputerUseClient mcp 启动，并使用 stdio MCP。
• SkyComputerUseService 是更底层的原生服务，负责系统 UI 控制；它和 Client 是不同进程，完整 IPC 协议没有公开。
• computer-use@openai-bundled 更接近直接提供 list_apps、get_app_state、点击和输入等 Computer Use MCP 工具。
• unified-computer-use 按 browser、computer 或两者启用 surface；包含 computer 时注册 @oai/sky 的 trusted RPC，典型调用包括 sky.list_apps()、sky.list_windows() 和窗口状态查询。
• Windows 侧公开线索显示 native helper 可以通过 SKY_CUA_NATIVE_PIPE_DIRECTORY 和命名管道通信，说明不同系统可能使用不同 native transport。

4.3 node_repl 与 cua_repl 的语义和运行时

两者都以 MCP 工具承载 JavaScript 执行，但不是公开的通用 CUA 协议：

• node_repl 是 Codex 注入能力后的持久化 Node.js 上下文；Computer Use 通过 @oai/sky、nodeRepl 配置和 native pipe 等扩展连接原生服务。
• cua_repl 是面向 Computer Use 的统一 JS 入口，通过 cua 对象和 browser/computer surface 选择具体能力；运行时由 launcher、trusted service 和相应的浏览器或桌面 backend 组装。
• 模型通常看到的是 JS 返回值经过 MCP 包装后的文本、结构化状态或图片，不是固定的截图格式；完整对象和 IPC schema 未公开。

因此，普通 Node REPL 或 MCP Server 只能复刻外层调用形式，不能透明替代 Codex 的 CU runtime。node_repl 更像扩展底座，cua_repl 更像其上的 CUA 会话封装。

4.4 SkyComputerUseService 是否开源

目前应视为 OpenAI 的闭源 runtime：

• 公开 Codex 仓库没有它的源码、独立 SDK 或协议规范。
• 用户拿到的是随 Codex/ChatGPT Desktop 分发的已签名二进制。
• 公开可见的是插件 glue code、启动路径、进程日志和故障报告，不是 Service 的实现本身。

因此更准确的关系是：

Codex 开源编排代码
        +
OpenAI 闭源 Sky Computer Use runtime

4.5 Codex CU 是纯视觉吗

不能把它描述成纯视觉方案：

• 官方文档区分了专用插件/结构化集成和视觉 Computer Use。
• Chrome 扩展、Excel add-in 等属于应用级结构化控制。
• macOS Accessibility 权限说明底层存在系统级 UI 控制边界，但官方没有公开 unified-computer-use 是否直接使用 Apple AX API。
• 当前 Codex 测试存在 multimodal 和 text fallback 路径，说明状态可能包含图片，也可能退化为文本。
• cua.getState()、AX Tree 是否直接暴露、截图何时附带，以及 get_app_state 的完整 schema 都没有公开定义。

更准确的概括是：Codex CU 是结构化应用集成、桌面状态和视觉反馈的混合系统；具体使用 AX、截图、浏览器扩展还是内部驱动，由 runtime/provider 决定。

4.6 给 Agent/LLM 的输出

需要区分三层格式：

1. Codex → runtime：node_repl/cua_repl 的 JS 调用，例如 await cua.getState()；这是私有 host-side 契约。
2. runtime → Codex：MCP tool result，可能包含文本状态、结构化状态和图片。
3. Codex → 模型：Codex 按模型能力把结果整理成文本或多模态上下文。

公开调试样例显示，模型可见状态更像“应用/窗口状态 + 可定位语义元素（例如 element_index）+ 必要时截图”，而不是只有截图。完整 JSON schema 仍未公开，不能直接说它等于 AB 的 snapshot + refs，也不能说它等于 OpenAI API 的 computer_call + computer_screenshot。

4.7 Codex CU 的边界

• 它是 Codex 产品集成，不是可以独立安装的通用开源 CU driver。
• cua_repl 是 Codex 私有接入约定，普通 MCP Server 不能透明替代它。
• macOS 需要 Accessibility/Screen Recording 权限，并受应用访问和敏感操作审批影响。
• AX 树不完整时可能退化到截图和坐标；Canvas、游戏、远程桌面尤其困难。
• Windows 的前台桌面限制通常比 macOS 更明显。
• Codex 负责 Agent 编排，runtime 负责界面执行，两者的故障和能力边界不能混为一谈。

五、统一比较：观察、动作和边界

因此没有一个统一的“CU 输出格式”：常见形态是网页结构化状态、桌面混合状态，或截图加坐标动作。

5.1 本地浏览器的选型

对本地 Chrome/Chromium，AB、Chrome DevTools MCP 和 BU 的底层控制都主要落到 CDP；差别在于 CDP 之上的封装，而不是各自拥有完全不同的浏览器控制能力。

• AB：CDP + session/profile 管理 + Agent 友好的 snapshot/refs 和 CLI，偏稳定操作与多实例。
• Chrome DevTools MCP：更接近直接暴露 DevTools/CDP，偏 Console、Network、Performance、Trace 和页面调试。
• BU 本地模式：CDP/Playwright + 页面状态抽取 + 高层 action + Agent Loop，偏让 LLM 自主完成多步网页任务。

BU Cloud 只是额外提供远程浏览器、隔离实例、代理、云端 profile 和并发托管；本地使用 BU 不需要 Cloud。若已有自己的 Agent 编排，本地 CDP 通常已经足够。

日常主力 Chrome 也可以打开 chrome://inspect/#remote-debugging，允许当前浏览器实例的远程调试，再由 AB、Chrome DevTools MCP 或 BU 通过 CDP 连接；这时它们可以操作当前 Chrome 的窗口和标签页。远程调试端口会授予本机程序较高的浏览器控制权限，不应在处理敏感页面时长期开放。

如果不希望自动化直接影响日常会话，则应启动独立浏览器和独立 profile。AB 还支持把日常 Chrome profile 复制成临时快照来复用登录状态，原 profile 不被修改。

对开发者，建议以 AB 作为日常浏览器执行层，以 Chrome DevTools MCP 作为调试层，按需使用 BU 的高层网页 Agent；如果已有 Codex 或自建 Agent Loop，直接使用本地 CDP 也可以。不要把正在使用的日常 Chrome 作为默认自动化目标。

参考链接

主要项目和官方文档

• Agent Browser GitHub README
• Agent Browser Provider 配置
• Agent Browser Sessions
• Agent Browser session-management.md
• Browser Use 开源项目
• Browser Use Provider for AB
• ChromeDevTools MCP GitHub 仓库
• Chrome DevTools MCP 官方介绍
• OpenAI Computer Use 产品文档
• OpenAI API：Computer Use
• OpenAI API：Computer Use 集成方式
• trycua/cua GitHub 仓库

输出和 macOS 细节

• AB：snapshot 与 Provider
• Chrome DevTools MCP：工具参考
• Chrome DevTools MCP：连接已有 Chrome/CDP
• Cua Driver：Capture and Delivery Modalities
• Cua Driver：macOS MCP tools
• Cua Driver：AX/PX 调用契约
• Cua：macOS window internals

Codex 源码和公开线索

• Codex：bundled hooks
• Codex：MCP Server 特殊命名空间判断
• Codex：Computer Use 生命周期测试
• Codex：MCP 客户端实现目录
• Codex #25813：bundled Computer Use plugin 和 SkyComputerUseClient
• Codex #35448：.mcp.json、per-user runtime 和 launcher
• Codex #43498：unified-computer-use、surface、@oai/sky 和 cua_node
• Codex #25139：SkyComputerUseClient 的 stdio MCP 初始化
• Codex #24433：SkyComputerUseService 和应用状态工具
• Codex #29157：SkyComputerUseClient/Service 生命周期
• Codex #25507：Windows native pipe 和 SKY_CUA_NATIVE_PIPE_DIRECTORY