想象这样一个场景：你打开终端，不再跟 AI 助手一对一对话。你启动的是一个「循环」，它会自己拆解任务，自己调工具，自己判断是否完成，如果没完成，就再来一轮。等你喝完咖啡回来，代码已经写好了，review 也做完了，patch 也合入了 main 分支。

你甚至不知道中间发生了什么。

这不是科幻。Flask 和 Jinja2 的创造者 Armin Ronacher 在 2026 年 6 月 23 日发表了一篇题为《The Coming Loop》的长文，指出 AI 编程正在经历一场从「人在循环中」到「循环接管一切」的范式转移。

这篇文章在 Hacker News 上引发了激烈讨论，300 多赞，200 多条评论。以下是我对原文的梳理和延伸思考。

两种循环：Agent Loop 与 Harness Loop#

Ronacher 区分了两种性质截然不同的循环。

**Agent Loop（代理层循环）**是每个 AI 编程工具内部都有的那一层：模型调一个工具，拿到结果，再调下一个工具，读文件，改文件，跑测试，最后输出答案。Codex、Claude Code、Cline，这些工具的核心都是这样工作的。这个循环我们已经很熟悉了。

**Harness Loop（架构层循环）**则是一个外层的、更高阶的循环。它不关心单次对话的结束，而是把一个任务放进队列，让机器去执行，执行完之后，由 harness（可以理解为「调度器」或「评价器」）来判断：这真的是终点了，还是需要再来一轮？如果不够好，harness 可以继续当前会话、注入新消息、启动新的 session、甚至把任务转发给另一台机器。

打个比方：Agent Loop 像是一个工人在车间里操作各种设备完成一个零件，Harness Loop 则像是车间经理，在流水线的尽头检查零件质量，不合格就打回去重做，或者重新分配任务。

Ronacher 引用了 Boris Cherny 的一句话：「我已经不再直接跟 Claude 对话了。我写循环，让循环去跟 Claude 对话。」

循环已经在哪些领域大杀四方？#

Ronacher 是诚实的。尽管他对这种趋势持保留态度，他清楚地看到了循环模式在特定场景下的惊人效果。

代码迁移是最亮眼的例子。最轰动的是 Bun 从 Zig 到 Rust 的大规模迁移工作。这本质上是一种机械翻译：给定一个已有的、经过验证的代码库，让 AI 逐段翻译成另一种语言。验证标准非常明确，要么编译通过并且行为一致，要么就不行。Ronacher 自己用这种方式把 MiniJinja 从 Rust 迁移到了 Go，效果出色。

性能探索也很适合循环。让机器不断尝试、benchmark、丢弃失败的尝试、继续搜索。这种纯探索性的工作不产生持久代码，跑完就扔，但对优化关键路径非常有价值。

安全扫描天然适配。攻击者在用循环扫描你的代码，防御者也需要用循环来应对。

这些场景有一个共同点：产出的代码要么不产生新的逻辑（只是翻译），要么不需要长期维护（POC、研究、一次性实验），要么验证标准极其明确。

当循环开始写需要维护的代码时#

问题出在另一个方向。

Ronacher 对自己「在意」的代码尝试过 loop 的工作方式，体验并不好。他给出了几个非常具体的批评：

模型会为了「安全感」而过度防御。 Karpathy 曾经说过一个观点：LLM 对异常「极度恐惧」。当模型遇到一个边界情况，它的直觉反应是加一层 try-catch，再加一个 fallback，再补一个默认值。这些东西单独看都有道理，累积起来就变成了没人能理解的防御层。

正确的方式不是「处理每个畸形状态」，而是让畸形状态根本不可能出现。 这是编程里一个古老而深刻的洞察。但 LLM 天然倾向于前者，你越是让它自由发挥、不加干预，它就越是堆砌防御。

循环会放大这个问题。 每一轮迭代加一点小防御，系统表面看越来越「健壮」，内里越来越混乱。代码变得像是被绷带层层裹住的伤口，外面看上去没问题，里面早就烂了。

Ronacher 对所谓的「全自动」模式（比如 Claude Code 配 ultracode）特别不满：「让机器连续工作 30 分钟不中断，产出的代码比我们去年的水平还差。」过去那种人工介入更多的工作流，至少能在关键节点把好关。

软件正在从「机器」变成「生物」#

Ronacher 用了一个非常形象的比喻：我们正在从「软件即确定性机器」走向「软件即有机生命体」。

他回忆自己成为工程师的那个时代：机器是确定的，代码是可理解的，每一层都可以剥开来研究。系统里总有工程师知道「不变量」住在哪里，哪些部分是承重的，哪些改动是安全的。

但现实已经在变化。即使是纯人类写的、没有 AI 参与的分布式系统，我们也已经像医生诊断病人一样来对待它们：观察症状、形成假设、「再做个检查」、尝试一些疗法、继续观察。我们并不总是完全理解系统，但我们可以管理它。

LLM 加速了这个过程。越来越多工程师的生产事故处理流程变成了：先把日志给 AI 分析，让它提根因假设，让它生成 patch，然后另一个 AI 去 review 这个 patch，最后自动合入 main。全程没有人看过。

Ronacher 说：「我们治疗它、监控它、稳定它，但我们不一定理解它。」

你其实无法选择退出#

Ronacher 文章里最让人不安的部分，不是他对 loop 的批评，而是他的结论：你其实无法选择退出这场游戏。

以安全为例。即使你自己不用 loop 写代码，攻击者会用 loop 来攻击你的软件。安全研究员也会。AI 生成的漏洞报告会像潮水一样涌来，你不靠机器去 triage 和复现，根本处理不完。

curl 的维护者 Daniel Stenberg 最近写了一篇「夏日宁静」文章，描述维护者面临的压力。curl 的核心开发并没有用 AI，但维护者已经被 AI 生成的报告淹没了。

竞争的维度也一样。有些团队会用 loop 实现你三倍的速度。有些五人的初创公司能做到过去五十人做的事。有些竞争对手会直接用 loop 对着你的产品说：「让我们的代码做到一样的事。」

在一些容忍粗糙、追求速度的领域，这种差距会越来越大。

新的依赖：不是工具，是「氧气」#

Ronacher 提出了一个很少有人认真讨论的问题：我们正在建立一种前所未有的依赖。

过去做软件要买编译器，但那是一次性的成本。现在你对 AI 的依赖不是一次性的，是持续的。代码是 loop 写的，review 是 loop 做的，patch 是 loop 打的，维护也是 loop 在撑着。

那么，当你失去这些系统的时候怎么办？贸易限制让你无法访问最强大的模型？成本变得不可承受？你和你的团队突然失去了不靠机器就理解代码的能力？

他说：「我们可能正在创建一种代码库，它们不但难以由人类维护，而且在设计上就假设了机器参与作为维护模型的一部分。」这已经不是在预测了，这就是现在正在发生的事。

我对 Ronacher 观点的补充#

Ronacher 的文章写得很克制，但方向很明确。作为每天都在用 Codex 和类似工具的人，我想补充几点自己的观察：

第一，loop 的效率优势在「探索性工作」上是碾压式的。 我自己最近用 Codex + Harness 跑了一个跨语言代码迁移的实验，原计划两周的工作量，两天内完成了一个可用的原型。Armin 说的「机器做实验，人看结果」的模式确实已经到来。

第二，「过度防御代码」的问题真实存在，但可能不是永久性的。 当前模型在「保持代码简洁」和「防御所有边界」之间偏向后者，这是训练数据中大量企业级代码的副作用。但随着更多针对性的 fine-tuning 和强化学习，模型有可能学会「优雅地处理异常」而不是「恐慌式堆防御」。

第三，最危险的不是代码质量变差，而是「理解断层」。 当所有人都依赖机器来解释代码的时候，团队中最后一个真正理解系统的人离开的那天，就是整个系统从「资产」变成「负债」的时刻。

总结：问题不是「要不要循环」，而是「怎么在循环中不丢失判断力」#

Ronacher 的文章不是一篇「抗拒 AI」的檄文。他自己也在做 loop 实验，也在 Pi 这个平台上探索。他的思考更加务实：

循环不是要不要的问题，它已经来了。真正的问题是：

  • 在循环的未来，我们怎么不放弃自己的判断？
  • 怎么保留好的工程原则而不是让机器全权代劳？
  • 怎么确保负责任的人还能继续「监督」？
  • 我们需要重新思考什么样的代码架构，才能在这种新范式下保持清醒？

这篇文章值得每一位在用或者在观望 AI 编程工具的工程师读一读。不是因为答案已经有了，而是因为问题问对了。

参考来源： Armin Ronacher, “The Coming Loop”, lucumr.pocoo.org, June 23, 2026.