Codex 的 Computer Use 很好用，但 Pi 社区把另一套实现开源了
Codex 的 Computer Use 很好用，但 Pi 社区把另一套实现开源了
最近我把电脑里的 Pi Agent 更新到最新，准备研究它新增加的 Computer Use。
结果有点意外：我在 pi-mono 主仓库里没有找到相关代码。
实现这个功能的其实是一个社区扩展：pi-computer-use。截至 2026 年 7 月 14 日，它的最新版本是 v0.4.3，GitHub 上有 1000 多个 Star，采用 MIT 许可证，同时支持 macOS 和 Windows。
这个区别很重要。它不是 Pi 官方塞进核心的新功能，而是一套可以独立安装、完整阅读源码的 Computer Use 实现。
我把扩展仓库也拉到了本地，读了 TypeScript、Swift 和 Rust 三层代码，还在 Windows 上跑了一遍项目自带的检查。我最想弄清楚的不是它会不会点击按钮，而是另一个问题：界面随时会变，Agent 凭什么相信自己没有点错？
先别急着写“开源 Pi 挑战 Codex”
只比较产品体验，这个社区扩展目前赢不了 Codex。
根据 OpenAI 的官方文档，Codex 可以在 macOS 和 Windows 上操作桌面软件、浏览器和系统设置，也能执行跨应用任务。
它的权限管理也更成熟：第一次控制应用时会请求授权，可信应用可以加入 Always allow，敏感操作还可能再次确认。Windows 上会占用当前桌面和前台输入；macOS 则支持后台执行和受限制的 locked use。
如果只想找一个装好就能用的 Computer Use，Codex 仍然是更稳妥的选择。
但 Codex 有一部分我们看不到：这些桌面操作到底是怎么实现的。
OpenAI 开源了 Codex CLI、SDK、App Server 和 Skills，它们都列在官方开源组件清单中。Computer Use 插件没有出现在这份清单里。准确地说，Codex 并非完全闭源，只是这部分桌面控制能力目前没有公开源码。
pi-computer-use 的价值不是立刻替代 Codex，而是把几个关键问题摊开给开发者看：Agent 看到了什么？界面变了怎么办？点击发出后，如何证明任务真的完成了？
这套实现，开源到了原生层
有些开源 Agent 项目只公开工具定义，真正的执行仍然依赖无法检查的云服务。pi-computer-use 没有停在这里。
它的 Pi 扩展和状态管理由 TypeScript 编写，macOS 原生 Helper 使用 Swift，Windows 原生桥使用 Rust。底层接入了系统无障碍接口、窗口截图和 OCR；Chromium 浏览器还可以通过 CDP 工作。这些代码都在同一个仓库里。
从 Agent 拿到 act_ui 工具，到操作系统最终收到点击或键盘事件，中间的主要链路都能读到。
它不是“截图 + 猜坐标”
最简单的 Computer Use 是一个循环：截屏、猜坐标、点击、再截屏。它能做 Demo，却很容易被移动的窗口、突然出现的弹窗和加载中的页面骗到。
pi-computer-use 也使用截图，但截图不是唯一依据。它先寻找窗口，再观察界面、查询控件、执行动作、验证结果，最后保存新的状态。
这里有三个设计值得记住。
第一，先找 UI 树，图片负责补证据
扩展会把桌面窗口、菜单、弹窗和浏览器页面都当成一个 root。观察之后，按钮、文本框、菜单项和滚动区域会得到可引用的身份。
Agent 第一次只拿到折叠后的概要。如果目标不在里面，再查询局部，不必每次把整棵控件树和整张截图都塞进上下文。
系统控件树、窗口截图和 OCR 会组合使用：标准控件优先读取无障碍信息，识别不到的视觉文字再交给 OCR；浏览器页面也可以转换成同一种结构。
这比只看图片稳得多。控件树告诉 Agent“这是什么”，截图和 OCR 补充“它看起来在哪里”。
第二，用 stateId 阻止 Agent 拿旧界面乱点
每次观察界面，系统都会返回一个 stateId，后面的查询和操作必须带着它。
假设状态 A 里的某个按钮是“保存”。随后用户、应用或另一个任务改变了窗口，原来的位置变成“删除”。如果 Agent 还拿着状态 A 操作，坐标和控件引用都已经过期。
这个扩展会为资源维护递增的版本。界面被另一个操作改变后，旧状态发起的写操作会被判定为 stale，并在点击发出前拒绝执行。
它不是提醒模型“最好再看一眼”，而是从机制上让旧状态失去写入资格。对 Computer Use 来说，这比鼠标移动得像不像人更重要。
第三，能按控件操作，就先别碰鼠标；点完还要验结果
点击按钮时，扩展会先尝试操作系统提供的语义能力，例如直接执行“按下按钮”或“设置输入框内容”。只有语义方式不够用时，才退回坐标点击或键盘输入。
语义操作通常不需要移动鼠标，也不容易因为窗口偏了几十像素就点错。它还可以在不抢焦点、不发送原始鼠标键盘事件的受限模式下运行，做不到就直接失败。
更关键的是，它不会把“事件发出”当成“任务成功”。动作结果分为 worked、didnt 和 unknown。Agent 可以附加 postcondition，例如点击后必须出现“Archive completed”；预期内容没有在限时内出现，就判定失败。
结果不明确的鼠标操作不会自动重放，因为一次成功点击再来一遍，很可能变成双击。动作结束后，系统只把界面变化返回给模型；并发操作按资源协调，密码字段也会被隐藏。
开源不等于成熟
这段会降低一点兴奋感，但必须说。
我在 Windows 上跑了项目自带的检查。类型检查、并发检查和 Rust 的 cargo check 都能通过，但完整测试还不干净：部分 Node 脚本会把绝对路径拼成 C:\C:\...；两处 Rust 测试也没有跟上截图接口的参数变化。
项目最新的 macOS CI 是通过的。这些问题不能直接证明运行时不可用，但说明它仍是一个快速变化的 0.4.x 项目。把它当成值得研究的工程样本没问题，包装成 Codex 的成熟替代品就太早了。
它也没有 Codex 那套逐应用授权、敏感动作确认和企业策略。Windows 仍需要保持已解锁的交互式桌面，原始鼠标键盘操作也可能占用前台输入。它还是第三方 Pi 扩展，安装后可以执行本地代码，第一次尝试最好放在虚拟机或非敏感环境里。
Codex 是产品，Pi 社区给出了一份参考答案
读完源码后，我觉得二者暂时不在同一个阶段。
Codex 已经把 Computer Use 做成产品。用户关心的是授权哪个应用、任务能不能完成、出问题时怎么接管。
pi-computer-use 更像一份开放的参考实现。开发者可以研究它如何组合 UI 树与截图，如何让过期状态失效，又如何验证一次操作真的产生了预期结果。
所以，如果只是想让 AI 帮忙操作电脑，我会优先选择 Codex。如果正在开发 Agent，或者想知道 Computer Use 内部还有哪些坑，这个 Pi 社区扩展更值得读。
体验 v0.4.3 可以使用下面的命令：
1 | pi install git:github.com/injaneity/pi-computer-use@v0.4.3 |
会点鼠标的 Agent 已经很多。能让开发者查清它为什么敢点、点错后怎么办的开源实现，还不算多。
项目与资料：