Addy Osmani 谈 Claude Code 的实用循环工程：goal 与 loop 的用法和边界

O'Reilly Radar· Addy Osmani·2026-11-02 19:54· 1 小时前AI 评分74

实用循环工程

AI 导读

Addy Osmani 介绍自己如何用 Claude Code 和 Codex 的 loop engineering 原语，同时并行运行五到十个 Agent。goal 通过 /goal 定义可验证的完成条件驱动单个任务到目标达成，loop 类似 cron 按固定间隔重跑提示词，可用 /schedule 移到云端。

正文 · 原文

以下文章最初发表于 Addy Osmani 的 Elevate 博客 ，经作者许可在此重新发布。

我通常的工作方式是同时并行运行五到十个 Agent。有些任务我非常乐意完全交给 Agent，只要我对停止条件和相关约束有非常清晰的认识。还有一些任务，我会希望更密切地关注并对 Agent 的所作所为进行代码审查。

你可能已经听说过 loop engineering。几个月前我写过一篇关于它的大博客文章，当时就谈过这个话题。

循环是一个自主、自我纠正的反馈周期，AI Agent 在其中反复行动、测试结果并调整方法，直到达成特定目标。

现在基本上有两个核心原语可以考虑。在 Claude Code 中有一个 goal 原语，它可以推动单个有界任务向前推进，直到你达成某个特定目标，比如一个可衡量的终点线被满足。然后是 loop，它按定时器或固定间隔重新运行，因此你可以用它来安排变更。

在原语成为原语之前

我记得在 Claude Code 和 Codex 内置原语之前：循环工程很大程度上是关于搭建你自己的 bash 循环，一种手工打造的东西。我当时就是这么做的。你可能还记得今年早些时候，我们中一些人在玩 Geoff Huntley 的 Ralph loop。我们在做实验，分享工作流，分享哪些有效、哪些无效，但这主要是在我们的一些个人项目上，即使撞了墙，对我们来说也没有太大代价。

随着我们尝试弄清循环工程的哪些模式和方面现在已更加内置，我认为我们对如何照看它有了更清晰的认识。我现在基本上可以依赖 Claude Code 和 Codex 中原语的输出。我们已经前进了一些。但与此同时，我们需要非常勤勉，因为循环工程——如果你把它放在那里不管，又没有真正思考过最终目标或约束是否被良好定义——可能会让你陷入有问题的状态。这就是为什么在决定将其用于一个没有用户、也没有像棕地银行代码库那样多历史复杂性的常青代码库时，需要有所权衡。

Claude Code 团队如何界定循环

Claude Code 团队发表了他们对四种循环的看法，这与我使用原语的方式一致（他们的文章）。在进入正题之前，这是我的快速总结：

在 Claude Code 团队中，我们将循环定义为智能体重复执行工作周期，直到满足停止条件。我们根据循环的触发方式、停止方式、所使用的 Claude Code 原语以及最适合的任务类型，将循环分为几种不同类型。并非所有任务都需要复杂的循环；从最简单的解决方案开始，并有选择地使用这些模式。

你发送的每个提示都会启动一个手动循环，由你引导每一轮。Claude 收集上下文、采取行动、检查其工作、必要时重复，然后做出响应。我们称之为智能体循环。例如，让 Claude 创建一个“点赞”按钮。它会阅读你的代码、进行编辑、运行测试，并交回它认为可用的结果。然后你手动检查工作，并编写下一个提示。

他们的文章逐级讲解了每一层。

关于基于目标的循环：

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

关于基于时间的循环：

有些智能体工作是重复性的：任务保持不变，只有输入变化。例如，每天早上总结 Slack 消息。其他工作依赖于外部系统，而与之交互的一种简单方式是按间隔检查并对其变化做出反应。例如一个 PR，它可能会收到代码审查或 CI 失败。对于这些情况，你可以使用 /loop 触发 Claude 运行，它会按间隔重新运行提示。例如：/loop 5m 检查我的 PR，处理审查评论，并修复失败的 CI。/loop 在你的计算机上运行，因此如果你关闭它，它就会停止。你可以通过使用 /schedule 创建例程，将循环迁移到云端。

以及关于主动循环，最高层级：

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

他们的验证建议值得完整借鉴，因为它将手动检查转变为 Claude 自行应用的东西：

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
# Verifying frontend changes
Never 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 的方式是构建任何特定的工作，直到它可证明地完成。例如，你可以使用 goal 来说：“确保这个体验在五秒内加载完成，持续进行直到完成。”它将继续使用独立的评估检查来不断检查是否满足完成标准。更好的是，对所使用的工具更加具体。

至于我真正跑出数字的目标，有几件事我做过。我用目标来处理 GitHub issue 的推进：“审查并关闭最近 10 个 issue”，或者“审查并推进最近 10 个 issue”，诸如此类。这算是半开放式的，对吧？或者“让这个页面加载速度提升 50%”。有时效果很好，有时不行，但关键就在于实验。

Loop

Loop 更像是一个调度器，所以它会盯着某个东西，或者按某种节奏反复执行某个模式。可以把它想得有点像 cron。它最适合做轮询日志或监控外部状态之类的事情。你也可以用它来做潜在的签到。如果你发现自己按某种节奏重复做某些任务，loop 就很适合。

我委托什么，我盯什么

我每天大概用五到十个 agent。通常同时最多跑五个。其中有些任务可能相对安全一些。比如：“嘿，我实现了这个功能，去给它写文档。”或者“去再确认一下我们有足够的测试覆盖。”或者类似的事情。如果我正在处理一个更复杂的问题，而且我给了它一份好的规格说明，或者我认为是好的规格说明，并试着给它一些停止条件，它仍然有相当大的可能无法把所有事情都做对，所以我会尽量更密切地盯它。如果任务涉及任何稍微敏感的东西，无论是“我给了它某个系统的访问权限”，还是这个功能恰好涉及认证，或者与安全或财务相关，我肯定会密切盯着。

总的来说，我确实认为我们会走到这样一个阶段：人们越来越习惯委托，只要他们能有这些清晰的方式来验证自己的目标或停止条件已经满足。但你仍然需要看看代码，看看生成出来的东西，确保它符合你的要求。

另一个重要的习惯是，不要让干活的 agent 自己判定活干得好。一个子 agent 起草改动；另一个独立的 agent 来验证它。

有时一个 agent 会对某件事很有信心，而一个验证 agent 能抓住意料之外的东西。如果一个 agent 认为它生成的体验的基线性能其实没问题，但它只基于桌面端评估性能，而你实际上在意移动端的体验，那可能意味着这个 agent 对问题的一个维度非常自信，但对另一个维度并非如此。

而我是吃了苦头才学到这一点的。我当时很好奇，想弄清楚：有没有什么是我们遗漏的、且尚未从用户那里获得直接反馈的东西——无论是在问题追踪器里还是在某处的评论中？于是我让它去查看我们的一些竞争对手，整理出一份清单，并在本地生成一些 PR（没有推送），展示弥补其中一些差距可能是什么样子。我差点就推送了其中一些改动。但我实际上并没有足够仔细地查看它们。我读了它的调研，但我没有足够仔细地查看实现。所以我把任务委派出去了，但我差点把判断也一并委派出去了。当我真正仔细查看这些改动时，我意识到它会给我们的用户带来大量额外的复杂性，而我认为收益并没有那么大。所以我觉得你需要时不时检查一下，自己是不是把品味和判断也委派给了你的 agent。你委派的是任务，然后你要真正回头检查它是否达到了你的标准。

顺便说一下，goal 背后的评估器并不是那个检查器。它不会以任何方式、任何形态查看内容来判断好坏。它所做的只是检查对话记录，看你指定的硬性规则是否得到满足。

/goal Refactor the data-fetching layer in Dashboard.tsx until 
Lighthouse performance score is >= 92 and LCP is under 1.8s as 
shown by the Lighthouse CLI output. Do not change the public API 
of any hooks. Each turn must improve at least one reported metric; 
abort if two consecutive turns show no improvement. Stop after 10 turns.

我每天运行的工作流

我每天做的工作流之一：我有一个很受欢迎的开源仓库，叫 Agent Skills。我们有超过 80,000 个 star，直到最近，我们每天要收到 80 到 90 个需要审查的 pull request。所以每天我都会花些时间检查这个。现在有了 loop，你可以说：“嗯，每 24 小时或每 12 小时检查一次 GitHub 仓库有没有新的 open issue，并提供一份紧急程度摘要”，或者“提供一轮初步审查”，或者类似的事情。

/loop every 1h "Check the GitHub repository for any new open issues. 
Provide a bulleted summary of their urgency."

组合 loop 和 goal

现在你还可以把 loop 和 goal 组合起来。你用 loop 来安排检查，然后用 goal 来解决问题。所以你可以这样说：“每 24 小时循环一次，检查 GitHub 上标记为 bug 的 issue。如果存在，就用 goal 实现修复，直到所有本地测试通过并推送分支。”

/loop every 24h "Check GitHub for issues labeled 'bug'. If one exists, 
use /goal to implement a fix until all local tests pass and push the branch."

但也要记住，goal 在能塞进多少内容方面有一些限制。

Claude Code 团队的说明里还有一个组合示例，展示了这一切的发展方向：

上述原语，连同其他 Claude Code 功能，如 auto mode 和动态工作流（研究预览），可以组合成一个用于长时间运行工作的循环。例如，要处理传入的反馈，你可以使用：/schedule（研究预览）来运行一个检查新报告的例程，/goal 来定义“完成”是什么样子，以及 skills 来记录如何验证它。 动态工作流 来编排对每份报告进行分诊、修复并审查修复的 agent。Auto mode 让例程无需停下来请求许可即可运行。把它们组合起来，一个提示词可能长这样：/schedule 每小时：检查 project-feedback 频道是否有 bug 报告。/goal：在本次运行中发现的所有报告都被分诊、处理并回复之前不要停止。修复 bug 时，使用工作流在三个并行工作树中探索三种解决方案，并让一个评判者对抗性地审查它们。

分诊系统实际做什么

在 PR 分诊（triage）内部，当我让循环和目标协同为我工作时，我最终得到的是一个系统，它让我能够继续接收 PR 和 issue，能够每天掌握涌到我面前的事务，尤其是能够进行交叉引用。这对我来说意义重大。如果我想推进某个特定目标，比如“嘿，我们要重做系统的这一部分”，并且我需要确保任何恰好涉及它的 issue 都因这次重做而被关闭，或者确保我们不会妨碍到别人，我就能确保这一点被明确定义。

定时任务非常有用，可以定期审查新的 PR，并关闭那些明显不符合要求的内容。例如，一个很好的停止条件：我们有一套贡献指南，其中包含诸如“嘿，我们目前不接受翻译”这样的内容。

这并不是说我们不在意，而是因为这些内容对我们来说难以维护，因为我们并不掌握经常提交的那些语言。因此，如果我们让它关闭任何恰好涉及贡献指南中这一方面的 issue 或 PR，那么它在按计划运行时就能做得很好。这样就能减少我们需要审查的整体批次。

循环无法为你带来什么

经常有人问我，循环工程在哪些场景下不太适合。一般来说，如果你不清楚完成状态/完成/良好对你的完成意味着什么，它可能就不是适合你工作的模式。例如，一个模糊的目标会是“一直进行下去，直到这个 UI 设计变好”。这是什么意思？对谁来说算好？如何评估？需要人类品味、主观设计或开放式创意探索的任务并不适合。当你对目标有相当清晰的想法时，我认为循环是值得考虑的好选择。

细则

一个循环在原地空转的典型迹象是：同一条命令被反复尝试，而结果没有任何变化。如果同一条命令第三次执行时与第二次相比仍无变化，那大概就该停止了。

有一条值得了解的细则：循环任务在创建七天后过期。我之前一直告诉人们是三天。其实是七天。而且循环是会话范围的，所以当你开始新对话时它们就会停止，不过用 –resume 或 –continue 恢复该会话时，仍在七天窗口内的任何循环任务都会恢复。如果你需要比会话更持久的东西，/schedule 会在云端运行它。

如果你已经有每天早上手动运行的检查，那就是你的第一个循环。我的是那堆拉取请求。

来源：O'Reilly Radar · oreilly.com