竟在 Agent 工程落地时真正的难点一般不是“如何让模型回答一次”而是如何让它拥有以下工程感什么时候该继续往下做什么时候该停下来它怎么判断自己做对了哪些任务值得自动化循环哪些一轮对话就够了为了理清这些问题Claude Code 把 loop 细分成了四种类型。我们不妨来看看它们分别解决什么场景下的问题。基于轮次的循环1这是最常见的模式。你发一个 promptClaude 做一轮工作然后把结果交还给你。适用场景短任务、临时任务或者当你自己也还在探索、不确定下一步该怎么做的时候。典型例子“帮我加一个 like 按钮。”Claude 读代码、改代码、跑测试然后吐出一个它认为完工的版本。接下来要不要继续完全由你来判断。缺点这种方式虽然简单但验收极其依赖人工。你需要亲自去看页面、点按钮、查控制台、看截图然后再把反馈喂给 Agent。优化小技巧把验收步骤写进SKILL.md。以前端改动为例文档要明确 UI 改动不能只看代码有没有改完必须启动 dev server、打开页面、模拟点击、检查 console 报错必要时跑一遍性能 trace。这样Agent 就能把一部分“人工验收动作”写进自己的闭环里。SKILL 示例name: verify-frontend-changedescription: Verify any UI change end-to-end before declaring it done.Verifying frontend changesNever report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would:Start the dev server and open the edited page in the browser.Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after.Check the browser console: zero new errors or warnings.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.基于目标的循环/goal2这个 loop 主要解决一轮对话绝对搞不定但你心里很清楚“什么样才算做好了”的那些任务。语法示例/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.适用场景有明确、可量化验收标准的任务。比如测试全部通过、Lint 错误清零、某个 Bug 无法复现、或者迁移脚本跑完且两端数据一致。在这里你交给 Agent 的不只是一个任务还包含了一个停止条件。它不用自己去猜“是不是差不多可以收工了”每次想退出时都会通过评估器检查目标是否达成。达成了就停没达成就继续调整代码直到触发目标或达到你设定的最大尝试次数上面的示例就设置为尝试 5 次。/goal 的核心逻辑是要用代码或指标定义清楚“什么叫完成了”。基于时间的循环/loop 与 /schedule这一类循环的重点不在于“完成标准”而在于外部环境的触发方式。很多任务不是你当下问一次就行了因为外部状态在不断变化提交的 PR 随时可能有人提 review commentsCI/CD 流程可能过几分钟才会报错Slack 或 Issue 队列里持续有新的反馈涌入。这时你可以用/loop让 Claude 按照固定的时间间隔重复执行同一个 prompt。语法示例/loop 5m check my PR, address review comments, and fix failing CI上面这个示例的意思是每 5 分钟检查一次 PR有评论就回复/修改CI 挂了就去修。/loop命令运行在你本地电脑的终端电脑一关循环就断了。如果你希望它在云端全天候运行推荐使用/schedule来创建长期定时日程。主动循环3这个循环很接近理想中的“长期运行的 Agent 工作流”。它由特定的系统事件或定时日程触发不用你坐在电脑前盯着。每次触发后它会在目标达成时自动退出但这个 Routine 本身会一直常驻在后台直到你手动关闭它。适用场景重复、边界清晰、验收方式高度明确的工程管线。例如Bug 报告初筛、Issue 分类、第三方依赖自动升级、过时 API 迁移、PR 自动化跟进。/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定时去扫外部的新反馈用/goal严格定义每次处理到什么程度才算合格用skills声明具体的验证和测试手段用dynamic workflows编排多个不同职责的 Agent 协同用auto mode让整个日程在不频繁打扰人类的前提下静默执行。来完成了从“我来操作 Agent”到“我来设计 Agent 系统”的转变。最佳实践看着上面这些实操性很强的 Tips你可能已经跃跃欲试了。不过先别急着大干一场Claude 官方在这里特别提了一嘴“Keep it simple.”——也就是优先用最简单的方案来设计 Agent 系统。很多团队刚接触这些概念很容易一上来就堆复杂的动态工作流或者多 Agent 协同这会把系统搞得不可控。在动手设计任何一个 Loop 之前作为设计者的你只要能把下面这三个底层问题想清楚逻辑自然就顺了谁来触发是用户手动发 Prompt还是靠/goal里的评估器推着它往前走是基于/loop设定的固定时间步长还是等/schedule或外部的 Webhook 事件来唤醒什么时候停是让模型自己判断收工还是等测试全部通过、指标达到阈值是看到 PR 被成功合并还是单纯触达了你设定的最大尝试次数上限怎么控制质量与成本质量往往来自系统而非单纯来自模型。代码库本身要干净因为 Agent 极度擅长模仿已有代码验证步骤也要严密否则 Agent 很容易“钻空子作弊”绕过检查另外最好把 Code Review 交给一个全新上下文的 Agent毕竟当局者迷前一个 Agent 很容易陷入思维定势。成本控制则需要策略。小任务就别上复杂的循环能用小模型或者写个 Bash 脚本搞定的硬编码逻辑就别让大模型每次去重新推理在跑大面积的复杂流之前先小范围 Pilot 试错轮询间隔也要 match 任务变化的频率。如果数据一天才更新一次真没必要每分钟去 poll 一次。总结所以读完这篇文章最不重要的其实是具体命令的参数最重要的是这张 Agent Loop 场景选择指南4