Computer Use 怎么用：从 Codex 界面验证到 LCU 接入
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
Computer Use 让 AI 能观察软件界面，再点击、输入并检查结果。对开发者，它能补上“代码改完了，实际页面是否可用”这一段验证。下面给出 Codex 的启用方法、一次真实桌面操作，以及 LCU 接入其他 Agent 的路径。
我的判断是：先用它验证范围明确的界面流程，再把稳定、关键的路径沉淀成自动化测试。 一次操作成功，证明的是这次实际走过的路径，不是整个产品都正确。
Computer Use 是什么：把操作和验收放进同一个闭环
Computer Use 是一种图形界面操作能力。模型通过工具获得窗口、截图或界面元素信息，选择动作，执行后再观察状态，判断是否达到目标。
它不同于只根据截图给建议。截图分析停在“告诉你应该点哪里”，Computer Use 还能执行动作并读取后续状态。它也不等同于模型 API 本身：实际控制电脑还需要执行工具、运行环境及相应权限。
传统开发流程中，AI 可以修改表单校验代码、运行单元测试，却仍需要人打开页面检查焦点、错误提示和跳转。两类验证面对的是不同问题：函数返回正确，不代表用户能看见错误，也不代表弹窗没有挡住提交按钮。
Computer Use 的作用是让 Agent 直接走到用户操作这一层。它适合观察和复现界面问题；遇到重复的数据处理，专用接口通常更容易验收。
上图是教学简化。它说明动作后必须重新观察，不表示每个产品都使用相同截图算法，也没有展开审批和运行时生命周期。
理解这套机制，关键是区分三件事：模型选择动作，工具执行动作，实际状态证明结果。 工具没有报错，只能说明调用被接受；只有读取新状态，才能判断目标有没有实现。OpenAI 的使用说明也把图形界面的检查与操作作为这项能力的主要用途。Computer Use，OpenAI
什么时候用它：先看问题发生在哪一层
当你要检查的是界面行为，Computer Use 才有直接价值。我的选择标准是：最终答案能否从文件、接口响应或测试输出中得到？如果能，先用这些更直接的证据；如果不能，再操作界面。
任务 | 优先路径 | 验收依据 |
修改代码、构建、运行测试 | 终端和代码工具 | 差异、构建日志、断言 |
查询记录、批量修改配置 | API、MCP 或专用集成 | 请求结果、变更记录 |
检查本地 Web 页面的表单和布局 | 内置浏览器 | 实际页面状态、截图 |
复现桌面应用或模拟器里的问题 | Computer Use | 同一路径操作前后的状态 |
没有接口的后台操作 | 范围明确的界面任务 | 保存结果和目标数据 |
MCP 是连接工具的一种协议，Computer Use 是工具提供的能力。两者不在同一层：一个 MCP 服务可以提供数据库查询，也可以承载电脑操作。安装一个 MCP 服务，不意味着所有应用都自动获得控制授权。
对 Web 开发，最值得交付的不是一张“页面打开了”的截图，而是具体的验收项：空输入时出现错误、错误后能恢复、有效输入时进入目标页面。对 iOS 或桌面应用，也应写明目标窗口、测试数据和成功状态。
这些是工程上的验收建议，不是我已经测过某个注册项目。当前素材没有业务应用的测试记录，不能据此宣称它已经修复了注册或支付流程。
在 Codex 中启用：系统权限和应用批准要分别检查
官方桌面入口的最小路径，是启用 Computer Use 插件，再允许它观察和操作指定应用。功能是否出现还取决于地区和当前环境，下面以 macOS 为例。
- 在 ChatGPT 桌面应用中进入 Work 或 Codex。
- 打开
Plugins → Computer Use，按提示安装或启用插件，并打开 server 和 skill 开关。
- 在
Settings → Computer use查看应用访问配置。
- 按 macOS 提示授予屏幕录制和辅助功能权限。
- 指定一个无敏感数据的窗口，完成首次观察、操作和结果核对。
屏幕录制使工具能够看到目标界面，辅助功能使工具能够点击、输入和导航。它们解决的是操作系统层面的访问；ChatGPT 中的应用批准解决的是“这次允许使用哪个应用”。这两层需要分别确认。设置和权限说明，OpenAI
这张配置截图显示辅助功能已经完成。它不能单独证明屏幕录制和目标应用批准也已完成，更不能证明业务流程已经可用。
遇到系统提示，应检查申请主体和需要访问的内容。首次验收可选计算器或空白文档，避免让“功能能不能用”的检查混入账号、订单或真实发布操作。
系统设置截图只保留相关应用一行，其他应用的权限状态与本文判断无关。开关打开是必要配置证据，实际窗口是否能读取仍要通过一次工具调用确认。
一次最小实测：从计算器按钮到可核对的结果
我在当前 macOS 环境中，用官方 Computer Use 工具完成了计算器的
2 + 3 操作。界面状态返回 5，截图也显示同一结果。我先尝试创建内置浏览器标签页，工具返回
Browser is not available: iab。这说明当前会话没有这条浏览器通路，不能因为文档提到内置浏览器，就假定每个环境都能直接创建它。我随后把首次验收缩小到原生计算器：确认窗口和按钮，清除旧输入，再输入表达式，读取新状态。这次改变的是验证入口，目标仍是检查“观察、动作、结果”三步能否闭合。
以下是本次会话实际执行的代码。它运行在 Computer Use 提供的 JavaScript 环境里，不是复制到普通 Node.js 终端就能执行的脚本。
当时返回的无障碍树中，编号
8 是“全部清除”。确认这一点后，下一次调用执行：返回状态中，“上个表达式”变为
2 + 3，编辑字段变为 5。再调用 getScreenshot()，得到下面的真实窗口截图。
这里有两个可复用的判断。确定性的输入可以放在同一次调用里；涉及分支判断时，要先观察新状态。元素编号也不是持久标识，不能把这里的
8 当成所有计算器窗口的通用编号。这次验证只覆盖窗口读取、键盘操作、结果读取和截图。我没有通过它测量速度提升，也没有验证 LCU、Chrome 登录态或复杂跨应用流程。 把结果写到这个范围内，读者才知道哪些结论能复现。
LCU 接入：复用原版运行时，让其他 Agent 调用
LCU 是一个第三方开源项目，让 Claude Code、Codex CLI、Pi 等 Agent 工具调用 OpenAI 原版的 Computer Use 能力。
它的工作关系是：
LCU 的核心是接入和适配。它复用本机官方 ChatGPT 桌面应用提供的 Computer Use 运行时，并把能力接到其他 Agent 宿主中；它不是重新训练了一个模型，也不是自行重写截图和鼠标控制引擎。
项目的适配器文档说明，原版运行时仍负责指令、执行和权限请求；适配层负责工具注册、结果转发与生命周期衔接。模型侧主要看到
js 和 js_reset，宿主还需要处理回合结束等内部生命周期调用。LCU 适配器说明js 让模型通过带有 cua 对象的 JavaScript 环境操作电脑，js_reset 用于重置会话中的 JavaScript 状态。前面计算器例子展示了这类接口的使用方式，但那次执行走的是当前官方工具，不能当作 LCU 安装成功的证据。LCU 为什么值得关注？当开发工作在 Claude Code 或其他 Agent 中进行时，开发者希望继续在原来的任务上下文里检查界面，减少手动切换工具的成本。LCU 提供的是这条连接路径；是否更快、更省 token，需要在自己的任务上测量，不能从“工具更少”直接推导出来。
根据当前项目文档，Pi、Codex CLI 和 Claude Code 有对应适配；Oh My Pi、Hermes 属于实验性接入。LCU 的平台边界也不能与官方桌面入口混用：官方入口支持的系统，不代表 LCU 都支持。LCU 项目说明
下面给出 Apple Silicon Mac + Claude Code 的最小接入路径。前提是官方 ChatGPT 桌面应用和可用的 Claude Code 已经安装。当前 LCU 使用桌面应用内的 Node 运行时，不再要求额外安装 Python；不要求 ChatGPT 登录，也不等于 Agent 宿主无需自己的认证。LCU 安装说明
插件按项目安装流程配置 LCU。完成提示后重启 Claude Code，再从本机桌面终端执行：
接着把下面的任务交给 Agent：
安装完成不等于验收通过。期望看到的是诊断结果，以及实际窗口中的表达式与
5。只有注册信息，没有一次批准后的桌面操作，仍不能证明接入可用。这条安装路径依据项目文档列出，本文没有在本机另行安装或执行 LCU。失败怎么排查：按失败层次修复，不扩大权限猜原因
“装了插件还是不能用”没有唯一解法。应先确定失败发生在工具入口、系统权限、应用批准，还是运行时兼容这一层。
具体问题 | 对应处理 | 处理后的边界 |
内置浏览器提示不可用 | 检查当前可用浏览器入口，或先验收原生窗口 | 原生操作成功不证明浏览器通路可用 |
看不到窗口或无法点击 | 分别检查屏幕录制、辅助功能和目标应用批准 | 权限齐全仍需验证具体动作 |
lcu 提示找不到命令 | 使用上文的完整安装路径 | 解决 PATH 问题，不解决运行时兼容 |
Claude 桌面应用里的批准失败 | 按项目要求通过 Claude Code 注册，并检查批准界面支持 | 不能通过自动代答批准来解决 |
ChatGPT 更新后 LCU 调用失败 | 运行诊断并按项目流程更新接入 | 更新后仍要重走首次验收 |
项目当前要求 Apple Silicon macOS，或满足其文档条件的 X11 Linux 桌面；Intel Mac 和原生 Wayland 不在支持范围，Windows 仍处于候选阶段。遇到这些平台限制，应先核对支持条件，而不是反复执行同一条安装命令。平台要求，LCU
Chrome 是另一个需要单独验收的通路。LCU 默认原生桌面操作，Chrome 需要额外启用官方扩展，并处理站点批准。当前 Claude Code 的 Chrome 支持仍有实验性限制，不能用一次原生截图成功替代它的浏览器验收。Chrome 配置，LCU
我不会把自动批准作为日常桌面的默认排障方案。放宽一次工具调用的审批，也不会修复平台不支持、扩展连接失败或运行时不兼容。对有保存、提交、发布动作的任务，更应该把“检查到哪一步”和“允许执行到哪一步”写清楚。
把它用在开发中：交付实际路径和结果，而不是“已检查”
对真实项目，Computer Use 的交付单位应是一条可复述的路径，以及与验收条件对应的观测。下面这段是可直接调整的任务模板，不是本文已经执行过的注册测试。
验收时还要避免两个误判。第一个是只看最终页面：如果错误输入意外创建了记录，最终跳转可能看起来正常，但流程已经失败。第二个是只看截图：界面显示成功，不一定意味着后台状态正确；有结构化接口时，应核对相关记录。
我的建议是把探索与回归分开。让 Computer Use 找出实际界面路径和失败状态，再为关键逻辑添加合适的自动化检查。需要视觉判断的部分保留截图和操作记录，能用确定性断言表达的部分交给测试工具。
选择官方入口还是 LCU，应由你现在的开发环境决定：已经在 Codex 中工作，先用现成入口完成一个小任务；希望在其他 Agent 宿主中延续同一任务，再评估 LCU 的兼容性与批准支持。不要把迁移工具当成获得更高正确率的证据。
参考资料
你在开发中最想交给 Computer Use 的是哪条界面流程？欢迎留言说说应用、操作路径和卡住的步骤，这些具体经验也能帮助其他国内开发者判断工具是否适合自己的项目。
2026.10.09 21:02
沪 · 赵巷
关注沐风，不定期更新，全是干货。