ClaudeDevs (@ClaudeDevs)
2026-07-07
R
原文
---
title: "循环上手指南"
author: "ClaudeDevs (@ClaudeDevs)"
source_url: "https://x.com/ClaudeDevs/status/2074208949205881033"
published_at: "2026-07-06T19:08:45.000Z"
fetched_at: "2026-07-07T13:13:54Z"
updated_at: "2026-07-07T14:40:36Z"
language: "zh"
review_status: "reviewed"
---
# 循环上手指南
现在有很多人在谈论“设计循环”，而不是只给编程 agent 写提示词。如果你花点时间在 X 上想弄清楚循环到底是什么，会看到好几种不同答案。
在 Claude Code 团队，我们把**循环定义为：agent 一轮轮重复工作，直到满足停止条件**。我们会根据下面几个维度，对不同类型的循环做分类：
- 它们如何被触发
- 它们如何停止
- 使用了哪种 Claude Code 基础能力
- 每种循环最适合哪类任务。
下面会介绍几种主要的循环类型、各自适合在什么时候使用，以及在控制 token 用量的同时如何保持代码质量。不是所有任务都需要复杂循环；先从最简单的方案开始，有选择地使用这些模式。
---
### **轮次驱动的循环**
- **触发方式**：用户发出的一条提示词。
- **停止条件**：Claude 判断任务已经完成，或者需要更多上下文。
- **最适合用于：** 较短、且不属于固定流程或定时安排的任务。
- **用量控制方式：** 写具体的提示词，并用 skills 改进验证流程，从而减少轮次。****
你发出的每个提示词，都会启动一个手动循环：每一轮都由你来推进。Claude 收集上下文、采取行动、检查自己的工作、必要时重复，然后回复。这就是我们所说的 agentic loop。
比如，你让 Claude 创建一个点赞按钮。它会读取你的代码，做出修改，运行测试，然后交回一个它*认为*可用的结果。接着你手动检查这项工作，再写下一个提示词。
你可以把自己的手动验证步骤写进 SKILL.md，让 Claude 能端到端地检查更多自己的工作。这里应该包括一些工具或连接器，让 Claude 能够*看到*、*测量*结果，或*与结果交互*。检查越量化，Claude 就越容易自我验证。
例如，你可以在 SKILL.md 文件里这样写：
```markdown
---
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 次”。
有时候，单轮对话并不够，尤其是面对更复杂的任务时。agent 在能够迭代时表现更好。你可以用 `/goal` 定义“完成”是什么样子，让 Claude 多迭代几轮。
当你定义了成功标准，Claude 就不需要自行判断什么算“足够好”，也不会过早结束循环。每次 Claude 试图停止时，一个评估模型都会检查你的条件，并让它继续工作，直到目标达成，或达到你定义的轮次数。
这就是为什么确定性标准如此有效，例如通过的测试数量，或达到某个分数阈值。
例如：
```bash
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
```
---
### **时间驱动的循环（/loop 和 /schedule）**
- **触发方式**：指定的时间间隔。
- **停止条件**：你取消它，或者工作完成（PR 合并、队列清空）。
- **最适合用于：** 重复性工作，或与外部环境 / 系统交互。
- **用量控制方式：** 设置更长的间隔，或者基于事件而不是时间做出反应。
有些 agentic 工作是重复发生的：任务本身不变，只是输入在变化。例如，每天早上总结 Slack 消息。还有些工作依赖外部系统，而与外部系统交互的一种简单方式，就是按固定间隔检查它，并对变化做出反应。例如，一个可能收到代码评审意见、也可能 CI 失败的 PR。
对于这类情况，你可以用 `/loop` 让 Claude 按间隔运行；它会定期重新执行同一个提示词。例如：
```bash
/loop 5m check my PR, address review comments, and fix failing CI
```
`/loop` 在你的电脑上运行，所以如果你关掉电脑，它就会停止。你可以用 `/schedule` 创建一个例程（routine），把这个循环移到云端。
---
### **主动循环**
- **触发方式**：事件或日程安排，运行时没有人实时参与。
- **停止条件**：每个任务在达成目标时退出。这个 routine 会一直运行，直到你关闭它。
- **最适合用于：** 定义清楚的重复性工作流：错误报告、issue 分诊、迁移、依赖升级等。
- **用量控制方式：** 把 routine 分配给更小、更快的模型，把最强模型用于需要判断的环节。
上面这些基础能力，再加上 Claude Code 的其他功能，比如 **auto mode** 和 **dynamic workflows**（research preview 阶段），可以组合成长时间运行工作的循环。
例如，为了处理不断到来的反馈，你可以使用：
1. **`/schedule`**（research preview 阶段）：运行一个检查新报告的 routine
2. **`/goal`** 定义“完成”是什么样子，并用 **skills** 记录如何验证它
3. 用 **dynamic workflows** 编排 agent，对每个报告分类处理、修复，并审查修复结果
4. **Auto mode** 让 routine 运行时不再停下来请求许可
组合起来，一个提示词可以像这样：
```bash
/schedule every hour: check the project-feedback channel 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 一种验证自己工作的方式**：把你和团队对“什么样才算好”的判断写进 [skills](https://code.claude.com/docs/en/skills)。
- **让文档容易查到：** 框架和库的文档包含最新的最佳实践。
- **用第二个 agent 做代码评审**：带着新上下文的评审者偏见更少，也不会受主 agent 推理过程的影响。你可以使用内置的 `/code-review` skill，或者 GitHub 上的 [Code Review](https://code.claude.com/docs/en/code-review)。
当某一次结果没有达到标准时，不要只是修掉这个具体问题就停下，而要尝试把它沉淀到系统里，改进未来所有迭代。
---
### **控制 token 用量**
要控制 token 用量，循环需要有清晰边界：
- **为任务选择合适的 Claude Code 能力和模型：** 小任务不需要多个 agent 或循环。有些任务可以使用更便宜、更快的模型。
- **定义清楚的成功标准和停止条件：** 明确说明完成是什么样子，让 Claude 能更快收敛到解法（但也不要太快停止）。
- **大规模运行前先试点：** Dynamic workflows 可以拉起数百个 agent。先在较小的一部分工作上衡量用量。
- **把确定性工作交给脚本**：运行脚本比通过推理重新走一遍步骤更便宜。例如，一个 PDF skill 可以带上一个填表脚本，让 Claude 每次运行它，而不是每次重新推导代码。
- **不要让 routine 跑得比实际需要更频繁：** 让间隔匹配你监控对象的变化频率。
- **查看用量：** `/usage` 命令会按 skills、subagents 和 MCPs 展示最近用量明细；不带参数的 `/goal` 会显示目前为止的轮次数和 token 用量；`/workflows` 会显示每个 agent 的 token 用量，并且你可以随时停止某个 agent。
---
### **开始上手**
总结如下：
| **循环** | **你交出去的是** | **使用场景** | **优先考虑** |
| --- | --- | --- | --- |
| 轮次驱动 | 检查环节 | 你在探索或决策 | 自定义验证 skills |
| 目标驱动 | 停止条件 | 你知道完成是什么样子 | `/goal` |
| 时间驱动 | 触发器 | 工作在项目外部按日程发生 | `/loop`、`/schedule` |
| 主动循环 | 提示词 | 工作是重复发生且定义清楚的 | 上面这些能力，以及 dynamic workflows |
要开始使用循环，可以先看看你已经在做的工作。挑一个你自己成为瓶颈的任务，然后问：哪一部分可以交出去？你能写出验证检查吗？目标足够清楚吗？这项工作会按日程到来吗？
一旦有了想法，就运行这个循环，观察结果，例如它在哪里卡住、哪里做过头，然后不要害怕继续迭代。
更多信息可以阅读 Claude Code 文档中的[并行运行 agents](https://code.claude.com/docs/en/agents)，以及 [loop](https://code.claude.com/docs/en/goal)、[schedule](https://code.claude.com/docs/en/routines)、[goal](https://code.claude.com/docs/en/goal) 和 [dynamic workflows](https://code.claude.com/docs/en/workflows#orchestrate-subagents-at-scale-with-dynamic-workflows) 页面。
*本文作者：* @delba_oliveira