/goal 模式：让 Agent 自己跑完全程HERMES & AGENT ENGINEERING · 课时 08

8.1 一个场景

你下班回家，累得不想动，但又想看看关注的 UP 主今天有没有更新。

传统做法是写一条详细的提示词：第一步打开浏览器，第二步访问关注列表，第三步逐个检查视频，第四步提取字幕，第五步生成摘要，第六步推送通知。你写了半天，Agent 按部就班地执行。

/goal 模式的写法完全不同：

检查我 B 站特别关注分组的所有 UP 主，
找出过去 24 小时内的新视频，
提取字幕生成摘要，
把日报推送到我的微信。
完成标准：所有 UP 主都检查过了，日报已推送。

一句话定义目标，Agent 自己跑完全部流程。你合上电脑，第二天早上看结果。

8.2 /goal 从哪来

"给 Agent 一个目标，让它自己跑"这个想法，最早可以追溯到 2025 年底开发者 Geoffrey Huntley 提出的"Ralph Loop"。它的本质是一个极简的 bash 脚本：

while :; do
  cat PROMPT.md | claude
done

为什么叫 Ralph Loop？

Geoffrey Huntley 把这个循环命名为 "Ralph Wiggum Loop"——Ralph Wiggum 是《辛普森一家》里的角色，特征是"笨拙但永不放弃"。用这个名字是在自嘲：这个方案在工程上很粗糙（任何一次迭代都可能输出烂代码），但靠着机械重复加自我修正，最终能收敛到正确结果。

Huntley 自己说："This technique is deterministically bad in an undeterministic world"——任何单次运行都不靠谱，但跑足够多次就能成功。这个名字背后的哲学是：不追求 AI 每一次输出都完美，而是用持续迭代来逼近正确结果。

每次迭代把固定的提示词文件喂给 Agent，让它持续推进任务。Ralph Loop 的关键创新不在技术复杂度，而在于纪律性：每次迭代前把上下文重置到固定的锚点文件，进度通过磁盘文件持久化，而不是依赖模型的上下文窗口记忆。

这个概念在社区引起了不小的反响，但也暴露了一个问题：它完全依赖外部 bash 脚本驱动，没有内置的状态管理，没有进度持久化，没有预算控制。能跑，但很脆弱。

2026 年 4 月 30 日，OpenAI 在 ChatGPT CLI 0.128.0 中发布了 /goal 命令，把 Ralph Loop 的思路做进了内核里。Greg Brockman 在 X 上的说法是："codex now has a built in Ralph Loop++"。

这不是简单地加了一个循环。/goal 背后是一整套目标生命周期管理机制：有状态机（active / paused / achieved / unmet / budget_limited），有应用层的 API 接口，有模型级的工具（Agent 可以查询和更新目标状态），有运行时延续（每轮结束自动注入延续提示词），还有终端界面的暂停、恢复、清空控制。

一个月后的 v0.133（5 月 21 日），/goal 从实验功能变成默认开启。

8.3 /goal 的工作原理

抛开复杂的工程实现，/goal 模式的核心逻辑其实很简单：

1. 你定义一个目标 + 完成标准
2. Agent 自己规划、执行、验证
3. 没达标？根据反馈调整策略，再来一轮
4. 达标了？报告结果，结束

每轮结束时，系统会注入一段"延续提示词"，告诉 Agent：目标还没达成，继续推进。这个循环一直持续到目标完成、被暂停、被清空或 Token 预算耗尽。

和传统提示词相比，/goal 模式有几个关键区别：

自动迭代。 你不用一轮一轮手动驱动，Agent 自己持续推进。

状态持久化。 目标状态存在服务端，不在终端会话里。网络断了、电脑关了，下次打开还在。

预算控制。 可以设定 Token 上限，防止 Agent 失控烧钱。

可暂停恢复。 中途可以暂停，检查进度，再恢复继续。

不追求每一轮都正确。 它追求的是"持续迭代直到正确"。某一轮搞砸了没关系，下一轮会基于验证结果自我修正。

智能体本来就能自己推理，为什么还需要 /goal？

这里会有一个问题。Hermes、ChatGPT 本身就是智能体，给它一个任务，它本来就能自己规划步骤、多轮执行。不用任何特殊模式。那 /goal 到底多了什么？

答案是：普通智能体对话有三个我们可能没意识到的瓶颈，/goal 模式可以解决这三个问题。

1. 瓶颈一：上下文腐烂。

普通对话里，每一轮的输入输出都堆在上下文窗口里。到第 50 轮，模型得先消化前 49 轮的全部对话历史才能思考当前问题，又贵又乱。而且这些历史里掺着大量试错垃圾：方案 A 失败了、方案 B 有漏洞。模型被这些互相冲突的信息搞懵，输出质量断崖式下跌。

Ralph Loop 的做法是：每一轮启动全新进程，历史对话全部扔掉。进度不靠记忆，靠磁盘文件。这样每轮输入都很干净，模型读的是当前代码状态和任务列表，你可以把它理解为每一轮都是一个新的开始，不依靠历史的状态，不用在几十轮失败记录里翻找线索。这无疑降低了大模型的心智负担。

2. 瓶颈二：大模型不会判题。

这是最反直觉的一点。你让 AI 做一个任务，它做完会告诉你"搞定了"，但实际上可能根本没搞定。大模型的自我评估能力极不可靠。它会自信地说完成了，但现实不是这样。

而 Ralph Loop 的做法是：不看 AI 怎么谄媚地哄你，只看外部验证。使用 grep指令 还搜得到旧模式吗？测试全绿了没？TypeScript 类型检查过了没？完成条件由工具判定，不由 模型 自评。

3. 瓶颈三：让人疲惫的循环。

这个最隐蔽。你给 ChatGPT 一个任务，它的确能多步执行——但它每完成一轮就会停下来等你。你阅读输出、判断是否 OK、输入下一轮指令、批准工具调用。看起来是 AI 在做，实际上是你在驱动循环。而 /goal 把循环的控制权从你交还给 Agent：每轮结束自动注入"目标还没达成，继续推进"的提示词，直到目标完成或预算耗尽。

换句话说，普通模式里，你给 AI 一束花，它插好一朵就停下来等你选下一朵；/goal 模式里，你给 AI 一个花瓶和"插满为止"的标准，它自己把花插完，插到符合标准才叫你。

进度写进文件，跟堆在对话历史里有什么区别？

说完这三个瓶颈，你可能还有一个疑惑：Ralph Loop 把进度写进文件，但文件也会越来越多、越写越大。下一轮启动，模型照样要读这些文件。绕了一圈，上下文不还是在涨吗？

不一样。区别不在数据量多少，在存的什么、读的又是什么。

对话历史存的是"过程"。 每一轮推理、每一次试错，全堆在里面。到第 50 轮，模型面对的是前 49 轮的弯路。多种互相矛盾的信息充满了对话上下文，这让模型相当于在垃圾堆里找一颗珍珠。

文件存的是"结论"。 模型完成一轮，把"什么方案有效、哪个文件关键、什么坑要避开"写成摘要存进 progress.txt。这不是全量日志，是精选。失败的尝试直接丢弃，不进下一轮。

打一个比方。对话历史是监控录像——你离家 8 小时，回来要查快递员几点来的，得把 8 小时全过一遍。而外部文件相当于快递员在你家门口放了张便条，告诉你我几点来了。

还有一个更本质的区别：Ralph Loop 的读取是主动的、按需的。 而堆在对话历史里的东西，模型无法拒绝，都要通读。但如果是外部文件，模型可以只读当前任务需要的那部分，比如这一轮只关心还剩几个任务没做，就读 prd.json，不用通读整个 progress.txt。

8.4 什么任务适合 /goal

/goal 不是万能的。它适合这类任务：需要多轮迭代、有明确的完成标准、可能跑很久。

典型的例子：大规模代码重构、批量修复 CI 失败、持续的 Issue 分类和内容监控。

不适合的：需要人做判断的探索性任务、只需要一两轮就完成的简单问题、开放式讨论。

一个最佳实践：

如果你的任务可以写成"当 X 条件满足时可以认为完成任务"，那就适合 /goal。如果完成标准你自己也说不清楚，那 /goal 也帮不了你。

8.5 /goal 在 Hermes 里怎么用

Hermes 内置了 /goal 命令，和 ChatGPT CLI 的思路一脉相承。四个命令覆盖整个流程：

/goal <目标描述>    # 设置一个持久化目标
/goal status       # 查看当前目标的状态
/goal pause        # 暂停执行
/goal resume       # 恢复执行
/goal clear        # 清除当前目标，重新开始

比如你想让 Agent 检查所有关注的 UP 主并生成日报：

/goal 检查我 B 站特别关注分组的所有 UP 主，找出过去 24 小时内的新视频，
提取字幕生成摘要，整理成日报推送。
完成标准：所有 UP 主都已检查，日报已推送。

设完之后 Agent 就自己跑起来了。你关掉终端，第二天 /goal status 看看进度，没跑完就 /goal resume。

Hermes 的 /goal 有三个设计。

Judge 闭环。 每轮结束后，一个独立的 Judge 模型来判断目标是否完成。只有三种情况会认为完成任务：

1. Agent 明确确认完成了
2. 交付物已经产出了
3. 目标无法继续执行任务，需要外部输入。

除此之外，默认继续。

8.6 ■ 学点英语