Claude Code 入门：智能体循环

循环入门

现在有很多关于循环工程或"设计循环"而非直接给编码智能体写提示词的讨论。如果你花些时间在 X 上试图弄清楚循环到底是什么，你会看到多种不同的答案。

在 Claude Code 团队，我们将循环定义为智能体重复执行工作周期，直到满足停止条件。我们根据以下几个方面将循环分为几种不同类型：

• 它们如何被触发
• 它们如何被停止
• 使用了哪种 Claude Code 原语
• 每种类型最适合什么类型的任务。

我们将介绍主要的循环类型、各自的使用时机，以及如何在管理 token 用量的同时保持代码质量。并非所有任务都需要复杂的循环；从最简单的方案开始，有选择地使用这些模式。

轮次循环

• 触发方式：用户提示词。
• 停止条件：Claude 判断已完成任务或需要额外上下文。
• 最适用于：不属于常规流程或计划的较短任务。
• 通过以下方式管理用量：编写具体的提示词，并利用技能改进验证，以减少交互轮数。‍

你发送的每一条提示词都会启动一个手动循环，由你引导每一轮交互。Claude 收集上下文、采取行动、检查自己的工作、按需重复，然后给出回应。我们称之为智能体循环。

例如，让 Claude 创建一个点赞按钮。它会读取你的代码、进行修改、运行测试，然后交回一个它认为可用的结果。随后你手动检查这项工作，并编写下一条提示词。

你可以通过将手动步骤编写为 SKILL.md 来改进验证环节，让 Claude 能够端到端地自行检查更多工作。（关于在此类自动化中如何在技能、hooks 和子智能体之间做选择，请参阅我们的引导 Claude Code指南。）

这应当包含工具或连接器，让 Claude 能够查看、度量或交互结果。检查越量化，Claude 就越容易自我验证。

例如，在你的 SKILL.md 文件中可以指定：

--- 
name: verify-frontend-change 
description: Verify any UI change end-to-end before declaring it done. 
--- 
# Verifying frontend changes 
Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would: 
1. Start the dev server and open the edited page in the browser. 
2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after. 
3. Check the browser console: zero new errors or warnings. 
4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.
If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

基于目标的循环（/goal）

• 触发方式：实时手动输入提示词。
• 停止条件：目标达成，或达到最大轮次上限。
• 最适用场景：具有可验证退出条件的任务。
• 管理方式：设定明确的完成标准和显式的轮次上限，例如“尝试 5 次后停止”。

有时，单轮并不够，尤其是面对更复杂的任务。当智能体能够迭代时，表现会更好。你可以通过 /goal 定义“完成”的标准，从而延长 Claude 持续迭代的时间。

当你定义了成功标准后，Claude 就不必自行判断什么算“足够好”而提前结束循环。每当 Claude 试图停止时，一个评估模型会检查你的条件，并将它送回继续工作，直到目标达成或达到你设定的轮次上限。

这正是确定性标准如此有效的原因，例如通过的测试数量或达到某个分数阈值。

例如：

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

基于时间的循环（/loop 和 /schedule）

• 触发方式：指定的时间间隔。
• 停止条件：你取消它，或者工作完成（PR 合并、队列清空）。
• 最适用于：重复性工作，或与外部环境 / 系统交互。
• 管理使用方式：设置更长的间隔，或基于事件而非时间做出反应。

有些智能体工作是重复性的：任务保持不变，只有输入在变。例如，每天早上总结 Slack 消息。另一些工作则依赖外部系统，而与外部系统交互的一种简单方式就是按间隔检查它，并对发生变化的部分做出反应。例如，一个可能收到代码审查或 CI 失败的 PR。

对于这些情况，你可以通过 `/loop` 触发 Claude 运行，它会按间隔重新运行提示词。例如：

/loop 5m check my PR, address review comments, and fix failing CI

`/loop` 在你的电脑上运行，所以如果你关机，它就会停止。你可以通过 `/schedule` 创建例程，把循环迁移到云端。

主动循环

• 触发方式：由事件或计划触发，无需人工实时参与。
• 停止条件：每个任务在达成目标后退出。例程本身会一直运行，直到你将其关闭。
• 最适合用于：定义明确工作的重复性任务流：bug 报告、issue 分类、迁移、依赖升级等。
• 通过以下方式管理用量：将常规任务路由到更小、更快的模型，并将能力最强的模型用于需要判断的决策。

上述原语，连同 Claude Code 的其他功能（如 auto mode 和 dynamic workflows （研究预览）），可以组合成一个用于长时间运行工作的循环。

例如，要处理收到的反馈，你可以使用：

1. `/schedule` （研究预览）来运行一个检查新报告的例程
2. `/goal` 来定义完成的标准，skills 来记录如何验证它
3. Dynamic workflows 来编排智能体，对每份报告进行分类、修复并审查修复结果
4. Auto mode 让例程无需停下来请求许可即可运行

综合起来，提示词可以是这样：

/schedule every hour: check #project-feedback for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

维护代码质量

循环输出的质量取决于其周围的系统。在设计系统时：

• 保持代码库本身整洁：Claude 会遵循你代码库中已有的模式和约定。
• 给 Claude 一种验证自身工作的方式：用技能把你和团队心目中的"好"编码下来。
• 让文档易于获取：框架和库的文档包含最新的最佳实践。
• 使用第二个智能体进行代码审查：拥有全新上下文的审查者偏见更少，也不会受主智能体推理的影响。你可以使用内置的 `/code-review` 技能，或用于 Github 的代码审查。

当某个单独的结果不达标时，不要止步于修复这一个问题，而要尝试将其编码下来，以改进系统，惠及未来所有迭代。

管理 token 用量

为了管理 token 用量，循环应当有清晰的边界：

• 为任务选择合适的原语和模型：较小的任务不需要多个智能体或循环。有些任务可以使用更便宜、更快的模型。
• 定义明确的成功标准和停止标准：要具体说明"完成"是什么样子，这样 Claude 就能更快地得出解决方案（但也不要太快）。
• 大规模运行前先试点：动态工作流可能会生成数百个智能体。先在较小范围的工作上评估用量。
• 对确定性工作使用脚本：运行脚本比逐步推理更省成本。例如，一个 PDF 技能可以附带一个表单填写脚本，让 Claude 每次都直接运行，而不必重新推导代码。
• 不要比你需要的频率更频繁地运行例程：让间隔与你所关注对象的变化频率相匹配
• 查看用量：`/usage` 命令会按技能、子智能体和 MCP 细分近期用量，不带参数的 `/goal` 会显示目前的轮数和 token 用量，`/workflows` 会显示每个智能体的 token 用量，你可以随时停止某个智能体。

你的 模型和投入级别选择是影响循环成本的最大杠杆之一。

快速上手

总结如下：

要开始使用循环，先看看你已经在做的工作。挑一个你是瓶颈的任务，问问自己哪一部分可以交出去：你能写出验证检查吗？目标是否足够清晰？这项工作是否按计划到来？

一旦有了想法，就运行这个循环，观察结果，比如它在哪里卡住或过度延伸，并且不要害怕对它进行迭代。

如需了解更多信息，请阅读 Claude Code 文档中关于 并行运行智能体的内容，以及 循环、计划、目标和 动态工作流页面。

本文由 Delba de Oliveira 和 Michael Segner 撰写