跳转至

The Coming Loop

Ch01.371 The Coming Loop

📊 Level ⭐⭐ | 9.7KB | entities/the-coming-loop.md

The Coming Loop

Background：Armin Ronacher（Flask/Sentry 创始人）2026-06-23 发表的技术深度文章，从 Harness 工程师视角探讨 Agent Loop 的演进方向。文章区分了两种循环：Agent Loop（模型调用工具的内部循环）和 Harness Loop（外部编排器决定何时继续的循环），并对后者的发展提出了深刻的反思。

摘要

Armin Ronacher 观察到一种新的工作模式正在兴起：工作被放入队列，机器拾取、尝试、停止，然后一个 Harness 决定这是否真的是结束。这种"Harness Loop"模式已经在代码移植、性能探索、安全扫描等领域展现出惊人的效果，但 Ronacher 对将其用于编写持久代码持谨慎态度。他担心这会导致代码库变成"只能由机器诊断的有机体"，并呼吁在拥抱循环未来的同时保持人类判断力。

核心要点

1. 两种循环的区分

Ronacher 区分了两种根本不同的循环：

Agent Loop（内部循环）： - 模型调用工具、整合结果、调用另一个工具、读取文件、编辑文件、运行测试 - 这是我们早已熟悉的循环 - 最终模型说"完成"，人类审查

Harness Loop（外部循环）： - Harness 决定工作是否真的完成 - 如果不是，继续同一会话、注入新消息、启动修改后的上下文、或将任务发送给另一台机器 - 任务在模型自己说"完成"之后继续存在

这种区分是理解 Agent 系统架构的关键。

2. 循环在哪些领域有效

Ronacher 承认循环模式在某些领域已经"惊人地有效"：

  • 代码移植：Bun 从 Zig 到 Rust 的移植、MiniJinja 到 Go 的移植
  • 性能探索：机器可以尝试实验、基准测试、丢弃失败、继续搜索
  • 安全扫描：自然适合自动化循环
  • 研究：探索复杂问题空间并报告

这些领域的共同点是：要么不生成新代码（只转换已有代码），要么生成的代码不需要长期存活（概念验证、想法、发现）。

3. 循环在持久代码中的问题

Ronacher 对循环用于编写持久代码持保留态度：

当今的模型倾向于生成过于防御性、过于复杂、过于局部推理的代码。它们避免强不变量。它们添加回退而不是使坏状态不可能。它们复制代码、发明糟糕的抽象、用更多机制掩盖不清晰的设计。

更糟糕的是，将这种行为放入循环中会放大它： - 每次迭代添加一个小防御 - 系统逐渐变得更不可理解，同时看起来更健壮 - 你越放手，这种情况就越严重

Karpathy 提到模型"对异常极度恐惧"——在有重要不变量的系统中，正确的修复不是"处理每种畸形情况"，而是使畸形情况不可表示或不可能写出。

4. 软件作为有机体

Ronacher 提出了一个深刻的隐喻：从软件作为确定性机器到软件作为有机体的转变：

  • 传统的软件工程鼓励理解机器、追求确定性、可观察性
  • LLM 驱动的开发正在快速推向"像医生一样诊断分布式系统"的模式：观察症状、形成假设、"开更多检查"、尝试补救、再观察
  • 这种模式对某些软件是可以接受的
  • 但问题是：我们是否希望所有软件都以这种方式编写？

5. 无法完全退出

即使你不用循环来构建软件，其他人也会用循环来对抗你的软件：

  • 安全压力：攻击者会持续运行机器，安全研究者也会，自动化工作会产生信号和噪音
  • 竞争压力：一些团队会通过原始速度超越其他人，一些创业公司会用 5 人做过去需要 50 人的事
  • curl 的例子：尽管 AI 在 curl 核心开发中角色不大，维护者已经被 AI 生成的报告淹没

如果攻击者和报告者循环，防御者最终也需要循环来跟上。

6. 新的依赖性

最令人担忧的部分是我们对这些新机器的新型依赖：

  • 如果代码库由循环生成、由循环审查、由循环修补、由循环维护——当你不再能访问同类系统时会发生什么？
  • 贸易限制可能带走对最强大模型的访问权
  • 成本可能变得难以承受
  • 团队可能失去在不使用机器的情况下理解代码的最后能力

我们可能创建的代码库不仅难以由人类维护，而且假设机器参与作为其维护模型的一部分。这已经在发生。

深度分析

Harness Loop 的架构模式

Ronacher 描述的 Harness Loop 可以形式化为以下架构模式：

┌─────────────────────────────────────┐
│           Harness Loop              │
│  ┌─────────────────────────────┐   │
│  │       Agent Loop            │   │
│  │  Tool → Result → Tool → ... │   │
│  └─────────────────────────────┘   │
│           ↓ "完成"                  │
│  ┌─────────────────────────────┐   │
│  │       Harness Judge         │   │
│  │  评估：是否真正完成？         │   │
│  └─────────────────────────────┘   │
│           ↓ 否                      │
│  继续/修改上下文/切换机器            │
└─────────────────────────────────────┘

这个模式的关键挑战在于 Harness Judge 的设计： - 如何定义"完成"？ - 如何评估代码质量？ - 如何避免循环放大模型的系统性偏差？

与 Harness Engineering Framework 的关系

Ronacher 的文章为 Harness 工程框架提供了重要的维度补充：

  1. 循环层次：区分 Agent Loop 和 Harness Loop 是理解 Harness 设计的关键
  2. 适用边界：循环在不同场景下的效果差异很大
  3. 质量控制：循环可能放大模型的系统性偏差
  4. 人类角色：在循环未来中，人类的判断力仍然至关重要

代码质量的长期影响

Ronacher 的担忧指向一个更深层的问题：LLM 生成的代码的长期可维护性。

当前 LLM 的代码生成倾向于： - 过度防御：处理所有可能的错误，而不是使错误不可能 - 局部推理：关注当前问题，而不是整体架构 - 复杂性偏好：用更多机制解决问题，而不是简化设计

当这些倾向被循环放大时，可能产生： - 难以理解的代码库 - 过度复杂的防御机制 - 缺乏清晰的不变量和架构约束

这与 Vibe Coding Reality Gap 的讨论一致——短期的代码生成速度可能牺牲长期的代码质量。

软件工程的范式转变

Ronacher 的"软件作为有机体"隐喻捕捉了软件工程正在经历的范式转变：

维度 确定性机器 有机体
理解 完全理解 观察症状
调试 确定性追踪 假设-验证
维护 主动重构 被动响应
可靠性 形式化验证 统计信心
人类角色 作者/审查者 诊断者/管理者

这种转变对软件工程师的角色、技能要求和职业发展都有深远影响。

实践启示

对 Harness 工程师的建议

  1. 区分循环层次：明确你的系统是在 Agent Loop 还是 Harness Loop 层面工作
  2. 定义清晰的完成标准：Harness Judge 需要明确、可测量的完成条件
  3. 监控代码质量趋势：循环可能导致代码质量逐渐下降
  4. 保持人类在环：至少在当前阶段，人类判断力仍然是不可替代的

对代码质量的关注

  1. 审查 LLM 生成的代码：不要盲目接受循环输出的代码
  2. 投资代码可读性：LLM 倾向于生成难以理解的代码
  3. 维护架构约束：确保循环不会破坏系统的整体架构
  4. 文档化不变量：明确记录系统的关键不变量和设计决策

对 Agent 系统设计的启示

  1. Harness 是核心：Agent 的价值不仅在于单次推理，更在于 Harness 的编排能力
  2. 循环需要约束：无约束的循环可能产生不可控的结果
  3. 可观测性是关键：每一步的状态转换都应可追踪
  4. 停止条件比启动条件更难设计：过度循环和过早退出都是常见问题

相关实体

参考

→ 原文存档 → Harness Engineering 框架