The Coming Loop：当代码从“机器”变为“有机体”

来源：Hacker News / Armin Ronacher's Thoughts and Writings 作者：Armin Ronacher 日期：2026年6月23日

背景

随着 AI 编码代理（Coding Agents）的普及，开发者社区正在经历一场工作范式的转变。Boris Cherny 曾有一句名言：“我不再直接提示 Claude 了。我运行着循环来提示 Claude，并决定下一步该做什么。我的工作就是编写这些循环。”

在过去几个月里，作者观察到越来越多的开发者在编码代理之上构建新的工作流，这些工作流不仅仅是简单地使用代理，而是形成了一种新的模式：将任务放入队列，由机器拾取、尝试、中断，然后由一个“控制层”（Harness）决定这是否是终点。如果不是，控制层会继续同一会话，注入新消息，修改上下文，或将任务发送给另一台机器。这种让任务超越模型自身认为“已完成”状态的机制，构成了所谓的“循环”（Loop）。

尽管这种循环模式在早期的 Claude Code 时代就已存在，但最近几周它在 AI 工程领域的主导地位日益凸显，并在 Twitter 等社交平台上引发了广泛讨论。然而，作者 Armin Ronacher（Flask、Jinja2 等知名 Python 库的作者）目前的体验是：在处理他深切关心的核心代码时，这种工作方式并未带来预期的成功。

核心内容

两种循环：代理内部 vs. 控制层外部

作者区分了两种不同层级的循环：

1. 代理内部循环（Agent Loop）：这是每个编码代理固有的循环。模型调用工具，整合结果，调用另一个工具，读取或编辑文件，运行测试，最终产生答案。这是一个我们长期熟悉的模式。
2. 控制层循环（Harness Level Loop）：这是代理外部的循环。它负责管理任务的持久性、上下文切换和多轮迭代。虽然这一概念并不新鲜，但在最近的 AI 工程实践中，它正变得无处不在。

核心困境：代码质量与控制权的丧失

作者之所以对这种“放手式”的循环工作流持保留态度，主要基于以下两点：

• 品味与控制：作者对代码质量有高标准，并希望完全理解自己发布的代码。他希望在面临压力或与人讨论时，能够解释系统的行为，而不是先问一个“黑盒”（clanker）来解释。
• 当前模型生成的代码缺陷：目前的 LLM 生成的代码往往过于防御性、过于复杂、推理过于局部化。它们避免建立强不变量（Strong Invariants），而是通过添加回退机制（Fallbacks）来处理错误，而不是从设计上使错误状态不可能发生。此外，模型倾向于复制代码、发明糟糕的抽象，并用更多的机械结构来掩盖不清晰的设计。

作者指出，这种趋势似乎在恶化。以 Claude Code 配合 ultracode 为例，如果让它连续工作三十分钟以上（如使用 Fable 时），生成的代码质量反而不如去年秋天那种更有人类介入的过程。

局部失败与“异常恐惧症”

模型倾向于观察局部失败并添加局部防御。正如 Karpathy 所指出的，模型对异常（Exceptions）有着“致命的恐惧”。在涉及重要不变量的系统（如持久化数据格式或核心基础设施）中，正确的修复方式不是“处理每一种格式错误的情况”，而是让格式错误的情况在根本上不可表示或不可能写入。

然而，即使经过大量的人工引导，LLM 也难以自然地生成此类代码。更糟糕的是，即使代码生成了，模型仍会尝试处理那些理论上已不可能发生的错误。当这种行为被置于循环之后，每一次迭代都会增加微小的防御，导致系统虽然表面上更健壮，但实际变得难以理解。如果将这种工具交给缺乏指导的初级开发者，他们会因为能自圆其说而习得极坏的工程实践。

循环模式的真正适用领域

尽管作者对生成持久性代码持怀疑态度，但他承认循环模式在某些领域表现卓越：

1. 代码移植（Porting）：例如将 Bun 的部分组件从 Zig 移植到 Rust，或将 MiniJinja 移植到 Go。
2. 性能探索：机器可以尝试实验、基准测试、丢弃失败结果并继续搜索。
3. 安全扫描与研究：探索复杂的问题空间并报告发现，而不一定需要生成持久的代码。

这些成功案例的共同点是：它们要么不生成新代码而是转换现有代码，要么生成的代码故意不具有长期生命力（如概念验证、机械转换）。

从“确定性机器”到“有机体”

作者认为，关键在于区分“产生无需长期存在的工件”与“机械地衡量目标”。许多成功的循环应用使用另一个 LLM 作为裁判或协调者。例如，Claude Code 可以创建整个实验工作流并执行。虽然生成的代码可能是“垃圾”（slop），但这更多是模型的问题，而非控制层无法判断步骤是否带来净收益。控制层只需要一个信号来决定是否继续下一轮迭代，这个信号不必是二进制的，只需足够有用即可。

作者用了一个隐喻：软件正在从“确定性机器”演变为“有机体”。

• 过去的软件观：软件是确定性机器。架构师追求可理解性、可追溯性和强不变量。即使系统复杂，也应通过清晰的架构让新工程师能够导航。
• 现在的软件观：随着 LLM 的介入，我们正更快地走向“有机体”模式。大型软件系统本就庞大且依赖外部服务，难以完全放入人脑。在没有 LLM 之前，我们像医生诊断分布式系统一样，观察症状、形成假设、进行测试、尝试 remedies。现在，LLM 将这种模式推向了极致。

关键要点

• 工作范式转移：开发者角色正从“编写代码”转向“编写循环”和“设计控制层”，任务在代理和控制层之间流转，超越单次生成的界限。
• 代码质量风险：当前 LLM 在循环中生成的持久性代码往往过于防御性、复杂且缺乏强不变量，导致系统难以理解和维护，甚至可能比人工介入时更差。
• 局部优化陷阱：模型对异常的恐惧导致其倾向于添加局部防御而非根本性修复，循环放大了这一缺陷，使系统表面健壮但内部脆弱。
• 适用场景明确：循环模式在代码移植、性能基准测试、安全扫描和概念验证等非持久性、机械转换类任务中表现优异。
• 控制层的重要性：成功的循环应用依赖于有效的信号机制（如使用另一个 LLM 作为裁判），以驱动迭代，而非追求绝对的客观二进制判断。
• 软件哲学演变：软件开发正从追求确定性、可理解的“机器”模式，转向更具适应性、类似“有机体”的模式，这对传统软件工程的最佳实践提出了挑战。

意义与影响

这篇文章深刻揭示了 AI 辅助编程进入深水区后的核心矛盾：效率与可维护性之间的张力。

1. 对工程文化的冲击：传统软件工程强调“代码即文档”、“可理解性”和“确定性”。LLM 驱动的循环模式正在瓦解这些基石，迫使开发者重新定义什么是“好代码”。如果代码是由机器生成的“有机体”，那么传统的代码审查和架构设计方法可能需要彻底重构。
2. 工具链的重塑：未来的 AI 编程工具将不再仅仅是代码补全助手，而是具备“实验-执行-评估”能力的自动化工作流引擎。控制层（Harness）的设计将成为核心竞争力，如何设计有效的反馈信号和评估机制，比模型本身的能力更为关键。
3. 开发者技能的变迁：初级开发者可能更容易陷入“局部防御”的陷阱，而资深工程师的价值将更多体现在系统架构设计、不变量定义以及对 AI 生成结果的批判性审查上。开发者需要学会像“医生”一样诊断 AI 生成的系统，而非仅仅像“工匠”一样打磨每一行代码。
4. 长期维护的挑战：虽然循环模式在短期产出和实验上效率惊人，但其生成的代码可能缺乏长期生命力。企业需要权衡快速迭代带来的优势与长期技术债务积累的风险。对于核心基础设施，人类的主导地位可能在未来数年内仍不可动摇。

总之，Armin Ronacher 的观点提醒我们，在拥抱 AI 带来的生产力飞跃时，不应忽视软件工程的本质——构建可理解、可维护的系统。循环是