别再逐条下达指令,学会为Agent设计“工作循环”,让AI编程助手自主完成任务闭环。核心内容:1. 循环设计的核心定义与分类维度2. 基于轮次与基于目标的两大循环模式详解3. 如何通过技能文件与用量管理提升效率
现在有很多人在讨论"设计循环(loop)"而不是给你的编程 Agent 写提示词。如果你在 X 上花点时间想搞清楚循环到底是什么,你会找到各种不同的答案在 Claude Code 团队,我们对循环的定义是:Agent 反复执行工作周期,直到满足某个停止条件。我们根据以下维度将循环分为几种不同的类型:
如何触发如何停止使用哪个 Claude Code 原语每种类型最适合什么样的任务我们将介绍主要的循环类型、何时使用每种类型,以及如何在管理 Token 用量的同时保持代码质量。并非所有任务都需要复杂的循环;从最简单的方案开始,有选择地使用这些模式基于轮次的循环(Turn-based loops)
触发方式:用户的一条提示词停止条件:Claude 判断它已完成任务或需要额外上下文最佳适用场景:不属于常规流程或计划的较短任务管理用量的方式:编写具体的提示词,并通过 Skill 改进验证步骤以减少轮次数你发送的每条提示词都会启动一个手动循环,由你指挥每一轮。Claude 收集上下文、执行操作、检查工作成果、必要时重复,然后回复你。我们称之为 Agent 循环(agentic loop)举个例子,让 Claude 创建一个点赞按钮。它读取你的代码,进行修改,运行测试,然后交还一个它认为可以工作的结果。然后你手动检查工作,再写下一条提示词你可以把你的手动检查步骤编写成 SKILL.md 来改进验证环节,让 Claude 能端到端地检查更多自己的工作。这应该包含工具或连接器,让 Claude 能够看到、度量或交互结果。检查越是量化的,Claude 就越容易自我验证例如,在你的 SKILL.md 文件中你可以这样写:---
name: verify-frontend-change
description: 在宣告完成之前端到端验证任何 UI 变更。
---
# 验证前端变更
永远不要仅凭成功的代码编辑就报告 UI 变更已完成。像人类评审员那样去验证它:
1. 启动开发服务器并在浏览器中打开被修改的页面。
2. 直接与变更进行交互。对于新的控件(按钮、输入框、开关):
点击它,确认预期的状态变化,并截图对比前后效果。
3. 检查浏览器控制台:不能有任何新的错误或警告。
4. 使用 Chrome Devtools MCP,运行性能追踪并审计 Core Web Vitals。
如果任何步骤失败,修复问题并从步骤 1 重新开始
——不要交还部分验证的工作。
基于目标的循环(Goal-based loop) — /goal
触发方式:手动实时输入的提示词停止条件:目标达成,或达到最大轮次数最佳适用场景:具有可验证退出条件的任务管理用量的方式:设定具体的完成标准和明确的轮次上限,例如"5 次后停止"有时候,一轮是不够的,尤其对于更复杂的任务。Agent 在能够迭代的时候表现更好。你可以通过 /goal 定义"完成长什么样"来延长 Claude 持续迭代的时间当你定义了成功标准,Claude 就不需要自己判断什么是"够好了"然后提前结束循环。每次 Claude 试图停下时,一个评估模型会检查你的条件,然后把它送回去继续工作,直到目标达成或你定义的轮次数用完这就是为什么确定性标准——比如测试通过数量或达到某个分数阈值——如此有效例如:/goal 把首页的 Lighthouse 分数提高到 90 或以上,5 次后停止。
基于时间的循环(Time-based loop)— /loop 和 /schedule触发方式:指定的时间间隔停止条件:你取消它,或者工作完成(PR 合并了,队列清空了)最佳适用场景:重复性工作,或与外部环境/系统的对接管理用量的方式:设置更长的间隔,或基于事件而非时间来响应有些 Agent 工作是重复性的:任务不变,只是输入变了。例如,每天早上总结 Slack 消息。还有些工作依赖外部系统,一种简单的对接方式是按照一定间隔去检查它,然后对变化做出反应。例如,一个可能收到代码评审或 CI 失败的 PR对于这些情况,你可以用 /loop 来触发 Claude 运行,它会按照一个间隔重复执行某条提示词。例如:/loop 5m 检查我的 PR,处理评审意见,修复失败的 CI
/loop 在你的电脑上运行,所以如果你关机了,它就停了。你可以通过 /schedule 创建一个例行任务,把循环移到云端主动循环(Proactive loops)
触发方式:由事件或计划触发,无需人类实时参与停止条件:每个任务在目标达成时退出。例行任务本身会一直运行直到你关闭它最佳适用场景:重复性的、定义明确的工作流:Bug 报告、Issue 分类、迁移、依赖升级等管理用量的方式:将例行任务路由到更小更快的模型,关键判断使用最强大的模型上述的原语,加上 Claude Code 的其他功能如 Auto 模式 和 动态工作流(Dynamic Workflows)(研究预览),可以组合成一个用于长期运行工作的循环例如,要处理传入的反馈,你可以使用:- /schedule(研究预览)运行一个检查新报告的例行任务
- /goal 定义完成长什么样,Skills 记录如何验证
- 动态工作流 编排多个 Agent 对每个报告进行分类、修复和评审
- Auto 模式 让例行任务运行时不需要停下来请求许可
把它们放在一起,一条提示词可以是这样的:/schedule 每小时:检查 #project-feedback 中的 bug 报告。
/goal:不要停下来,直到本次运行发现的每个报告都已分类、处理和回复。
修复 bug 时,使用工作流在并行工作树中探索三个方案,
并让一个评审者对它们进行对抗性评审。
保持代码质量循环输出的质量取决于它周围的系统。在设计系统时:保持代码库本身的整洁:Claude 会遵循代码库中已有的模式和约定。给 Claude 一种验证自身工作的方式:用 Skill 编码你和你的团队对"好"的定义。让文档触手可及:框架和库的文档包含最新的最佳实践。使用第二个 Agent 做代码评审:拥有全新上下文的评审者偏见更少,不会受到主 Agent 推理的影响。你可以使用内置的 /code-review Skill 或 Code Review for Github。当某个结果不符合标准时,不要止步于修复单个问题——尝试将其编码化,以改进系统在所有未来迭代中的表现管理 Token 用量为了管理 Token 用量,循环应该有清晰的边界:为任务选择合适的原语和模型:较小的任务不需要多个 Agent 或循环。有些任务可以使用更便宜更快的模型。定义明确的成功和停止标准:具体说明完成长什么样,这样 Claude 可以更快地到达解决方案(但不能太快)。大规模运行前先小范围试跑:动态工作流可以生成数百个 Agent。先在一小部分工作上评估用量。确定性工作用脚本:运行脚本比推理每个步骤更便宜。例如,一个 PDF Skill 可以附带一个表单填写脚本让 Claude 每次运行,而不是每次重新推导代码。不要比需要的更频繁地运行例行任务:让间隔匹配你监控的东西变化的频率。查看用量:/usage 命令按 Skill、子 Agent 和 MCP 分解最近的用量,不带参数的 /goal 显示目前的轮次数和 Token 用量,/workflows 显示每个 Agent 的 Token 用量,你可以随时停止某个 Agent。总结一下:基于轮次 — 交出:验证检查 / 何时使用:你在探索或做决策 / 使用:自定义验证 Skill基于目标 — 交出:停止条件 / 何时使用:你知道完成长什么样 / 使用:/goal基于时间 — 交出:触发时机 / 何时使用:工作按计划在你的项目之外发生 / 使用:/loop、/schedule主动循环 — 交出:整个提示词 / 何时使用:工作是重复性且定义明确的 / 使用:以上所有,加上动态工作流要开始使用循环,看看你已经在做的工作。挑一个你是瓶颈的任务,问问自己哪部分可以交出去:你能写验证检查吗?目标够清晰吗?工作是按计划到来的吗?一旦有了想法,运行循环,观察结果——比如它在哪里卡住了或做过头了——不要害怕对它进行迭代更多信息请阅读 Claude Code 文档中关于并行运行 Agent、以及 loop、schedule、goal 和动态工作流的页面英文原文来自Claude code 官方博客
往期文章:
能写代码却上不了网?一句话「解封」你的 AI Agent,刷B站、搜小红书
日行一善,你奶奶都能学会的 Hermes 教程,免费,开源
登录查看剩余 70% 内容