循环工程实践

来源：https://addyo.substack.com/p/practical-loop-engineering 我通常的工作方式是同时运行五到十个代理。有些任务我会很乐意完全委托给代理，只要我对终止条件和约束条件有清晰的认识。另一些任务则需要我更密切地关注，审查代理的工作内容。

在此你可能听说过循环工程。几个月前我在一篇博文中详细讨论过这个概念。

循环是一个自主的自我修正反馈周期，AI代理在此过程中反复执行操作、测试结果并调整方法，直到达成特定目标

来自赞助商的简短信息：

使用Trigger.dev (https://fandf.co/4pVPWbQ)让AI代理在生产环境中生存下来。演示聊天机器人只需几行代码。但生产环境中的同一代理必须能经受住用户刷新、对话中途重新部署、服务器崩溃等考验——而且不能在没有人工介入的情况下执行不可逆操作。本期赞助商Trigger.dev (https://fandf.co/4pVPWbQ)刚刚推出了聊天代理来解决这一差距。它将整个多轮对话作为持久化任务运行——这样进行中的聊天就能承受刷新、重新部署、空闲间隔甚至崩溃，并从上次中断处继续。 现在基本有两种核心原语可以思考。在Claude Code中，有目标原语(https://code.claude.com/docs/en/goal)，可以驱动单一有界任务向前推进，直到达成特定目标（如可衡量的完成线）。然后**循环(https://code.claude.com/docs/en/scheduled-tasks)**会按计时器或固定间隔重新运行，可用于安排变更。

我记得在Claude Code和Codex内置原语之前，循环工程主要依赖自行搭建的bash循环——手工制作的方案。我当时就是这么做的。你可能还记得今年早些时候，我们很多人都在尝试Geoff Huntley的Ralph循环(https://ghuntley.com/loop/)。我们进行实验、分享工作流程、交流有效与无效的方法，但主要是在一些个人项目上——这样即使碰壁也不会造成太大损失。

随着我们探索循环工程中哪些模式和方面现已更趋成熟，我认为我们对如何驾驭它有了更清晰的认识。现在我基本可以依赖Claude Code和Codex中提供的原语输出。我们已经取得了长足进步。但同时必须保持高度警惕，因为如果采用循环工程后就放任不管，没有认真思考最终目标或约束条件是否定义明确，可能会导致问题。这就是为什么在决定将其用于没有用户或历史复杂度较低的常青代码库，还是用于像银行这样的棕地代码库时，需要细致考量。

Claude Code团队发布了他们对四种循环类型的见解，这与我使用原语的方式一致（他们的文章https://x.com/ClaudeDevs/article/2074208949205881033）。在深入之前，先来看我的简要总结：

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

他们的文章详细介绍了每个层级。

关于目标驱动循环：

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

关于基于时间的循环：

某些代理工作是周期性的：任务保持不变，只有输入会变化。例如每天早上总结Slack消息。其他工作依赖外部系统，与其交互的一种简单方法就是按间隔检查并对其变化做出反应。例如可能收到代码审查或CI失败的PR。对于这些，你可以使用/loop触发Claude运行，它会按间隔重新执行提示。例如：/loop 5分钟检查我的PR，处理审查评论并修复失败的CI。/loop在你的电脑上运行，所以关闭它就会停止。你可以通过/schedule (https://code.claude.com/docs/en/routines)将循环转移到云端。

以及主动循环——最高层级：

触发方式：事件或计划，无人实时参与。停止标准：每个任务在其目标达成时退出。例程本身会一直运行直到你关闭。最适合：定义明确的周期性工作流：错误报告、问题分类、迁移、依赖升级。使用策略：将例程路由到更小更快的模型，将最强大的模型用于判断决策。

他们的验证建议值得完整借鉴，因为它将手动检查转化为Claude自我应用的流程：

``

name: verify-frontend-change description: 在宣布前端变更完成前进行端到端验证。

验证前端变更

切勿仅凭编辑成功就报告UI变更完成。 应像人工审查员那样验证：

1. 启动开发服务器并在浏览器中打开编辑后的页面。
2. 直接与变更交互。对于新控件（按钮、输入框、开关）： 点击它，确认预期状态变化，并截取前后对比图。
3. 检查浏览器控制台：确保没有新的错误或警告。
4. 使用Chrome Devtools MCP，运行性能追踪并审计 Core Web Vitals。 如果任何步骤失败，修复问题并从步骤1重新开始——不要交还部分验证的工作。

我使用目标的方式是将其用于构建任何具体工作，直到证明完成。例如，你可以使用目标表示：确保这个界面在五秒内加载完成，持续工作直到完成。它会继续使用独立评估检查来验证完成标准是否满足。更好的做法是更具体地指定使用的工具。

至于我实际执行过的目标，有几件事我做过。我曾用目标处理GitHub问题：审查并关闭最近10个问题，或审查并推进最近10个问题，类似的任务。这是半开放式的目标，对吧？或者：让这个页面加载速度提升50%。有时效果很好，有时不然，但这重在实验。

[](https://substackcdn.com/image/fetch/$s_!r_sL!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F85bdc2cf-ca2a-4bd8-bc48-f283b3d0a6c5_3200x1880.png)
循环更像是调度器，它监控某些事物或按固定节奏重复执行模式。可以将其想象为cron任务。非常适合轮询日志或监控外部状态这类工作。你也可以用它进行定期检查。如果你发现自己定期执行重复性任务，循环很适合。

[](https://substackcdn.com/image/fetch/$s_!v9CV!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7e56709-7f67-4f14-84a4-5d34561e68f2_3200x1910.png)
对我来说，每天大约使用五到十个代理。通常最多同时运行五个。有些任务可能相对安全，比如：我已经实现了这个功能，去为它编写文档。或者检查我们的测试覆盖率是否足够。类似的工作。如果我处理更复杂的问题，或者即使我给出了完善的规格说明（我认为是完善的），也尝试设置了终止条件，但仍有相当可能无法完全正确完成的任务，我会更密切地关注。如果任务涉及任何敏感操作，无论是赋予系统访问权限，还是功能触及身份验证或安全/财务相关内容，我肯定会密切关注。

总的来说，我认为我们会逐渐习惯委托任务，前提是能够有明确的方法验证目标或终止条件是否达成。但你仍然需要检查生成的代码和内容，确保它们符合你的标准。

另一个重要习惯是不让执行工作的代理自己决定工作质量。一个子代理起草变更，另一个独立验证它。

有时代理可能对某些事情过于自信，而验证代理能发现它们未曾预料的问题。例如，如果代理认为它生成的界面基准性能没问题，但只基于桌面端评估性能，而你实际关心移动端体验。这可能意味着代理只在一个维度上表现自信，却忽略了其他维度。

[](https://substackcdn.com/image/fetch/$s_!fHg7!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0a538d8b-09db-4ee0-a5db-2c3100f15eb6_1456x851.webp)
我曾因此吃过苦头。当时我想弄清楚：是否有用户通过问题跟踪器或评论反馈之外遗漏的功能？于是我让代理研究一些竞争对手，整理一份清单，并在本地创建一些PR（未推送），展示解决这些差距可能的样子。我差点就推送了这些变更。但我没有仔细审查它们。我阅读了它的研究，但没有仔细检查具体实现。所以我委托了任务，但差点连判断也一并委托了。实际上当我仔细查看这些变更时，发现它们会给用户带来很多额外复杂性，而我认为收益并不大。所以我觉得你需要时常提醒自己，不要将品味和判断力也委托给代理。你是委托任务，然后自己检查它是否达到你的标准。

顺便说一下，目标背后的评估器并不是这个检查器。它不会从任何角度查看内容是好是坏。它只检查对话记录，看你指定的硬性规则是否得到满足。

``
/goal 重构Dashboard.tsx中的数据获取层，直到Lighthouse性能分数≥92且LCP低于1.8秒（根据Lighthouse CLI输出）。不要更改任何hooks的公共API。每轮必须至少改进一个报告的指标；如果连续两轮没有改进则中止。10轮后停止。

我每天都会执行的一个工作流程：我维护一个名为Agent Skills (https://github.com/addyosmani/agent-skills)的热门开源仓库。我们拥有超过80,000颗星，最近每天需要处理多达80-90个待审查的拉取请求。所以我每天都会花些时间检查这个仓库。现在使用循环，你可以这样设置：每24小时或每12小时检查GitHub仓库的新开放问题，总结其紧急程度，或进行初步审查，诸如此类。

`` /loop 每1小时 “检查GitHub仓库是否有新的开放问题。提供其紧急程度的要点摘要。”

[](https://substackcdn.com/image/fetch/$s_!IsI7!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feda9894c-b06f-4cf5-94cf-609391812e6a_3200x1760.png)
你还可以结合使用循环和目标。用循环安排检查任务，用目标解决问题。可以这样说：每24小时循环检查GitHub上标记为bug的问题。如果存在此类问题，使用目标实施修复，直到所有本地测试通过并推送分支。

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

但也要注意，目标对于能包含的内容量有一定限制。

他们的文章还包含一个组合示例，展示了这一切的发展方向：

上述原语与Claude Code的其他功能（如自动模式(https://code.claude.com/docs/en/auto-mode-config)和动态工作流（研究预览））可以组合成处理长时间工作的循环。例如处理传入反馈，你可以使用：/schedule（研究预览）运行检查新报告的例程，/goal定义完成标准，以及技能文档验证方法。动态工作流(https://code.claude.com/docs/en/workflows)用于协调代理对每个报告进行分类、修复和审查修复结果。自动模式使例程无需请求许可即可运行。组合起来，提示可以这样写：/schedule 每小时：检查project-feedback频道中的错误报告。/goal：不停止，直到本次运行发现的所有报告都完成分类、处理和回复。