# Getting started with loops / 开始使用智能体循环 **By Delba de Oliveira and Michael Segner | June 30, 2026** Learn how the Claude Code team defines agentic loops, with practical guidance on progressing from turn-based to goal-based, time-based, and proactive loops—and when to use each. > 了解 Claude Code 团队如何定义智能体循环（Agentic Loops），这里提供了一份实用的进阶指南，带你从基于回合（turn-based）的循环，逐步过渡到基于目标（goal-based）、基于时间（time-based）以及主动式（proactive）循环，并详细解析它们各自的适用场景。 --- There’s a lot of talk right now about "designing loops" instead of prompting your coding agent. A coding agent, like Claude Code, is an AI assistant that can autonomously read, write, and execute code directly in your local development environment. If you spend some time on X trying to pin down what a loop actually is, you'll come across multiple different answers. > 目前，关于“设计循环（designing loops）”而不是简单地向代码智能体（Coding Agent）输入提示词（prompt）的讨论非常多。代码智能体（例如 Anthropic 推出的 Claude Code）是一种可以直接在你的本地开发环境中自主阅读、编写和执行代码的 AI 助手。如果你在 X（原 Twitter）上花点时间去弄清楚循环到底是什么，你会看到很多不同的答案。 On the Claude Code team, we define **loops as agents repeating cycles of work until a stop condition is met**. We categorize a few different types of loops based on: > 在 Claude Code 团队中，我们将**循环定义为：智能体重复执行工作周期，直到满足某个停止条件为止**。我们根据以下几个维度将循环分为几种不同的类型： * How they are triggered > 它们是如何被触发的 * How they are stopped > 它们是如何停止的 * What Claude Code primitive is used > 使用了哪种 Claude Code 原生指令 * What type of task is most appropriate for each. > 每种类型最适合什么类型的任务 We’ll cover the main loop types, when to use each, and how to maintain code quality while managing token usage. Not all tasks require complex loops; start with the simplest solution and use these patterns selectively. > 我们将介绍主要的循环类型、它们各自的适用场景，以及如何在管理 Token 消耗的同时保持代码质量。并非所有任务都需要复杂的循环；建议从最简单的解决方案开始，并有选择性地使用这些模式。 --- ## Turn-based loops / 基于回合的循环 * **Triggered by:** A user prompt. > **触发条件：** 用户输入的提示词。 * **Stop criteria:** Claude judges it has completed the task or needs additional context. > **停止条件：** Claude 判断其已完成任务，或需要更多上下文信息。 * **Best used for:** Shorter tasks that are not part of a regular process or schedule. > **适用场景：** 不属于常规流程或计划内任务的较短任务。 * **Managed usage by:** Write specific prompts and improve verification using skills to reduce the number of turns. > **用量管理：** 编写明确的提示词，并利用技能（Skills）改进验证过程，从而减少交互回合数。 Every prompt you send starts a manual loop with you directing each turn. Claude gathers context, takes action, checks its work, repeats if needed, and responds. We call this the agentic loop. > 你发送的每一个提示词都会启动一个由你主导每一个回合的手动循环。Claude 会收集上下文、采取行动、检查工作成果，并在必要时重复这一过程，最后给出回复。我们称之为“智能体循环（Agentic loop）”。 For example, ask Claude to create a like button. It reads your code, makes the edit, runs the tests, and hands back something it *believes* works. You then manually check the work, and write the next prompt. > 例如，你要求 Claude 创建一个点赞按钮。它会读取你的代码、进行编辑、运行测试，然后返回它*认为*有效的成果。随后，你需要手动检查这些工作，并写下下一个提示词。 You can improve the verification step by encoding your manual steps as a `SKILL.md` (a custom configuration file in Claude Code used to define specific developer workflows and verification checks) so Claude can check more of its own work, end-to-end. This should include tools or connectors to allow Claude to *see*, *measure* or *interact* with the result. The more quantitative the checks are, the easier it is for Claude to self-verify. > 你可以通过将手动验证步骤编写为 `SKILL.md` 文件（这是 Claude Code 中的自定义配置文件，用于定义特定的开发者工作流和验证检查），来改进验证环节，从而让 Claude 能够端到端地自行检查更多工作成果。这应当包含相关的工具或连接器，让 Claude 能够**看到（see）**、**测量（measure）**或**交互（interact）**最终结果。检查标准越量化，Claude 就越容易进行自我验证。 For example, in your `SKILL.md` file you may specify: > 例如，在你的 `SKILL.md` 文件中，你可以这样指定： ```yaml --- 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. ``` *(Background Note: MCP stands for Model Context Protocol, an open standard by Anthropic that allows AI models to connect seamlessly to external tools and data sources like Chrome Devtools.)* > *（背景补充：MCP 即模型上下文协议，是 Anthropic 推出的一项开放标准，允许 AI 模型与 Chrome 开发者工具等外部工具和数据源无缝连接。）* *(中文对照内容)* ```yaml # 验证前端更改永远不要仅凭代码编辑成功就报告 UI 更改已完成。请像人类代码审查员一样进行验证： 1. 启动开发服务器并在浏览器中打开已编辑的页面。 2. 直接与更改内容交互。对于新控件（按钮、输入框、开关）：点击它，确认预期的状态变化，并在操作前后截图。 3. 检查浏览器控制台：确保没有新的错误或警告。 4. 使用 Chrome Devtools MCP（模型上下文协议），运行性能追踪并审计核心 Web 指标 (Core Web Vitals)。如果任何步骤失败，请修复问题并从第1步重新运行——不要交付仅经过部分验证的工作。 ``` --- ## Goal-based loop (/goal) / 基于目标的循环 * **Triggered by:** A manual prompt in real-time. > **触发条件：** 实时输入的手动提示词。 * **Stop criteria:** Goal achieved OR maximum number of turns reached. > **停止条件：** 达到目标或达到最大交互回合数。 * **Best used for:** Tasks that have verifiable exit criteria. > **适用场景：** 具有可验证退出标准（exit criteria）的任务。 * **Managed usage by:** Setting a specific completion criteria and explicit turn caps, “stop after 5 tries.” > **用量管理：** 设定明确的完成标准和明确的回合上限，例如“尝试 5 次后停止”。 Sometimes, a single turn is not enough, especially for more complex tasks. Agents do better when they can iterate. You can extend how long Claude keeps iterating by defining what done looks like with `/goal`. > 有时候，仅仅一个回合是不够的，对于复杂任务尤其如此。智能体在可以进行迭代时表现得更好。你可以通过使用 `/goal` 指令定义“完成的标准”，来延长 Claude 持续迭代的时间。 When you define the success criteria, Claude doesn’t have to make a determination on what is “good enough” and end the loop early. Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work until the goal is met or a number of turns you define is reached. > 当你定义了成功标准后，Claude 就无需自行决定什么是“足够好”并过早结束循环。每次 Claude 试图停止时，评估模型（evaluator model）都会检查你设定的条件，如果不满足，则将其发回继续工作，直到目标达成或达到你设定的回合数上限。 This is why deterministic criteria, such as number of tests passed or clearing a certain score threshold, are so effective. > 这就是为什么确定性的标准（例如通过的测试用例数量或达到特定的分数阈值）如此有效的原因。 For example: > 例如： ```bash /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries. ``` > `/goal 使主页的 Lighthouse 评分达到 90 分或以上，尝试 5 次后停止。` --- ## Time-based loop (/loop and /schedule) / 基于时间的循环 * **Triggered by:** A specified time interval. > **触发条件：** 设定的时间间隔。 * **Stop criteria:** You cancel it, or the work completes (the PR merges, the queue is empty). > **停止条件：** 用户手动取消，或工作完成（如 PR 已合并、队列已清空）。 * **Best used for:** For recurring work, or interfacing with external environments / systems. > **适用场景：** 周期性任务，或与外部环境/系统进行交互。 * **Managed usage by:** Set longer intervals or react based on events rather than time. > **用量管理：** 设置更长的时间间隔，或者基于事件触发而非单纯基于时间触发。 Some agentic work is recurring: the task stays the same and only the inputs change. For example, summarizing Slack messages every morning. Other work depends on external systems, and a simple way to interface with one is to check it on an interval and react to what changed. For example, a PR which may receive code reviews or fail CI. > 某些智能体工作是周期性的：任务本身不变，变化的只是输入内容。例如，每天早上总结 Slack 消息。另一些工作则依赖于外部系统，与之交互的最简单方式就是定期检查并对变化做出反应。例如，一个随时可能收到代码审查意见或 CI 测试失败的 PR (Pull Request)。 For these, you can trigger when Claude runs with `/loop` which re-runs a prompt on an interval. For example: > 对于这些场景，你可以使用 `/loop` 指令来触发 Claude，它会按照设定的时间间隔重新运行提示词。例如： ```bash /loop 5m check my PR, address review comments, and fix failing CI ``` > `/loop 每 5 分钟检查一次我的 PR，处理审查意见，并修复失败的 CI 测试。` `/loop` runs on your computer, so if you turn it off, it stops. You can move the loop to the cloud by creating a routine with `/schedule`. > `/loop` 是在你的本地计算机上运行的，因此一旦关闭本地环境它就会停止。如果你希望将循环迁移到云端，可以使用 `/schedule` 创建一个例行任务（routine）。 --- ## Proactive loops / 主动式循环 * **Triggered by:** An event or schedule, with no human in real time. > **触发条件：** 事件或计划任务，无须人类实时干预。 * **Stop criteria:** Each task exits when its goal is met. The routine itself runs until you turn it off. > **停止条件：** 单个任务在达到目标后退出。例行任务本身会持续运行，直到你将其关闭。 * **Best used for:** Recurring streams of well-defined work: bug reports, issue triage, migrations, dependency upgrades, etc. > **适用场景：** 定义明确的重复性工作流：如 Bug 报告处理、工单分类 (Issue triage)、代码迁移、依赖升级等。 * **Managed usage by:** Routing routines to smaller, faster models and using the most capable model for judgment calls. > **用量管理：** 将例行任务分配给更小、更快的模型处理，而将最强大的模型保留用于进行关键的判断。 The primitives above, along with other Claude Code features like **auto mode** (which allows Claude to execute terminal commands and modify files without requiring user confirmation for every step) and **dynamic workflows** (research preview: allowing complex orchestration of multiple sub-agents) can be composed into a loop for long-running work. > 上述原生指令，结合 Claude Code 的其他功能（如 **自动模式 / auto mode** —— 允许 Claude 无需用户步步确认即可执行终端命令和修改文件，以及 **动态工作流 / dynamic workflows** —— 处于研究预览阶段，允许对多个子智能体进行复杂的编排），可以组合成一个用于长时间运行工作的循环。 For example, to handle incoming feedback, you can use: > 例如，为了处理源源不断的反馈，你可以这样设置： 1. **`/schedule`** (research preview) to run a routine that checks for new reports > 使用 **`/schedule`**（研究预览版）运行例行程序，检查新的反馈报告 2. **`/goal`** to define what done looks and **skills** to document how to verify it > 使用 **`/goal`** 定义完成标准，并利用 **技能 (skills)** 记录如何进行验证 3. **Dynamic workflows** to orchestrate agents that triage each report, fix it, and review the fix > 使用 **动态工作流 (Dynamic workflows)** 编排多个智能体，分别负责对报告进行分类、修复问题以及审查修复结果 4. **Auto mode** so the routine runs without stopping to ask for permission > 开启 **自动模式 (Auto mode)**，这样例行程序就能持续运行，而无需中途停下来请求权限 Putting it together, a prompt could look like this: > 将这些组合在一起，提示词大概是这样的： ```bash /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. ``` > `/schedule 每小时执行一次：检查 #project-feedback 频道的 bug 报告。 /goal：本次运行中发现的所有报告都必须被分类、处理并回复，否则不停止。在修复 bug 时，使用工作流在平行的工作树中探索三种解决方案，并让裁判模型对它们进行对抗性审查。` --- ## Maintaining code quality / 保持代码质量 The quality of a loop’s output depends on the system around it. When designing the system: > 循环输出的质量取决于围绕它构建的系统。在设计系统时，请注意： * **Keep the codebase itself clean:** Claude follows patterns and conventions that already exist in your codebase. > **保持代码库本身的整洁：** Claude 会遵循你的代码库中已有的模式和规范。 * **Give Claude a way to verify its own work:** Encode what good looks like for you and your team with skills. > **赋予 Claude 验证自身工作的方法：** 使用“技能（skills）” 将你和团队认可的“好标准”编写成规范。 * **Make docs easy to reach:** Frameworks and libraries docs have up-to-date best practices. > **让文档易于获取：** 框架和库的文档包含了最新的最佳实践。 * **Use a second agent for code reviews:** A reviewer with fresh context is less biased and not influenced by the main agent’s reasoning. You can use the built-in `/code-review` skill or Code Review for Github. > **使用第二个智能体进行代码审查：** 拥有全新上下文的审查员不易产生偏见，也不会受主智能体推理逻辑的影响。你可以使用内置的 `/code-review` 技能或针对 Github 的代码审查工具。 When an individual result doesn’t meet the standard, don’t stop at fixing the individual issue, try to encode it to improve the system for all future iterations. > 当某一次个别结果未达到标准时，不要仅仅停留在修复个别问题上，应尝试将其编写成规则，以便在未来的所有迭代中改进整个系统。 --- ## Managing token usage / 管理 Token 消耗 To manage token usage, loops should have clear boundaries: > 为了妥善管理 Token 使用量，循环应具备清晰的边界： * **Choose the right primitive and model for the job:** Smaller tasks don’t need multiple agents or loops. Some tasks can use cheaper and faster models. > **为任务选择合适的原生指令和模型：** 较小的任务不需要多个智能体或循环。某些任务完全可以使用更便宜、更快的模型。 * **Define clear success and stop criteria:** Be specific about what done looks like so Claude can arrive at the solution sooner (but not too soon). > **定义清晰的成功和停止标准：** 明确什么是“已完成”，以便 Claude 更快地得出解决方案（但也不能过早退出）。 * **Pilot before a large run:** Dynamic workflows can spawn hundreds of agents. Gauge usage on a smaller slice of the work first. > **在大规模运行前先进行试点：** 动态工作流可能会生成数百个智能体。先在小部分工作上测试使用情况。 * **Use scripts for deterministic work:** Running a script is cheaper than reasoning through the steps. For example, a PDF skill can ship a form-filling script that Claude runs each time, instead of re-deriving the code. > **针对确定性工作使用脚本：** 运行预设脚本比让大模型一步步推理成本更低。例如，一个 PDF 技能可以包含一个填表脚本，让 Claude 每次直接运行，而不是每次都重新推导代码。 * **Don’t run routines more often that you need to:** Match the interval to how often the thing you’re watching changes > **不要过度频繁地运行例行任务：** 让检查间隔与你所监控事物的变化频率相匹配。 * **Review usage:** The `/usage` command breaks down recent usage by skills, subagents, and MCPs, `/goal` with no arguments shows number of turns and token usage so far, `/workflows` shows each agent’s token usage and you can stop an agent at any time. > **审查使用量：** `/usage` 命令会按技能、子智能体和 MCP 细分近期的使用情况；不带参数的 `/goal` 会显示当前的交互回合数和 token 消耗量；`/workflows` 会显示每个智能体的 token 消耗，你还可以随时停止任何一个智能体。 --- ## Getting started / 开始行动 To summarize: > 总结如下： | Loop / 循环类型 | You hand off / 你需要提供 | Use it when / 适用场景 | Reach for / 使用工具 | | :--- | :--- | :--- | :--- | | **Turn-based**
基于回合 | The check
验证检查 | You're exploring or deciding
处于探索或决策阶段 | Custom verification skills
自定义验证技能 | | **Goal-based**
基于目标 | The stop condition
停止条件 | You know what done looks like
明确知道完成的标准 | `/goal` | | **Time-based**
基于时间 | The trigger
触发器 | The work happens outside your project on a schedule
任务在项目外部按计划发生 | `/loop`, `/schedule` | | **Proactive**
主动式 | The prompt
提示词 | The work is recurring and well-defined
任务是重复且定义明确的 | All of the above, and dynamic workflows
以上所有，以及动态工作流 | To get started with loops, look at the work you already do. Pick one task where you’re the bottleneck and ask which piece you could hand off: can you write the verification check? Is the goal clear enough? Does the work arrive on a schedule? > 要开始使用循环，请审视你目前正在做的工作。挑选一个你正成为效率瓶颈的任务，然后问问自己可以把哪一部分交接出去：你能写出验证检查脚本吗？目标足够清晰吗？工作是按计划准时到来的吗？ Once you have an idea, run the loop, observe the results like where it stalls or over-reaches, and don’t be afraid to iterate on it. > 一旦有了思路，就跑一遍循环，观察它的表现（比如它在哪里卡住了，或者在哪里做过头了），并且不要害怕对其进行迭代优化。