在Codex中使用Goal目标模式

在Codex中，目标是持久的任务，能够让一个线程在多个回合中持续朝着既定的结果推进。目标为Codex提供了完成条件：应满足什么条件、如何验证成功，以及哪些约束条件必须保持不变。

对于规模较大的编码任务来说,Codex已经表现的相当不错了,比如可以用于检查仓库状态、错误修复、故障分析、或者实施特定的调整。

目标适用于那些下一步行动取决于Codex在过程中所学内容的任务：比如性能分析、补丁修复、基准测试、重现不稳定的测试，或者将研究问题转化为有证据支持的审计。

这些任务不需要过多的提示,而是需要明确持久的目标。目标模式下,codex能始终持续性的关注当前目标的进度,自动评估工作时候完成,自主决定下一步要采取的动作,而无需你每次都进行中断干预,直白点说就是,目标模式下,你只需要等待最终目标完成之后的结果验收,中途不需要给codex一直要求继续推进的提示。

“目标”模式并非完全没有边界的后台自主运行。而是一个具有明确范围、由用户控制的完成协议。当你定义一个结果,Codex根据线程中的证据进行处理,该目标可以被暂停、恢复、清除、完成,或者因为套餐用量耗尽而终止。

先决条件

• 一个支持目标功能的Codex版本

• 一个具有明确完成标准且可查验证据来源的任务,例如测试、基准测试或者最终成果。

• 提供足够的仓库或研究背景,以便于Codex能够验证进度,而不仅仅是描述进度。

快速开始,使用Goals目标模式

要使用“目标”功能，请安装或更新 Codex，并确认你的版本。该功能自 Codex 0.128.0 起提供。你可以使用下面的命令检查或者更新你的codex版本。

 # 使用npm
 npm install -g @openai/codex@latest
 codex --version
 ​
 #使用Homebrew
 brew update
 brew upgrade --cask codex
 codex --version

然后使用斜杠指令“/goal”并跟上预期结果的来设定一个目标,开启目标模式。比如

 /goal Reduce p95 latency below 120 ms without regressing correctness tests

你可以在同一命令界面中管理生命周期：

 /goal       查看当前目标
 /goal pause    暂停当前目标
 /goal resume   恢复已暂停的目标
 /goal clear    删除当前目标

一旦“目标”生效，Codex 即可检查代码、执行相关命令、进行修改、测试结果，并持续执行直至达到停止条件。

停止条件可能包括成功、暂停、清除、中断、预算限制，或是需要用户输入的阻塞条件。 当你发现自己在每个回合结束后都会重复诸如下面这些类似的话时，请使用“目标”功能。

 Keep going.
 Try the next likely fix.
 Run the benchmark again.
 Now check the tests.
 Continue until this is actually done.

目标模式与提示模式

普通的提示可能是 接下来做这件事。

而目标模式下的提示规则可能是这样的: 持续工作,知道该结果成立。

这种区别很重要。在普通请求中，Codex 会执行当下的指令，报告结果，然后等待。而对于目标，Codex 会将一个持久的目标与该线程关联起来。

回合结束后，它可以检查当前证据，并判断目标是否已达成。如果答案是否定的，且目标仍然有效且在预算范围内，Codex 可以从最新状态继续执行。

这使得“目标”在以下情况下最为有用：正确的下一步行动取决于 Codex 刚刚学到的内容。例如:

 /goal 在保持正确性测试套件通过（显示为绿色）的同时，将 p95 结账基准测试中的结账延迟降低至 120 毫秒以下

这一请求不仅要求提升性能，还为 Codex 提供了可衡量的结果、验证依据和约束条件。Codex 可以运行基准测试，检查热点路径，进行有针对性的修改，重新运行基准测试，执行正确性测试套件，如果结果仍不理想，则继续优化。

如何制定目标

一个好的目标不仅仅是一个更宽泛的提示。它是一份简明扼要的协议,明确了Codex应如何运作、什么才算是成功、以及在尚未达成成功时应采取什么措施。

一个准确的的目标通常会明确以下六点：

• 结果：工作完成后应达到的状态。

• 验证依据：能够证明该结果的测试、基准测试、报告、成果、命令输出或源材料。

• 约束条件：在 Codex 运行期间，哪些方面绝不能出现退化。

• 边界：Codex 可以使用哪些文件、工具、数据、存储库或资源。

• 迭代策略：Codex 在每次尝试后应如何决定下一步的尝试方向。

• 阻塞终止条件：当 Codex 应在何时停止运行，并报告在当前限制下已无可行的路径时。

一个不错的目标设定模版:

 /目标 <期望的最终状态>，由 <具体证据> 验证，同时满足 <约束条件>。使用 <允许的输入、工具或边界条件>。在迭代之间，<Codex 应如何选择次优行动>。如果遇到阻碍或已无有效路径，<Codex 应报告什么内容，以及什么能推动进展>。

比如,下面这个目标虽然也能运行,但是略显粗糙:

 /goal 将 p95 结账延迟降低至 120 毫秒以下，同时不导致正确性测试出现退化

我们可以优化一下

 /goal 将 p95 结账延迟降低至 120 毫秒以下（通过结账基准测试验证），同时确保正确性测试套件保持“绿色”状态。仅使用结账服务、基准测试 fixture 及相关测试。在每次迭代之间，记录发生了哪些变化、基准测试显示的结果，以及接下来最值得尝试的实验方案。如果基准测试无法运行或已无有效路径，则记录已尝试的路径、收集到的证据、阻塞问题以及下一步所需的输入，并停止当前迭代。

在研究和调查中，同样适用这一原则。在工作开始之前就应明确证据标准，尤其是在可能无法获得确凿证据的情况下：

 /goal 利用现有材料和当地资源，尽可能准确地重现该论文的研究结果，并提供最有力的证据支持。在可行的情况下尝试复现主要结果，尽可能验证输出结果，并在报告结尾明确区分已确认的发现、近似重建、被驳斥的论点以及仍存在的不确定性。

这种目标既为 Codex 留出了探索的空间，又能确保最终结果的真实性。它通过明确界定“完成”、“受阻”和“尚不确定”的含义，超越了“继续推进”这一简单要求。 当任务明确但目标尚不明确时，Codex 可以协助撰写目标本身。一个简单的两步工作流效果很好：

• 首先，用通俗易懂的语言描述工作内容，并让 Codex 将其转化为目标草案；

• 其次，在激活该目标之前，审查该草案并完善成功条件、验证范围、约束条件以及受阻终止条件。

举个例子:

 请帮我将此内容转化为一个有力的 `/goal`：我希望 Codex 能继续针对这个不稳定的检出测试进行排查，直到我们通过证据修复该问题，或者能够明确解释是什么阻碍了进展。

随后，Codex 可以提出一个更完整的目标，询问任何真正必要的缺失细节，并为你提供一个更简洁的 /goal 供你使用。这其实算是一种Codex的自举,即让codex自己拟定一份目标,然后自己来用目标模式完成这个目标。

当目标处于活动状态时，会有哪些变化

当一个目标处于活动状态时，会有三点变化。

• 首先，目标始终可见。如果 Codex 运行的测试失败，该线程仍会保留原始目标。如果基准测试结果有所提升但未达到阈值，Codex 仍可继续运行。如果研究路径遇到数据缺失的情况，Codex 可以在不偏离研究标准的前提下调整证据计划。

• 其次，空闲线程可以继续执行。当另一个回合处于活动状态、用户输入处于队列中，或其他线程工作待处理时，Codex 不会继续执行。只有当线程处于空闲状态，且目标处于活动状态并在预算范围内时，它才会继续执行。

• 第三，完成必须基于证据。不应仅因模型认为目标“可能已完成”就将其标记为完成。只有在对照相关文件、测试、日志、基准测试输出、生成的成果或其他具体证据验证了目标后，才应视为完成。 这就是设计的核心：Codex 可以持续推进，但是否完成由证据决定。

Codex 中目标的设计方式:

目标以持久化的线程状态形式实现，而非全局内存，也非项目级指令。这一设计选择至关重要：目标属于包含相关上下文的线程，包括 Codex 检查过的文件、执行过的命令、生成的差异、查看过的日志以及构建的推理轨迹。

在架构层面上，一个“目标”（Goal）是一种持久的、在线程范围内有效的状态。它记录了Codex在一段时间内评估该线程所需的目标、生命周期、预算以及进度统计信息。关键的界定在于作用域：“目标”属于当前线程，而不属于全局内存或项目指令。

Codex将该状态视为用户、模型和线程之间的契约。一个“目标”可以处于活动、暂停、完成或预算受限状态。这些状态决定了 Codex 是否可以继续执行、是否应等待用户，以及是否应汇总进度而非开始新工作。

继续执行是事件驱动的，而非简单的循环。Codex 仅在安全边界处检查是否继续执行：当一个轮次结束时、当没有其他待处理工作时、当没有用户输入排队时，以及当线程处于空闲状态时。

调度器的行为设计上刻意采取保守策略。仅涉及规划的工作不会触发继续执行。中断会暂停目标的执行。在适当的时候，恢复线程可以重启该目标。如果某次继续执行轮次未调用任何工具，则会抑制下一次自动继续执行，以避免 Codex 陷入空转。

提示层强化了这一架构。延续性提示使Codex围绕当前目标展开工作，但这些提示在完成前也需要经过审核。Codex必须将目标与具体证据进行比对：文件变更、已执行的命令、通过的测试、基准测试结果、生成的成果或研究证据。

预算管理是显式的。当达到预算上限时，Codex 应停止实质性工作，总结进展和阻碍因素，并确定下一步有用的行动。达到预算上限并不等同于完成目标。

工具契约限定了生命周期控制权限。模型可以启动一个目标，但只有当证据支持完成时，才能将现有目标标记为已完成。暂停、恢复、清除以及受预算限制的过渡仍由用户或系统控制。

需要牢记的架构是：一个目标是一个线程作用域内的完成契约。它结合了持久的目标状态、生命周期控制、延续策略、预算核算以及基于证据的完成机制。关键不在于让 Codex 无限循环，而在于让目标持续存在，直到证据表明工作已完成。

将一个不明确的目标转化为一个明确的目标

更强化的版本为 Codex 提供了三样东西：一个结果、一种验证方法和一个约束条件。它还为 Codex 提供了一种判断何时不应停止的方法。如果 p95 从 180 毫秒提升到 135 毫秒，则该目标尚未达成。如果延迟降至 120 毫秒以下，但正确性测试失败，则该目标尚未达成。如果无法运行基准测试，Codex 必须指出该阻碍因素，而不是宣布成功。

这一规则同样适用于性能优化之外的工作：目标应具体到足以进行验证，但又应开放到足以支持探索。

一个目标应足够具体以便审计，但又应足够宽泛以让 Codex 选择下一步行动。如果真正的问题在于上游依赖项，那么“修复失败的代码检出测试”可能过于狭窄；而“改进整个系统”则过于宽泛，因为缺乏可审计的切入点。相比之下，“在不改变公共 API 行为的前提下，让当前分支上的代码检出测试套件通过”是一个更好的目标。

一个粗糙版本的目标可能是这样的:

 /goal 为该功能编写文档

而一个健壮完善的目标应该是:

 /goal 为“Goals”创建一个文档页面，说明其生命周期、命令接口以及两个示例。验证该页面能否在本地构建，并确保所有引用的命令与当前 CLI 的行为一致。

第二个目标为Codex提供了可供检查的对象：一个页面、一个构建命令以及命令的行为。 对于研究目标而言，这种严谨性显得尤为重要。在调查开始之前，应先明确证据标准：什么算作精确重现，什么算作部分重建，什么算作间接支持，以及什么应被视为受阻。

一个有力的研究目标应要求 Codex 建立主张清单，将主张与证据对应，实施可行的部分，标记阻碍因素，并生成一份审计报告，将已确认的主张、仅具支持作用的证据、受阻的主张以及剩余的不确定性区分开来。 这使得目标足够具体，便于进行审计，同时又不会预先规定整个路径。Codex 可以自主选择下一步行动，但完成标准是固定的。

什么时候不建议使用目标模式

目标并非适用于所有任务的合适工具。 对于一行代码的修改、简单的说明、简短的代码审查，或是只需一个答案即可结束的问题，请勿使用“目标”。此类情况更适合使用普通的 Codex 提示。

当目标不明确时，请勿使用“目标”。“改进此代码”无法为 Codex 提供可靠的完成条件。“重构此代码”同样效果有限，除非你明确定义了预期的最终状态、测试用例和约束条件。

不要利用“目标”来掩盖不确定性。如果数据可能不可用，请在“目标”中说明这一点；如果基准测试可能不稳定，请说明如何处理；如果允许使用替代证据，请定义其应如何标注。

参考与引用:

• https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex#quickstart-using-goals