Codex 控制浏览器为什么有快有慢：Browser、Playwright 与 Computer Use 的区别

最近我同时观察两个 Codex 任务操作网页，体验差别非常明显：一个任务可以直接打开页面、找到按钮、等待跳转并读取结果；另一个任务却要不停切换 Chrome 窗口、聚焦 DevTools、确认页签，再像真人一样点击和滚动。

这并不是某个任务“权限更高”，也不代表 Codex 忽然换了一套能力。真正的原因是它们使用了不同的浏览器控制层：Browser 运行时负责连接浏览器，标签页级 Playwright 直接操作网页内部，Computer Use 则操作整个可见的电脑界面。

理解这三层之后，就能解释为什么有些网页验收非常顺滑，有些场景却必须慢慢切窗口。

Browser 运行时是浏览器连接层

Browser 运行时可以理解为 Codex 与浏览器之间的桥。它负责选择可用的浏览器、创建或认领标签页、维持连接，并把某个标签页交给后续操作。

它本身不是 Chrome，也不是 Playwright。根据任务需要，它可能连接 Codex 管理的浏览器，也可能连接带扩展的真实 Chrome。代码里如果使用“根据网址选择浏览器”的方式，得到的也不一定是用户眼前那个 Chrome 窗口。

连接成功后，任务通常会获得两个层级的对象：

• 浏览器对象：管理受控标签页。
• 标签页对象：负责跳转、读取页面、点击和截图。

因此，“Browser 已经连接”只说明桥搭好了，不等于网页 DOM、截图或调试器能力已经正常。真正验收前，还要证明同一个标签页可以读取页面结构并取得有效画面。

标签页级 Playwright 是直接操作网页内部

标签页级 Playwright 使用的是网页结构和语义，不是屏幕像素。它可以直接寻找“登录”按钮、搜索框或某个链接，然后点击并等待页面变化。

一个简化后的操作大概是这样：

await tab.goto("http://127.0.0.1:3333/login");

const loginButton = tab.playwright.getByRole("button", {
  name: "登录"
});

await loginButton.click();
await tab.playwright.waitForURL("**/dashboard");

这里没有“把鼠标移动到 x=820、y=460”。它寻找的是语义为按钮、名称为“登录”的元素。只要页面语义没有改变，按钮上下移动几十像素通常不会影响操作。

这类标签页接口通常还能完成：

• 获取 DOM 快照，确认页面结构和文本。
• 使用角色、名称、标签或属性定位元素。
• 点击、输入、等待元素出现或消失。
• 等待 URL、页面加载状态或异步结果。
• 读取网页控制台中的 warning 和 error。
• 截取当前视口或指定页面状态。

这也是它看起来更快的原因：任务不需要不断识别整张屏幕，也不用反复把正确窗口切到最前面。关于语义定位的基本思路，可以参考 Playwright 官方定位器文档。

Computer Use 操作的是整个可见电脑界面

Computer Use 更接近真人坐在电脑前操作。它读取应用的无障碍树和当前截图，然后点击元素或坐标、输入文字、按快捷键、滚动页面。

它能处理标签页级 Playwright 无法触及的区域，例如：

• Chrome 地址栏、页签栏和浏览器菜单。
• DevTools 面板和设备预览。
• 扩展弹窗、文件选择器和系统对话框。
• 多个 Chrome 窗口之间的切换。
• 页面调试连接失效，但可见界面仍能正常操作的情况。

代价也很明显。窗口焦点、页面缩放、遮挡、白屏首帧和多个同名窗口都会影响判断。每次动作后还需要重新读取当前界面，不能长期复用旧的元素索引。

所以 Computer Use 看起来步骤多，并不是它“比较笨”，而是它工作的层级更靠外：Playwright 直接进入网页内部，Computer Use 则从电脑屏幕这一层完成真实操作。

真实 Chrome 连接是中间一层

除了管理浏览器和 Computer Use，还可能使用 Chrome 扩展连接用户正在运行的真实 Chrome。它的优势是可以复用现有登录状态、Cookie、扩展和已打开页签，同时又有机会获得 DOM、截图和标签页级控制。

但扩展能够列出页签标题和 URL，并不代表页面调试器已经附着成功。常见情况是：

• 可以看到页签列表；
• 可以读到当前网址；
• 一旦读取 DOM、设置视口或截图就超时；
• 页面接口提示调试器未附着。

这时不能把“看到了页签名称”当作网页验收通过。如果真实 Chrome 的页面级控制连续失败，而任务又必须操作这个现成窗口，才适合退回 Computer Use。

为什么同一个 Codex 任务看起来完全不同

控制方式通常由几个条件共同决定。

是否必须复用现有 Chrome

本地开发页、公开网站和不依赖登录的页面，通常适合使用管理浏览器和标签页级 Playwright。涉及现有登录、浏览器扩展或用户指定页签时，则更适合明确连接真实 Chrome。

操作目标是在网页内还是网页外

点击网页按钮、填写表单和验证跳转属于网页内部操作。调整 DevTools 设备视口、切换 Chrome 窗口或操作扩展弹窗属于网页外部操作，只能交给 Computer Use 或其他系统界面能力。

页面调试连接是否正常

Playwright 依赖稳定的页面控制通道。调试器没有附着、标签页绑定已经失效或页面接口连续超时后，继续调用 DOM 定位器并不会自动恢复。

是否存在多个窗口和焦点竞争

Computer Use 必须知道当前最前面的是哪个窗口。用户同时打开项目后台、参考站、Coin 页面和其他 Chrome 时，任务要在每次点击前重新核对标题与网址，因此会多出大量“切换、确认、再读取”的动作。

哪种方式更适合不同任务

普通本地页面和公开网站

优先使用 Browser 运行时与标签页级 Playwright。它读取 DOM 更便宜，定位更稳定，也容易自动验证 URL、文本、控制台和表单状态。

必须复用登录和扩展的页面

优先明确连接真实 Chrome，再确认页面 DOM、视口和截图能力是否都正常。只有标题和 URL 可读还不够。

DevTools、浏览器菜单和系统弹窗

使用 Computer Use。它虽然慢一些，但能操作网页边界之外的真实界面。

页面控制已经失效但画面可见

可以在授权范围内用 Computer Use 做有限恢复或可见交互，不过不能借它绕过浏览器证书警告、系统权限和安全策略。

常见的三个误解

更快不等于权限更高

标签页级 Playwright 快，是因为它直接操作 DOM，省去了图像识别和窗口切换。它不能因此操作系统设置、Chrome 菜单或其他应用。

Computer Use 不是 Playwright 的全面替代品

Computer Use 可以点到更多界面，但对重复表格、复杂表单和精确状态判断，DOM 语义通常更可靠。能用页面接口完成的动作，没有必要全部退化为坐标点击。

截图不等于完成验收

截图只能证明一个可见瞬间。完整的页面验收还需要确认网址、视口、缩放、主题、交互状态和页面结构。截图如果来自另一个管理浏览器，也不能冒充用户指定 Chrome 的证据。

更稳定的实际工作顺序

我现在更倾向于按下面的顺序使用这些能力：

1. 先判断任务是否必须复用用户现有 Chrome。
2. 只控制一个浏览器实例，并锁定当前目标标签页。
3. 能用 DOM 和语义定位时，优先使用标签页级 Playwright。
4. 每个关键操作后验证 URL、页面状态或控制台结果。
5. 只在需要视觉证明时保存关键截图，并先检查截图不是白屏、加载中或错误窗口。
6. 页面接口确实无法完成、操作目标位于网页外部时，再切换到 Computer Use。
7. 同一外部状态连续失败后停止重试，先处理调试器、窗口或锁屏状态。

这套顺序不是为了限制浏览器操作，而是让每一层只做自己最擅长的事：Browser 运行时负责连接，Playwright 负责网页语义和交互，真实 Chrome 负责复用用户状态，Computer Use 负责可见界面与网页之外的区域。

最后的判断

当 Codex 看起来“没有移动鼠标就把页面验完了”，通常是标签页级 Playwright 在直接操作 DOM；当它不停切窗口、返回 DevTools、确认地址栏时，通常是 Computer Use 在操作真实电脑界面。

两者没有绝对的高低之分。对普通页面，Playwright 更快、更稳定；对 DevTools、扩展和真实窗口，Computer Use 覆盖范围更广。真正高效的做法不是固定只用一种，而是在任务开始时选对控制层，并在页面级控制失效时有边界地降级。