你有没有遇到过这样的场景？#

你有一个 40 个文件的 API 迁移任务要完成。你打开 Codex，输入指令，它帮你改了两三个文件。然后呢？你得再发一条消息，告诉它继续。改完，再发消息。再改，再发。整个下午，你基本上就是一个「继续」按钮的搬运工。

这种情况在 2026 年 5 月 21 日之后有了根本性的改变。

OpenAI 在那天一次性发布了三个 Codex 更新，内部称之为 “Codex Thursday”。其中最核心的一个功能就是 Goal Mode 正式版。它从实验阶段走向全平台稳定发布，覆盖 Codex 桌面应用、VS Code 和 JetBrains 扩展，以及 CLI。

简单来说，Goal Mode 让你可以给 Codex 一个跨越数小时的长期目标，设定一个验证成功条件，然后就去做别的事。等你回来的时候，任务已经完成了。

从「工具」到「有任务的 Agent」#

要理解 Goal Mode 的价值，得先看清楚传统 AI 编程助手的工作模式有什么问题。

绝大多数基于大语言模型的编程工具都是「请求响应」式的：你写一段提示词，模型写一段代码，你检查，再提修改意见，它再改。这种方式处理单个函数、解释一个 Bug、生成一段测试代码，效果很好。

但它有一个致命的短板：一旦任务需要跨文件规划、执行测试、修复失败、再重跑测试这样的循环流程，请求响应模式就撑不住了。因为每一轮对话结束后，模型的状态就重置了。它不记得上一轮干了什么，也不知道接下来该干什么。全靠你在每一轮重新描述目标。

Goal Mode 增加的是一层「持久化记忆」。当你设定一个目标后，这个目标会存活在本地 SQLite 数据库里，不会因为对话轮次的切换、中断、预算暂停或恢复而丢失。Codex 会持续追踪目标的完成状态，把自己的输出和你定义的成功条件做对比，然后不断迭代，直到目标完成或者触发了你设定的边界条件。

用一句话概括：模型从「你问它答」的工具，变成了「领了任务就干活」的自主 Agent。

五层架构，让目标运转起来#

理解 Goal Mode 的内部架构，能帮你写出更高效的目标定义，也能在出问题时快速定位原因。

状态层（SQLite）：每个线程只能有一个活跃目标。目标的完整生命周期信息都存在一张本地 SQLite 表里，包括目标文本、当前状态（active、paused、budget_limited、complete）、Token 预算（可选）和实时消耗计数。

应用服务 API（JSON-RPC）：Codex 应用服务器暴露了 thread/goal/set、thread/goal/get、thread/goal/clear 三个接口。你在 TUI 界面输入的 /goal pause 或 /goal clear 命令，底层调的就是这些接口。

模型工具层：模型可以使用三个工具，分别是 create_goal、update_goal（包括标记完成状态）和 get_goal。这里有一个关键设计：模型不能自己暂停或恢复目标。这些状态转换只能由系统控制。这避免了一类棘手的边界情况，模型在卡住时可能会尝试无限循环，或者过早放弃。

运行时事件总线：一个生命周期钩子，负责在每一轮追踪 Token 和时间增量，接收中断时自动暂停目标，线程恢复时自动重新激活暂停的目标，以及在接近预算限制时向模型的响应流注入「预算告警」引导信息。

TUI 控制层：你输入的 /goal 系列命令是以上所有功能的用户接口。

怎么用 Goal Mode#

CLI 环境#

CLI 需要 0.128.0 或更高版本。安装或升级：

npm install -g @openai/codex
codex --version   # 确认是 0.128.0 以上

进入项目目录，启动 Codex CLI 会话，然后用 /goal 命令：

/goal 将 src/api/ 下所有 fetch() 调用迁移到集中式的 apiClient 工具函数。验证每个文件能编译通过，现有集成测试全部绿灯。

VS Code 和 JetBrains#

两个 IDE 扩展都直接支持 Goal Mode，不需要额外配置。打开 Codex 面板，启动会话，在聊天输入框里输入 /goal。面板上会出现目标生命周期控制按钮（暂停、恢复、清除）。IDE 扩展还会在状态栏显示当前目标状态，比如 Codex: goal active 或 Codex: goal paused。

Codex 桌面应用#

在 macOS 的 Codex 应用中同样使用 /goal 命令。同一版本还发布了 Appshots 功能：同时按下两个 Command 键，可以截取当前最前面窗口的截图并附加到消息中。这在定义目标时特别有用，你可以直接把错误信息、测试输出或 UI 截图作为上下文发给 Codex，省去手动复制粘贴的麻烦。

写出好目标的三个要素#

Goal Mode 成功率最大的影响因素，就是你的目标定义够不够精确。Codex 很擅长推断合理的子步骤，但它推断不出你没说清楚的成功条件。

一个结构良好的目标包含三个部分：

1. 目标本身，完成后应该满足什么条件

2. 验证手段，Codex 应该怎样检查自己的工作

3. 约束条件，哪些东西不能动

来看一个对比：

反面教材：

/goal 改进代码库

这给了 Codex 零完成条件。它会不停地生成改进，直到预算耗尽或者你手动清除目标。

正面示范：

/goal 将 src/store/ 中所有已废弃的 createStore() 调用替换为
@reduxjs/toolkit 的新 API configureStore()。不要改动 reducer 和中间件配置。
验证构建通过，src/store/__tests__/ 下的 Vitest 测试全部绿灯。

这个目标有边界、有验证步骤（构建加测试）、有明确的约束（不要动 reducer 和中间件）。

实践中效果不错的几种目标类型：

  • 迁移任务：把 X 从库 A 迁移到库 B，验证测试通过
  • 有测试覆盖的重构：把组件 X 中的数据获取逻辑抽成自定义 Hook，更新所有使用点，测试保持绿灯
  • 文档补全：给 src/utils/ 里每个还没有 JSDoc 注释的导出函数补上注释，验证 npm run docs 能无错构建
  • 部署重试循环：运行预发布部署脚本，解析错误，修复根因，重新运行直到成功或遇到无法自行解决的错误

目标的生命周期#

目标激活后，Codex 进入一个自主循环：

while 目标状态 != 完成:
    规划朝目标前进的下一步
    执行步骤（文件编辑、Shell 命令、测试）
    检查输出是否满足成功条件
    if 满足:
        标记目标完成
    elif 卡住或报错:
        尝试恢复或请求输入
    elif 触发预算限制:
        暂停目标，通知用户

你可以在任何时候介入：

/goal          # 查看当前目标和状态
/goal pause    # 当前轮次完成后暂停
/goal resume   # 恢复已暂停或预算耗尽的目标
/goal clear    # 完全放弃当前目标

当目标达到你设定的 Token 预算时，会自动进入暂停状态。你会收到通知，可以审阅已完成的工作，然后决定是恢复还是放弃。

Token 预算和成本控制#

对于可能运行数小时的自主目标，成本控制是绕不开的话题。2026 年 5 月起，Codex 的定价完全基于 Token：

费用 = (输入 Token x 输入费率) + (缓存输入 Token x 缓存费率) + (输出 Token x 输出费率)

缓存输入 Token（在多个轮次中重复出现的上下文）的成本大约是普通输入的 10%。对于长时间运行的目标，相同的文件上下文会反复出现在每一轮对话中，缓存是你能用到的最大的成本削减手段。

你可以在定义目标时设定预算上限：

/goal --budget 50000 修复 src/ 下所有 TypeScript 严格模式错误。验证 tsc --strict 通过。

这会把目标限制在 50,000 个 Credit。预算耗尽后 Codex 自动暂停，并汇报已完成的部分。你可以审阅 Diff，然后 /goal resume（继续并分配新预算）或者 /goal clear 接管工作。

根据 OpenAI 的使用数据，开发者月均开销在 100 到 200 美元之间，具体取决于模型选择和目标复杂度。长时间运行的自主目标会处于开销的上端。

Goal Mode 什么时候该用，什么时候不该用#

不是所有任务都适合用 Goal Mode。下面是一个实用的决策框架：

场景用普通轮次用 Goal Mode
写一个函数更好杀鸡用牛刀
解释一个 Bug更好不适用
迁移 40 个文件到新 API太繁琐更好
大规模重构加测试覆盖需要反复提示更好
探索性架构设计更好太早了
部署重试循环手动操作更好
多小时的验证式迁移不现实专为这种场景设计

核心判断标准：这个任务有没有一个可验证的完成状态？它的规模是不是超过一两次对话能搞定的？如果两个答案都是「是」，Goal Mode 值得一试。如果你还在探索想做什么，用普通轮次更合适。

两个实用的配套功能#

Locked Computer Use#

这个功能让 Codex 在你的 Mac 锁屏后继续工作。OpenAI 的实现使用短期授权令牌，Codex 工作期间覆盖屏幕显示，检测到本地输入时自动重新锁屏，并在需要时回退到手动解锁。

对于需要数小时的自主目标运行，这意味着你可以启动一个目标，锁上电脑，去做别的事，回来时工作已经完成。但要注意，这个功能目前只适用于桌面应用，CLI 和 IDE 扩展暂不支持。

Appshots#

双击 Command 键可以截取当前窗口的截图并发送给 Codex。截取的内容包括截图和提取出的文本。这在定义目标时最有用，你可以把错误信息、测试运行输出或 UI 截图作为上下文，不用手动复制粘贴。

实战中的常见错误#

目标定义太宽泛。「将整个代码库重构为 TypeScript 严格模式」在技术上是有边界的（tsc --strict 通过），但在任何非平凡的项目上都会消耗大量预算。把目标限定在一个目录或一个模块。

没有验证手段。如果目标里没有告诉 Codex 怎么验证完成，它常常会提前标记目标为已完成。在目标文本里显式写上验证命令。

过早清除目标。/goal clear 会放弃当前目标并丢弃进度追踪。如果你只是想暂停审阅，先用 /goal pause，审阅完再恢复。

在活跃开发分支上跑 Goal Mode。如果团队成员（或者你自己）在目标运行的同时修改文件，冲突几乎不可避免。Goal Mode 最适合在独立分支上使用，确保 Codex 对相关文件有独占写权限。

第一次运行不做成本监控。新目标类型的 Token 消耗很难预测。第一次跑完后检查用量面板，为以后类似的目标校准预算。

几个常见问题#

Goal Mode 支持私有仓库吗？ 支持。Codex 在本地文件系统（CLI 和 IDE 扩展）或你关联的仓库（桌面应用）中运行。除了模型 API 调用外，不会把代码库发到别的服务器。目标状态存在本地 SQLite 中。

能同时跑多个目标吗？ 不能。每个线程同一时间只支持一个活跃目标。如果需要并行执行多个目标，可以在不同的终端窗口或 IDE 面板中启动独立的 Codex 会话。

Codex 在某个子任务上卡住了怎么办？ 如果 Codex 无法推进（编译错误修不好、测试跑不过），它会把阻塞点展示出来并暂停，请求你的输入，而不是无限循环。这是由模型的 update_goal 工具控制的，检测到不可恢复的状态时会设置目标为暂停并描述需要什么帮助。

Goal Mode 和 Codex 已有的 Agent 功能有什么区别？ 标准的 Codex 任务已经包含单轮内的多步执行（运行测试、读文件、写代码）。Goal Mode 增加的是跨轮次的持久化：目标状态在轮次之间存活，Codex 不需要你在每个循环重新提示。它是在现有 Agent 基础设施上加了一层持久化。

总结#

Goal Mode 是真正兑现「自主编程助手」承诺的功能。它接管了那些无聊的、有边界的、需要数小时的工作：迁移、重构、文档补全、部署重试，而你可以把精力放在真正需要判断力的决策上。

关键在于，给目标设定清晰的完成条件和验证手段。这样做，Codex 就能交付高质量的结果。如果不设验证条件，你大概率会看到一堆半成品。

参考来源：本文基于 dev.to 文章 “Codex Goal Mode: Run Long-Horizon AI Coding Tasks for Hours or Days”（2026-05-27）的核心内容进行原创重写，补充了架构分析和实战建议。