从「一问一答」到「给我一个任务，我干完叫你」#

你有没有这样的经历？用 Codex 或其他 AI 编程助手写代码，每次都是「提一个需求，等它完成，检查结果，再提下一个需求」。一个涉及几十个文件的迁移任务，你可能要手动循环二十多次，每次都要重新告诉它上下文、目标和约束。

这种「请求，响应」的交互模式，本质上把 AI 当成了一个更聪明的自动补全。它能帮你写一个函数、解释一个 bug、生成一段测试，但当任务需要跨多个文件规划、反复执行测试、自动修复失败、再重试时，这种模式就力不从心了。

2026 年 5 月 21 日，OpenAI 发布了被称为「Codex Thursday」的重大更新。其中最引人注目的功能，就是 Goal Mode 从实验阶段正式毕业，成为 Codex App、VS Code 扩展、JetBrains 扩展和 CLI 的稳定功能。

简单来说，Goal Mode 把 Codex 从「响应指令的工具」变成了「领受任务的自主 Agent」。你给它一个长期目标，定义好成功条件，设定一个 token 预算，然后就可以锁屏走人了。等你回来时，任务可能已经完成了。

Goal Mode 的五层架构#

要真正用好 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（包括设置 complete 状态）和 get_goal。有一个重要设计决策：模型无法自行暂停或恢复目标，这些状态转换由系统控制。这防止了模型陷入死循环时自行「续命」，或者在遇到困难时过早放弃。

运行时事件总线

生命周期钩子会追踪每轮的 token 消耗和墙钟时间，在收到中断信号时自动暂停，在线程恢复时自动重新激活，并在接近预算限制时向模型的响应流注入「该收尾了」的引导信号。

TUI 控制层

你输入的 /goal 命令是以上所有机制的用户界面。

如何写出真正能完成的目标#

Goal Mode 最大的坑，不在功能本身，而在你怎么写目标。Codex 擅长推断合理的子步骤，但它无法推断你没有明说的成功条件。

一个好目标包含三个要素：

  • 目标：完成后应该是什么状态
  • 验证方式：Codex 应该如何检查自己的工作
  • 约束：什么不能改

反面示例：

/goal improve the codebase

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

正面示例：

/goal Replace all instances of the deprecated createStore() call in
src/store/ with the new configureStore() API from @reduxjs/toolkit.
Leave reducers and middleware configs untouched. Verify the build
passes and existing Vitest tests in src/store/__tests__/ run green.

这个目标有明确的范围、清晰的约束、可执行的验证步骤。

适合 Goal Mode 的任务模式：

  • 迁移任务：「把 X 从库 A 迁移到库 B，验证测试通过」
  • 带测试覆盖的重构：「从组件 X 中抽取数据获取逻辑为自定义 hook，更新所有调用点，测试保持绿色」
  • 文档批量补全：「为 src/utils/ 下所有缺少 JSDoc 的导出函数添加注释，验证 npm run docs 能正常构建」
  • 部署重试循环：「运行 staging 部署脚本，解析错误，修复根因，重新运行直到成功或遇到无法解决的错误」

目标的生命周期#

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

  1. 规划朝向目标的下一步
  2. 执行步骤（文件编辑、shell 命令、测试）
  3. 将输出与成功条件对比
  4. 如果成功条件满足，标记目标完成
  5. 如果卡住或出错，尝试恢复或请求输入
  6. 如果触发预算限制，暂停目标并通知用户

你可以在任何时刻介入：

  • /goal 查看当前目标和状态
  • /goal pause 在当前轮次完成后暂停
  • /goal resume 恢复暂停或预算受限的目标
  • /goal clear 完全放弃当前目标

当目标触发你设定的 token 预算时，Codex 会自动暂停并通知你。你可以审查已完成的工作，然后决定是继续还是接手。

Token 预算和成本控制#

对于可能运行数小时的自主目标，成本模型至关重要。Codex 的定价基于 token 用量：

credits = (input_tokens × input_rate) +
          (cached_input_tokens × cached_rate) +
          (output_tokens × output_rate)

缓存输入 token（跨轮次重复出现的上下文）的费用大约是普通输入的 10%。对于长期运行的目标，同样的文件上下文会出现在每一轮中，缓存是最重要的成本优化手段。

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

/goal --budget 50000 Fix all TypeScript strict-mode errors in src/.
Verify tsc --strict passes.

这会把目标限制在 50,000 个 credit。预算耗尽时，Codex 会暂停并报告已完成的部分。你可以用 /goal resume 继续（使用新的预算分配），或者 /goal clear 接手。

根据 OpenAI 的使用数据，典型开发者的月度费用在 100 到 200 美元之间，具体取决于模型选择和目标复杂度。多小时的自主目标会偏向高端。

Goal Mode 与常规模式的选择#

不是所有任务都适合 Goal Mode。一个简单的判断框架：

场景常规模式Goal Mode
写一个函数更适合大材小用
解释一个 bug更适合不适用
迁移 40 个文件到新 API需要反复提示更适合
带测试覆盖的大型重构需要反复提示更适合
探索性架构工作更适合过早
部署重试循环手动操作更适合
多小时的验证迁移不现实专为此设计

核心判断标准：这个任务是否有可验证的完成状态？它是否大于一两个提示词的范围？如果两个答案都是「是」，Goal Mode 值得一用。

锁屏运行与截图功能#

Goal Mode 发布时同步推出了两个配套功能。

锁屏运行（Locked Computer Use）

让 Codex 在你的 Mac 锁屏后继续工作。OpenAI 的实现使用短期授权令牌，在 Codex 工作时覆盖显示器，在本地输入时重新锁定。对于需要数小时的自主目标，这意味着你可以启动一个任务，锁屏离开，回来时工作已经完成。目前这个功能仅限桌面 App，CLI 和 IDE 扩展不支持。

截图附注（Appshots）

按两个 Command 键可以截取当前最前面的窗口，作为截图加提取文本发送给 Codex。在设定目标时特别有用：你可以直接指向一个错误消息、测试运行器输出或 UI 截图，作为上下文包含在目标定义中，不需要手动复制粘贴终端输出。

五个常见错误#

目标范围过大。 「重构整个代码库以使用 TypeScript 严格模式」在技术上是有界的（tsc –strict 通过），但在任何非平凡项目上都会消耗巨量预算。应该把目标限定到一个目录或模块。

没有验证条件。 如果目标不包含验证完成的方式，Codex 经常会在实际完成之前就标记完成。务必在目标文本中包含检查命令。

过早清除目标。 /goal clear 会放弃当前目标并丢弃进度追踪。如果你想暂停审查，应该先用 /goal pause。

在活跃开发中运行 Goal Mode。 如果其他团队成员（或者你自己）在目标运行时修改文件，冲突几乎不可避免。Goal Mode 最适合在 Codex 拥有独占写权限的隔离分支上运行。

不监控首次运行。 新类型目标的 token 消耗很难预测。第一次运行后检查用量面板，为后续类似目标校准预算预期。

我的看法：Goal Mode 是 AI 编程 Agent 的关键一步#

从 2024 年 Copilot 的自动补全，到 2025 年 Cursor 的对话式编程，再到 2026 年 Codex 的 Goal Mode，AI 编程工具的进化路径非常清晰：从辅助补全到对话协作，再到自主执行。

Goal Mode 之所以重要，不是因为它能让 AI 「自己写代码」，而是因为它解决了人机协作中的一个核心痛点：上下文传递的成本。在传统模式下，每一轮对话你都要重新描述背景、约束和目标。Goal Mode 把这些信息持久化了，让 AI 可以跨轮次保持对任务的理解。

但这也意味着，写好目标描述本身成了一项新的技能。就像管理一个初级开发者一样，你给他的指令越清晰、越具体、越有可验证的完成标准，他的产出就越好。模糊的指令只会得到模糊的结果。

对于团队来说，Goal Mode 最大的价值可能在于那些「重要但不紧急」的批量任务：迁移过时的 API 调用、补充缺失的测试覆盖、统一代码风格、更新过时的文档。这些任务单个都不难，但数量多、耗时长，人工做起来枯燥且容易出错。把它们打包成 Goal Mode 任务，在非工作时间自动执行，是一个非常自然的效率提升。

关键要点#

  • Goal Mode 于 2026 年 5 月 21 日正式发布，支持 Codex App、VS Code、JetBrains 扩展和 CLI（版本 0.128.0 以上）
  • 使用 /goal <目标> 启动，/goal pause、/goal resume、/goal clear 管理生命周期
  • 有效的目标需要包含目标描述、验证条件和约束
  • Token 预算（--budget <credits>）是长期目标的主要成本控制手段
  • Goal Mode 最适合有界的、可验证的多小时任务；探索性工作用常规模式更合适
  • 首次运行新类型目标时务必监控用量，校准预算预期

参考来源：Codex Goal Mode: Run Long-Horizon AI Coding Tasks for Hours or Days by Jangwook Kim