去年底，我们还在讨论怎样让 AI 像人一样看屏幕、点鼠标。
九个月后，Astra 展示出的 Computer Use 已经出现另一种变化：Agent 可以结合视觉和结构化信息理解软件，并通过代码等更高效的方式改变软件状态。
GUI Agent 正在从“模仿人操作电脑”，走向“让 Agent 用自己的方式使用软件”。
本文是「企业研发 AI 自动化」系列第 41 篇，欢迎关注和交流。
2025 年 12 月，豆包手机和 AutoGLM 让 GUI Agent 成为一个热门话题。
当时我写过一篇 《从 AutoGLM 到豆包手机：GUI Agent 技术探索与对比》，研究的核心问题很直接：
AI 到底怎样像人一样操作手机和电脑？
AutoGLM 的实现很典型。
Agent 获取手机截图，视觉模型理解当前界面，判断下一步动作，再输出点击坐标、滑动、输入等操作。系统执行后重新截图，继续下一轮判断。
我当时实际运行 AutoGLM 时，日志里甚至能直接看到模型判断：搜索图标在右上角，坐标大约是 (922, 64)。
然后执行 Tap，重新观察屏幕，再继续下一步。
这条路线非常符合人的直觉：人通过眼睛看屏幕、用手操作鼠标和触屏；Agent 通过视觉模型看截图，再模拟点击、滑动和输入。
九个月之后再看 Astra，我觉得值得重新问一个问题：
AI 真的还需要像人一样使用电脑吗？
Computer Use 最近发生的变化，已经超过了“模型看 UI 更准、坐标点得更准”。
Agent 开始学习一种更适合机器的软件使用方式。
人面对电脑，首先看到的是 GUI。
按钮是什么颜色，输入框在哪里，哪个图标可以点击，都通过屏幕上的像素传递给我们。
早期 Computer Use 自然沿用了这条路径：
但软件内部还有大量人眼看不到、机器可以直接读取的信息。
Accessibility Tree 就是其中一个例子。
它原本主要服务于屏幕阅读器等无障碍场景。浏览器和操作系统会向辅助工具提供带有语义的界面结构。
一个人在屏幕上看到的按钮，对机器可能表现为：
人看到的是一个按钮。
Agent 可以直接知道：这里有一个名为“提交订单”的 button。
Browserbase 工程师 Kyle Jeong 最近根据 Codex 相关实现和 OpenAI 文档，对 Astra Computer Use 做了一次分析。原文见 《How does Astra’s computer use actually work?》。
按照 Kyle 的还原，Codex Computer Use 会话可以利用 Accessibility Tree 等文本信息，也会结合 Screenshot 观察当前界面；在他的架构分析中，Codex 还会启动持续运行的 Node REPL 保存会话状态。
这里需要说明：这是 Kyle 基于实现进行的工程分析，并非 OpenAI 对 Astra 内部架构的完整官方披露。
但这种结构本身很有启发。
Accessibility Tree 更擅长告诉 Agent：这里是什么元素、叫什么、处于什么状态、是否可以操作。
Screenshot 则更适合页面布局、图片、图表、Canvas、游戏、Blender 等视觉信息更重要的环境。
于是 Computer Use 的“眼睛”开始从单一视觉输入扩展：
这里真正重要的变化是：
视觉界面不再是 Agent 理解软件的唯一入口。
Agent 可以看软件呈现给人的画面，也开始利用软件暴露给机器的结构。
感知方式在变，操作方式也在变。
过去典型的 Computer Use 很像人在远程控制电脑：
每完成一个动作，模型都可能重新观察和推理。
今天 OpenAI 的 Computer Use 已经明确支持另一条重要路径：Code Execution。
按照 OpenAI Computer Use 官方文档，当前主要有两种接入方式：
对于 GPT-6 Astra，OpenAI 当前明确推荐 Code Execution，同时保留 computer tool 作为另一种选择。一次代码调用还可以组合多个动作、循环和条件判断。
比如完成一次网页搜索，纯 GUI 操作可能经历：
通过 Playwright，模型可以直接写：
一次执行就能组合多个动作。
OpenAI 还明确要求执行环境在不同调用之间保持可用。前面创建的 browser 或 desktop session、变量和中间状态，可以被后续操作继续使用；一组动作结束后，再提供新的 Screenshot，让模型检查实际结果。
于是“AI 会写代码”和“AI 会操作电脑”这两件事，开始在 Computer Use 里汇合。
因为代码本身就是一种非常高效的软件操作方式。
一段 Playwright 可以完成五个动作，Agent 就没有必要坚持把它们拆成五次鼠标点击。
Computer Use 因此开始从模拟人的每一个动作，逐渐走向选择更有效的方式改变软件状态。
去年那篇文章里，我专门比较过 GUI Agent 和 API Agent。
GUI Agent 最大的价值在于覆盖面：只要人能操作的软件，Agent 理论上就有机会操作。
软件不需要提前为 AI 提供专门接口。
API Agent 提供的是另一种优势：执行路径更加结构化，效率和确定性通常更高。
当时我的判断是：GUI Agent 和 API Agent 会逐渐融合，由 Agent 根据环境选择合适的操作方式。
今天看，这个判断正在兑现。
现实甚至比“GUI + API”两个选项丰富得多。
从更广义的 Agent 系统看，它面对一个浏览器时，可能拥有 Screenshot、Accessibility Tree、DOM、Playwright、浏览器接口、MCP 等不同入口。
面对桌面软件，又可能使用 Screenshot、系统 UI Automation、鼠标键盘、代码执行、Shell 或应用自身的脚本能力。
这里已经很难继续用“GUI Agent vs API Agent”概括。
Agent 面对的更像一个完整的软件环境。
这个环境向它提供两类核心能力。
Agent 根据任务，在不同的表示和执行方式之间动态选择。
过去讨论 GUI Agent 时，我们关注的主要是“模型如何理解这个界面”。
今天的问题开始扩大成：
Agent 如何理解整个软件环境，又有哪些方式可以改变这个环境？
这也让我重新理解了去年研究 AutoGLM 时的另一个问题。
AutoGLM 的工程框架相对直接。
ADB 负责截图和设备控制，Action Handler 执行点击、滑动等动作，Agent Loop 把整个过程串起来。
真正困难的能力高度集中在模型：
所以当时研究 GUI Agent，很容易把主要注意力放在 VLM 和模型训练上。
Astra/Codex 展现出来的 Computer Use 已经复杂很多。
Kyle 的分析认为，Codex Computer Use 会话拥有持续运行的 Node REPL，用来保存页面对象和会话状态；Agent 根据任务选择浏览器或原生 Computer Use 能力，执行后重新观察环境，检查实际结果。
OpenAI 官方 API 文档虽然没有披露完全相同的内部实现，但明确要求：
执行环境持续存在、保存 browser 或 desktop session，并在一组动作之后重新观察结果。
把这些能力抽象出来，一个完整的 Computer Use Harness 已经开始包含多个部分。
这也是 Astra 发布里一个很容易被忽略的信息。
OpenAI 在 GPT-6 Astra 官方发布文章 中专门提到，他们在发布 Astra 的同时更新了 Codex Harness，以显著提高 Computer Use 的速度。
这不是一个只有架构意义的变化。
OpenAI 给出的结果是，Astra 的效率提升与更新后的 Codex Harness 结合后，在 Mind2Web benchmark 上，任务完成速度达到此前 GPT-5.6 Sol 体验的 1.9 倍。
这说明用户最终感受到的 Computer Use 能力，越来越适合用一个组合来理解：
Model × Harness
模型能力让 Agent 做出更好的判断。
Harness 把这种能力组织成一个能够持续观察、执行、验证和恢复的工作循环。
去年研究 GUI Agent 时，最令人兴奋的一点，是 AI 开始突破 API 的限制。
软件没有专门为 AI 开接口也没关系。
只要人能通过 GUI 操作，Agent 就有机会完成任务。
这极大扩大了 Agent 能够触达的软件范围。
Astra 展现出的下一步，是 Agent 开始逐渐摆脱人类操作方式本身的限制。
它可以看 Screenshot，也可以利用结构化界面信息。
可以点击按钮，也可以通过 Playwright 直接定位元素。
可以一步一步操作，也可以一次生成一段代码。
从更广义的 Agent 系统看，软件提供 API 或 MCP 时，又可以直接使用机器接口。
这些能力共同扩展了 Agent 使用软件时的环境表示和动作空间。
于是 Computer Use 真正值得关注的问题也在变化。
几年前我们关心：AI 能不能看懂屏幕、点准按钮？
今天更值得追问：怎样给 Agent 提供更好的环境表示、更丰富的执行方式，以及可靠的验证闭环？
再往前一步，这个变化可能还会反过来影响软件本身。
过去几十年，软件主要围绕人的使用方式设计。
GUI、菜单、按钮、快捷键，本质上都是人与软件之间的接口。
当 Agent 开始成为软件的重要使用者，软件可能会多出另一类设计目标：
让 Agent 更容易理解当前状态，更稳定地执行操作，更明确地判断任务是否完成。
Accessibility Tree、DOM、API、MCP 已经提供了一部分基础。
未来还可能出现更多专门面向 Agent 的环境表示、执行接口和验证机制。
所以从 AutoGLM 到 Astra，真正发生变化的远不止 GUI Agent 变强。
去年，我们还在训练 AI 像人一样使用电脑。
现在，它开始学会用自己的方式使用软件。
接下来更值得关注的问题可能是：
当 Agent 成为软件的重要使用者，软件本身应该怎样变化？
《企业研发 AI 自动化》是我持续记录 AI 进入真实研发流程后的实践系列。
它关注的不只是 AI Coding 工具本身，而是从需求输入、任务表示、Agent 执行到自动化验证的完整链路：AI 如何在真实工程系统里稳定运行，并逐渐形成可复用的研发自动化能力。
欢迎关注和交流～
