Claude Code Goal模式测评：AI编程如何像澳洲大叔一样高效？

【导读】澳洲牧羊人Geoffrey Huntley随手写的三行bash脚本，在11天内被OpenAI、Anthropic和Hermes Agent集体采纳，成为AI编程工具的核心功能。

Claude Code再次迎来关键更新。

Claude Code最新推出的/goal功能，旨在让AI编程助手能够持续工作，直至达成预设的完整任务目标。

开发者只需设定明确的完成条件，Claude便会像设定好程序的自动化工具一样，不达目标不停止。

对于深度使用AI编程工具的开发者而言，这一功能的价值不言而喻。

想象一下，你给AI智能体下达一个复杂的代码任务。它执行了几个步骤，修改了几个文件，却突然中断并询问：“下一步需要我做什么？”

然而，核心的bug修复或功能实现可能尚未完成。

尽管AI智能体在代码生成速度和理解能力上飞速进步，但“独立、完整地交付一个任务”这一基础要求，直到2026年初，仍是行业普遍存在的痛点。

随后，澳大利亚的开发者兼牧场主Geoffrey Huntley，用一段仅三行的bash脚本提供了解决方案。

• while:;do
• cat PROMPT.md | claude-code --continue
• done

他将这个脚本命名为Ralph Loop，灵感来源于《辛普森一家》中那个虽时常迷糊却永不放弃的角色Ralph Wiggum。

其逻辑直接而有效：构建一个无限循环，持续将同一个任务指令（prompt）喂给AI智能体。工作进度通过文件系统和Git历史记录来保存，当对话上下文达到上限时，便启动新的会话实例，并读取之前的文件记录继续执行。

这个方法原始，甚至有些粗糙，但其效果立竿见影。

效果显著到足以吸引OpenAI、Nous Research以及Anthropic的注意。

短短11天内，这三家顶尖的AI实验室不约而同地将这三行脚本的核心思想，集成到了各自的官方产品中。

这一事件揭示了一个清晰的行业信号——

迈向更通用人工智能的关键一步，或许不在于模型本身变得更“聪明”，而在于其能否具备可靠的“任务完成”能力。

换言之，AI编程竞争的核心，正从“代码生成”转向“任务闭环与交付”。

11天，三条技术路径，同一个目标

4月30日，OpenAI的Codex率先集成了/goal功能。

Greg Brockman在X平台上简洁地宣布：“Codex now has Ralph loop++ built in.”

一周后，Hermes Agent跟进。四天之后，Claude Code也加入了这一行列。

11天，三家巨头，围绕同一个核心命令，推出了相似的功能。

然而，三家的具体实现方案却截然不同。

简而言之：Codex解决了“记忆持久化”，Hermes Agent杜绝了“任务烂尾”，Claude Code则规避了“自我评估偏差”。

Codex：将目标持久化为数据库记录

OpenAI是三者中行动最快的，其方案也最为简洁和工程化。

在Codex中，/goal被实现为一个持久化的工作流对象，直接存储在本地应用服务器的状态层中。

这意味着，即使关闭终端、合上笔记本电脑或重启系统，你的任务目标都不会丢失。下次启动Codex时，它会自动从上次中断的位置恢复执行。

模型通过一个结构化的`update_goal`工具来汇报进度状态。当token预算耗尽时，系统触发的是“软停止”而非强制中断。

已有用户利用此功能连续运行了14个小时的任务，中间暂停5小时休息后，返回发现Codex能从精确的断点处继续，最终完成了一个复杂的设备驱动项目。

整个方案体现了工程师思维的克制与清晰。

Hermes Agent：单智能体无法完成，则启用智能体团队

相比之下，Hermes Agent的架构更具野心。

在这里，/goal只是其庞大系统的一角。真正的核心是其多智能体看板系统。Hermes将“让AI完成任务”的挑战，从单智能体的耐力测试，升级为多智能体的协同作战。

看板底层基于本地SQLite数据库，同样具备持久化存储能力，确保系统重启后数据不丢失。

当你在看板上创建一个任务卡片时，Hermes会将其自动拆解为多个子任务，并分配给不同的智能体工作进程（Agent worker）。每个worker都是一个独立的操作系统进程，拥有专属的身份、模型配置和工作目录。

看板与/goal是两套互补的机制。/goal负责锁定单个智能体的目标（即Ralph Loop的核心），而看板则负责多个智能体间的任务调度与协作，实现了纵向深度与横向广度的结合。

其最值得称道的是五层防任务失败机制，堪称智能体领域的“工程安全标准”。

第一层，心跳检测。每个worker必须定期向看板发送“心跳”信号，证明其处于活动状态。

第二层，僵尸进程回收。worker若超时无响应，系统将自动判定其失效，回收其分配的任务，并重新派发给其他worker。在macOS系统上，甚至实现了专门的达尔文僵尸进程检测逻辑。

第三层，异常退出拦截。worker若未完成任务就退出，系统会自动将其标记为`blocked`状态，阻止其领取新任务，有效防止了“低效智能体”反复占用资源却不产出。

第四层，产出幻觉拦截。这是最严格的一层。AI仅口头声称“任务完成”是无效的，系统会验证其声称的代码修改是否实际写入到了文件系统中。智能体声称创建了文件但实际未创建？系统会捕获此行为，回滚操作，并重新尝试。

第五层，重试预算控制。每个任务都设有独立的`max_retries`（最大重试次数）参数。超过设定上限后，任务将自动上报给人类处理员，从根本上杜绝了因无限重试导致的系统资源耗尽风险。

Claude Code：执行者与验收者分离

Anthropic是三者中最后发布的，但其方案设计精妙，直指智能体工作的一个核心难题：自我评估的固有偏差。

本质上，Claude Code的/goal是一个会话级别的停止钩子。

你设定一个明确的完成条件（例如“`test/auth`目录下所有测试通过且代码规范检查无报错”），Claude便会开始执行任务。

关键设计在于验收环节。每完成一轮工作后，系统不会让Claude自行判断任务是否完成。

相反，它会将完整的对话记录连同你设定的完成条件，一并发送给一个独立的、更轻量级的模型（默认为Haiku），由这个“裁判”模型进行客观评估。

如果裁判模型判定任务未完成，它必须返回具体的理由（例如“`test_login.py`中仍有2个测试用例失败”）。这个理由会被精准地注入Claude下一轮工作的上下文中，指导其进行针对性修复。

若裁判模型判定条件已满足，目标则被自动清除，任务优雅终止。

值得注意的是，这个裁判模型不调用任何外部工具，不读取文件系统，也不执行命令。它仅基于Claude在对话中产生的文本内容进行判断。

因此，你设定的完成条件，必须是Claude能在对话中提供证据予以证明的事项。条件最长支持4000字符，允许进行非常细致的描述。

你甚至可以在条件中加入约束条款，例如“不得修改其他测试文件”、“在20轮迭代内完成，否则停止”等，从而实现更精细的任务流程控制。

决赛进行时：争夺工作流入口

将视角拉远来看。

Claude Code背后是Anthropic，Codex背后是OpenAI，而Hermes Agent同时集成了这两家的模型，并且也是DeepSeek V4等模型的主要分发渠道之一。

这三条技术路径，恰好覆盖了当前迈向更通用人工智能（AGI/ASI）竞争中的几个主要生态入口。

它们争夺的，本质上是同一个东西：开发者工作流。

哪家的智能体能率先让开发者养成“设定目标即可离开，返回时验收成果”的工作习惯，哪家就占据了下一代开发工作流的战略入口。

因为这种深度集成的工作习惯一旦形成，迁移成本将呈指数级上升。开发者不会轻易离开一个已经提供了成熟看板调度、断点续传、检查点回滚等功能的智能体基础设施。

一个看似简单的`/goal`命令，其背后关乎的是整个智能体工作流生态的护城河建设。这场关于“任务完成度”的竞赛，实际上才刚刚拉开序幕。