摘要：
Astra 让每一步电脑操作都接得住
正文：
模型完成一次点击，只推进了任务中的一步。动作执行后，界面状态随之变化，模型需要看到新的界面，才能继续判断下一步该做什么。于是，多步 Computer Use 实际上形成了一条反复循环的执行链路：获取当前状态、判断下一步、执行动作，再获取动作后的新状态，同时跨步骤维持运行环境，并确认操作是否生效。
OpenAI 最近发布的 GPT-6 Astra，是怎么把这条链路持续跑起来的呢？
结合 Codex 源代码、OpenAI 官方资料和相关实现信息来看，这条链路中的分工是，模型负责判断下一步动作，Harness 负责维持运行环境、执行操作、把最新环境状态返回给模型，同时接入安全审查机制。
界面状态获取结合截图与结构化信息
要让多步任务持续执行，Agent 首先需要稳定获取当前界面状态。纯视觉 Computer Use 通常让模型读取屏幕截图，再输出类似 click(x, y) 的坐标动作。以 Claude 3.5 Sonnet 为例，模型会返回包含动作类型和 x、y 坐标的 JSON，再由 Stagehand、Playwright 等自动化驱动映射成实际的浏览器或计算机操作。像素定位容易受到视口尺寸和布局变化影响；仅依赖截图，也难以直接获得部分复杂交互背后的结构信息。
Astra / Codex 会利用无障碍树获取结构化的界面状态。无障碍树原本服务于屏幕阅读器等辅助功能，会把按钮、输入框、菜单等界面元素暴露成带有语义角色和交互信息的结构化节点。相比直接处理完整网页视觉层，这类结构可以过滤大量 CSS、类名等视觉实现信息，让模型获得更紧凑的界面语义。Chrome 会自动为网页生成无障碍树，因此这类结构化信息可以直接用于许多网页界面。
图1：网页渲染结果与 Chrome 开发者工具中的无障碍树对照
截图仍然是获取界面状态的一种方式。Agent 可以根据任务使用文本、截图，或者组合两种方式获取当前状态。结构化界面信息可以提供元素语义，截图则补充布局、图像等视觉状态。
动作开始从鼠标事件转向代码执行
模型获得当前界面状态后，需要把下一步动作真正执行出去。传统 Computer Use 往往一次输出一个结构化鼠标或键盘动作，例如点击某个坐标、输入一段文本。Astra / Codex 则开始更多通过代码表达界面操作。例如，模型可以生成类似下面的调用：
{
"type": "function_call",
"name": "exec_js",
"call_id": "call_123",
"arguments": "{\"code\":\"await page.getByRole('searchbox').fill('browser automation'); ...\"}"
}
对于浏览器任务，模型可以通过类似 Playwright 的自动化方式直接描述“找到角色为 searchbox 的元素并填写内容”，不需要把每一次操作都还原成屏幕上的绝对坐标。模型由此可以通过 Harness 调用已有的软件自动化能力。
代码执行要求运行环境持续存在。在这套 Codex 实现中，Computer Use 会话会启动一个持续存在的 Node REPL。REPL 是 Read-Eval-Print Loop（读取—求值—输出循环）的缩写，可以理解为一个持续运行的 Node.js 交互式执行环境。这里它主要用于保存 Computer Use 的执行状态，并承载浏览器和原生桌面操作所需的能力，页面、标签页等运行时对象可以跨多次模型调用继续存在。
这里需要区分模型上下文和真实执行环境两类状态。模型上下文记录 Agent 之前做过什么。真实执行环境则保存浏览器当前停在哪个页面、是否已经登录、前一步创建的对象是否仍然存在。
即使模型记得“我已经打开了这个网页”，底层浏览器会话一旦销毁，任务仍然无法继续。Harness 还需要维护实际运行环境。Node REPL 持续贯穿整个 Computer Use 会话，就是这一状态要求在这套实现中的具体体现。
动作落到系统以前，还要经过执行适配层。完整架构中，持久化 JavaScript 运行环境分别连接浏览器**适配器**和 Mac 原生适配器。在这套被检查的 ChatGPT 客户端本地实现中，CodexComputerUseIPC-5 服务负责执行相关请求。在 Mac 原生路径中，执行层会把模型选中的元素转换成系统原生元素 ID，或者在需要时使用坐标，再通过本地管道和 JSON-RPC 完成通信。模型给出“点击这个按钮”的高层动作后，Harness、适配层和底层运行环境继续把它映射成真实的浏览器或桌面操作。
动作执行后还要重新验证状态
模型提交操作代码后，本地服务正常返回，只能说明这次动作请求已经得到处理。页面是否进入预期状态，还需要重新获取界面状态。
页面可能尚未加载完成，按钮可能没有产生预期效果，也可能突然出现新的弹窗。从模型完成观察到动作真正执行之间，界面状态本身也可能发生变化。请求执行后，系统会再次获取新的界面状态，把实际结果与预期状态进行比较，再决定下一步。
图 2：Codex Computer Use 的端到端执行架构，包括任务模型、Harness、持久 JavaScript 运行环境、浏览器 / Mac 原生适配器、Guardian 与状态观察回路
整个过程形成一个持续循环：
观察当前环境 → 模型决定下一步 → 执行动作 → 重新观察真实状态 → 验证结果 → 继续下一步或根据新状态调整
工具调用成功 ≠ 任务完成。工具调用成功，只说明动作请求已经正常返回；任务是否达成，还需要由新的外部环境状态证明。如果状态与预期不一致，模型可以根据新的环境信息调整动作，必要时进入恢复流程。
安全判断被拆成独立的审查环节
结果验证负责判断动作是否得到预期结果，执行链路还需要单独处理权限问题。当 Agent 可以登录账号、修改设置、提交敏感数据或者执行不可逆操作时，权限判断不能完全交给主任务模型自行完成。
在本文所依据的 Codex / ChatGPT 版本中，Guardian 使用 GPT-5.6 Luna 作为后台风险分类器，对当前工作流和潜在风险进行判断；检测到高风险后，会进一步触发阻塞式审查。审查时可以读取：
候选动作及参数；
对话中的用户授权；
上层环境与权限上下文；
Node 运行环境中的已有证据；
截图等图像信息；
当前审批请求及其原因。
审查结果可以结构化为：
{
"risk_level": "high",
"user_authorization": "low",
"outcome": "deny",
"rationale": "..."
}
常见审查范围包括权限授予、账户操作、敏感数据提交、重要界面点击、绕过限制、破坏性操作，以及超出任务范围访问私人数据等。执行链路中存在两种不同的检查：
Guardian 安全审查负责判断动作是否允许执行，控制权限边界；
结果验证负责检查动作执行后的真实状态，控制任务正确性。
主任务模型负责规划和推进任务，高风险动作是否允许落地由独立审查机制判断。
真实环境仍然会让执行链路失效
Agent 可能拿到不完整的无障碍状态，也可能遇到截图细节不足或者已经过期的界面视图。
模型完成观察以后，到动作真正执行之前，界面也可能发生变化，这就是状态漂移。在一些应用中，无障碍树本身也可能频繁变化，从而让此前生成的元素定位和操作失效。
更长时间尺度的问题也还没有解决。上下文压缩已经能够支持 Astra 保持较长时间的高保真执行，但对于连续运行数天甚至数周后的表现，现有材料还没有给出验证结果。
模型负责理解任务、判断下一步，并根据新的环境状态继续决策；Harness 负责维持运行环境、执行动作、返回新的观察结果并接入权限审查。Computer Use 也由单次的屏幕识别与鼠标操作，扩展成一套连接模型决策与真实软件环境的持续执行闭环。
来源与参考
How does Astra’s computer use actually work?
OpenAI Codex 开源仓库，github.com/openai/codex
OpenAI GPT-6 Astra 介绍，openai.com/index/gpt-6-astra/
OpenAI Computer Use 开发者文档，developers.openai.com/api/docs/guides/tools-computer-use
