循环工程真的是我们需要的吗？

大约一周前，Anthropic公司Claude Code的负责人Boris Cherny在WorkOS主办的Acquired Unplugged活动上说了这样一句话：

我不再给Claude写提示了。我现在跑着循环，这些循环在给Claude写提示并决定该做什么。我的工作就是写循环。

这段视频在X上迅速走红，48小时内获得了230万次观看。几天后，OpenClaw的创建者Peter Steinberger也发表了类似观点，获得了820万次观看。

同一天，Google Cloud AI的总监Addy Osmani发布了一篇爆款博文，给这个趋势取了一个名字：循环工程（Loop Engineering）。

就这样，大量开发者、vibe编码者和AI从业者开始觉得他们需要升级技能，学习循环工程。

但是，让我们稍微放慢脚步，问问自己：我们真的都需要开始让我们的智能体循环起来吗？

1、循环工程究竟是什么？

为了公平地讨论这个想法，我们需要理解Boris实际在描述什么。以下是他Acquired Unplugged活动演讲中的原话：

现在它又上了一个台阶，我认为，到了下一波抽象层次——我不再给Claude写提示了。我有循环在运行。它们才是给Claude写提示并决定该做什么的。我的工作就是写循环。

所以，循环就是一个编排层，它反复调用编码智能体，根据预定义标准评估输出结果，并不断迭代直到满足完成条件。

在他的演讲中，Boris描述了他的进化过程，大致经历了三个阶段：

手工编写代码。
同时运行五到十个Claude会话，手动为每个会话写提示。
现在，编写系统来自动完成提示工作。

这个系统会读取他的GitHub、Slack和Issues，决定构建什么，将子智能体分派到独立的git工作树中，验证输出，然后创建PR。他在cron（一种基于时间的任务调度器）上运行它。

怀疑论者会不客气地说："哦，你只是发现了cron而已。"

但这没有抓住重点。

cron任务运行一个固定的脚本，而循环运行的是一个模型，它会查看当前状态，决定做什么，执行，检查是否成功，然后决定是继续还是停止。决策逻辑属于模型，而不是脚本。

这正是创新的关键所在！

所以，这个核心思想是真实且有趣的。但问题不在于循环是否是一种合法的工程模式。而在于它是否是大多数开发者现在需要考虑的东西。

2、这是为谁准备的？

需要记住的一个重要事实是：Boris不仅仅是Claude Code的早期采用者，他就是构建Claude Code的人。

这意味着他在Anthropic内部工作，拥有几乎无限的计算资源、世界一流的基础设施，以及一个在数月内将智能体优先的工作流程内化了的团队。

所以他的循环之所以有效，是因为他已经解决了更困难的问题：对系统有足够深入的理解，可以将其交给自主智能体并信任其输出。

这个背景极其重要，但在社交媒体的传播过程中很容易被忽略。

仅凭 Token 经济这一点，就应该让大多数开发者停下来思考，然后再去拥抱任何新的AI趋势。

每次迭代都会产生一个制造者智能体和一个检查者智能体的循环，会在早餐前就用光有限的计划额度。

成本压力并非假设性的，有大量实践者以真实节奏运行过这些系统，并将失控的账单描述为一等关注事项。

还有一个更令人不安的方面：循环会静默失败。

如果没有适当的工程保障，一个本应在完成时才发出完成信号的智能体可能提前发出信号，循环在一个半完成的任务上就退出了，且无人知晓。这就是为什么没有严格的验证关卡，你的自动化循环就不能被完全信任。

3、速度是一种债务

循环工程的主要回报是复合生产力。写一次循环，然后让它在你睡觉时工作，这听起来确实很吸引人，但问题在于你正在承担更大的技术债务。

此外，当一个循环发布了你没有编写、审查或完全理解的代码时，你就承担了一些实践者现在称之为理解债务的东西（即代码库中存在的东西与你实际理解之间的差距）。

技术债务虽然代价高昂，但理解债务可以说更糟糕，因为你甚至不知道自己欠了什么。

当然，这种风险在很大程度上取决于任务的复杂度。但是，即使是最先进的模型也无法在编码基准测试中达到90%的准确率阈值。最近，cognition.ai发布了一个不仅检查代码正确性还检查代码质量的新基准，当前领先模型的结果并不令人满意。

这表明：

人力的努力和输入仍然不可替代。
模型还有很多改进空间。
你越是把工作交给AI，之后就需要做越多的QA。

不要误解我的意思，循环工程确实有富有成效的版本，但这需要你保持在设计师和审查者的角色上。

Boris Cherny的循环之所以有效，是因为他仍然是那个工程师。他设计了循环，他阅读进入仓库的每一行代码，他的判断主宰着整个系统。

4、循环何时才真正有意义

我之前说的这些并不意味着循环是个坏主意。对于合适类型的问题，它们确实是一种有用的模式。

循环在以下情况下效果最佳：

成功条件是可以客观验证的（例如，测试套件通过、分数超过阈值、lint检查通过）。
任务是可重复且定义明确的（例如，PR审查自动化、依赖升级、CI分类、文档同步）。
你已经手动解决了这个问题，并且希望不再每次都手动解决。

在构建循环之前，一个有用的自我检查：

我能否写下一个完整且明确无误的成功条件，让模型可以在不向我提问的情况下进行验证？

如果答案是否定的，那你就不是遇到了循环问题。你遇到的是规格问题，循环无法解决它。

5、正确的问题

循环工程是真实存在的，但它仍然是小众的。其背后的转变是一种真正的演进，可能会在未来几年内塑造我们使用AI工具的方式。但我们还没有到那一步。

大多数开发者不需要停止给智能体写提示。他们需要更好地理解人类判断不可替代的地方，建立验证的习惯，并控制技术和理解债务。

真正能从循环工程中受益的工程师是那些：

已经深入了解自己系统的人。
有真正可重复的工作可以委派出去的人。
有足够预算来覆盖循环预估成本的人。

所以，没有必要急于学习如何编写循环，因为问题不是"你开始写循环了吗？"，而是"你需要循环吗？你能负担得起循环吗？"

原文链接: Is Loop Engineering Really What We Need?

汇智网翻译整理，转载请标明出处