循环入门

最近大家都在聊「设计循环（loops）」，而不是给你的编码 agent 写提示词。但如果你在 X 上花点时间想搞清楚循环到底是什么，会发现众说纷纭。

在 Claude Code 团队，我们把循环定义为：agent 反复执行一轮又一轮的工作，直到满足某个终止条件。我们按以下几个维度，把循环分成几种类型：

• 如何触发
• 如何终止
• 用到哪个 Claude Code 原语（primitive）
• 最适合处理哪类任务

下面会讲清楚主要的循环类型、各自的适用场景，以及如何在控制 token 用量的同时保住代码质量。不是所有任务都需要复杂的循环——先从最简单的方案入手，按需选用这些模式。

逐轮循环（Turn-based loops）

• 触发方式：一次用户提示。
• 终止条件：Claude 判断任务已完成，或需要补充上下文。
• 最适合：较短、不属于常规流程或排期的任务。
• 控制用量的办法：把提示词写得更具体，并用技能（skill）强化验证环节，从而减少轮次。

你发出的每一条提示，都会开启一个由你掌舵、逐轮推进的手动循环。Claude 收集上下文、采取行动、检查成果，必要时重复，最后给出回复。我们把这个过程称为 agentic 循环。

举个例子：你让 Claude 做一个点赞按钮。它读你的代码、改代码、跑测试，然后把它认为能用的结果交回给你。接着由你亲自检查成果，再写下一条提示。

你可以把验证这一步做得更强：把你手动执行的检查步骤沉淀成一个 SKILL.md，让 Claude 端到端地自查更多环节。这里应当包含相应的工具或连接器，让 Claude 能够看到、测量或操作结果。检查越量化，Claude 就越容易自我验证。

比如，你可以在 SKILL.md 里这样写：

目标驱动循环（/goal）

• 触发方式：实时手动提示。
• 终止条件：目标达成，或达到最大轮次上限。
• 最适合：有可验证退出标准的任务。
• 控制用量的办法：设定明确的完成标准和硬性的轮次上限，比如「试 5 次后停」。

有时候一轮不够，复杂任务尤其如此。让 agent 能够反复迭代，效果会更好。用 /goal 定义清楚「怎样算完成」，就能延长 Claude 迭代的时长。

当你把成功标准定义清楚，Claude 就不用自己判断「够好了没」，也就不会过早收手。每当 Claude 想停下时，会有一个评估模型（evaluator）来核对你的条件，把它打回去继续干，直到目标达成或触及你设定的轮次上限。

这也是为什么确定性的标准特别管用——比如「通过多少个测试」或「达到某个分数阈值」。

例如：

定时循环（/loop 与 /schedule）

• 触发方式：设定的时间间隔。
• 终止条件：你取消它，或工作自然完成（PR 合入、队列清空）。
• 最适合：周期性的工作，或与外部环境/系统对接。
• 控制用量的办法：拉长间隔，或改成基于事件（而非时间）来响应。

有些 agent 工作是周期性的：任务本身不变，变的只是输入。比如每天早上汇总 Slack 消息。还有些工作依赖外部系统，而一种简单的对接方式，就是按固定间隔去查看它、根据变化做出反应。比如一个 PR，可能收到代码评审意见或 CI 挂掉。

对于这类场景，可以用 /loop 来触发 Claude 定期运行，它会按间隔重复执行同一条提示。例如：

/loop 跑在你自己的电脑上，所以你一关机它就停了。你可以用 /schedule 创建一个例程（routine），把循环搬到云端去跑。

主动式循环（Proactive loops）

• 触发方式：由事件或排期触发，没有真人实时参与。
• 终止条件：每个任务在自己的目标达成时退出；例程本身则一直运行，直到你关掉它。
• 最适合：源源不断、定义清晰的重复性工作，如 bug 上报、issue 分诊、迁移、依赖升级等。
• 控制用量的办法：把例程路由到更小、更快的模型，只在需要判断力的关键决策上启用最强模型。

上面这些原语，加上 Claude Code 的其他能力——自动模式（auto mode） 和动态工作流（dynamic workflows，研究预览）——可以组合成一个循环，用于长时间运行的工作。

比如，处理源源不断的反馈，你可以这样组合：

/schedule（研究预览）：跑一个例程，定期检查有没有新上报。

/goal：定义「怎样算完成」，配合**技能（skills）**说明如何验证。

动态工作流：编排多个 agent，对每一条上报做分诊、修复、复审。

自动模式：让例程一路跑下去，不用停下来征求许可。

拼在一起，一条提示可能长这样：

保住代码质量

一个循环产出的质量，取决于它周围的整个系统。设计这套系统时：

• 保持代码库本身的整洁：Claude 会沿用你代码库里已有的模式和约定。
• 给 Claude 自我验证的手段：用技能把「你和团队眼中的好」编码下来。
• 让文档触手可及：框架和库的文档里有最新的最佳实践。
• 用第二个 agent 做代码评审：一个带着全新上下文的评审者偏见更少，不会被主 agent 的推理带跑。你可以用内置的 /code-review 技能，或用 Code Review（面向 GitHub）。

当某次结果没达标时，别只停在「修好这一个问题」，而要试着把它编码进系统，让未来所有迭代都因此受益。

控制 token 用量

要控制 token 用量，循环得有清晰的边界：

• 为任务挑对原语和模型：小任务不需要多个 agent 或循环；有些任务用更便宜、更快的模型就够了。
• 定义清晰的成功与终止标准：把「怎样算完成」说具体，Claude 就能更快抵达答案（但也别太早收手）。
• 大规模开跑前先试点：动态工作流可能一次派生出成百上千个 agent，先在一小片工作上估算用量。
• 确定性的活儿用脚本：跑脚本比一步步推理便宜。比如一个 PDF 技能可以自带一个填表脚本，让 Claude 每次直接调用，而不是每次重新推导代码。
• 例程别跑得比实际需要更勤：让间隔匹配「你盯的东西多久变一次」。
• 复盘用量：/usage 命令按技能、子 agent、MCP 拆解近期用量；/goal 不带参数运行时会显示已用轮次和 token；/workflows 会显示每个 agent 的 token 用量，你随时可以叫停某个 agent。

上手指南

小结如下：

有了想法就把循环跑起来，观察结果——看它在哪里卡住、在哪里用力过猛——然后大胆迭代。

更多内容可阅读 Claude Code 文档中关于并行运行 agent 的部分，以及 loop、schedule、goal 和动态工作流各页面。

本文由 @delba_oliveira 撰写。

原文：https://x.com/ClaudeDevs/article/2074208949205881033