Claude Code 的 Goal、Loop 与 Workflows：终点、节奏和规模

#核心判断

Claude Code 里的 /goal、/loop 和 Dynamic Workflows 容易被混在一起理解成“让 Agent 多干一会儿”。这个理解太粗。三者真正改变的是自动化控制面里的三个不同变量：/goal 约束终点，/loop 约束节奏，Dynamic Workflows 约束规模和编排。

对 AI 全栈架构师来说，选错工具的代价不是体验差一点，而是任务会失控。把周期巡检交给 /goal，目标永远不满足；把收敛型修复交给 /loop，每轮都像重新开始；把还没确定流程的探索任务直接丢给 Workflows，会得到一组并行但方向不稳的 Agent。

#三个命令分别回答什么问题

工具	它回答的问题	适合任务	不适合任务
`/goal`	什么时候算完成	有明确验收条件的长任务	没有可验证终点的巡检或探索
`/loop`	隔多久再回来跑一次	CI 轮询、部署观察、PR 维护、状态检查	需要连续上下文推进的复杂实现
Dynamic Workflows	一次如何组织多 Agent	大规模审计、迁移、交叉研究、并行验证	需要频繁人工拍板的开放问题

Anthropic 对 /goal 的官方定义是设置完成条件，让 Claude 在多个 turn 之间继续推进，并由独立评估器判断条件是否满足。这个设计的关键不是“自动继续”，而是 maker/checker 分离：执行任务的 Agent 不再自己宣布完成，另一个评估步骤会看条件是否成立。

/loop 属于会话内调度能力。它可以按固定间隔或动态间隔重复运行同一个 prompt，也可以执行内置维护任务。它最适合轮询和照看，而不是证明一个复杂目标已经完成。真正需要长期稳定运行的定时任务，还应该上升到 Desktop scheduled tasks、云端 Routines 或 CI/CD 调度。

Dynamic Workflows 则把编排逻辑从聊天上下文搬进脚本。一个 workflow 可以启动多个 subagent，把循环、分支和中间结果放在运行时里，而不是塞进主会话上下文。它不是“更强的 /goal”，而是更适合重复、并行、可审计的多 Agent 编排。

#用确定性而不是任务大小来选择

很多团队会按任务大小选工具：小任务不用，大任务上 workflow。这个维度不够准。更好的判断标准是确定性。

第一类是 终点确定，路径不确定。例如“把这个模块迁移到新 API，直到测试和类型检查通过”。你知道验收条件，但不知道中间会遇到多少文件、多少错误、多少修复轮次。这类任务适合 /goal。条件必须能被验证，例如命令退出码、测试范围、文件数量、issue 队列为空，而不是“代码质量达到生产级别”这种模糊表述。

第二类是 节奏确定，终点开放。例如“每 10 分钟检查部署是否完成并反馈状态”。它不一定要一次性完成，也不应该让 Agent 连续自我推进。它需要的是按时回来观察，所以适合 /loop。如果循环可能运行很久，必须设置最长时间、预算上限和停止条件。

第三类是 流程确定，规模较大。例如“让多个 Agent 分别审计 API 鉴权、输入校验、日志脱敏和测试覆盖，并互相复核结论”。流程本身可以写成阶段、分支和合并规则，这时 Dynamic Workflows 更合适。它的优势不是只是并发，而是把编排变成可读、可复用、可暂停的脚本。

第四类是 目标和流程都不确定。例如“我们应该怎么重构这套系统”。这种任务先不要自动化。先用普通对话或小范围调研把问题收敛成可验证目标，再决定是否进入 /goal 或 workflow。

#组合方式

三者可以组合，但组合的前提是边界清楚。

一种常见组合是 Workflow 负责铺开，/goal 负责收敛。例如先用 workflow 让多个 Agent 扫描代码库，产出候选问题和证据；再把确定的问题交给 /goal，让主 Agent 修到测试通过。这样可以避免 workflow 直接承担所有实现风险，也避免 /goal 在信息不足时盲目搜索。

第二种组合是 /loop 负责观察，事件触发后进入人工或 /goal。例如部署过程中用 /loop 定期检查状态；一旦发现失败日志，再启动明确的修复目标。这里 /loop 不负责无限修复，它只负责及时发现状态变化。

第三种组合是 Workflow 负责交叉验证。当研究、审计或方案设计需要多个独立视角时，workflow 可以让 Agent 分别收集证据、互相挑战和投票筛选。最终报告再由人决定是否进入实现阶段。

#常见误区

第一个误区是把 /goal 写成愿望。目标条件必须可观察、可证明、可停止。好的条件包括“npm test 退出码为 0”“所有 legacyClient 调用点迁移完成”“指定目录下没有超过 500 行的文件”。差的条件包括“架构更优雅”“代码更干净”“尽量修好”。

第二个误区是把 /loop 当成无人值守后台服务。会话内 loop 依赖当前会话，适合短期照看；生产级定时任务要有独立调度、日志、告警、重试和权限边界。否则你得到的是一个正在消耗 token 的聊天会话，而不是一个可靠任务系统。

第三个误区是以为 Workflows 只是在堆更多 Agent。更多 Agent 会带来更多 token、更多中间状态、更多重复发现和更多合并成本。只有当任务可以拆出明确角色、阶段和验证规则时，并行才有意义。否则一个清晰的单 Agent 计划更稳。

第四个误区是忽略人工确认。支付、安全策略、权限模型、生产数据写入和公开发布这类动作不能因为用了 /goal 或 workflow 就自动放行。自动化可以承担收集证据、提出补丁和跑验证，但关键决策点仍要有审批和审计。

#工程落地检查清单

每个 /goal 是否有一个可测的完成条件，并写明用什么命令或证据证明。
每个 /loop 是否有最长运行时间、预算上限、停止条件和失败升级路径。
每个 workflow 是否有清晰阶段、角色分工、合并规则和输出格式。
多 Agent 任务是否限制并发和总 Agent 数，避免成本失控。
是否把高风险写操作、部署、权限变更和外部发布放进人工审批。
是否记录 prompt、工具调用、命令输出、文件 diff、token 成本和最终结论。
是否先在小范围样本上试跑，再扩大到全仓库、全队列或生产流程。

#对平台设计的启发

这三个能力背后反映的是同一个趋势：Agent 产品正在从“对话界面”走向“任务运行时”。对话只负责表达意图，真正的控制面要管理终点、节奏、并发、状态、权限、成本和审计。

如果要在企业内部建设 Coding Agent 或 AI 工程平台，不应该只问模型能不能写代码，而要问平台能否回答这些问题：当前任务的完成条件在哪里，谁在评估完成，下一轮什么时候触发，多个 Agent 的中间结果存在哪里，失败后能否恢复，哪些动作需要审批，成本是否能被上限约束。

/goal、/loop 和 Dynamic Workflows 的价值不在命令本身，而在它们把 Agent 自动化拆成了三个可治理的维度。只有把终点、节奏和规模分开设计，团队才可能让 Agent 稳定进入真实工程流程，而不是停留在一次次临场发挥。