前些日子，Codex 里出现了一个新命令：/goal。可能已经有小伙伴用上它了。
Goal 的使用方式很简单：在 prompt 开头输入 /goal，再告诉 Codex 你希望它完成什么目标。接下来，Codex 就会围绕这个目标持续循环，直到它认为目标已经完成。
Goal 模式不是普通的一轮对话，也不是你让模型“帮我改一下代码”那么简单。它更像是一个持续运行的 Agent 循环：执行动作、评估结果、判断是否达成目标，如果没有达成，就继续下一轮。所以，要想让 Codex Goal 真正跑得好，prompt 的写法也要稍微变一下。
OpenAI FDE Chris Hayduk 上周分享了自己使用 Codex Goal 的经验。本文就基于他的分享，展开讲讲 Goal 模式应该怎么用。
Codex Goal 的循环机制
图注：Goal 模式不是“一次性回答”，而是一个持续循环。
可量化的目标
现在很多人和 AI 交互的时候，一般都会给一些比较模糊的指令。比如，你只说一句：帮我把这段代码改好一点。对于普通对话，模型大概率也能理解你的大致意思，甚至做出一些还不错的修改。
但在 Goal 模式下，这种模糊的目标反而很容易出问题。
Goal 模式的核心是一个循环：Agent 会先执行一些动作，然后评估这些动作的结果，再判断当前结果是否满足目标。如果满足，就停止；如果不满足，就继续。
这里最关键的是“判断是否满足目标”这一步。
如果目标本身很模糊，比如“让我的代码更好”，Agent 就很难知道什么时候该停。什么叫“更好”？更好到什么程度才算完成？是更快、更干净、更稳定，还是更容易维护？
这类模糊目标通常会带来两种失败模式：一种是 Agent 很快放弃，工作几分钟就停下来；另一种是 Agent 一直停不下来，不断做一些没有明确方向的修改，试图满足一个本来就无法判断是否完成的目标。
更好的写法应该是：将 src/data_loader.py 中的代码运行时间降低 20%，同时确保现有单元测试和集成测试全部通过。
这个目标就清楚很多。它有明确的量化指标：运行时间降低 20%。也有明确的约束：不能破坏已有单元测试和集成测试。
Codex 就能知道自己要优化什么、如何验证，以及什么时候应该停止。
图注：模糊目标 vs 可量化目标
Chris Hayduk 提到一个很有意思的例子。他曾经让 Codex 把一篇 NeurIPS 预印本论文改成 ICML workshop paper 的格式。问题是，ICML 的格式要求很多，而且都写在 LaTeX 文件里，不太适合直接拿来做自动评估。
为了解决这个问题，他先让 Codex 把这些格式要求提取成一个 Markdown checklist，里面有 200 多条格式和风格规则。再把 Codex 的目标写成：根据 checklist.md，将 NeurIPS 论文改成 ICML 格式，但不要修改论文的技术内容。
这样一来，原本很难评估的“改成 ICML 格式”，就变成了一个可以逐条检查的任务。Codex 只需要判断：这 200 多条规则是不是都完成了。
虽然每一条规则本身可能仍然有一点模糊，但相比直接让模型理解“格式改好了吗”，让它逐条检查 checklist 会稳定得多。
作者还会让 Codex 在完成某些检查项后，把 checklist 里的项目勾掉。这样一方面能让 Codex 把进度持久化到文件系统里，另一方面用户也可以直观看到它做到哪一步了。
反馈循环尽量短
如果你希望 Agent 自己判断“我做得怎么样”，那它就必须有一个测试和评估机制。这个机制越快，Codex 获得反馈就越快；Codex 越容易运行这个测试，它就越容易持续推进。
比如，你让 Codex 改进一个机器学习算法的架构。如果每次实验都要跑完整训练集，可能一次评估就要几天。这种反馈循环太慢，Agent 很难高效迭代。更好的方式，是先让它在更小的模型规模、更小的数据子集上做实验。这样 Codex 可以快速测试不同思路，而不是每试一次都卡在完整训练流程上。Chris Hayduk 在做蛋白质结构模型架构搜索时，用了 NanoFold 这个规模更小、但样本覆盖较好的数据集来跑实验。这样一来，原本完整训练集需要几天才能得到结果的评估，被压缩到了几分钟。
这就是 Goal 模式里很关键的一点：你不只是要告诉 Agent 目标是什么，还要给它一个足够快、足够明确的验证方式。
当然，反馈循环变快不代表可以牺牲评估质量。关键是找到一个折中点：既能缩短评估时间，又不至于让模型拿到一个完全不可靠的分数。
图注：反馈循环越短，Agent 迭代越快
可持续记录的 Markdown 文件
Goal 模式可以让 GPT-5.5 在很长时间里持续运行，甚至跑上好几天。
即使 Codex 本身有不错的上下文压缩能力，长时间任务仍然很难完全依赖模型记忆。时间一长，模型很容易忘记自己之前试过什么、哪些方法失败了、当前计划为什么这么推进。
所以，这里建议：不要让模型把所有上下文都记在脑子里，而是给它准备几个 Markdown 文件，让它把计划、实验和实时想法写下来。
Chris Hayduk 通常会在 Goal 模式中准备三个文件：
PLAN.md：用来记录整体计划。这里可以写 Agent 接下来准备怎么推进，也可以提前放入你自己的一些初始思路。EXPERIMENTS.md：用来记录每一次实验的细节。这个文件在机器学习任务里尤其有用，但也可以迁移到很多其他类型的任务中。通常可以包括实验标题、尝试了什么、结果如何。EXPERIMENT_NOTES.md：这是 Agent 的实时笔记。它可以按时间顺序记录 Agent 在执行过程中的想法、判断和中间观察。这个文件很适合用来审计 Agent 的执行过程：你可以看到它为什么这么做，以及是否需要把它拉回正确方向。
在这三个文件里，原文作者认为最重要的是 EXPERIMENTS.md。
因为它能让你和 Agent 一起回顾之前已经尝试过哪些方法、哪些有效、哪些无效，以及为什么失败。对于长时间运行的 Goal 模式来说，这类外部记忆非常重要。
否则，Agent 很容易在几个小时后重复尝试同样的失败路径，或者忘记某个已经被验证过的方向。
Goal 模式用好的关键
Codex Goal 真正适合的，不是那种一句话就能完成的小任务，而是有明确目标、需要持续推进、可以反复验证的长任务。
想用好它，核心其实就是三件事：
第一，目标要清晰可衡量，不要只说“让代码更好”。
第二，反馈循环要足够短，让 Codex 能快速知道自己是否取得进展。
第三，给它 Markdown 文件记录计划、实验和过程，别让长任务完全依赖上下文记忆。
当这三件事准备好之后，Codex 才更像一个能持续推进任务的 Agent，而不是一个只会响应单轮 prompt 的代码助手。
换句话说，/goal 的重点不是让 Codex “一直跑”，而是让它围绕一个可验证的目标，持续循环、持续检查、持续修正，直到任务完成。
