用好 Codex Goal,关键就这三步
前些日子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 “一直跑”而是让它围绕一个可验证的目标持续循环、持续检查、持续修正直到任务完成。