Practical Loop Engineering

实用循环工程 - Addy Osmani - Elevate

实用循环工程

目标、循环与不委托判断的学科

Addy Osmani

2026年8月14日

我通常的工作方式是同时并行处理5到10个代理。有些任务我可以完全委托给代理执行，只要我对停止条件和约束有非常明确的了解。而有些任务则需要我保持更密切的关注，并审查代理执行的代码。

在这些内容中，你可能已经听说过"循环工程"（loop engineering）。几个月前我写了一篇长文详细讨论过这个概念。

循环是一种自主的、自我纠正的反馈周期，AI代理会不断采取行动、测试结果并调整方法，直到达成特定目标。

我们的赞助商信息：

使用Trigger.dev让AI代理在生产环境中存活。一个演示聊天机器人只需几行代码。但生产环境中的相同代理必须应对用户刷新页面、你在对话中途重新部署、服务器崩溃等情况，而且在没有人工介入的情况下不能执行不可逆操作。本次专题的赞助商Trigger.dev刚刚推出了他们的聊天代理，正好填补了这个空白。该代理可以将整个多轮对话作为一项持久任务运行——因此即使在对话中途刷新页面、重新部署、出现空闲间隔甚至服务器崩溃时，对话也能从中断处继续。

现在基本上有两种核心原语（primitive）可供思考。在Claude Code中，你有目标原语（goal primitive），它可以推动单一有界任务向前发展，直到达成特定目标，比如达到可衡量的终点线。然后循环会按照定时器或固定时间间隔重跑，因此你可以用它来安排变更。

在原语成为原语之前

我记得在Claude Code和Codex内置原语之前，循环工程很大程度上依赖于我们自己设置bash循环，手动编写脚本。这就是我当初的处理方式。你可能还记得今年早些时候，我们中的一些人曾尝试使用Geoff Huntley开发的Ralph循环。我们进行了实验，分享了工作流程，交流了哪些方法有效、哪些无效。但当时大多数尝试都局限于个人项目，如果遇到障碍，对我们来说成本并不高。

随着我们不断探索循环工程的模式和特点，现在对如何管理它有了更清晰的认识。我现在可以很大程度上依赖Claude Code和Codex原语的输出。我们已经取得了一些进展。但同时，你必须非常谨慎，因为如果你只是将循环工程放在一边不管不顾，又没有认真思考最终目标或约束条件是否明确，就可能导致问题状态。这就是为什么在决定是否将它用于没有用户或历史复杂度较低的"常青"代码库，与比如需要处理历史遗留问题的银行系统代码库时，需要仔细权衡。

Claude Code团队对循环的定义方式

Claude Code团队提出了四种类型的循环，并给出了他们的见解（他们的文章）。在进入具体内容之前，这是我的简要总结：

在 Claude Code 团队中，我们将循环定义为代理重复执行工作周期，直到满足停止条件。我们根据触发方式、停止方式、使用的 Claude Code 原语以及最适合的任务类型，对不同类型的循环进行分类。并非所有任务都需要复杂的循环，建议从最简单的方案开始，选择性地使用这些模式。你发送的每个提示都会启动一个手动循环，由你主导每一步操作。Claude 会收集上下文、采取行动、检查工作成果、根据需要重复操作并作出回应。我们将这个过程称为智能循环（agentic loop）。例如，要求 Claude 创建一个点赞按钮，它会读取你的代码、进行修改、运行测试，并返回它认为可行的结果。你随后手动检查工作成果，并编写下一个提示。

他们的说明逐步解释了每个环节。

关于基于目标的循环：

有时，单次交互不足以完成任务，尤其是更复杂的任务。当代理能够迭代时表现更佳。你可以通过定义“完成”的标准来延长 Claude 的迭代时间，使用 /goal 命令。当你设定成功标准后，Claude 不需要自行判断“足够好”的标准并提前终止循环。每次 Claude 尝试停止时，评估模型会检查你的条件，直到目标达成或达到你设定的交互次数上限才会停止。这就是为什么确定性标准（如通过的测试数量或达到特定分数阈值）如此有效。例如：/goal 将首页 Lighthouse 分数提升至 90 或以上，最多尝试 5 次。

关于基于时间的循环：

一些智能工作是周期性重复的：任务本身保持不变，仅输入内容变化。例如，每天早上汇总 Slack 消息。其他工作依赖外部系统，一种简单的接口方式是定期检查系统状态并响应变化。例如，一个可能收到代码评审或 CI 失败的 PR。对于这些场景，你可以使用 /loop 命令触发 Claude 的重复执行，定期重新运行提示。例如：/loop 5m 检查我的 PR，处理评审意见并修复失败的 CI。/loop 在本地计算机上运行，如果你关闭它，循环就会停止。你可以通过 /schedule 创建例行任务，将循环迁移到云端。

至于主动循环（最顶层的循环）：

触发方式：由事件或计划触发，且不依赖实时人工干预。停止条件：每个任务在达成目标后自动退出。例行任务本身会持续运行，直到你手动关闭。最佳适用场景：重复出现的、定义明确的工作流：错误报告、问题分类、迁移、依赖项升级。管理方式：将例行任务路由到更小、更快的模型，并使用能力最强的模型进行判断决策。

他们关于验证的建议值得全文引用，因为这将人工检查转化为 Claude 自主执行的机制：

---
name: verify-frontend-change
description: 在声明完成之前，通过端到端验证任何UI更改。
---
# 验证前端更改
不要仅凭一次成功的编辑就报告UI更改已完成。
请像人类审核员那样进行验证：
1. 启动开发服务器并在浏览器中打开已编辑的页面。
2. 直接与更改内容进行交互。对于新控件（按钮、输入框、切换开关）：点击它，确认预期的状态变化，并截取更改前后的截图。
3. 检查浏览器控制台：确保没有新的错误或警告。
4. 使用Chrome Devtools MCP，运行性能追踪并审计核心网页指标（Core Web Vitals）。
如果任何步骤失败，请修复问题并从步骤1重新开始验证 - 不要提交部分验证的工作成果。

目标

我使用目标（goal）的方式是通过它来完成任何具体的工作，直到可以证明工作已经完成。例如，你可以设置一个目标：确保这个体验在5秒内加载，持续进行直到达成目标。系统会持续使用独立的评估检查来验证是否满足完成标准。更好的做法是更具体地说明使用的工具。

关于我实际运行过的量化目标，做过一些事情。我曾用目标来处理GitHub问题：比如审查并关闭最近的10个问题，或审查并将最近的10个问题推进到下一流程。这类目标具有半开放性。或者设定目标：让这个页面加载速度提升50%。有时这种方法有效，有时无效，但关键在于实验。

循环（Loop）

Loop更像是一个调度器，它会持续监控某事物或按照一定周期重复执行某种模式。可以把它想成类似cron的工具。它最适合用于轮询日志或监控外部状态。你可以用它来执行定期检查。如果你发现自己在某个周期内重复执行某些任务，Loop会非常适用。

我委托的任务和我亲自监督的内容

对我而言，我每天大概会使用5到10个代理。通常最多同时运行5个。其中一些任务可能相对安全。比如：嘿，我实现了这个功能，去写相关文档。或者去复查测试覆盖率是否足够。类似这样的任务。当我处理更复杂的问题，或者知道即使我提供了良好的规格说明，或者我认为是良好的规格说明，并设置了停止条件，仍然存在合理可能性无法完全正确完成时，我会更密切地监督这些任务。如果任务涉及任何稍微敏感的内容，比如我已授予系统访问权限，或者功能涉及认证、安全或金融相关的内容，我一定会密切监督。

总的来说，我认为随着人们能够通过清晰的方式验证目标或停止条件是否达成，大家会越来越习惯于委托任务。但你仍然需要查看生成的代码，确保它符合你的预期。

另一个重要的习惯是：不要让完成任务的代理自行决定工作是否合格。一个子代理负责起草更改，另一个独立的子代理负责验证更改。

有时代理会对自己某些判断非常自信，而验证代理可能会发现一些意想不到的问题。例如，它可能认为自己生成的体验基线表现已经足够好，仅基于桌面端评估性能，但你实际上更关注移动端的体验。这可能意味着代理在一个维度上非常自信，却忽略了另一个关键维度。

我曾以一种痛苦的方式认识到这一点。我很好奇：是否存在一些我们尚未从用户处获得直接反馈的问题？无论是通过问题跟踪器还是评论。因此我让它去查看一些竞争对手的情况，整理出一份列表，以及一些尚未推送但本地存在的PR，说明解决这些差距可能的方案。我几乎要推送其中的一些更改，但没有仔细检查。我浏览了它的研究内容，却没有深入查看实现细节。我将任务委托了出去，但几乎也将判断权一并委托。当我真正查看这些更改时，我意识到这会给用户带来大量额外的复杂性，而我个人认为带来的收益却并不大。因此我感到，有时需要自我检查，确保没有将品味和判断权完全交给代理。你应委托任务，但之后必须亲自检查是否达到了你的标准。

顺便说一下，目标背后的评估器并不是那个检查者。它不会以任何方式、形状或形式查看内容的好坏。它唯一要做的就是检查对话记录，确认你指定的硬性规则是否满足。

/goal 将 Dashboard.tsx 中的数据获取层重构，直到 Lighthouse 性能评分 >= 92 且 LCP 时间低于 1.8 秒（如 Lighthouse CLI 输出所示）。不要更改任何钩子的公共 API。每次迭代必须至少改进一个报告指标；如果连续两次迭代没有改进则中止。10 次迭代后停止。

我每天运行的工作流程

我每天执行的工作流程之一：我有一个名为 Agent Skills 的流行开源仓库。我们拥有超过 80,000 个星标，直到最近我们每天需要审查的拉取请求数量高达 80 到 90 个。因此我每天都会花时间查看这些内容。现在使用 loop，你可以设置：每 24 小时或每 12 小时检查一次 GitHub 仓库，查看是否有新的开放问题，并提供它们的紧急程度摘要，或进行初步审查等操作。

/loop every 1h "检查 GitHub 仓库中是否有新的开放问题。提供一个关于其紧急程度的项目符号摘要。"

结合循环和目标

你还可以将循环和目标结合起来使用。你用 loop 安排检查，然后用 goal 解决问题。例如，你可以设置：每 24 小时循环一次，检查 GitHub 上标记为 bug 的问题。如果存在，使用 goal 实施修复，直到所有本地测试通过并推送分支。

/loop every 24h "检查 GitHub 上标记为 'bug' 的问题。如果存在，使用 /goal 实施修复，直到所有本地测试通过并推送分支。"

但同时也要记住，goal 有一些限制，你不能在其中塞入太多内容。

他们的文章中还提供了一个完整示例，展示了这些功能的最终应用方向：

上述基础功能，结合Claude Code的其他特性如自动模式和动态工作流（研究预览版），可以组合成一个用于长期任务的循环系统。例如，处理新反馈时，可以使用：/schedule（研究预览版）运行例行检查新报告的程序，使用/goal定义完成的标准，使用技能文档说明如何验证结果。通过动态工作流协调代理来处理每个报告、修复问题并审查修复结果。自动模式让程序无需中途请求许可即可持续运行。综合起来，提示语可能如下：/schedule 每小时执行：检查项目反馈频道中的漏洞报告。/goal：直到本次运行发现的所有报告都完成分类处理并作出响应前不要停止。修复漏洞时，使用工作流并行探索三个解决方案，并让裁判进行对抗性审查。

三重检查系统实际运作方式

在PR三重检查流程中，当我的循环系统和目标设定协同工作时，最终形成了一套能持续接收PR和问题的系统。这套系统让我能始终掌控每日涌入的工作内容，特别是能实现跨引用关联。这对我的工作影响非常重大。如果我要专注于某个目标，比如"我们要重构系统这部分"，并需要确保所有涉及这部分的issue都因这次重构而关闭，避免与其他工作产生冲突，我就能明确地定义这些要求。

定时任务在定期审查新PR和关闭明显不符合规范的内容方面非常实用。一个有效的终止条件示例：我们有一套贡献指南，其中明确说明目前不接受翻译类提交。

这并不是我们不重视这类工作，而是由于我们团队成员通常不精通所有涌入的编程语言，维护这些翻译内容对我们来说难度较大。因此，当系统能自动关闭涉及该贡献指南条款的PR和issue时，这种自动化能力在定时任务中能发挥巨大作用。这能显著减少我们需要人工审查的工作总量。

循环系统无法解决的场景

我经常被问到循环工程不适用的场景。一般来说，如果你对完成目标的最终状态/完成标准/良好程度没有清晰定义，这种模式可能不适合你的工作。例如，模糊的目标可能是"持续改进直到这个UI设计变得优秀"。这究竟意味着什么？对谁来说是优秀的？如何评估？需要人类审美判断、主观设计决策或开放性创意探索的任务都不适合这种模式。当你对目标有明确清晰的定义时，我认为循环系统是一个值得考虑的解决方案。

赞助商最后的提示：

还在手动构建持久化代理？Trigger.dev新推出的聊天代理（上方示例）能将多轮AI对话转化为单一持久化任务 - 能够跨越部署和崩溃，可暂停等待人工审批，并能从暂停处精确恢复。开源实现，TypeScript编写，可直接集成到Vercel AI SDK。立即查看他们的方案。

重要说明

一个典型的循环系统正在运行的标志是：持续重复执行相同命令却没有任何结果变化。当同一个命令第三次执行时，如果结果与第二次完全相同，这时候应该考虑终止循环。

有一点细节需要注意。重复循环在创建七天后过期。我之前告诉人们这是三天，其实是七天。循环是会话作用域的，因此当你开始新对话时它们会停止——不过通过 --resume 或 --continue 恢复会话时，只要该重复任务仍在七天窗口期内，任务会继续执行。如果需要在会话结束后仍持续运行的任务，可以使用 /schedule 命令在云端执行。

如果你已经每天手动执行某个检查任务，那这就是你的第一个循环。我的第一个循环是处理待处理的拉取请求堆。