翻译：循环 loops 入门指南

智能体循环（agentic loops）正成为AI编程领域的热门议题，但其定义与分类方式众说纷纭。本文将从实践角度系统梳理循环的核心概念与类型，帮助开发者高效运用。

当前业界关于"设计循环（loops）"而非单纯编写提示词（prompt）的讨论日益增多。若在社交媒体上探究循环的具体含义，会收获多种不同答案。

在开发团队的定义中，循环是智能体重复执行工作周期直至满足特定停止条件的过程。其分类依据包括以下几点：

1. 触发方式
2. 停止条件
3. 所使用的原语（primitive）类型
4. 适用任务类型

接下来将介绍主要的循环类型、适用场景，以及如何在控制token用量的同时维护代码质量。并非所有任务都需要复杂循环，建议从最简单的方案入手，按需选用这些模式。

回合制循环（Turn-based loops）

1. 触发方式：用户提示词。
2. 停止条件：AI助手判定任务已完成或需要额外上下文。
3. 最适合用于：不属于常规流程或时间安排的较短任务。
4. 用量管理方式：编写具体的提示词，并使用技能（skills）改进验证，减少回合数。

每一条提示词都会启动一个手动循环，由你指挥每一个回合。AI助手收集上下文、采取行动、检查自身工作、必要时重复，并给出回复。这一过程被称为智能体循环（agentic loop）。

例如，让AI助手创建一个点赞按钮。它会读取现有代码、执行修改、运行测试，并交回一个它认为可用的结果。随后你手动检查该工作，并写下下一条提示词。

通过将手动步骤编码为一份SKILL.md文件，可以改进验证环节，使AI助手端到端地检查更多自身工作。该文件应当包含让AI助手能够看见、测量或交互该结果的工具或连接器。检查越具量化性，自我验证就越容易。

例如，在SKILL.md文件中可以指定：

---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: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.

基于目标的循环（Goal-based loop，/goal）

1. 触发方式：实时手动提示词。
2. 停止条件：达成目标，或达到最大回合数。
3. 最适合用于：具有可验证退出条件的任务。
4. 用量管理方式：设定具体的完成条件与显式回合上限，例如"5次尝试后停止"。

对于更复杂的任务，单个回合往往不够。智能体在能够迭代时表现更佳。通过用/goal定义"完成"的具体标准，可以延长AI助手持续迭代的时间。

明确定义成功条件后，AI助手不必自行判断什么是"足够好"而过早结束循环。每次AI助手尝试停止时，一个评估模型（evaluator model）会检查你的条件，并把它送回继续工作，直到目标达成或达到设定的回合数。

这就是确定性条件（例如通过的测试数量，或达到某个分数阈值）如此有效的原因。

例如：

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

基于时间的循环（Time-based loop，/loop 和 /schedule）

1. 触发方式：指定的时间间隔。
2. 停止条件：你取消它，或工作完成（PR合并、队列清空）。
3. 最适合用于：周期性工作，或与外部环境/系统交互。
4. 用量管理方式：设定更长的间隔，或基于事件而非时间做出反应。

某些智能体工作是周期性的：任务不变，只有输入变化。例如，每天早上汇总Slack消息。另一些工作依赖外部系统，按间隔检查并对其变化做出反应是一种简单的交互方式。例如，一个PR可能收到代码审查或CI失败。

针对这些场景，可以用/loop触发AI助手的运行时间，使其在设定的间隔上重复执行一条提示词。例如：

/loop 5m check my PR, address review comments, and fix failing CI

/loop运行在你的电脑上，关机即停止。通过用/schedule创建一个例程（routine），可以把循环迁移到云端。

主动式循环（Proactive loops）

1. 触发方式：事件或时间安排，实时无人参与。
2. 停止条件：每个任务在达成其目标时退出。例程本身会一直运行，直到你关闭它。
3. 最适合用于：定义良好的周期性工作流：bug报告、issue分诊、迁移、依赖升级等。
4. 用量管理方式：把例程路由到更小、更快的模型，并把最有能力的模型用于需要判断的决策。

上述原语，连同其他智能体编程特性如自动模式（auto mode）和动态工作流（dynamic workflows）（研究预览），可以组合成一个用于长期运行的循环。

例如，要处理传入的反馈，可以组合使用以下方式：

1. /schedule（研究预览）运行一个检查新报告的例程
2. /goal定义"完成"的标准，并用技能（skills）文档化验证方式
3. 动态工作流编排智能体对每条报告进行分诊、修复并审查该修复
4. 自动模式让例程无需停下来请求许可即可运行

将它们组合起来，一条提示词可以长这样：

/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.

维护代码质量

循环产出的质量取决于它周围的系统。设计系统时需注意：

1. 保持代码库本身整洁：AI助手会遵循代码库中已有的模式与约定。
2. 给AI助手一种验证自身工作的方式：用技能（skills）为你和你的团队编码"好"的标准。
3. 让文档触手可及：框架和库的文档包含最新的最佳实践。
4. 使用第二个智能体做代码审查：拥有全新上下文的审查者偏见更少，且不会受主智能体推理的影响。可以使用内置的/code-review技能或GitHub的代码审查（Code Review）。

当某个结果未达到标准时，不要止步于修复这一个别问题，而应尝试将其编码下来，以改进系统在所有未来迭代中的表现。