别再只写 Prompt 了，开始设计 Loop

最近圈子里很流行讨论"设计 loop"而不是单纯写 prompt 指挥 coding agent。但如果你去 X 上搜一下"loop 到底是什么"，会发现说法五花八门。

Claude Code 团队给出的定义是：loop 就是 agent 反复执行一轮工作，直到满足某个终止条件为止。

文章按以下几个维度对 loop 进行了分类：

• 触发方式是什么

• 如何终止

• 用到了 Claude Code 的哪个原语(primitive)

• 什么类型的任务最适合用哪种 loop

核心建议是：不是所有任务都需要复杂的 loop，先从最简单的方案开始，按需选用这些模式。

01按轮次触发

•触发方式：用户输入一次 prompt

•终止条件：Claude 自己判断任务完成，或者需要更多信息

•适用场景：比较短、不属于常规流程或排期任务的工作

•管理方式：写具体的 prompt，用 skills 改进验证环节，从而减少来回轮次

每次你发一条 prompt，就手动启动了一轮 loop：Claude 收集上下文、执行动作、检查自己的工作(如果需要就重复)、再给出结果。

这个过程就叫做 agentic loop。

举例来说：让 Claude 做一个类似按钮的功能，它会读代码、改代码、跑测试，然后把它"认为"完成的结果交给你，你手动核实、再决定下一步 prompt。

你可以把验证这一步写进 SKILL.md，让 Claude 能更端到端地核查自己的工作，而不需要你介入。

可以在 skill 里包含工具或指令，让 Claude 能自己看、自己交互、自己核实结果。

检查项越量化，Claude 自我验证的能力就越强。

比如在 SKILL.md 里可以这样写(核心思路)：

If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

02目标导向

•触发方式：一次性手动 prompt

•终止条件：达成目标，或者达到最大轮次上限

•适用场景：有明确、可验证成功标准的任务

•管理方式：设置具体的完成标准和明确的轮次上限，比如"跑到 5 次后停止"

对更复杂的任务，单轮对话往往不够，需要 Claude 能自己迭代。

做法是明确定义"什么叫成功"，让 Claude 自己反复尝试，直到满足条件，或提前触及轮次上限。

由你来定义判断标准，Claude 不需要自己判断"是否足够好"，也不会提前结束。每一轮它会检查是否达到你定义的条件，没达到就继续，直到满足为止。

正因如此，可量化的判断标准(比如测试全部通过，或者达到某个分数)效果最好。

举例：

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

03按时间触发

•触发方式：设定的时间间隔

•终止条件：你手动取消，或工作本身完成(比如 PR 合并、队列清空)

•适用场景：周期性工作，或需要对接外部环境/系统的工作

•管理方式：设置合适的时间间隔，或者基于事件触发而不是纯粹按时间

有些 agentic 工作本质上是周期性的：任务内容不变，但输入每次都在变化。比如每天早上总结 Slack 消息。

也有些工作依赖外部状态变化，只需要在状态变化时检查一下，比如一个可能会因为 CI 通过而收到新 review 意见的 PR。

对这类场景，可以用/loop命令，让 Claude 在同一个 prompt 上反复运行：

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

/loop是在你本机运行的，所以关掉终端它就停了。如果想把这个 loop 挪到云端持续运行，可以用/schedule创建一个例行任务。

04主动型

•触发方式：事件或排期触发，全程无需人工实时介入

•终止条件：每个具体任务在达成目标后自动退出，整个例行程序会一直运行，直到你手动关闭

•适用场景：定义明确、反复出现的一类工作，比如 bug 报告、issue 分诊、依赖升级、迁移工作等

•管理方式：把例行任务路由给更小更快的模型，只在需要判断力的地方用最强模型

05组合起来

上面提到的几种 loop 类型，再加上 Claude Code 的其他能力，比如auto mode(自动模式)和dynamic workflows(动态工作流，研究预览版)，可以组合成能长期运行的复杂 loop。

比如要处理用户反馈，你可以这样组合：

1./schedule(研究预览版)：定期检查是否有新的反馈

2./goal：定义"完成"的标准，用 skills 记录如何验证

3.Dynamic workflows：编排多个 agent 分诊每条反馈、修复问题、审查修复结果

4.Auto mode：让整个流程自动运行，不需要人工授权确认

组合起来，一条 prompt 大概是这样：

/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.

06代码质量

loop 输出质量的好坏，取决于你围绕它搭建的整个系统。

文章给出了几条建议：

•保持代码库本身干净：Claude 会遵循代码库里已有的模式和约定

•给 Claude 一种验证自己工作的方式：用 skills 把"什么叫好"这件事写清楚

•让文档容易被查阅到：框架和库的文档要保持最新的最佳实践

•用第二个 agent 做代码审查：一个带着"新鲜"上下文、不受主 agent 推理过程影响的 reviewer 更客观。可以用内置的/code-reviewskill，或者 GitHub 上的 Code Review 功能

当某一次结果没达到标准时，不要只是修补这一次的问题，尽量把它沉淀进系统里，让未来所有迭代都能受益。

07token 消耗

loop 应该有清晰的边界，具体建议：

•选对原语和模型：简单任务不需要多个 agent 或复杂 loop，也不需要用最贵的模型

•明确定义成功和终止标准：讲清楚"完成"是什么样子，让 Claude 能尽早收敛(但也别太早)

•大规模跑之前先小范围试点：dynamic workflows 可能一次派生上百个 agent，先在一小部分工作上评估用量

•确定性工作用脚本解决：比如一个填表脚本，比每次都让模型重新推导代码更省钱

•不要跑得比实际需要更频繁：检查间隔应该匹配你关注对象变化的频率

•定期查看用量：/usage命令可以查看近期各 skill、subagent、MCP 的使用和 token 消耗；/goal不带参数可查看当前轮次和 token 用量；/workflows可查看每个 agent 的 token 用量，随时可以终止某个 agent

08入门总结

Loop 类型 交出去的是什么 什么时候用 用哪个功能 Turn-based 按轮次 检查这一步 你还在探索 或做决策 自定义验证 skill Goal-based 目标导向 终止条件 你清楚完成 是什么样子 /goal Time-based 按时间 触发条件 发生在项目 排期之外 /loop /schedule Proactive 主动型 整个 prompt 反复出现且 定义明确 以上全部 + dynamic workflows

▲ 图：不同 loop 类型的适用场景

想要开始用 loop，可以先看看你手头已有的工作，找一个你自己是瓶颈的任务，问自己：能不能把验证这一步交出去？目标是不是足够清晰？这个工作是不是可以排期？

一旦有了想法，先跑起来，观察它在哪里卡住或者过度发挥，然后大胆迭代。

更多信息可以查看 Claude Code 文档中关于"并行运行 agent"以及 loop、schedule、goal、dynamic workflows 相关的页面。

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

你现在最想把哪一步交给 loop？

觉得有用 → 点个❤️在看转给朋友