Codex Goal 深度解析：让 AI Agent 连续工作数小时的目标驱动工作流

Tue, 26 May 2026 23:44:37 +0800

浏览器、终端和 IDE 里的 AI Agent 已经越来越会写代码了，但很多人真正遇到的问题不是“它不会做”，而是“它做了一半就说完成了”。

简单 ticket 很适合交给编程 Agent：修一个按钮、补一个接口、改一段文案、加一个测试。目标清楚，边界很小，验证方式也直接。但一旦任务变成大型迁移、跨模块重构、测试套件修复、依赖升级、prompt 评测优化，Agent 就很容易出现一种典型问题：

它完成了一个看起来合理的中间状态，然后过早停下。

Codex Goal / Persistent Goals 这类能力要解决的，正是这个“提前收工”问题。它的重点不是让 Agent 多跑几轮，而是让 Agent 围绕明确目标持续推进，直到满足可验证的完成标准。

Codex Goal 解决的不是循环，而是停止条件

很多长任务自动化会从一个粗糙方案开始：

`1`	`继续检查代码，修复问题，直到没有错误。`

或者更机械一点：

循环 10 次：
1. 运行测试
2. 让模型修复失败
3. 再运行测试

这类粗糙循环看起来能让 Agent 工作更久，但它有两个硬伤：

它不知道什么时候真的该停。
它也不知道“没有继续报错”是否等于“任务完成”。

Codex Goal 的关键不是循环次数，而是 goal、state、judge stop condition 三件事。也就是说，Agent 需要知道这次工作的目标是什么，当前已经完成到哪里，以及哪些证据能证明任务真的结束了。

这也是长任务 Agent 的核心分水岭：不是“多执行几步”，而是“能不能判断自己还差什么”。

Goal 和普通 prompt 的区别

普通 prompt 更像一次性指令：

`1`	`把这个项目的测试修好。`

Goal prompt 则更像一份小型任务合约：

目标：修复当前仓库中失败的测试。
范围：只修改 src/ 和 tests/，不要改构建脚本。
完成标准：npm test 全部通过，且新增修改不引入 lint 错误。
验证命令：npm test && npm run lint。
失败处理：如果超过 3 次仍无法修复，输出剩余失败用例、已尝试方案和阻塞点。
输出：总结修改文件、修复原因、验证结果。

两者最大的差别在于，Goal prompt 把“完成”定义清楚了。

如果没有清晰的完成定义，Agent 很容易把“我改了代码”误判成“我完成了任务”。如果有明确的完成标准，Agent 就必须围绕测试、日志、diff、构建结果、eval 分数这些外部证据继续推进。

为什么 LLM judge stop condition 很关键

长任务里最难的不是让 Agent 执行命令，而是让它判断：

现在是否真的完成了？
是否只是通过了局部测试？
是否修了一个问题，却引入了另一个问题？
是否需要继续搜索、继续运行验证、继续回滚某个方向？

这就是 LLM judge stop condition 的价值。

理想状态下，Agent 不应该只看“最后一个命令是否退出码为 0”。它还应该综合判断：

用户给出的完成标准是否全部满足；
修改是否限定在允许范围内；
测试、lint、build、eval 是否都跑过；
失败日志是否还有未处理项；
是否存在明显的副作用和风险；
最终输出是否能让人类快速复核。

换句话说，judge 不只是“判定成功”，还要防止 Agent 自我安慰式收尾。

哪些任务适合交给 Goal

Codex Goal / Persistent Goals 更适合那些需要多轮探索和验证的复杂编程任务，例如：

代码迁移：从旧框架迁到新框架，从 CommonJS 迁到 ESM，从旧 API 迁到新 API。
大型重构：拆分模块、整理边界、替换重复实现、降低复杂度。
测试修复：连续分析失败用例，定位原因，修复后反复验证。
依赖升级：升级框架、SDK、构建工具，同时处理破坏性变更。
Prompt 评测优化：运行评测，分析失败样本，调整 prompt 或工具调用策略。
技术债清理：围绕明确规则逐步替换旧写法，并保持行为不变。

这些任务的共同点是：中间状态很多，失败原因不一定一次能看清，完成标准必须依赖验证结果。

哪些任务不适合只靠 Goal

Goal 并不是万能的。下面这些任务如果只靠一个长提示词，风险会很高：

目标非常模糊，例如“把产品增长做好”。
周期很长，例如连续几周的 SEO、GEO、广告投放优化。
需要跨系统调度，例如同时处理内容、数据、投放、客服和业务指标。
涉及生产风险，例如数据库变更、线上配置、财务操作、账号权限调整。
缺少验证手段，例如没有测试、没有指标、没有日志、没有人工验收标准。

这类任务更像 Mission，而不是 Goal。

Goal 适合小时级到一两天的深度执行。Mission 则需要状态、历史、调度、人类审批、阶段性复盘和长期指标。比如 SEO / GEO / Ads 优化，不能只是让 Agent 循环写内容或调参数，还要持续记录策略、实验、数据变化和下一步计划。

写好 Goal Prompt 的模板

一个好用的 Goal prompt，至少应该包含下面几块内容：

目标：
用一句话说明最终要达成什么结果。

背景：
说明当前问题、相关文件、业务约束、已有尝试。

范围：
允许修改哪些目录、文件、模块；哪些地方不要碰。

完成标准：
列出可验证的 definition of done。

验证命令：
写清楚需要运行的测试、lint、build、eval 或脚本。

失败策略：
如果无法完成，要求 Agent 输出失败原因、已尝试方案、剩余阻塞点。

风险边界：
禁止破坏性操作，生产配置、密钥、数据库、外部服务需要人工确认。

交付格式：
要求总结修改点、验证结果、风险和后续建议。

真正决定长任务效果的，往往不是 prompt 写得多漂亮，而是完成标准是否足够明确、足够可验证。

Goal Buddy 的价值：先帮你把任务说清楚

很多长任务失败，不是因为 Agent 能力不够，而是因为人类一开始没有把任务拆清楚。

Goal Buddy 这类辅助工具的价值在于：在正式把任务交给 Agent 之前，先帮你准备目标、边界、完成标准和验证方式。它像一个任务预检器，会追问：

这个任务的最终可见结果是什么？
哪些目录可以改，哪些不能改？
成功后跑什么命令证明？
失败时要不要继续尝试，最多尝试到什么程度？
是否需要分阶段提交？
哪些操作必须让人类确认？

这一步看似啰嗦，但它能显著减少 Agent 中途跑偏、过早停止，或改出一堆难以复核的代码的概率。

给 Codex、Claude Code、OpenCode 用户的实践建议

如果你正在用 Codex、Claude Code、OpenCode、OpenClaw 或类似编程 Agent，可以按下面方式处理长任务：

先提交当前工作区，保证有干净回滚点。
把任务写成 Goal，而不是一句泛泛的需求。
明确允许修改的范围和禁止修改的范围。
给出验证命令，最好让 Agent 每一轮都能自己运行。
要求 Agent 在无法完成时报告阻塞点，而不是硬编一个“完成”。
对高风险操作设置人工确认，例如删除文件、改数据库、改部署配置。
最后只接受带有测试结果和修改总结的交付。

长任务 Agent 的正确使用方式，不是“让它自己随便干一晚上”，而是给它一个清楚的目标、坚实的护栏，以及可验证的出口。

小结

Codex Goal / Persistent Goals 的意义在于，把编程 Agent 从“执行一句指令”推进到“围绕一个目标持续工作”。

它最适合复杂但边界明确的工程任务：迁移、重构、测试修复、依赖升级、评测优化。它不适合完全模糊、周期很长、缺少验证标准的业务任务；那些更应该设计成 Mission 系统。

未来 AI Agent 的竞争点，很可能不只是模型会不会写代码，而是能不能围绕目标持续推进、正确判断停止时机，并把过程留给人类复核。

参考：

长任务 on KnightLi的博客