Claude Code 的 /loop 与 /goal 到底区别在哪里？

从底层实现到实战选型，一文讲透 Anthropic 两大自动化命令的设计哲学、技术架构与最佳实践

背景：Claude Code 的自动化演进

2026 年初，Anthropic 的 Claude Code 经历了一次重要的能力跃迁——从交互式编码助手进化为自主后台工作者。这场演进的标志性产物，就是两个斜杠命令：/loop（2026 年 3 月随 v2.1.72 发布）和 /goal（2026 年 5 月 11 日随 v2.1.139 发布）[1][2]。

对 loop engineering 了解的请查看这篇：

为什么大厂都在偷偷搞Loop Engineering？

一文看懂MCP、Skill、Harness、Loop 工程

表面上看，两者都让 Claude "自动干活"，但它们的触发机制、停止逻辑、底层架构和适用场景截然不同。选错命令，轻则浪费 token，重则烧光预算——已有开发者报告 14 小时跑掉 $200 的案例[3]。

本文将从技术实现层面，逐层拆解两者的核心差异。

核心定义：一句话区分

/loop — 时间驱动的定时调度器

按固定间隔（或动态间隔）反复执行同一段 prompt，本质是 Claude Code 内置的 cron 调度器。适合"每隔 X 分钟帮我检查一下 Y"这类监控场景。

/goal — 条件驱动的目标执行器

设定一个完成条件，Claude 每轮结束后由独立评判模型检查是否达标——达标则停，不达标则继续。适合"把这件事做到某个可验证的标准为止"这类构建场景。

底层架构对比

/loop 的技术实现

/loop 底层封装了三个 cron 工具：CronCreate、CronList、CronDelete[1]。每个任务拥有 8 字符 ID，单会话上限 50 个。调度器每秒检查到期任务，以低优先级入队，在用户回合之间执行（不在 Claude 响应过程中执行）[1]。

为避免所有会话同时请求 API，调度器添加了确定性 Jitter（抖动）：重复任务最多延迟计划时间的 30 分钟，一次性任务最多提前 90 秒[1]。

语法速查

1
2
3
4
5
6
7
8

# 固定间隔 + prompt
/loop 5m check the deploy status
 
# 仅 prompt（Claude 动态选择 1min~1h 的间隔）
/loop check the deploy
 
# 裸命令（运行内置维护模式或 loop.md）
/loop    

/goal 的技术实现

/goal 的底层是一个会话级（session-scoped）基于 prompt 的 Stop Hook[2]。其核心创新在于工作模型与评判模型分离：

1. 用户设定完成条件（上限 4000 字符）
2. Claude 主模型执行一轮工作
3. 每轮结束后，独立的快速模型（默认 Claude Haiku）读取完整对话记录，返回 yes/no + 理由
4. 若 no → 理由作为下一轮引导，继续工作
5. 若 yes → 目标清除，标记为"已达成"[2]

关键设计：评判模型不调用工具、不读文件、不执行命令，仅根据对话中已出现的内容做判断[2]。这意味着用户必须在条件中要求 Claude 将验证证据留在对话中，评判模型才能做出准确判断。

语法速查

1
2
3
4
5
6
7
8

# 设置目标
/goal All tests pass and the new endpoint returns 200, or stop after 20 turns
 
# 查看当前目标状态
/goal
 
# 清除目标
/goal clear 

架构流程图

图 1：/loop 与 /goal 的执行流程对比

全维度对比表

Token 消耗与成本分析

这是实际使用中最容易被忽视、却影响最大的维度。

/loop 的 token 消耗

每次循环产生一次 API 调用，消耗取决于上下文大小和输出长度。例如：每小时运行、每次读取 10,000 token 日志并生成 1,000 token 摘要，72 小时约消耗 ~792,000 token[4]。/loop 的优势在于等待期间不消耗 token——只有执行时才计费。

/goal 的 token 消耗

/goal 的消耗结构更复杂：

• 主轮 token由任务复杂度决定，是消耗的大头
• 评判 token每轮增加一次 Haiku 调用。官方称"通常与主轮开销相比可忽略"[2]，但长跑目标（30+ 轮）上下文膨胀后，评判模型的输入 token 累积也不可忽视
• 无内置预算硬上限一个中等复杂度的目标可能需要 20-80 轮，累计可达数十万到上千万 token[3]

一位开发者运行 /goal 14 小时后烧光了 $200 账户的全部周额度[3]。Anthropic 自身数据也表明，多代理系统比普通聊天多耗约 15 倍 token[5]。务必在条件中写入轮次上限。

适用场景：何时用哪个？

/loop 的最佳场景

/loop 适合周期性、重复性、监控类任务，核心特征是"每次执行相互独立，不需要累积上下文"[1]：

• 轮询部署状态：/loop 5m check the deploy status with 'kubectl rollout status'
• 监控 PR 评论：/loop 2h /review-pr 1234
• 检查 CI 构建：/loop 30m check if CI passed on main
• 日志监控：/loop 15m scan error logs and flag anything new
• 定时提醒：remind me at 3pm to push the release branch

裸 /loop（不带参数）会运行内置维护模式：继续未完成的工作 → 处理 PR 评论和 CI 失败 → 运行代码清理[1]。

/goal 的最佳场景

/goal 适合有明确可验证终态的实质性构建工作[2]：

• API 迁移：将模块迁移到新 API，直到所有调用点编译且测试通过
• 设计实现：实现设计文档，直到所有验收标准满足
• 文件拆分：将大文件拆分为专注模块，直到每个文件低于大小限制
• Issue 处理：处理带标签的 issue 队列，直到队列清空

不适合的场景

与 Auto Mode 的协作关系

理解 /loop 和 /goal，还需要引入第三个概念：Auto Mode。

三者的分工形成了一个清晰的自动化层次[2]：

• Auto Mode消除单轮内的工具确认提示（Claude 不再每步都问"可以执行这个命令吗？"）
• /goal消除轮间确认提示（Claude 一轮结束后不再等你输入，自动开始下一轮）
• /loop在轮间加入时间间隔（适合不需要连续执行、而是定时检查的场景）

Auto Mode + /goal 组合可以实现完全无人值守的长时间构建——这也是社区中"睡前设 goal，醒来收代码"玩法的根基[3]。

图 2：Auto Mode、/goal、/loop 的自动化层次

常见失败模式与最佳实践

/goal 的四大陷阱

陷阱 1：模糊的完成条件

"Build the feature" 不是有效 goal。"All tests pass and the new endpoint returns 200" 才是[3]。评判模型只能做 yes/no 判断，条件必须可测量、可验证。

陷阱 2：无范围限制

不指定工作目录，agent 可能修改意外文件。始终在条件中限定范围。

陷阱 3：确认循环（Acknowledgement Loop）

条件太模糊时，Claude 每轮声称"有进展"但实际未推进，评判模型被说服后不断返回 no[3]。解决方法：要求 Claude 运行测试并将输出留在对话中。

陷阱 4：无轮次上限

/goal 没有内置 --max-turns。必须在条件中显式写入：or stop after 20 turns[2]。

最佳实践清单

/goal 条件三要素

可测量的终态 + 验证方法 + 约束条件

1
2
3
4
5

# 好的条件示例
/goal Run `npm test` and `npm run lint` — all must pass with zero errors. \
Only modify files under src/features/payment/. \
Do not touch shared utilities. \
Stop after 30 turns or when all tests pass.

• 始终添加轮次上限：or stop after N turns
• 配合 Auto Mode 使用以实现真正的无人值守
• 准备 CLAUDE.md + PRD + 设计文档，goal 就能变成一行命令[3]
• 在条件中要求 Claude 产出验证证据（测试输出、编译结果等），评判模型才能验证

/loop 的注意事项

• 会话关闭即停止——不具备跨重启持久性[1]
• 重复任务 7 天后自动过期[1]
• Claude 忙碌时错过的执行不会补跑[1]
• 可通过 loop.md 自定义默认维护 prompt[1]
• Bedrock / Vertex / Foundry 上无间隔时固定 10 分钟，不支持维护模式[1]

历史背景：从 Ralph Wiggum Loop 到 /goal

/goal 的设计并非凭空而来。它的前身是社区中被称为 "Ralph Wiggum Loop" 的模式[3]：

• Ralph Loop（2025 年初）：社区术语，指手动编写的 bash 脚本反复调用 Claude Code
• Ralph Wiggum Loop（2025 年底）：同模式加上辛普森梗，在 Twitter 上流行
• Codex CLI /goal（2026 年 4 月 30 日）：OpenAI Codex 先发布了 goal 子命令
• Claude Code /goal（2026 年 5 月 11 日）：Anthropic 官方产品化实现，仅隔 11 天[5]

值得注意的是，Claude Code 的 /goal 与 Codex 的 /goal 虽然同名，但设计不同：Codex 有 pause/resume 子命令和预算门控，主模型自行判断完成；Claude Code 更精简——一个条件、一个停止、一个清除，由外部模型评估[6]。

组合使用：1+1 > 2

社区实践中，/goal 和 /loop 可以组合使用[7]：

• 在 /background 会话中设 /goal，实现脱离终端的自主运行
• 用 /loop 轮询 /goal 的进度
• 先用 /goal 完成主任务，其中嵌入 /loop 做子监控

这种组合模式代表了 Claude Code 自动化的高级用法——将目标驱动的连续执行与时间驱动的周期检查结合起来，构建多层自动化工作流。

总结：选型决策树

图 3：/loop 与 /goal 选型决策树

归根结底，/loop 和 /goal 的区别可以用一句话概括：

/loop 回答的是"多久做一次"，/goal 回答的是"做到什么程度才算完"。

前者是定时器，后者是终点线。理解了这个本质区别，就能在实际开发中做出正确的选型，避免 token 浪费，真正发挥 Claude Code 自动化能力的价值。

参考来源

1. [官方] Anthropic, Claude Code Documentation — Run prompts on a schedule (/loop)https://code.claude.com/docs/en/scheduled-tasks
2. [官方] Anthropic, Claude Code Documentation — Keep Claude working toward a goal (/goal)https://code.claude.com/docs/en/goal
3. [行业分析] The AI Architects, The Ralph Wiggum Loop and /goal in Claude Codehttps://theaiarchitects.com/blog/claude-code-ralph-loop
4. [行业分析] ClaudeLab, Claude Code Gets /loop Commandhttps://claudelab.net/en/articles/claude-ai/claude-code-loop-cron-scheduling
5. [行业报道] 腾讯云, Claude Code 的三种"循环"：/loop、/goal、Dynamic Workflowshttps://cloud.tencent.com/developer/article/2691900
6. [行业分析] Build Great Products, Claude Code /goal 详解https://www.buildgreatproducts.com/guides/claude-code-goal
7. [行业分析] dev.to, Claude Code Stops Pausing Every Turn: /goal, /loop, /batch, /backgroundhttps://dev.to/jessyt/claude-code-stops-pausing-every-turn-goal-loop-batch-background-24nb
8. [行业分析] claude-code-guide.org, Loophttps://claude-code-guide.org/loop/
9. [行业分析] FindSkill, Claude Code /goal: Set a Finish Line, Walk Awayhttps://findskill.ai/blog/claude-code-goal-command/
10. [行业分析] Classmethod, /goal コマンド 〜/loop・Stop hook・Ralph Wiggumとの使い分けhttps://dev.classmethod.jp/articles/claude-code-goal-command/