最近圈子里很流行讨论"设计 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 里可以这样写(核心思路)：
--- 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.
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 类型的适用场景
想要开始用 loop，可以先看看你手头已有的工作，找一个你自己是瓶颈的任务，问自己：能不能把验证这一步交出去？目标是不是足够清晰？这个工作是不是可以排期？
一旦有了想法，先跑起来，观察它在哪里卡住或者过度发挥，然后大胆迭代。
