为什么你的 Agent 总在半路停下来你让 Claude「实现这个模块」它跑了一轮就交回来——然后你呢还得手动再推它一把。这中间缺的就是一个循环loop。但奇怪的是你去搜「Loop Engineering 到底怎么落地」很少有文章真的把循环拆开来讲——大多还停留在「循环很重要」这样的口号上。所以这篇文章我们跟着 Claude Code 团队在 X 上的技术文章把四种循环模式逐一拆开从最基础的回合制到自动判断的目标驱动到按点干活的定时循环再到完全无人值守的主动循环。在 Claude Code 团队内部对循环有一个简单而明确的定义循环 智能体agent不断地重复一个「工作周期」直到满足某个停止条件为止。围绕着这个定义我们可以依据四个维度把循环分门别类如何触发Triggered by是什么让循环启动如何停止Stop condition什么情况下循环结束使用了哪种 Claude Code 原语Primitive背后依赖的是loop、goal、schedule还是别的机制最适合哪类任务Best for它擅长解决什么问题不过先给一句重要的提醒并不是所有任务都需要一个复杂的循环。能用最简单方案解决的事就不要上复杂模式。先从一个最朴素的方案跑起来再在真正需要的地方有选择地套用下面这些模式。如果你觉得这四种模式抽象不妨换个角度理解——它们本质上对应四种管理风格循环模式管理风格类比回合制微管理每一步都等老板下指令目标驱动定 OKR定好 KPI下属自己干到达标定时排班表到了点自动接班、干活主动全授权招了人让他们独立跑业务1. 回合制循环: 最基础的「推一下动一下」▲ 上图的逻辑很简单你每次发一条 prompt 就是一个完整回合——你触发、你验收主动权始终在你手里。核心特征一览触发方式由用户的 prompt 触发停止条件由 Claude 判断任务已完成或需要更多上下文最适合不属于固定流程、也不按时间表发生的短任务用量管理写具体的 prompt用 skills 强化验证环节、减少来回轮次你发出的每一次prompt其实都在启动一个「手动循环」——只不过每一回合都由你亲自把控。Claude 会先收集上下文、动手执行接着自我检查工作成果。如果发现不够好就重复这个周期直到满意再给你一个回应。我们把这种模式称为agentic loop智能体循环。举个小例子你让 Claude 创建一个「点赞按钮」。它会阅读你的代码、动手修改、跑测试然后返回它认为能用的结果。接下来由你手动检查结果再写下一条 prompt 推进下一步。这里有一个很实用的优化点你可以把原本需要人工执行的验证步骤写进一个SKILL.md里让 Claude 能够端到端地自查更多工作。这个 skill 里应该包含工具或连接器让 Claude 能「看见、度量或真正操作」结果——可量化的检查越多Claude 自我验证就越容易。比如你的SKILL.md可以这样写已翻译为中文便于阅读其中name是技能的技术标识通常保留英文 slug正文与 description 可写中文--- name: verify-frontend-change description: 端到端验证任何前端 UI 改动 --- # 验证一次前端改动 绝不要仅凭代码检查就报告「UI 改动已完成」。 1. 启动开发服务器打开改动后的页面 2. 直接操作这次改动。比如新增了一个按钮就点一下它确认状态确实发生了变化 3. 检查浏览器控制台确保没有新增任何报错或警告 4. 用 Chrome Devtools MCP 跑一次性能审计 如果某一步失败修复问题后从第 1 步重新开始。笔者的实战建议回合制循环是所有模式的地基。哪怕你后面用/goal或/loop本质都是在「自动化的回合制循环」之上包了一层停止条件。所以先把验证 skill 写好后面的高级模式才能跑得稳。2. 目标驱动循环 : 从手动推进到自动收工▲ 这张图里多了一个评估判断环节——Claude 不再凭感觉收工而是拿你定的目标去核对不达标就继续。核心特征一览触发方式实时、手动的 prompt停止条件目标达成或达到最大轮次最适合拥有可验证退出标准的任务用量管理设定具体的完成条件并给出清晰的轮次上限例如「尝试 5 次后停止」很多时候一个回合远远不够——尤其是复杂的任务。智能体在能够「反复迭代」时表现更好。你可以通过/goal来定义什么叫「做完了」从而拉长 Claude 的迭代次数。关键在于一旦你定义了成功标准Claude 就不必自己判断「够不够好」并提前结束循环。每次 Claude 想停下来时一个 Claude **内置的评估机制evaluator model**都会去核对你的条件如果没满足就把任务打回去继续干——直到目标达成或者触达你设定的轮次上限。这也解释了为什么确定性的标准比如「通过的测试数量」或「某个分数阈值」效果最好它们可以被评估模型明确判断不依赖主观感觉。命令示例保持英文/goal get the homepage Lighthouse score to90or above, stop after5tries笔者的实战建议用/goal时尽量把「完成标准」写成数字或布尔值通过/未通过而不是「看起来不错」「足够优雅」这类模糊描述。越确定循环越不会「偷懒」提前收工也不会陷入无限重试。3. 定时循环 : 从「我去看」到「它定期来」▲ 定时循环的关键变化是触发不再靠人。Claude 按你设的间隔自动启动你只需要在产出准备好时验收。核心特征一览触发方式由指定的时间间隔触发停止条件你手动取消或者工作已完成PR 被合并、队列清空等最适合重复性工作或需要对接外部环境 / 系统的场景用量管理把间隔设长一些或者改为「响应事件」而非「响应时间」有一部分智能体工作是重复性的任务本身不变变的只是输入。比如每天早上汇总一遍 Slack 消息。另一类工作则依赖外部系统——最简单的对接方式就是按固定间隔去「探一下」再对变化做出响应。例如某个 PR 可能收到了代码评审意见或者 CI 挂了。对于这类情况用/loop让 Claude 按间隔反复执行同一条 prompt/loop 5m check my PR, address review comments, commit and push any fixes需要注意/loop是运行在你本机上的所以一旦你关掉终端它就停了。如果你希望这个例行任务脱离本地、长期在云端跑可以用/schedule把它迁到云上。笔者的实战建议定时循环最大的坑是「轮询太频繁」——既浪费 token又让 Claude 在「没什么新变化」的轮次里空转。一个实用的经验法是间隔长度 ≈ 你监控的对象真正发生变化的频率。PR 评审意见通常几小时才来一波就没必要每 5 分钟探一次。4. 主动循环: 从「人在场」到「无人值守」▲ 加上事件触发、多智能体协作、Auto 模式——这就是最接近全自动流水线的形态。不过每一环都要先独立跑通。核心特征一览触发方式由事件或时间表触发实时环节里没有人参与停止条件每个子任务在达成自身目标后退出而整个例行任务会一直运行直到你把它关闭最适合定义清晰的工作流——Bug 报告、Issue 分流、迁移、依赖升级等用量管理把例行任务路由到更小、更快的模型把最需要判断力的环节留给最强模型前面的这些原语再加上 Claude Code 的其他能力比如Auto 模式和Dynamic workflows 动态工作流可以被组合成一个用于「长时运行」任务的循环。举个例子要处理源源不断的用户反馈你可以这样搭一条流水线用/scheduleresearch preview跑一个例行任务定期检查有没有新的反馈报告用/goal定义什么叫「处理完了」并配一套记录「如何验证」的 skills用Dynamic workflows来编排多个智能体给每条报告做分流、修复、再评审用Auto 模式让整条流水线无需暂停等待授权自动跑下去。组合起来一条命令大概长这样/schedule every hour: check the project-feedback repositoryfornew bug reports. For each report, triage it, assign it to the right person, and post a summaryinour#bugs channel笔者的实战建议主动循环是「终极形态」但它对系统的健壮性要求最高。建议先单独把每一环跑通验证 skill、/goal标准、/schedule触发再组合起来。否则一处卡住整条无人值守的流水线就会在深夜悄悄空转烧 token。保持代码质量Maintaining Code Quality一个循环产出物的质量取决于它所处的整个系统。在设计这套系统时请记住代码库本身要清爽——Claude 会照着仓库里已有的风格写代码。然后给它一条自查的路径把「做完了、做对了」的标准写进 skills。文档也要放对位置方便它随时翻阅。此外可以用第二个智能体做代码评审——带着「新鲜上下文」的评审者偏见更少也不会被主智能体带偏。内置的/code-reviewskill 或 GitHub 的 Code Review 功能都能派上用场。当某次结果没达标时不要只停留在「修掉这一个具体问题」——要尽量把它沉淀进系统让以后的每一次迭代都变得更好。管理 Token 用量Managing Token Usage要让 token 用量可控循环必须拥有清晰的边界选对原语和模型小任务不需要多智能体也不需要循环有些任务用更便宜、更快的模型就够了定义清晰的「成功 / 停止」条件具体说明什么叫「做完了」Claude 才能更快到达解但也不要早退先小范围试跑再扩大规模Dynamic workflows 可能会一下子拉起成百上千个智能体。先在更小的一块工作上评估用量确定性工作用脚本跑一段脚本比做一次推理步骤更便宜。例如某个 PDF skill 可以自带一个「填表脚本」让 Claude 每次直接运行而不是每次重新推导代码例行任务别跑得比需要的更频繁间隔要匹配你监控对象实际发生变化的频率定期回顾用量/usage命令会按 skills、子智能体、MCP 拆解近期用量不带参数的/goal会显示截至目前的轮次与 token 用量/workflows会显示每个智能体的 token 用量并且你可以随时停掉任意一个智能体。总结如何开始How to get started模式何时使用用哪个回合制Turn-based探索 / 检查 / 决策—无专用原语本质是每次手动 prompt目标驱动Goal-based你清楚「做完」长什么样/goal定时Time-based工作发生在外部/loop、/schedule主动Proactive以上全部 动态工作流组合/goal/schedule Auto 模式 Dynamic workflows要开始用循环先看看你已经在做的工作。挑一个「你本人是瓶颈」的任务问问自己哪一部分可以交出去你能把验证检查写下来吗目标是否足够清晰工作是按时间表来的吗一旦有了想法就先把循环跑起来盯着结果看——尤其留意它在哪里卡住、在哪里「用力过猛」——然后不要害怕去迭代它。一起把 Loop 用起来如果这篇对你有启发欢迎点赞 · 在看 · 转发让更多被「Loop」卡住的同事看到。想继续聊 留言告诉我你还想了解什么 关注本号下一篇我们拆Dynamic workflows——怎么把多智能体编排成一条无人值守的流水线。