Codex /goal 和 OpenGUI：长时间运行的任务需要状态
I’m happy to help translate the article, but I don’t have the full text of the post. Could you please paste the content you’d like translated here? Once you provide the text, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown syntax, and code blocks.
长时间运行的代理在后半段往往会失败
第一步通常没问题——修复 CI 失败、打开应用、点击按钮、搜索关键词。模型可以给出一个合理的首个操作。麻烦在第 10 步左右开始出现：已经发生了什么、任务卡在哪、最初的边界是什么、以及任务何时可以结束。这些细节会脱离上下文。
Codex CLI 0.128.0 添加了 /goal。发布说明描述了一种持久化目标工作流：应用服务器 API、模型工具、运行时续写，以及用于 create、pause、resume 和 clear 的 TUI 控件。Simon Willison 将其比作 OpenAI 版的 Ralph 循环：为 Codex 设定目标，然后让它持续执行、检查并纠正，直至目标完成或预算耗尽。
在长期任务的语境下，这一变化涉及 目标所在的位置。它从单个提示中的文本转移为可以恢复、暂停、清除并在以后再次引用的状态。
为什么编码代理需要目标
以一次 CI 失败为例。最直接的失败可能是某个测试用例报错。代理先修改测试，然后修改实现，随后因为代码感觉别扭而调整类型。每一步都有理由，但最终的 diff 远大于最初的问题。
代码生成本身往往不是难点。运行时没有附加稳定的约束。最初的目标可能小到：
/goal 修复当前 failing tests，保持 diff 尽量小，最后跑完 npm test或：
/goal 处理这个 PR 的 review comments，不改无关文件，最后给出改动摘要这种目标包含 目标对象、边界 和 接受条件。它告诉代理去哪里、哪些不该动、以及何时停止。
没有这些状态，代理很容易被当前错误牵着走。类型看起来别扭，就去改类型；测试写起来困难，就去改测试；结构感觉混乱，就去重构。每一次局部的操作都可能合理，但整个任务会逐渐偏离原本的目标。
Source:
在手机上，难点在于屏幕状态
OpenGUI 处理的是另一种长期任务：让 AI 操作真实的 Android 手机。
代码仓库：
在代码库中，状态仍然可以落在文件、测试和差异中。而在手机上，状态是一个 实时屏幕。
例如，让手机执行以下操作：
- 打开 X。
- 搜索关于移动 AI 代理的讨论。
- 收集要点。
- 总结人们关心的内容。
作为一句话看起来很简单，但在手机上它会变成一系列状态检查：
- 应用已经打开了吗？
- 这是首页吗？
- 搜索框已经获得焦点了吗？
- 结果已经加载完毕了吗？
- 是否出现了登录提示、权限提示或关注‑推荐？
截图 → 点击 → 截图 的循环只能处理短任务。如果屏幕没有变化，系统必须判断是点击失误、网络慢、页面加载中，还是操作没有可见反馈。如果页面跳转到别处，系统必须决定是返回、重试，还是从新页面继续。
因此，移动端的目标必须回答几个具体问题：
- 任务当前处于哪个步骤？
- 当前屏幕是否支持下一步？
- 失败后如何恢复？
- 何时可以结束运行？
OpenGUI 将目标转化为状态流
我运行了 OpenGUI 并阅读了源码。它将后端图、设备连接和 Android 端的动作执行串联起来，而不是把手机自动化留作脚本。
- 后端入口点:
server/apps/backend/src/modules/graph-agent/graph/mobile-agent.graph.ts - 计划监督器: 将复杂计划拆分为可执行的子任务。
- 执行子图:
executor.graph.ts在设备上运行动作。 - 结果处理: 监督器接收执行结果并决定是继续、重试、重新规划，还是交给
Summarizer。
在 Android 上，动作会作用于真实设备：
client/core_accessibility/.../GestureService.kt执行 GUI 动作，如点击和输入。- 设备保持与后端的 WebSocket 连接；
client/core_network/.../StandbySocketManager.kt处理待机连接。 - 飞书/钉钉、Telegram 和 REST API 可以作为远程任务入口，使手机从本地演示设备转变为能够接收任务的工作节点。
OpenGUI 将目标分散到多个状态片段：
| 状态片段 | 描述 |
|---|---|
| 计划文档 | 模型编写的高级计划 |
| 当前子任务 | 正在执行的具体动作 |
| 设备截图 | 每个动作后的视觉反馈 |
| 执行结果 | 成功/失败，错误分类 |
| 失败分类 | 失败原因（例如，点击未命中、网络超时） |
| 最终摘要 | 人类可读的完成情况报告 |
每次设备动作后，后端会获取最新的设备状态并决定下一步。简单脚本假设页面会按预期顺序进行；OpenGUI 假设页面可能会变化，因此执行器必须不断向后端报告真实状态。
成本
将目标放入图中会使系统更沉重。
- 维护任务状态。
- 保持 WebSocket 连接活跃。
- 处理设备待机。
- 将执行结果和截图返回。
- 为 continue、retry、cancel 和 summarize 设计状态转换。
- 调用模型和截图分析也会产生费用。
任务运行时间越长，这些成本就越成为工程关注点，而不是一个小细节。
但在移动端很难避免这些成本。真实的应用会弹出提示框、卡在加载页面、误读点击，并把用户带到完全不同的页面。仅仅一个提示循环就会迅速演变成基于截图的 while true。
OpenGUI 将这种复杂性引入系统。一次错误的点击会变成供监督者消费的执行结果。设备持续上报状态。它的行为更像是一个工作者，而不是被点击的屏幕。设计更为沉重，但它为长时间运行的任务提供了 调试、恢复 和 审查 的位置。
潜在的首批使用场景
- 社区调研（例如，从移动论坛收集意见）
- 移动流程测试（自动化 UI 回归）
- 手机上的运维任务（例如，大规模配置更改）
- 应用层面的演示或教程
概述
只有网页自动化无法触及的工作流才需要专用的执行系统。这些任务可能不需要最强大的模型，但它们必须能够：
- 持续跟踪目标
- 及时检测失败
- 将状态更新发送回控制器
在编码代理中，Codex 使用 /goal 接口将目标存储为可恢复的状态。在移动设备上，OpenGUI 将任务进度、设备反馈和失败处理整合为一个连贯的状态流。因此，长期运行的代理需要：
- 跟踪整体运行，而不仅仅是下一步
- 在中断期间保持持久状态
- 对错误作出响应并相应调整计划
References
- OpenAI Codex 0.128.0 发布
- Simon Willison – “Codex 目标” (30 Apr 2026)
- OpenGUI (Core‑Mate)