by smallnest

Goal, goal, goal! 三个智能体几乎同时推出的新功能

一个巧合，还是一个拐点？

2026 年 4 月底到 5 月中旬，AI 编程助手的赛道上发生了一件罕见的事：三家最活跃的智能体——OpenAI 的 Codex CLI、Anthropic 的 Claude Code、以及 Nous Research 的 Hermes Agent——在不到两周的时间窗口内，先后推出了各自的 /goal 斜杠命令。

这并非简单的功能追赶。/goal 背后代表的，是 AI 编程助手从"你问我答"的工具，走向"你定目标，我来完成"的自主智能体的关键一步。三家几乎同时落子，说明行业对这一方向的共识已经形成：持久化目标追踪 + 自主循环执行，将是下一代 AI Agent 的标配能力。

本文将从技术实现、设计哲学和行业趋势三个维度，拆解这三个 /goal 命令的异同，试图回答一个问题：当 AI 学会了自己"定目标、追目标、达目标"，开发者的角色将如何改变？

一、OpenAI Codex CLI：最工程化的目标系统

发布时间：2026 年 4 月 30 日（Codex v0.128.0）

Codex 的 /goal 是三者中架构最精密的。OpenAI 用 5 个 PR、约 15,000 行代码，在 10 天内完成了整个实现。据 OpenAI CEO Greg Brockman 的描述，这是"built-in Ralph loop++"——把社区里流行的自主循环模式直接做进了产品。

五层架构

Codex 的目标系统被设计为一个分层架构：

  1. 持久层：SQLite 数据库存储目标状态，字段包括 goal_id、objective、status、token_budget、tokens_used、time_used_seconds。四种状态：active、paused、budget_limited、complete。

  2. API 层：JSON-RPC 方法——thread/goal/set、thread/goal/get、thread/goal/clear，配合通知机制 thread/goal/updated 和 thread/goal/cleared。

  3. 模型工具层：模型可调用的工具有三个——create_goal（创建目标）、update_goal（标记完成，只有 action model 能调用）、get_goal（查询状态）。注意：模型不能暂停或恢复目标——这些是系统级控制，模型无权触及。

  4. 核心运行时：事件驱动的生命周期管理，自动的 token/时间会计，预算耗尽时自动暂停，以及防止无限循环的 continuation suppression 机制。

  5. TUI 界面：/goal、/goal pause、/goal resume、/goal clear 四个子命令，状态栏实时显示使用量指标。

目标模板

Codex 社区总结出的"黄金标准"目标模板是：

1
2
3
4
5
6
7
8
9
10
11
12
/goal <objective>
Scope: <文件边界>
Constraints:
- <硬约束 1>
- <硬约束 2>
Done when:
1. <可验证的输出 1>
2. <可验证的输出 2>
Stop if:
- <机械停止条件 1>
- <机械停止条件 2>
Use a token budget of <N> tokens.

这个模板的核心思想是：目标必须是机器可验证的。不是"我觉得代码写得差不多了"，而是"ruff check 通过、测试全部绿色、覆盖率不低于 80%"。

预算治理

Codex 的预算系统是三者中最精细的。每个目标可以设定 token 预算，系统持续追踪消耗，接近上限时自动触发 soft stop。这解决了 AI Agent 最让人头疼的问题之一——失控的 token 消耗。一个没有预算控制的目标追踪系统，本质上是一张没有上限的信用卡。

二、Claude Code：最简洁的评判模型

发布时间：2026 年 5 月 11 日（Claude Code v2.1.139）

Claude Code 的 /goal 比 Codex 晚了 11 天，设计上走了一条更克制的路线。没有五层架构，没有 SQLite，没有预算系统——而是用一个轻量的"评判模型"解决了最核心的问题：怎么知道目标完成了？

评判模型机制

每次工作模型完成一个 turn 后，系统将目标条件和当前对话上下文一起发给一个小而快的模型（很可能是 Claude Haiku）。这个评判模型只做一件事：判断目标条件是否已满足，返回 yes/no 加上一条简短理由。

如果是 no，Claude 自动开启下一个 turn 继续工作。如果是 yes，自动停止。

这个设计的精妙之处在于关注点分离：干活的是一个模型，验收的是另一个模型。这避免了"自己给自己打分"的利益冲突——工作模型天然倾向于说"我做完了"，而独立的评判模型没有这个偏见。

用户体验

Claude Code 的 /goal 接口极简：

  • /goal <condition>：设定目标和完成条件
  • /goal：查看当前目标状态（包括运行时间、已评估的 turn 数、token 消耗、评判模型的最近一次理由）
  • /goal clear：清除目标

目标条件最长 4,000 字符，需要满足三个要素：一个可衡量的终态、一个可检查的方法、以及真正重要的约束。

与其他自主模式的对比

Claude Code 同时提供三种自主工作机制：

模式 触发条件 适合场景
/goal 条件达成时停止 有明确完成标准的任务
/loop 定时重复执行 持续监控、定期轮询
Stop hooks 脚本/提示触发 自定义停止逻辑

/goal 是条件驱动的，/loop 是时间驱动的，Stop hooks 是事件驱动的。三者覆盖了自主执行的主要模式。

三、Hermes Agent：最持久的跨会话目标

发布时间：2026 年 5 月 7 日（Hermes v0.13.0）

Hermes 的 /goal 在时间线上夹在 Codex 和 Claude Code 之间，但它的设计取向截然不同——它解决的核心问题是：目标能不能跨会话存活？

跨平台持久化

Hermes 的目标状态存储在 SessionDB.state_meta 中，以 goal:<session_id> 为键。这意味着：

  • 目标可以在 CLI 中设定，在 Telegram 中检查进度，在 Discord 中恢复执行

  • 会话断开后目标不丢失，/resume 或 /continue 可以精确恢复到之前的状态（active/paused/done）

  • 支持的平台包括：CLI、Telegram、Discord、Slack、Matrix、Signal、WhatsApp、SMS、iMessage、Webhook、API 服务器、Web Dashboard

这是 Codex 和 Claude Code 都不具备的能力。后两者的目标是会话级别的——关掉终端，目标就没了。Hermes 的目标是Agent 级别的——它属于这个 Agent，不属于某个终端。

评判模型的容错设计

Hermes 的评判模型（goal_judge task）有一个值得注意的容错语义：fail-open。如果评判模型出错，默认判定为"继续"——坏掉的评判模型永远不会卡住进度。

这和 Claude Code 的设计哲学形成对比：Claude 的评判模型更"保守"，而 Hermes 的设计更"乐观"。两种选择各有道理——保守减少误报（目标没完成却判定完成），乐观减少卡死（评判模型故障导致 Agent 停摆）。

Turn Budget 和假阳性处理

Hermes 设定了默认 20 个 continuation turn 的预算，到达后自动暂停，可通过 /goal resume 重置计数器。同时，评判模型被设计为"保守判断"——只有在响应明确确认完成、交付物确实产出、或目标确实无法完成时才标记 done。这个保守策略配合 turn budget，形成了双层防护：假阳性靠保守判断减少，假阴性靠 turn budget 兜底。

可配置的评判模型

Hermes 允许用户将 goal_judge 配置为便宜快速的模型，以降低成本。这在实际使用中很重要——如果一个目标需要 50 个 turn 才能完成，每次评判都用 Opus 级别的模型，仅评判成本就不可忽视。

四、横向对比

维度 Codex CLI Claude Code Hermes Agent
发布日期 2026-04-30 2026-05-11 2026-05-07
目标存储 SQLite（线程级） 会话内存 SessionDB（Agent 级）
评判机制 模型 update_goal 工具 独立小模型（Haiku 级） 可配置的 goal_judge
预算控制 Token + 时间双重预算 无显式预算 Turn budget（默认 20）
跨平台 否（CLI only） 否（CLI/IDE/Slack） 是（12+ 平台）
跨会话 否 /resume 可恢复 完全持久化
容错 Continuation suppression 自动停止 Fail-open
架构复杂度 五层 轻量 中等
适用场景 大型重构、迁移 编码会话 持久 Agent 任务

五、为什么是 /goal？为什么是现在？

三家公司几乎同时推出 /goal，背后有三个共同的驱动力。

1. 从"提示工程"到"目标工程"

过去两年，行业的焦点是提示工程——怎么写好一句话让模型输出高质量结果。/goal 标志着一个转向：开发者需要学习的不再是怎么写好单个提示，而是怎么定义一个机器可验证的目标。这需要不同的思维模型：从"告诉模型怎么做"转向"告诉模型做到什么算完"。

2. 自主循环的工程化

社区里早就有各种"Ralph loop"式的自主循环 hack——让模型反复执行直到任务完成。但这些方案缺乏统一的停止条件、预算控制和状态管理。/goal 把这些最佳实践产品化了：停止条件变成了一等公民，预算变成了可配置参数，状态变成了可查询的记录。

3. Agent 可靠性的必经之路

一个每次都需要人类说"继续"的 Agent，不是真正的 Agent。/goal 解决的是 Agent 的"半途而废"问题——它让 Agent 有了自主判断"我做完了"的能力。这是从辅助工具到自主智能体的关键跳跃。

六、开发者的新角色

当 Agent 学会了自主追踪目标，开发者的角色正在发生一次静悄悄的转移：

从驾驶员变成调度员。 你不再需要一步步指挥 Agent 做什么，而是定义目标、设定约束、审计结果。这不是降级——调度员的决策权比驾驶员更大，只是工作方式不同了。

从代码编写者变成目标工程师。 写好一个 /goal 比写好一个 prompt 更难，因为目标必须是可验证的、有边界的、有预算的。这是一项新的工程技能。

从实时监控者变成事后审计者。 当 Agent 可以自主跑几个小时甚至几天，开发者不再需要盯着屏幕。你设定目标，去干别的事，回来审计结果。

七、/goal 最佳实践

三个实现各有千秋，但使用 /goal 的核心原则是相通的。以下是从三个产品的设计哲学和社区实践中提炼出的最佳实践。

1. 写可验证的完成条件

这是最重要的原则。一个好的 /goal 完成条件应该是机器可以自动检查的，而不是需要人类主观判断的。

反面示例：

1
/goal 重构认证模块，让代码更清晰

这个目标无法被自动验证——什么是"更清晰"？谁来判定？

正面示例：

1
2
3
4
5
6
/goal 重构认证模块
Done when:
1. 所有 auth 相关逻辑从 app.py 迁移到 auth/ 目录
2. pytest 测试全部通过
3. ruff check 零警告
4. 认证相关代码覆盖率不低于 85%

每一个条件都可以用一个命令或脚本自动检查。

2. 设定明确的作用域

目标越具体，Agent 越不容易跑偏。好的作用域定义包括：文件范围、技术栈约束、不允许触碰的区域。

1
2
3
4
5
6
7
8
9
/goal 为用户 API 添加分页功能
Scope: src/api/users.py, src/tests/test_users.py
Constraints:
- 只修改用户相关的文件，不碰其他模块
- 使用现有的 SQLAlchemy 分页工具
- 保持向后兼容，默认行为不变
Stop if:
- 需要修改数据库 schema
- 影响到其他 API 端点的行为

"Stop if" 条件是容易被忽视但极其重要的——它告诉 Agent 在什么时候应该停下来请求人类介入。

3. 为大目标设置预算

一个没有预算的目标追踪系统，本质上是一张没有上限的信用卡。根据 Codex 社区的经验，合理的预算取决于任务复杂度：

任务类型 建议 Token 预算 建议 Turn 预算
Bug 修复 50K-100K 5-10
功能开发 100K-300K 10-20
大型重构 300K-500K 20-40
全项目迁移 500K+ 40+

如果你用的是 Claude Code（没有显式预算），可以通过 /goal 的条件描述间接控制："在不超过 15 分钟内完成"。Hermes 用户则可以调整 goal_judge 使用更便宜的模型来降低评判成本。

4. 善用评判模型的特性

Claude Code 和 Hermes 都采用独立的评判模型来验证目标完成情况。理解评判模型的工作方式，可以帮助你写出更可靠的目标条件。

关键技巧：

  • 把验证步骤写进条件里——不要只说"实现登录功能"，而是说"实现登录功能，且 curl -X POST /api/login -d '...' 返回 200"
  • 避免模糊的形容词——"性能优化"不可验证，"P99 延迟降低到 200ms 以下"可以验证
  • 提供检查命令——在条件中包含具体的测试命令或脚本路径，评判模型可以直接执行或引用

5. 分而治之

一个大型目标应该被拆分为多个小目标依次执行，而不是一个巨大的目标一次完成。这不仅更可靠，也更节省 token。

错误做法：

1
/goal 把整个项目从 JavaScript 迁移到 TypeScript，所有测试通过

正确做法：

1
2
3
4
/goal 1: 将 src/utils/ 迁移到 TypeScript，utils 相关测试全部通过
/goal 2: 将 src/api/ 迁移到 TypeScript，API 测试全部通过
/goal 3: 将 src/models/ 迁移到 TypeScript，model 测试全部通过
...

每个小目标完成后，检查结果，确认无误后再启动下一个。这种增量式的方法虽然需要更多人工介入，但大幅降低了返工的风险。

6. 审计，不要监控

/goal 的设计哲学是让你从"盯着屏幕等结果"转变为"设定目标，去做别的事，回来审计结果"。但审计不等于盲信任。

推荐的审计流程：

  1. 目标完成后，先看状态摘要——Claude Code 的 /goal 会显示评判模型的理由，Codex 会显示 token 消耗和执行时间
  2. 检查 Agent 修改了哪些文件——用 git diff 快速浏览变更范围
  3. 运行完整的测试套件——不要只依赖 Agent 报告的测试结果，自己跑一遍
  4. 检查边界条件——Agent 容易在错误处理、边界值、并发场景上偷懒

7. 选择适合你场景的实现

三个 /goal 实现各有所长，选择的关键是匹配你的使用场景：

你的场景 推荐 原因
单次编码会话，目标明确 Claude Code /goal 极简、评判模型优雅、上手快
大型工程任务，需要精细控制 Codex CLI /goal 预算治理、五层架构、目标模板
长期运行的 Agent，跨平台 Hermes /goal 跨会话持久化、12+ 平台
快速实验、学习 Claude Code /goal 零配置，开箱即用

如果你同时使用多个 Agent，可以利用 Hermes 作为"统一目标管理器"——在 Hermes 中设定持久化目标，通过不同平台监控和恢复执行。

8. 常见的反模式

最后，几个在实际使用中反复出现的错误模式：

反模式一：目标太抽象。 "优化代码质量"不是目标，"将 src/ 下的 lint 警告从 47 个降到 0 个"才是。

反模式二：忽略约束条件。 不设定 Stop if 条件，Agent 可能在遇到意外情况时继续蛮干，浪费大量 token 甚至破坏代码。

反模式三：一次性目标太大。 把"重写整个认证系统"作为一个目标，几乎注定会超预算或产生低质量结果。

反模式四：不审计结果。 评判模型说"完成"不等于真正完成。始终用 git diff + 完整测试来验证。

反模式五：预算设置不合理。 给一个简单的 bug 修复分配 500K token 预算，会让 Agent 在遇到问题时无节制地重试。预算应该略高于预期消耗，但不应高出一个数量级。

结语

/goal 不是一个功能，而是一个信号。它标志着 AI 编程助手正式从"对话式工具"进化为"自主式 Agent"。Codex 带来了工程化的严谨，Claude Code 带来了评判模型的优雅，Hermes 带来了跨平台持久化的实用性。三者的路径不同，但指向同一个方向：AI 不再只是帮你写代码，而是帮你完成目标。

至于谁的目标系统会胜出？这可能问错了问题。更准确的问题是：当所有 Agent 都有了 /goal，开发者的核心竞争力会变成什么？

也许是——定义正确目标的能力。