第24篇：持久目标——AI 的长期待办

第24篇：持久目标——AI 的长期待办

你有没有遇到过这种情况：让 AI 干活，它干完一步就停下来等你发话，你只能一遍遍敲“继续”。就像你让同事整理文件，他整理完一个抽屉就坐回去等你吩咐，你恨不得给他贴张便签：“把所有抽屉都整理完再下班”。

Hermes 的 /goal 就是这张便签。它给 AI 设定一个跨轮次存活的长期目标，AI 每完成一步，系统会用一个轻量裁判模型检查“目标达成了吗？”——没达成，就自动喂回提示词，让它接着干，直到完成、你喊停、或预算轮次耗尽。

第1步：什么时候用？ 一句话：当你不想每轮都重复“继续”的时候。比如：

“修复 src/ 下所有 lint 错误，并确认 ruff check 通过”
“把仓库 Y 的 X 功能移植过来，包含测试，让 CI 变绿”
“调查会话 ID 在压缩时漂移的原因，写份报告”

如果任务一轮就能干完，就不需要它。需要你连说三次“继续”的任务，才是它的主场。

第2步：它和看板（Kanban）的区别 很多人以为 /goal 和看板是一回事，其实边界很清晰：

/goal 是单会话的。它只在这个对话里自动续跑，不会创建看板卡片，不会分配给其他 profile，不会扩散。
看板是多任务面板。每张卡片由独立 worker 进程处理，卡片、依赖、交接都在面板上。
唯一交集：看板卡片加 --goal 参数时，会借用 /goal 的续跑引擎，但只在那张卡片的 worker 会话里生效。

简单记：这个聊天里的事用 /goal，面板上的事用看板。 两者互不自动转换。

第3步：快速上手 直接发：

/goal Fix every failing test in tests/hermes_cli/ and make sure scripts/run_tests.sh passes for that directory

你会看到：

⊙ Goal set (20-turn budget): <目标> —— 目标被接受，20 轮预算
第 1 轮开始执行
裁判模型判断 done 或 continue
若 continue，显示 ↻ Continuing toward goal (1/20): <原因>，自动继续
最终 ✓ Goal achieved 或 ⏸ Goal paused — N/20 turns used

第4步：常用命令一览

/goal <text>          # 设置或替换目标，立即开始
/goal draft <text>    # 从自然语言草拟结构化完成合同，再设置
/goal show            # 查看当前目标的完成合同
/goal status          # 查看目标、状态、已用轮次
/goal pause           # 暂停自动续跑（不清除目标）
/goal resume          # 恢复续跑（轮次计数归零）
/goal clear           # 彻底清除目标
/goal wait <pid> [reason]  # 等待后台进程，期间暂停续跑，进程结束自动恢复
/goal unwait          # 取消等待，恢复续跑
/goal gate add <command>   # 加一道质量门：必须通过的 shell 命令
/goal gate list       # 查看所有门及其通过状态
/goal gate remove <N> # 删掉第 N 道门
/goal gate clear      # 清空所有门

/goal wait 里的 PID 必须是 Hermes 主机上真实存活的进程；远程的或已经退出的 PID 会被拒绝，不会让循环白等。

第5步：质量门（Quality Gate） 完成合同让裁判更严格，但裁判毕竟还是 LLM 在读文字。质量门更硬：一条 shell 命令，必须退出码为 0，目标才可能被判完成。

/goal Fix the flaky session tests
/goal gate add scripts/run_tests.sh tests/hermes_cli/test_goals.py

每轮的工作顺序是：先跑门，再叫裁判。门挂了就不叫裁判——红的门本身就是“没做完”的硬证据，门的退出码和输出尾部会变成续跑提示词，让 AI 对着真实报错改，而不是凭感觉。所有门都过了，才轮到裁判照常判断。

门每次都在当前输入上重跑，不会拿旧结果糊弄你；每道门默认 3 次重试、5 分钟超时，重试耗尽就自动暂停目标，等你手动修、删门或 /goal resume。

第6步：等后台进程 有些目标卡在慢活儿上——CI 跑 PR、长构建、测试矩阵、部署、限流冷却。这种时候循环会一直戳 AI“好了没”，纯属瞎忙。

现在这件事自动处理：裁判每轮都能看到本会话自己起的后台进程（pid、命令、运行时长、最近输出、触发条件），当进度确实卡在某个进程上时，它会返回 wait 判定，循环就停靠——后续轮次直接跳过（不叫裁判、不续跑、不消耗轮次），等条件满足再带着结果继续。基于 pid/会话的等待最多 30 分钟，防止一个永不退出的 watcher 把目标无限期挂住。停靠期间 /goal status 会显示 ⏳ Goal (parked …)。

你不需要手动敲什么，这是裁判自己决定的；/goal wait <pid> 和 /goal unwait 只是给你留的手动开关。

第7步：中途加验收条件 跑着跑着发现还想让它多做一件事？用 /subgoal 追加，不用打断循环：

/subgoal <text>       # 给当前目标追加一条验收条件
/subgoal              # 查看当前编号列表
/subgoal remove <N>   # 删掉第 N 条
/subgoal clear        # 清空所有子目标，保留原目标

子目标会并进完成合同，裁判必须原目标 + 每条子目标都满足才算完成。它们和合同一样存在 SessionDB.state_meta 里，/resume 之后还在。

总结 /goal 是 Hermes 的“长期待办便签”——设定一次，AI 自己迭代到完成为止。它适合单会话内的持续任务，和看板（多任务面板）是互补关系，别混用。想让“完成”变得可机械验证，就加质量门；想中途加条件，就用 /subgoal。下次你发现自己在重复说“继续”时，就该把它写成一个 /goal 了。

下一篇预告： 第25篇将深入看板（Kanban）——如何把多个任务变成卡片、分配 worker、处理依赖和交接。如果你需要管理一堆并行任务，那篇就是为你准备的。