现在大家都在讨论“设计循环（loops）”而不是单纯提示你的编码代理。如果你花时间在 X 上搜索“loop”到底是什么，会看到各种不同的答案。
我们根据以下维度对几种不同类型的 loop 进行分类：
我们会介绍主要的 loop 类型、各自的使用场景，以及如何在管理 token 消耗的同时保持代码质量。不是所有任务都需要复杂的 loop，从最简单的方案开始，有选择地使用这些模式。
1. Turn-based loops（回合制循环）
- 停止条件：Claude 判断任务已完成，或需要额外上下文
- 控制用量方式：写更具体的提示，并通过 skills 改进验证步骤，减少回合数
每次你发送提示，都会手动启动一个循环，由你来主导每一轮。Claude 会收集上下文、执行操作、检查工作、必要时重复，然后回复。我们把这个称为 agentic loop（代理循环）。
例如：让你创建一个点赞按钮。它会读取你的代码、进行修改、运行测试，然后把认为可用的结果交给你。你再手动检查并写下一个提示。
你可以通过把手动验证步骤编码成 SKILL.md 文件，让 Claude 能更自主地检查自己的工作（端到端验证）。这个文件里可以包含工具或连接器，让 Claude 能看到、测量或与结果交互。检查越量化，Claude 就越容易自我验证。
例如，在你的 SKILL.md 文件中你可以指定：
（此处原帖附有示例截图）
2. Goal-based loop（目标导向循环）—— /goal
- 最适合：有可验证退出条件（verifiable exit criteria）的任务
- 控制用量方式：设置明确的完成标准和明确的回合上限，例如“最多尝试 5 次后停止”
有时候单次回合不够，尤其是复杂任务。代理在能迭代时表现更好。你可以用 /goal 定义“完成”的样子，从而延长 Claude 迭代的时间。
当你定义好成功标准后，Claude 就不需要自己判断“够好就停”，每次它想停止时，评估模型（evaluator model）会检查你的条件是否满足，如果没满足就继续工作，直到目标达成或达到你设定的回合数。
因此，确定性标准（如通过多少测试、达到某个分数阈值）特别有效。
例如：
（此处原帖附有示例截图）
3. Time-based loop（基于时间的循环）—— /loop 和 /schedule
- 停止条件：你手动取消，或工作完成（PR 已合并、队列已清空）
- 最适合： recurring（重复性）工作，或需要与外部环境/系统交互的任务
- 控制用量方式：设置更长的间隔，或根据事件而非纯时间触发
有些代理工作是重复性的：任务本身不变，只是输入在变化。比如每天早上总结 Slack 消息。另一些工作依赖外部系统，最简单的方式就是定时检查并对变化做出反应，比如某个 PR 收到代码审查或 CI 失败。
对于这类任务，你可以用 /loop 让 Claude 按间隔重新运行提示。例如：
/loop 是在你的电脑上运行的，所以关机就停了。你可以通过创建 routine（例程）用 /schedule 把 loop 移到云端运行。
4. Proactive loops（主动式循环）
- 停止条件：每个任务在目标达成时退出；整个 routine 一直运行直到你关闭它
- 最适合：持续流入的、定义清晰的工作流：bug 报告、issue 分流、迁移、依赖升级等
- 控制用量方式：把 routine 路由到更小、更快的模型，只在需要判断时才使用最强的模型
上面的这些原语，加上 Claude Code 的其他功能（如 auto mode 和 dynamic workflows（研究预览版）），可以组合成用于长时间运行工作的 loop。
例如，处理 incoming feedback（反馈）时，你可以这样组合使用：
- 用
/schedule（研究预览版）运行一个 routine，检查新报告
- 用
/goal 定义“完成”的样子，并用 skills 记录如何验证
- 用 Dynamic workflows 编排多个代理：分流报告 → 修复 → 审查修复
- 用 Auto mode 让 routine 运行时无需每次询问许可
把它们组合起来，一个提示可能长这样：
（此处原帖附有示例截图）
保持代码质量
loop 输出质量取决于它周围的系统。设计系统时要注意：
- 保持代码库本身干净：Claude 会遵循代码库中已有的模式和规范。
- 给 Claude 自我验证的方式：用 skills 把“你和团队认为什么是好的”编码进去。
- 让文档容易获取：框架和库的文档要提供最新的最佳实践。
- 使用第二个代理做代码审查：一个有新鲜上下文的 reviewer 更少偏见，不受主代理推理过程影响。你可以使用内置的
/code-review skill 或 GitHub 的 Code Review 功能。
- 当某个结果不符合标准时，不要只修复单个问题，要把问题编码进系统，让所有未来的迭代都受益。
管理 Token 用量
要控制 token 消耗，loop 必须有清晰的边界：
- 为任务选择合适的原语和模型：简单任务不需要多个代理或复杂 loop。有些任务可以用更便宜、更快的模型。
- 定义清晰的成功和停止条件：具体说明“完成”是什么样子，让 Claude 更快到达解决方案（但不要太早停止）。
- 先小规模试点再大规模运行：Dynamic workflows 可能 spawn（生成）数百个代理，先在小范围工作上测试用量。
- 确定性工作用脚本：运行脚本比让模型一步步推理更便宜。例如，用 PDF skill 直接运行一个填表脚本，而不是每次都重新推导代码。
- 不要过度频繁运行 routine：间隔要匹配你监控的事物变化的频率。
- 查看用量：
/usage 命令可以按 skills、subagents、MCPs 拆解近期用量；不带参数的 /goal 会显示已用回合数和 token；/workflows 会显示每个代理的 token 使用情况，你可以随时停止某个代理。
如何开始使用 loops
总结一下：
要开始使用 loops，先看看你目前正在做的工作。挑一个你自己是瓶颈的任务，问问自己哪一部分可以交给代理：
一旦有想法，就运行 loop，观察结果（它在哪里卡住、哪里过度执行），然后大胆迭代优化。
更多信息，请阅读 Claude Code 文档中关于并行运行代理、loop、schedule、goal 以及 dynamic workflows 的页面。
本文作者：@delba_oliveira
AI 速览
