关于 Goal 的 What、Why、How

最近在 X 上看到又掀起了一波关于 AI Agent /goal 模式的讨论。

大家对 /goal 的看法不一。但看下来，似乎很少有从本质、原理以及具体实现差异上进行的深度探讨。

所以，这篇文章想从第一性原理出发，聊聊 Goal 模式的底层实现，以及我对它当前价值和未来演进的判断。

先说下我的判断：

1. 核心实现很简单：在 AI 准备停下来时检查目标有没有完成，没完成就让它继续。（但实现落地上，还是有很多细节需要考虑的）

2. 现阶段依然有价值：在当前阶段（2026 年 9 月），即使是 SOTA 模型，长程自驱力依然不足，Goal 模式能够有效解决模型偷懒的问题。

3. 未来一定会被模型内化：由于 Goal 很大程度上是在 Harness 层为当前模型能力的缺陷打补丁，未来这种机制必然会被模型内化。

还是像之前的文章一样，我们从实际的问题出发：为什么要用 Goal？不用 Goal，会遇到什么问题？

然后再看 Codex 和 Claude Code 是怎么解决这些问题的，以及它们为什么采用了不同的策略。

一、第一性原理：我们为什么需要 Goal？

我们想用 Goal，通常是希望把一个较大的任务交给 AI，让它自己持续往下做，而不是每隔几分钟就回来找我们一次。

比如迁移一个项目、完成一个较大的需求，或者围绕某个性能指标持续优化。我们希望它能自己工作几个小时，甚至更久。

对于长程任务，我们可以将面临的挑战拆解为三个核心问题：

1. 防止漂移：长上下文任务，尤其是经历了多轮上下文压缩后，如何保证它还记得最初的目标和约束？
2. 完成依据判断：如何准确判断这个任务已经真正完成？
3. 防止中途停止：明明还有事情可以继续做，为什么要停下来等人发一句「继续」？

1 和 2 其实更多依赖于人对 Goal 任务的设定是否足够清晰、可验证，但 3 就纯是模型犯蠢需要靠 Harness 来驱动了。

大家平时使用 AI Agent，如果多观察一下，肯定遇到过这样的场景：

你已经把需求说清楚了，它做了一部分，然后告诉你：

目前已经完成了功能 A，接下来还需要完成 B。需要我继续吗？你说继续我就开始下一个任务

这不是废话。。。我当然需要你继续啊

最烦的地方在于，它不是不知道下一步该做什么，而是知道还有下一步，却还是把控制权交回来了。

于是人就得守在电脑前，时不时看一眼它有没有停。停了，就发一句「继续」。你已经说过「不用问我，你自己继续就行」，但过了一会儿，它又停下来了。

至少在我的使用体感里，今年上半年这种情况尤其明显。到了现在，也就是 2026 年 9 月，顶级模型已经改善了很多，但仍然没有完全消失。即便用 GPT-6 Astra（比起 5.6 Sol，这方面的能力甚至倒退了），也还是会遇到类似的问题，尤其是在任务比较长、经历多轮压缩之后。

生产力的提高来自于偷懒。

人一直蹲在电脑前，防止 AI 偷懒，工作内容就是给它发「继续」，实在是太烦了。既然这件事有明确的触发时机，我们能不能让程序来代劳？

这就是 Goal 最朴素的出发点。

二、一个 Hook，就能实现核心逻辑

其实在有专门的 Goal 功能之前，就可以通过一些比较简单的方式实现类似的效果了。

今年 3 月左右，我做过一次工具的语言迁移，把原来的 JS/TS 实现迁到 Go。这件事在之前的文章《模型与工程：从第一性原理看 AI Engineering 的范式转移》里也提到过。

当时我先让 AI 梳理了一份迁移计划，把需要迁移的功能、对应的验证方式整理成 Markdown 待办清单。然后写了一个非常简单的 Hook，在 AI 准备结束当前这轮执行时，通过 Hook 执行脚本去检查计划里是不是还有没勾选的任务。

有，就阻止它结束，并返回一段提示：

迁移计划中仍有未完成的任务。请重新阅读迁移计划，继续完成剩余工作，并在验证通过后更新任务状态。

没有，就正常放行。

Hook：在 Agent 会话生命周期的各个节点（如执行工具前、停止会话前等等）插入的一个程序，会在对应的节点自动触发，通过 Hook 我们可以写代码来介入 Agent 的执行过程。Stop Hook 对应停止会话前的 Hook。

当时用的 Harness 是 Claude Code，接的模型是 GPT-5.4。就是这样一个很简单的 Hook，让它连续跑了好几个小时，把迁移任务做完了。

后来在另一个长程任务里，我甚至用了一个更简单的版本：不检查 Markdown 清单，只维护一个小 JSON，记录任务描述和完成状态。

大概长这样：

{
  "goal": "按照 migration-plan.md 完成迁移，并通过约定的验证",
  "completed": false
}

每次 AI 想停下来，Hook 就看一眼 completed。

还是 false，就告诉它：

当前目标尚未完成。请继续执行；只有在确认目标及验收条件全部满足后，才能将 completed 改为 true。

它确认完成后，自己把字段改成 true，下一次检查就会放行。

就这么简单。

当然，这个实现有一个很明显的前提：我们相信模型不会为了结束任务，随便把这个字段改成 true。

Hook 只知道字段有没有变，不知道现实里的任务究竟有没有做完。这个完成状态靠不靠谱，取决于模型能不能认真检查自己的产出。

这也是后面两种实现最值得讨论的区别。

接下来我们通过 Codex、Claude Code 这两个常见的 Harness 来讲讲它们各自的实现。

三、Codex：让执行任务的 Agent 自己判断

Codex CLI 是开源的：https://github.com/openai/codex，大家可以通过源码来自己分析

它的核心思路，和前面那个 JSON 版本非常接近：保存一个持续存在的目标，由执行任务的 Agent 更新目标状态；当前一轮结束后，只要目标仍处于进行中，Harness 就自动发起下一轮，注入提示词，把目标和续跑要求重新交给主 Agent，让它继续干。

注入的提示词模板源码：https://github.com/openai/codex/blob/main/codex-rs/ext/goal/templates/goals/continuation.md

模型可以结束当前这一轮，但结束一轮，不等于完成目标。只要目标还在进行中，系统就会继续推动它。

相比我之前在本地随手维护一个 JSON，Codex 把这些能力正式集成进了 Harness：目标的持久化、状态管理、恢复，以及 Token 预算等，都有对应的实现。达到预算限制或进入阻塞等状态时，系统也会停止自动续跑，而不是无限循环。

这里面最重要的一点是：

谁来判断目标已经完成？

在这套机制里，主要还是执行任务的 Agent 自己。

它认为目标完成了，就调用 update_goal，把状态标记为 complete。Harness 看到这个状态，就不再继续推动。

对真正的阻塞（同一种阻塞至少连续出现三轮），确认无法在没有用户输入或外部状态变化的情况下取得进展，再标记为 blocked。

这套策略依赖模型有比较可靠的自我审查能力和自驱力。

我们假定模型在已知目标的情况下，不会敷衍了事、不会随便给自己打个勾就宣布下班。它可以偶尔忘记继续，可以习惯性地结束一轮，但当目标被重新摆到眼前时，应该能够承认「我还没做完」。

四、Claude Code：独立上下文，对抗性审查

Claude Code 非开源，且之前源码泄露的时候还没有 Goal 机制，所以想要分析其底层实现，我们得通过抓取网络请求、分析会话文件来进行，这部分工作可以使用 https://github.com/liaohch3/claude-tap 这个工具来完成，claude-tap 可以比较清晰地查看 API 流量和上下文，对于我们的分析非常有帮助。

它的主流程其实没有特别大的区别，同样是设定目标、执行任务、在准备结束时检查，然后决定放行还是继续。

区别在于，它把「任务是否完成」交给了另一次独立的模型调用。

Claude Code 官方文档把 /goal 描述为一个会话级的、基于提示词的 Stop Hook：主 Agent 结束一轮后，系统会把 Goal 条件和当前会话内容交给配置的快速模型，让它判断目标是否达成。

主 Agent 的工作是完成任务；验收模型的工作，是根据目标和已有证据判断它到底做完了没有。

没有达成，就返回原因，Harness 把这个原因交回主 Agent，作为下一轮继续工作的依据。达成了，就允许结束；评估器判断条件无法满足时，也可以标记为失败或受阻从而停止 Goal。

可以把它理解成一种对抗性的验收：干活的人自己说了不算，得专门的评估人员来检查任务。

这里最重要的，倒不是说一定要使用不同的模型，主要还是把执行和判定的上下文隔离开。验收调用不需要继续沿着主 Agent 的思路干活，它拿着自己的审查任务，重新判断当前证据是否足以支持「已经完成」。

需要注意的是，这里的验收模型不具备任何工具调用的能力，对当前任务的评估完全来自于 Goal 的内容以及主 Agent 所处的上下文。因此，主 Agent 有没有把验证结果真正做出来、展示出来，非常重要。

五、为什么它们选择了不同的策略？

把这两套实现放在一起看，我觉得最值得关注的不是 Hook 怎么注册、状态怎么存，而是它们对模型做了什么假设。

Codex 的做法更接近：

你可能会提前停下来，但只要我把目标重新提醒给你，并要求你严格自查，你应该能判断自己还有没有做完。

Claude Code 的做法则多加了一层：

你不但可能提前停下来，还可能对自己的结果过于满意。所以，是否完成这件事，不能只听你自己说。

这个区别，和我今年 3 月用 Hook 跑长程任务时的体感非常接近。

前面说过，我当时是在 Claude Code 里接 GPT，而不是直接使用 Claude 模型。就是因为同样的任务，Claude 草草了事，任务倒是都标记完成了，但结果嘛。。。

六、为什么 /goal 终将被模型吞噬

讲到这儿，相信大家应该大概能理解为什么我前面说，goal 这部分能力一定会被模型内化掉。我们围绕着 goal 做的这一堆事其实都是在解决模型的几个短板做补齐。

如果模型做到了长上下文注意力机制不漂移、上下文压缩不丢失关键上下文、别在该继续的时候停下来…

那我们 Harness 这一层就完全不用干这部分事，放开交给模型，只需要做好持久化、预算控制等外围基础功能就够了。

Harness 就是在不断为模型的能力短板做补齐增强，不同时期、不同模型我们需要做的事都不太一样。

现在需要补，不代表永远需要补；未来可能不需要，也不代表现在装上这个补丁就没有价值。

七、怎么用好 Goal？

讲完原理，最后说说使用。

这一部分其实之前的文章《模型与工程：从第一性原理看 AI Engineering 的范式转移》也都写过了，Codex 官方的文档也有详尽的描述，有兴趣的可以看看。我这儿就只简单总结下我的观点。

我觉得最重要的就是想清楚：你要什么结果，以及根据什么判断这个结果已经达成。

描述清楚你希望 AI 交付一个什么样的结果永远都是最重要的：

对于性能优化类的 goal，可以是从指标 x 提升到 y，这一类需求是非常容易量化的；

对于大型需求类的 goal，可以先和 AI 对齐产出一份完整的 Spec 文档，里面写清楚要实现哪些功能以及每个功能的验收标准，需求越大，对于输入的要求就越高，输入的越清晰、精准，执行过程中也就越不容易跑偏。前期不愿意花精力写清楚自己的预期，那就和许愿抽卡差不多了，只能祈祷 AI 能和你心有灵犀，从模糊的需求中识别到你想要的具体是什么了。

此外，如果想要 Agent 能在更长程的任务中，持久聚焦不跑偏，其实还有很多工作可以做，边界条件、执行约束、阻塞条件等等，这也是我们做 Harness 工程的价值所在。