7月7日，Anthropic的Claude Code团队在X 上发布了一份循环设计指南，系统拆解了他们是怎么设计loop的。这份指南读下来，你会发现一个有意思的信号：Agent工程的重心正在从写好指令转向设好规则。

四种循环：从手动到自循环

Claude Code团队把loop分成了四种类型。它们之间的差异不在于技术实现，而在于你把多少控制权交给了Agent。

轮次循环（Turn-based loop）

每次你给Claude Code发一个提示词，就启动了一个轮次循环。

它的运作方式是：Claude收到指令后，收集上下文、采取行动、检查结果、在需要时重复、最后回复你。这个过程里，由它自己决定什么时候停下来，例如它判断自己完成了任务，或者需要你提供更多上下文。

所以你其实一直在用loop，只是没意识到。

但问题也在这里。Claude判断它完成了的标准，和你的预期之间往往有差距。你觉得有些东西还没做好，但它觉得已经可以交差了。这个差距，就是轮次循环最大的短板。

怎么缩小这个差距？Claude Code团队的答案是不要靠prompt去描述你该怎么做，而是靠SKILL.md去定义做完之后必须验证什么。

举个例子。如果你只是写了一句“帮我在这个页面加一个点赞按钮”，Claude加完代码就会停。但如果你的SKILL.md里写了这么一段：

绝对不要仅基于成功的编辑就报告UI更改已完成。像人类评审员一样对其验证：启动开发服务器，在浏览器中打开页面，直接与更改交互，截图对比修改前后状态，检查控制台有无新错误，运行Core Web Vitals审计。任何步骤失败，回到第一步重新来。

这个SKILL.md就是一个**可执行的验收清单，**它把你脑子里那些隐性的判断标准翻译成了Agent可以自动执行的检查清单。

目标循环（Goal-based loop）

轮次循环解决的是Agent怎么干活，但更复杂的任务还需要解决另一个问题：Agent怎么知道自己什么时候真的干完了？这就是目标循环要解决的问题。

使用/goal指令，你给Claude设定的是一个具体的、可验证的目标，而不是一个模糊的期望。比如：

/goal 将主页Lighthouse分数提升到90分或以上，尝试5次后停止。

如果只是说“请优化主页性能”，Claude会根据自己的判断决定优化到什么程度算够好了。这个判断通常是保守的，它倾向于早点交差。而“Lighthouse分数到90分”的判断是客观的，如果没达到就继续。

这里有一个很容易被忽视的设计细节：目标循环的工作原理不是让Claude更加努力，而是引入了一个评估层。每次Claude尝试停止时，一个独立的评估模型会检查目标条件，没达标就驳回继续工作。

这个评估层是全新的上下文，它不受主Agent推理过程的影响。这很关键。Agent在执行任务时会产生某种思维惯性，认为自己做的修改都是合理的。一个独立的评估者正好打破这个惯性。

目标循环的优势在于可量化的完成标准比任何精心措辞的prompt都可靠。不是prompt写得不够好，而是prompt再怎么好，最终的够好了仍然依赖Agent自己的主观判断。而数字不会通融，90分就是90分，少一分都不行。

时间循环（Time-based loop）

前两种循环都是你来触发。但如果Agent的工作需要跟外部系统交互呢？

比如，你的Pull Request收到了新的审阅意见，或者CI跑失败了。这些事件发生在你不在电脑前的时候，等你回来再手动触发Agent处理，黄花菜都凉了。

时间循环就是为这种场景设计的。/loop指令让Claude定时重新执行任务：

/loop 5m 检查我的PR，处理评审意见，修复失败的CI。

每5分钟，Claude自动检查你的PR状态，发现问题就自己动手修。

/schedule是/loop的云端版本，把定时任务从你的本地机器搬到服务器上运行。关了电脑也不会停。

Claude Code团队的建议是尽量让时间间隔跟变化频率匹配，不要太频繁。如果你每1分钟轮询一次，大部分检查都是在空跑，什么都没变，白烧Token。如果你的PR平均3小时才收到一次评审，那每30分钟检查一次已经足够快了。

此外，能基于事件就别基于时间。如果你的代码仓库支持webhook通知（PR有新评论时推送事件），用事件触发远比定时轮询更高效。时间循环只是当你没有事件机制时的一个替代方案。

主动循环（Proactive loops）

主动循环不是一种全新的循环类型，而是前三种的组合包。

它把/schedule（触发）、/goal（目标定义）、动态工作流（任务编排）和自动模式（免确认运行）串起来，构成一条完整的自动化流水线。

举一个原文里的例子：

/schedule 每小时：检查project-feedback频道中的Bug报告。/goal：直到本次运行中发现的每个报告都经过分类、处理并回复才停止。在修复Bug时，使用工作流在三个并行工作树中探索三种解决方案，并让评审智能体进行对抗性审查。

这段指令相当于告诉Claude“我不参与了，每小时你自己看着办”。

从设计的角度来看，主动循环体现了一个关键的工程思路：复杂系统的可靠性不来自于某个厉害的组件，而来自于合理组合简单、可靠的组件。/schedule负责触发，/goal负责边界，工作流负责分工，评审Agent负责质量。每个组件只做一件事，做好自己的事，组合起来就是一条能自主运行的流水线。

三大工程原则

四种循环的拆解提供了操作手册，什么时候用什么。但Claude Code团队的这份指南里，还藏着三条更深层的设计原则，它们解释了为什么loop能生效，而不仅仅是loop怎么用。

原则一：验证闭环决定质量上限

这份指南里有一句话：循环输出的质量取决于它周围的系统。

loop本身只是一个执行框架，它告诉Agent去干、检查、不行就再来。但如果检查这一步是糊弄的，loop做得越多错得越多。

验证系统的设计有三个层次。

第一层：把人的隐性判断变成可执行的检查项。如果SKILL.md里的验证步骤不是文档是代码，Agent真的会去执行。要求检查控制台有没有新错误，Agent就会去读console log。要求对比修改前后的截图，Agent就会真的截两张图放在一起看。验证越具象、越可量化，loop就越不容易跑偏。

第二层：引入独立评审者打破思维惯性。Agent执行任务时会形成自己的推理链，顺着这个推理链往下走，很容易忽略自己犯的错误。这就是为什么Claude Code在目标循环里加了一个独立的评估模型，全新上下文，不受主Agent推理过程影响，只看结果不看过程。这个设计跟人类团队的Code Review逻辑完全一致：写代码的人自己是审不出所有问题的，必须要一个没参与写代码的人来审。

第三层：对抗性审查。在主动循环那个Bug修复的例子中，Claude Code不仅让一个Agent修Bug，还让评审Agent做对抗性审查。不是你改完了我看看就过了，而是我专门来找你漏洞的。你的修复方案有没有引入新问题？有没有边界情况没覆盖？测试用例够不够？

四种循环的本质差异，就是验证自动化程度的不同。

• 轮次循环：验证全靠人，你手动检查Agent的输出
• 目标循环：验证部分自动化，可量化的标准由系统检查
• 时间循环：验证全自动化，Agent自己检查、自己修复
• 主动循环：验证流水线化，多个Agent交叉验证

loop能不能跑稳，不取决于loop本身，取决于你花了多少心思设计验证。

原则二：停止条件比prompt更重要

有多少人写prompt的时候，会在最后加一句请确保质量足够好？问题是，什么是足够好？Agent想要交差，你说质量还不够好。你们之间没有一个共识，因为你没说清楚好到底指什么。

Claude Code团队在设计loop的停止条件时，分了明确的三个层级：

• 任务级：目标达成，Lighthouse上90分了，测试全通过了
• 资源级：最大轮次到了，尝试5次了，该停了
• 经济级：Token预算耗尽，不用无限循环烧钱

这三层里，任务级的停止条件是唯一真正定义完成的。它的设计原则很明确：必须是可量化的、可自动判断的，不能依赖Agent的主观评价。

让代码质量变好不是一个合格的停止条件，因为谁也判断不了什么叫变好。所有测试通过是，Lighthouse分数≥90分是，构建时间减少至少20%是。

这个原则挑战了一个写prompt时的常见习惯：我们总喜欢在prompt里描述质量的期望，而不是定义质量的度量。但loop的设计思路刚好相反：别告诉Agent怎么做得好，告诉它什么叫达标。只要达标了就停，没达标就继续。

原则三：代码库本身就是质量基础设施

Claude Code认为干净的代码库是loop能高效工作的前提。这不是空话。

Agent不是凭空理解你的项目的。它通过读取现有代码、分析文件结构、学习代码风格来建立上下文。如果代码库本身混乱，风格不统一、命名不规范、到处都是死代码，Agent的理解就会出错，基于错误理解做出的修改自然好不到哪去。

更关键的是成本。Claude Code团队明确区分了两种操作方式的成本差异：运行脚本 vs 逐步推理。

如果有一个PDF表单填充的脚本，Agent只需要调一次脚本就完成了。如果没有脚本，Agent需要每次重新推导表单填充的逻辑，这中间的Token消耗可能是几十倍的差距。

这个原则深层含义是别把所有事情都丢给Agent去推理。能做脚本的就写成脚本，能工具化的就工具化。Agent的推理能力是稀缺资源，把它用在真正需要判断的地方，而不是用在可以标准化的重复性工作上。

Claude Code提供/usage命令来查看Token消耗，按技能、子Agent和MCP工具细分。Claude Code团队的建议是：大规模跑loop之前，先用小规模试点看消耗。动态工作流可能一次跑出几百个子Agent，成本变化是指数级的。

从写指令到设规则

传统的Agent开发思路是prompt越写越长，越写越精妙，试图用一段完美的指令覆盖所有可能的情况。loop的设计思路反过来了，prompt不需要完美，系统才需要。只要你把验证条件定义清楚了、停止边界设好了、工具链搭好了，Agent自己会迭代到对为止。当前Agent设计的重心已经从指令层上移到了系统层。你在系统层面付出的每一分设计成本，验证步骤、停止条件、工具链，最终都会转化为Agent输出的可靠性。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】