声明：这是看到 GPT-5.4 Computer Use 后产生的一个即兴想法，还没有经过工程验证。
OpenAI 在 computer-use-preview 的模型文档里，把这项能力概括为“理解截图并控制鼠标键盘”；在 Computer use 指南里，又进一步说明模型会“返回由你的代码执行的界面动作”。这两句话合在一起，已经把边界说得很清楚了：模型负责理解界面和决定下一步，本地系统负责真正执行动作、回传截图和维护状态。
它的标准工作流也很明确：
- 在
Responses API中启用computer工具； - 发送任务和当前界面状态；
- 接收模型返回的
computer_call； - 用本地执行器执行这些动作；
- 重新截图，并通过
computer_call_output回传； - 继续循环，直到任务完成。
也就是说，Computer Use 的标准模式本质上就是：
截图 -> 模型判断 -> 返回动作 -> 本地执行 -> 再截图
来源：
这件事对 OpenClaw 的意义很直接。过去，OpenClaw 这类 agent 系统在浏览器里天然更强，因为浏览器提供了 DOM、可访问性树、URL、网络状态，以及 Playwright / MCP 这类成熟工具链。Agent 不是在“看图猜页面”，而是在操作结构化对象。
桌面应用不是这样。很多桌面程序没有统一、稳定、可编程的交互层，自动化往往只能退回到截图理解、坐标点击、窗口聚焦、键盘输入。这让桌面自动化既脆弱又昂贵。
GPT-5.4 的 Computer Use 改变了这一点。它让 OpenClaw 首次真正具备了进入桌面自动化的能力。但它也带来了一个新的工程问题：如果每一步都让 GPT-5.4 读截图、判断页面、生成动作，那么在重复性很强的桌面流程里，成本和延迟都会偏高。
这篇文章讨论的，就是一个针对这个问题的优化方向：把 GPT-5.4 当作高精度兜底模型，用它解决未知页面；同时为 OpenClaw 增加一层本地页面动作缓存，在重复桌面页面上尽可能复用历史动作，从而减少重复视觉推理的 token 消耗。
为什么浏览器自动化更容易，桌面自动化更难
浏览器自动化之所以强，本质上是因为浏览器提供了结构化交互层。Agent 可以依赖：
- DOM 结构
- a11y tree
- 表单标签
- URL
- 页面跳转历史
- 成熟的自动化框架
而桌面自动化很多时候只有这些：
- 当前屏幕长什么样
- 当前窗口在哪
- 某个按钮可能在什么位置
- 某段文字是否出现
这就是为什么浏览器自动化天然更容易“语义化”，而桌面自动化经常只能“视觉化”。
一旦系统完全依赖视觉推理，问题就来了：
- 每一步都要传截图；
- 每一步都要用高能力模型判断当前界面；
- 即使同一个页面反复出现，也会重复支付视觉理解成本；
- 整体延迟和费用都很难压下来。
而企业里的很多桌面流程，恰恰又是高度重复的：
- 登录页
- 参数设置页
- 导入导出弹窗
- 审批确认框
- 收银或录单界面
- 老旧内部业务系统
这类场景的难点并不是“页面太复杂”，而是“页面重复出现得太多”。既然如此，把已经成功走通的页面动作缓存下来，就是一个很自然的优化方向。
把 GPT-5.4 当成兜底模型，而不是每一步都在线推理
我更倾向于把 GPT-5.4 Computer Use 看成一个高精度兜底模型，而不是每一步都在线实时推理的唯一引擎。
系统可以分成两层：
- 上层：GPT-5.4，负责未知页面、复杂页面、异常页面；
- 下层：本地页面识别与动作缓存，负责稳定重复页面。
首次遇到某个页面时，流程仍然完全交给 GPT-5.4：
- 本地截图；
- 发给 GPT-5.4；
- 接收
computer_call； - 在本地执行动作；
- 如果执行成功，记录该页面的状态特征和动作计划。
再次遇到类似页面时，不急着再调用 GPT-5.4，而是先走本地识别：
- 本地截图；
- 提取 OCR 文本；
- 收集窗口标题、分辨率、应用标识、关键词等信息；
- 用低级模型或规则引擎判断当前更像哪个页面；
- 查本地缓存；
- 如果高置信度命中，则直接执行缓存动作；
- 如果未命中，或者执行后校验失败，再回退到 GPT-5.4。
这个思路的重点不是“替代 GPT-5.4”，而是“让 GPT-5.4 只在真正需要时出现”。
如果把这个思路压缩成一条工程链路，它大概会是这样：
首次页面:
截图 -> GPT-5.4 -> computer_call -> 本地执行 -> 成功后写入缓存
重复页面:
截图 -> OCR / 低级模型 -> 缓存匹配 -> 命中则执行缓存动作
-> 未命中则回退 GPT-5.4
缓存的不应该是截图本身，而是页面状态和动作计划
如果只是把整张截图和坐标点击机械地存下来，这个系统会非常脆弱。窗口一移动、分辨率一变、字体一缩放，缓存就可能失效。
所以缓存更合理的对象，不是“图像本身”，而是一个页面状态签名。这个签名至少应该包含：
- 应用标识
- 窗口标题
- 分辨率
- 是否全屏
- OCR 提取出的关键词
computer_call的动作缓存
动作也不应该只存裸坐标。更稳的做法是尽可能往语义动作上靠，例如：
{
"action": "click_text_anchor",
"target_text": "保存",
"fallback": { "type": "click", "x": 1452, "y": 894 }
}
OCR + 低级模型，是这套方案真正的降成本层
这个设想里，OCR 不是为了完全替代视觉理解，而是为了把一部分“看图判断页面”的问题转成“读字判断页面”的问题。
原因很简单：
- 文本比整图便宜；
- 文本更容易做缓存；
- 文本更容易和历史页面做相似度匹配；
- 低级模型更适合做“这是登录页还是设置页”这类轻量分类。
所以一个更合理的流水线是：
截图后先用 OCR 识别出当前窗口文字，把 OCR 结果结合本地缓存的 computer_call 动作交给低级模型分析当前页面最可能对应的动作，只有在识别失败时才调用 GPT-5.4 进行兜底。
换句话说，这是一套典型的分层推理系统：
- 便宜的识别器负责常见页面；
- 昂贵的模型负责新页面和疑难页面。
这套方案为什么只适合“受控桌面”
这个设想成立，但它不是一个无条件成立的方案。相反，它有非常强的环境假设。
我认为最关键的前提有四个：
- 一次只操作一个目标窗口。
- 窗口尽量固定，最好全屏。
- 分辨率、DPI、缩放比例基本不变。
- 应用的页面结构总体稳定。
如果这些前提不成立，缓存很容易退化成“死界面脚本”：
- 窗口挪一下就点偏；
- 换个显示器就失效；
- 更新一个版本后按钮顺序变了；
- 页面里出现动态提示或通知，OCR 就变了；
- 两个页面文字很像，结果误命中缓存。
所以这套方案最适合的第一批场景不是开放式桌面，而是强约束、固定布局、重复度高的桌面流程。
例如：
- 内部办公系统客户端
- POS 或录单软件
- Electron 类固定布局工具
- 传统 Windows 配置程序
一个更稳的执行策略
如果 OpenClaw 真要落这个方向，我不建议把缓存当成“主逻辑”，而应该把它当成“优化层”。执行策略可以很简单：
- 先跑本地规则。
- 规则不命中时，做 OCR 和页面轻量分类。
- 如果缓存高置信度命中，则执行缓存动作。
- 执行后做一次快速校验。
- 校验失败或无法判断时，调用 GPT-5.4。
- GPT-5.4 成功后，更新缓存。
这里最重要的不是缓存本身，而是回退机制必须稳定。因为缓存天然会失效，而 GPT-5.4 的价值正是在缓存失效时兜底。
这套方案最明显的风险
这个想法有价值，但风险也必须说透。
第一，强依赖固定界面。如果动作最终还是以坐标为主，那么窗口移动、缩放、多显示器、主题变化都会让它迅速变脆。
第二，动态页面很难缓存。任何包含异步区域、通知、广告、个性化内容、可变列表的页面，都会让缓存匹配和回放变得不稳定。
第三，OCR 本身会出错。小字号、低对比度、图标按钮、中英文混排、自绘控件，都会降低识别质量。
第四，相似页面误判是高风险问题。两个页面只差一行提示文字，但按钮位置不同，这种情况如果误命中缓存，后果可能是执行错误操作。
第五，这套方案在本质上仍然偏工程优化，而不是通用桌面智能。它解决的是“重复流程成本太高”，不是“桌面自动化已经完全可靠”。
第一阶段原型应当只覆盖最受控的场景
我认为一个现实的第一阶段原型，应该严格限制范围：
- 只支持一个桌面应用；
- 只支持单窗口；
- 要求默认全屏；
- 要求固定分辨率；
- 先只支持少量动作类型；
- 所有不确定情况直接回退到 GPT-5.4；
- 本地缓存先用 JSON 或 SQLite 即可。
这个阶段最重要的不是追求泛化，而是验证一个更具体的问题：
在受控桌面环境里，本地页面动作缓存能不能显著减少 GPT-5.4 的重复视觉调用，同时保持可接受的成功率？
如果这个问题验证不成立，就没有必要继续往更复杂的系统设计上投入。
这篇 proposal 最应该收束到的结论
我不认为这篇文章应该得出“桌面自动化已经被 GPT-5.4 解决了”这种结论。那会过度乐观，也不准确。
更合理的结论应该是：
GPT-5.4 Computer Use 让 OpenClaw 首次真正具备了进入桌面自动化的能力；而在受控、稳定、重复度高的桌面场景里，本地页面动作缓存可能成为降低成本、提升吞吐的有效优化层。
这也是我觉得它值得作为讨论的原因。它不是一个万能方案，但它是一个非常明确、非常工程化、而且可以被快速验证的方向。
