The Coming LoopThe Coming Loop

写于 2026 年 6 月 23 日

“我不再手动给 Claude 发提示词了。我运行的循环会去提示 Claude 并弄清楚该做什么。我的工作就是写循环。” —— Boris Cherny

过去几个月里，我看到越来越多的人基于编程智能体（coding agents）构建应用，这与单纯使用编程智能体有着显著的不同。其中一些是基于 Pi 构建的，看到这些确实很酷！不过，这里的模式到处都一样：工作被放入某种队列中，机器接收任务、进行尝试、然后停止，接着由某个控制框架（harness）来决定这是否真的结束了。

如果没有结束，控制框架会继续当前会话，注入另一条消息，在修改上下文后开启一个新会话，或者将任务发送给另一台机器。即使模型通常会自行表示“我做完了”，任务依然会继续存活。

我思考这类循环的频率，比我愿意承认的还要高。

每个编程智能体内部都已经存在一个智能体循环（agent loop）。模型调用工具，整合结果，调用另一个工具，读取文件，编辑文件，运行测试，最终给出某个答案。这个循环是我们长期以来非常熟悉的。另一个循环是控制框架级别的循环：智能体循环之外的循环。这个循环也不是新事物。从 Claude Code 早期开始，我们就在做这种循环的各种版本，但它在智能体工程（agentic engineering）中正变得越来越普遍，并且在最近几周，它已经开始主导 Twitter 上的讨论。

我还不太擅长这个

我目前的状况是，对于我深切关注的代码（事实证明有很多），采用这种工作方式并没有取得多大成功。

部分原因在于品味，部分原因在于控制权。我试图对我期望的代码形态设定很高的标准，并且我想理解我发布的代码。在压力下，或者在与他人讨论时，我希望能够解释系统的工作原理，而不必先去问一台机器来给我解释。当然，现在存在一个问题，那就是几年后我是否还会保留这种理解代码的渴望。就目前而言，我依然认为理解代码对我很重要。

鉴于这种渴望，对于我没有投入精力关注的代码（尤其是循环生成的代码），我的体验中缺少了某些东西。当前的模型往往会产生过于防御性、过于复杂、推理过于局限的代码。它们避免使用强不变量（strong invariants）。它们添加回退机制，而不是让错误状态根本不可能发生。它们复制代码，发明糟糕的抽象，并用更多的机制来掩盖不清晰的设计。更糟糕的是：到目前为止，我几乎没有看到这方面有所改善的进展。如果有的话，在这方面，我感觉我们甚至可能在朝着错误的方向迈步。至少就我的品味而言，当前无需人工干预的控制框架（如带有 ultracode 的 Claude Code）生成的代码，比我们去年秋天生成的还要糟糕。那是因为，例如带有 Fable 的 Claude Code 会在某个问题上不受打扰地连续工作三十分钟甚至更久，而以前的过程会包含更多的人工参与（human in the loop）。

此外，众所周知，模型倾向于观察到某些局部故障并添加局部防御。Karpathy 曾提到它们“对异常极其恐惧”。在具有重要不变量的系统中，尤其是持久化数据格式或核心基础设施，正确的解决方法不是“处理每种畸形情况”。正确的解决方法是从一开始就让畸形情况无法表示或根本无法写入。然而，即使进行大量的人工干预，这类代码也不会自然而然地从 LLM 中生成，即使代码自然地生成了，它们仍会试图去处理那些现在已经不可能发生的错误。

当你把这种行为放在循环中时，往往会将其放大。如果每次迭代都增加一点小防御，系统在看起来更健壮的同时，会慢慢变得难以理解。你越是不加干预，这种情况就越严重。如果在没有明确指导的情况下将此类工具交给初级开发人员，还会给他们灌输极其糟糕的实践。因为如果你问他们为什么要这么做，他们会给出令人信服的理由。

循环模式适用的场景

与此同时，假装循环模式不起作用是不诚实的，因为它在某些领域已经表现得非常出色。

代码移植就是其中之一。目前已经有了大规模自动化移植的惊艳案例，包括据说将 Bun 的部分代码从 Zig 迁移到 Rust 的工作。我自己也曾成功使用它将 MiniJinja 移植到 Go。性能探索是另一个绝佳的应用场景。机器可以尝试实验、进行基准测试、丢弃失败的结果，并继续搜索。安全扫描也很契合，几乎所有类型的研究也是如此：要求系统探索复杂的问题空间并返回报告，而不必提交持久的代码。这些场景的一个共同点是，它们要么不生成新代码，而是转换现有代码；要么生成的代码故意设计为生命周期很短。它们要么生成概念证明或想法，要么展示发现，或者更类似于机械转换。

我相信，生成无需长期存在的产物的循环，或者创建某种可明确验证的机械转换的循环，比执行框架机械衡量目标的一般能力更重要。许多成功的循环应用使用另一个 LLM 作为评判者或编排者。机械转换的情况可以通过二元测试用例来验证，但也可以改由 LLM 来评判！

例如，Claude Code 越来越擅长创建并随后执行完整的实验工作流。当然，它生成的代码很糟糕，但这更多是模型本身的错，而不是执行框架无法很好地判断工作流中的某一步是否带来了实质性的改进或完成。

执行框架只需要一些能让它继续运行的信号。它不需要是客观的或二元的，只要足够有用，能驱动下一次迭代即可。

我已经完全爱上了这些循环，它们帮我省去了日常实验和测量中枯燥的部分，并为我提供灵感。

软件即有机体

另一方面，使用同样的循环方法来编写持久的代码仍然让我感到不太妥当。我喜欢用这样一个比喻：软件正从确定性的机器转变为一种有机体。

我成为一名软件工程师的环境，鼓励我去理解机器。总会有更深的一层供你探索，以加深你的理解。对于没有表现出确定性可观察行为的机器，人们或许可以接受，但通常认为这并非最佳状态。在软件架构方面，我认为朝着更高确定性（而不是更低）的方向推进是可取的。同样，让代码具备可理解性一直是一个毋庸置疑的目标。尽管理论上这并不总能实现，但我们依然为编写出的代码感到自豪，因为通过巧妙的架构，即使是新工程师也能在复杂的代码库中游刃有余。在精心设计的系统中，总有工程师清楚不变量存在于何处，哪些部分是承重结构，以及哪些更改是安全的。理想情况下，所有这些也都应有完善的文档记录。如果缺乏这种理解，通常会被视为需要改进的地方。

显然，这种理想状态一直面临挑战。许多软件系统，特别是那些非常成功的系统，都曾有过团队工程师能够保持其整洁的时期。大型软件系统往往太大、太动态、且过度依赖外部服务，以至于任何人都无法完全掌握。即使没有 LLM，我们在诊断分布式系统时也已经有点像医生看病了：我们观察症状，提出假设，“安排更多检查”，尝试一些疗法，然后再次观察。

然而，随着 LLM 的出现，我们正以更快的速度朝着这个方向走得更远。我们不仅用它们来编写代码，还用它们来进行诊断和修复。许多工程师已经处于这样一个世界中：生产环境出现问题后的第一步，就是让一个机器人去读取日志，提出根本原因，并主动提交补丁。然后，生成的补丁通常会被另一台机器接管并进行审查，有时甚至在没有任何人工监督的情况下将其合并到主干分支。

显然这很强大，我也不否认这听起来很吸引人。但是，屈服于这种想法，尤其是在人工监督越来越少的情况下，意味着我们必须接受：我们可能无法再像以前那样理解整个系统了。我们治疗它、监控它、稳定它，但我们不一定真正理解它。

我毫不怀疑，对于某些软件来说，这没什么问题。并不是每一行代码都值得由人类亲手编写，而且过去写出的代码可能更糟。

但是，我希望所有软件都以这种方式编写吗？

你无法完全置身事外

令人非常不安的是，我们可能根本无法选择退出这个完全由机器驱动的未来。

如今，安全性就是最明显的例子。即使你不使用自动化循环来构建软件，其他人也会用自动化循环来攻击你的软件。攻击者会持续运行机器；退一步讲，即使不是攻击者，安全研究人员也会这么做。这些自动化工作不仅会制造干扰，也会发现真正的问题。而且，无论是有用的信号还是无用的噪音，其庞大的数量都会让你根本无法应付，除非你自己也动用机器来解决问题。

Daniel Stenberg 关于 curl “幸福之夏”的博文就是一个很好的例子，说明了维护者目前面临的压力。据我所知，如今 AI 在 curl 的核心开发中并没有发挥巨大的作用。然而尽管如此，维护者已经被各种报告淹没，其中大多数现在都是由 AI 生成的。

如果攻击者和报告者形成循环，防御者最终也需要形成循环才能跟上步伐。也许不是直接编写补丁，也许仅仅是进行分类和复现，但压力将会不断增加。

在竞争层面也是如此，一些团队将凭借纯粹的速度在构建能力上超越其他团队。一些项目会突然加快进度，因为一个小团队找到了有效编排机器的方法。一些初创公司将用五个人完成过去需要五十个人的工作。有些人可能真的会让机器以循环的方式针对你的产品运行，并要求它“做得和另一个一样”。如果他们的用户很满意，这真的重要吗？

并非所有软件都会受到同等程度的影响。某些领域会惩罚草率行事，并要求信任和责任，但许多软件所处的世界，纯粹的速度、快速的实验和广泛的覆盖范围至关重要。

构建新的依赖关系

对我来说，最可怕的一点是，我们正在以全新的方式依赖这些新机器。软件一直依赖于工具。我还记得过去必须为编译器付费的日子。这些新工具让人回想起那个创建软件伴随着真实成本的时代。但现在这不再是一次性付费，而是一种持续的依赖。不仅是对充足资金的依赖，更是一种认知上的依赖。

如果一个代码库是由循环生成的，由循环审查的，由循环打补丁的，并由循环来维持其生命力，那么当你不再能够访问同类系统时会发生什么？当某些贸易限制让你无法再访问最强大的模型时会发生什么？如果仅仅是成本变得难以承受会怎样？如果你和你的团队完全失去了不使用机器就无法理解代码的最后一点能力，又会怎样？

我们可能会创造出不仅人类难以维护，而且将机器参与作为其维护模型一部分的代码库。这已经在发生了！它并没有在所有地方发生，甚至可能并没有以被视为有问题的方式发生，但我们看到这种情况越来越多。人们越来越多地合并他们无法完全解释的代码。人们失去了创建问题报告或在聊天中讨论问题的能力，除非借助机器程序提供的上下文来增强或重新表述他们的消息。太多的人越来越依赖机器来进行总结或提供上下文。我遇到越来越多的人通过 LLM 的间接方式与我交流。

话说回来，也许这甚至不算是错的，但这与我们过去的做事方式相比是一个巨大的改变。

未来的工具框架

我毫不怀疑这就是事物发展的方向，但要达到那个阶段，我们需要在所有地方改进我们的工具，而不仅仅是在代码智能体方面。

仅仅编排更多的循环是不够的。更好的变更可视化、编排可视化或智能体可视化，都无法恢复我们的理解力。我们要么需要找到聪明的方法，将人类重新拉回循环中，并使循环带来的变更在长期内保持清晰可读，要么就需要找到更好的方法来组合这些日益复杂的系统。

这也是我对 Pi 的角色看法发生改变的地方。Pi 一直很谨慎，我认为这种谨慎是件好事。我不希望未来的每一次交互都变成一群不受控制的机器做出我无法跟上的修改。我不希望 Pi 为了赢得编写自身软件的竞赛而变成一团无法维护的乱局，我也不希望 Pi 提倡这种类型的工程实践。同时，Pi 是一个框架，而框架正是人们运行这些新型实验的核心。

用于编码任务的任务队列、智能体（agents）的编排、子智能体（subagents）以及持久会话（durable sessions）将变得越来越重要。即使是我们中那些对此持保留意见、不盲目拥抱循环（loops）的人，也不得不开始进行这些实验。我们需要这样做，因为我们需要弄清楚如何让这个未来变得有边界且可生存。

控制循环

正如你从这篇文章中所读到的，我对这个未来感到非常不安。不是因为恐惧，而是出于迄今为止对这项技术的经验所带来的谨慎。

采用框架循环的理念意味着由框架来决定工作何时完成。在智能体循环中，模型最终会说“完成”，然后由我来审查。甚至在那之前，我通常也会在过程中进行引导。我参与其中，并享受在这个过程中学习的乐趣。而在框架操作的循环中，我甚至不确定自己的角色到底是什么。甚至连“完成”信号也失去了所有意义，仅仅是传达给另一台用于评判的机器而已。我的角色被降级成了一个信使。

如今，我不太喜欢通过这种方式构建的系统中看到的大部分代码，也不太喜欢与过多由 AI 辅助构建的软件进行交互。循环虽然强大，但它越来越剥夺了责任感，而且至少在今天，它非常强烈地鼓励我们向机器屈服。

然而，我毫不怀疑，尽管我目前对此感到反感，但这种循环的未来必将成为我们的未来。我已经看到规模惊人的小团队正以不可思议的速度进行构建，我也看到代码库正越来越变成晦涩难懂、令人困惑的有机体，只能靠更多的机器来诊断。这些代码库既非常有用，又混乱不堪。

所以我想我开始接受这样一个事实：问题不在于我们是否会使用循环，因为显然我们会。也许问题在于，在充满循环的未来，我们如何做到不放弃判断力，如何保留良好工程规范，如何确保负责任的人类能够继续进行监督，以及我们需要如何重新思考代码架构设计，以在这一过程中保持理智。

此条目标签为 ai 和 pi

复制为 / 查看 markdown