OpenAI 最近发布了一篇关于在 Codex中使用 Goals 的官方文档。简单来说，Goals 让 Codex 从"一次性对话"变成了"持续循环"——每一步都有证据校验，直到达成预设目标。
苏米注：Goals 是 Codex 最重要的功能之一，但它的使用方式和你习惯的普通 prompt 完全不同。理解 Goals 的核心在于理解"完成条件"——不是让 AI 做事，而是定义"做完"意味着什么。
Goals 是什么？
Goals 是 Codex 里的持久目标机制。
普通的 prompt 是一次性的：你说做什么，Codex 做完，等你下一条指令。Goals 不一样，它给 Codex 一个持续有效的完成条件：任务什么时候算做完，怎么验证，过程中什么不能动。
只要目标还在、还在预算内，Codex 可以自己检查进度、决定下一步，不需要你每轮重复一遍目的。
Codex 原本就能处理边界清晰的任务：看代码、修 bug、写测试、解释报错。Goals 针对的是另一类任务：下一步该怎么做，取决于上一步发现了什么。比如性能调优、不稳定测试排查、依赖迁移、需要复现的 bug、多步重构、基于 benchmark 的调参，或者要产出最终文档的研究任务。
这类任务不需要更长的 prompt，需要的是一个持久的目标。
Goals 不是放任 AI 无边界自主运行。它是一个有范围、用户可控的完成合约。你定义结果，Codex 对着线程里的证据工作，目标可以暂停、恢复、清除、完成，也可以被预算限制住。
怎么用？
Goals 从 Codex 0.128.0 开始支持。目前只支持 codex CLI，更新到最新版即可使用。
安装或更新：
# 使用 npm
npm install -g @openai/codex@latest
# 或使用 Homebrew
brew update
brew upgrade --cask codex设置目标，用 /goal 加上你想达到的结果：
/goal 将 p95 延迟降至 120 毫秒以下，且不引起正确性测试回退生命周期管理命令：
| 命令 | 功能 |
|---|---|
/goal |
查看当前目标 |
/goal pause |
暂停激活中的目标 |
/goal resume |
恢复已暂停的目标 |
/goal clear |
移除当前目标 |
目标激活后，Codex 可以自己看代码、跑相关命令、做修改、测结果，一直到达到停止条件为止。停止条件包括：成功完成、暂停、清除、被打断、达到预算上限、或者遇到需要用户介入的阻塞点。
Goals 和普通 prompt 的区别
普通 prompt：你说做这件事，Codex 做，汇报结果，等待。
Goals：Codex 工作，检查是否达标，继续或完成。
区别就在这里。普通请求里，Codex 做完当前指令，等下一条。Goals 让 Codex 有一个持续附在线程上的目标。每轮结束后，它能检查当前证据，判断目标是否达成。如果没有，且目标仍然激活、仍在预算内，Codex 从最新状态继续。
举个例子：
/goal 在 checkout 基准测试中，将 p95 checkout 延迟降至 120 毫秒以下，同时保持正确性测试套件全绿通过这不只是一个"提升性能"的请求。它给了 Codex 一个可测量的结果、一个验证方法、一个约束条件。Codex 可以跑 benchmark，检查热路径，做针对性修改，重跑 benchmark，跑正确性测试套件，如果结果还不达标就继续。
怎么写一个好的 Goal
好的 Goal 不是更长的 prompt，是一个关于 Codex 怎么工作、什么算成功、成功暂时无法达到时怎么办的精简合约。
强 Goal 通常定义六件事：
| 要素 | 说明 |
|---|---|
| 结果 | 工作完成时应该是什么状态 |
| 验证方法 | 用什么来证明（测试、benchmark、报告、产出物、命令输出、源材料） |
| 约束 | Codex 工作期间什么不能退化 |
| 边界 | Codex 可以用哪些文件、工具、数据、仓库或资源 |
| 迭代策略 | 每次尝试后，Codex 怎么决定下一步试什么 |
| 阻塞停止条件 | 什么时候应该停下来，告知当前限制下没有可行路径 |
一个实用的写法模板：
/goal [达成什么结果]
通过 [什么验证方法] 验证
同时保持 [什么约束条件]
使用 [什么工具/资源]
每次迭代之间 [如何决策下一步]
如果遇到阻塞或没有有效路径 [如何处理]
比较一个弱 Goal 和一个强 Goal：
弱版本：
/goal 将 p95 checkout 延迟降至 120 毫秒以下，同时不引起正确性测试回退强版本：
/goal 将 p95 checkout 延迟降至 120 毫秒以下，
以 checkout 基准测试验证，同时保持正确性测试套件全部通过。
仅使用 checkout 服务、基准测试夹具及相关测试。
在每次迭代之间，记录变动内容、基准测试结果，以及下一步要尝试的最佳实验。
如果基准测试无法运行或无有效路径剩余，则停止，并附上已尝试路径、收集到的证据、阻塞点，以及所需的下一步输入强版本里，如果 p95 从 180ms 降到 135ms，Goal 还没完成。如果延迟降到 120ms 以下但正确性测试挂了，Goal 也没完成。如果 benchmark 跑不起来，Codex 必须把这个阻塞报上来，而不是宣布成功。
苏米注：如果任务清楚但还不知道怎么写 Goal，也可以让 Codex 来帮写。先用普通语言描述工作，让 Codex 把它转成 Goal 草稿；再审查草稿，收紧成功条件、验证方法、约束和阻塞停止条件，然后再激活。
Goal 激活后，三件事会改变
第一，目标持续可见。如果 Codex 跑了一个测试、失败了，线程里还有原始目标。如果 benchmark 提升了但没过阈值，Codex 可以继续。如果研究路径碰到了数据缺失，Codex 可以调整证据计划，不会丢失研究标准。
第二，可以从空闲线程继续。Codex 不会在另一轮还在跑的时候继续，不会在用户输入排队的时候继续，不会在有其他线程工作待处理的时候继续。只有在线程空闲、目标激活、在预算内时才继续。
第三，完成必须有证据。Goal 不应该因为模型觉得"大概差不多了"就被标记为完成。只有把目标和具体证据对照检查之后，比如文件改动、命令运行、测试通过、benchmark 输出、生成产物或研究证据，才能标完成。
Goals 的内部设计
Goals 是持久化的线程状态，不是全局记忆，也不是项目级指令。设计上的这个选择很重要：目标属于有相关上下文的那个线程，包括 Codex 检查过的文件、跑过的命令、产出的 diff、看到的日志、积累的推理链。
在架构层，Goal 是一个持久的、线程范围内的状态。它记录了 Codex 评估线程所需的目标、生命周期、预算和进度。关键边界是范围：Goal 属于当前线程，不属于全局记忆或项目指令。
Codex 把这个状态作为用户、模型、线程三者之间的合约。Goal 可以处于激活、暂停、完成或达预算上限等状态。这些状态决定了 Codex 是否可以继续、是否应该等用户、还是应该汇总进度而不是开始新工作。
继续是事件驱动的，不是简单的循环。Codex 只在安全边界处检查是否继续：一轮结束后、没有其他待处理工作时、没有用户输入排队时、线程空闲时。
调度器的行为是有意保守的。纯规划工作不触发继续。被打断会暂停目标。恢复线程时，可以在适当情况下恢复目标。如果某次继续没有产生任何工具调用，下一次自动继续会被抑制，防止 Codex 空转。
预算处理是明确的。达到预算上限时，Codex 应该停止实质性工作，汇总进度和阻塞点，并指出下一步有用的行动。达到预算上限不等于完成目标。
用 Goals 做复杂研究：复现一篇量化论文
来看一个具体的研究 Goal 示例。
研究对象是 Buehler、Gonon、Teichmann 和 Wood 的 Deep Hedging 论文。这篇论文探讨神经交易策略能否在不同风险偏好、交易成本和更高维度市场配置下复现基于模型的对冲。
弱版本：
/goal 复现 Buehler 等人的《Deep Hedging》这太模糊了。没有说哪个部分重要，什么算复现，怎么处理训练状态不可用的情况，怎么区分数值接近和精确重现。
更好的版本：
/goal 利用现有论文材料和本地资源，对 Buehler 等人的《Deep Hedging》进行最强证据支持的复现。
尝试每一个主要结果，验证输出，最终形成一份报告，将复现成功的工作机制、近似训练结果、被阻断的精确复现路径及剩余不确定性区分开来说明强版本有效，因为它指定了证据标准和最终产出物。Codex 不只是在尝试做一个令人印象深刻的复现，它是在用现有证据尽量减少不确定性，同时不夸大证据所能支持的结论。
在实际操作中，这个 Goal 给调查提供了一个具体的操作合约。Codex 用它来：
- 分离核心结论与支撑性结论
- 把这些结论映射到可用证据上
- 重建可以在本地测试的部分
- 标注哪些结论因缺乏可用材料而无法精确复现
最终报告应该保留这些不同层次的支撑，而不是把它们压平成一个单一的"成功"声明。
苏米注：这个研究复现的案例非常典型。Goals 的价值在于它让工作在遇到阻塞后继续推进，同时也让最终语言保持诚实。训练替代品可以支持一个结论，数值接近可以提升置信度，重建的图表可以验证部分结果，但这些都不应该被描述为精确还原了原始实验。Goal 不只是让 Codex 把事情做完，它定义了"做完"意味着什么。
什么时候不该用 Goals
Goals 不适合所有任务。
不要对一行代码的修改用 Goal，不要对简单解释用 Goal，不要对短小的代码评审用 Goal，不要对你只想要一个答案然后停下来的问题用 Goal。普通的 Codex prompt 更适合这些情况。
不要在终点线模糊的时候用 Goal。"把这个做得更好"没有给 Codex 可靠的完成条件。"重构这段代码"也很弱，除非你定义了预期的最终状态、测试和约束。
不要用 Goal 来掩盖不确定性。如果数据可能不可用，在 Goal 里说清楚。如果 benchmark 可能不稳定，说明怎么处理。如果允许用代理证据，定义它应该怎么标注。
Goals 在三个特性同时具备时最有力：有持久目标，有基于证据的完成线，以及路径可能需要多轮调查。
总结
Goals 改变了 Codex 的运作模式。它把一个线程从一连串孤立的 prompt 变成了围绕着明确结果的有状态工作循环。
架构上是有意限制的。Goal 属于线程范围，带有生命周期状态和预算，可以暂停、恢复、清除、完成或被预算停止。Codex 可以继续工作，但只能在用户定义的合约范围内。
这让 Goals 对 Codex 最有价值的工作最有用：调试、优化、迁移、测试和研究。用户提供目标，Codex 跟着证据走，Goal 让两者保持连接，直到工作要么完成，要么诚实地宣告受阻。
对于复杂研究，这是生成一个答案和产出一份审计报告之间的区别。好的 Goal 不只是让 Codex 把事做完，它告诉 Codex"做完"是什么意思。
原文地址：https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex