循环模式在代码领域：效果显著但也带来诸多挑战，未来该如何应对？

即将到来的循环

2026 年 6 月 23 日撰写的文章中，鲍里斯·切尔尼表示不再直接向 Claude 提问，而是运行循环程序让它们向 Claude 提问并决定下一步行动，他的工作就是编写这些循环程序。

过去几个月，越来越多人基于编码代理构建出不同的东西，部分基于 [Pi] 实现。各地模式相同，将工作放入队列，机器接手尝试，中途停止，由管理程序决定是否结束。若未结束，管理程序会继续当前会话、注入新消息、开启新会话或把任务发给另一台机器，任务会持续超越模型说“我完成了”的节点。

每个编码代理内部有代理循环，模型调用工具、整合结果等最终给出答案，这一循环大家很熟悉。另一个是管理程序层面的循环，并非新鲜事物，从早期 Claude Code 时代就开始做，在智能代理工程中越来越重要，最近几周主导了 Twitter 上的讨论。

我目前还不擅长这个

对于在意的代码，采用这种工作方式没取得太多成功。部分因为个人品味，部分因为对控制权的需求。作者对代码质量要求高，希望理解交付的代码，在压力或与他人讨论时，能无需机器解释说明系统工作原理。几年后是否还需要这种理解代码的能力是个问题，目前理解代码仍很重要。

基于此需求，作者对未参与编写、尤其是循环生成的代码觉得有所欠缺。如今模型生成的代码过于保守、复杂，推理局限，避免使用强不变量，不消除不良状态，添加回退机制，复制代码，创造糟糕抽象，用更多机制掩盖不清晰设计。像 Claude Code 搭配 ultracode 生成的代码比去年秋天编写的还差，因为以前过程有更多人工参与。

大家都知道模型会针对局部故障添加局部防御机制，卡帕西提到它们“对异常极度恐惧”。在有重要不变量的系统中，正确做法是让格式错误情况无法出现，但大语言模型很难自然生成这样的代码，即便生成了仍会处理不可能出现的错误。

把这种行为放在循环中，问题会被放大。每次迭代添加小防御机制，系统看似更健壮却越来越难理解，参与度越低情况越严重。把这样的工具交给新手且无明确指导，会让他们养成糟糕编程习惯，还会振振有词地为做法辩护。

循环适用的场景

假装循环模式没有效果是不诚实的，它在某些领域已取得惊人效果。

代码移植是其一，有大规模自动移植成功案例，如 [Bun 从 Zig 移植到 Rust] 的报道，作者自己也成功将 MiniJinja 移植到了 Go。性能探索、安全扫描、几乎任何类型的研究都适用循环模式。这些场景要么不生成新代码，对现有代码进行转换，要么生成的代码无需长期维护，要么产生概念验证或想法、揭示发现，要么更像机械转换。

生成不需要长期保存的工件，或进行可明确验证的机械转换的循环，比管理程序机械衡量目标的一般能力更重要。许多成功的循环应用会用另一个大语言模型作为评判者或协调者，机械转换情况可通过二进制测试用例验证，也可由大语言模型评判。

Claude Code 越来越擅长创建整个实验工作流并执行，虽生成代码质量不高，但更多是模型问题，而非管理程序无法判断工作流步骤是否带来净改进或完成任务。管理程序只需一些信号继续运行，这个信号不一定要客观或二元，足以驱动下一次迭代即可。作者已很喜欢能帮自己完成日常实验、测量工作中无聊部分并提供想法的循环程序。

软件即有机体

用同样的循环方法编写持久代码，作者目前不太能接受。作者喜欢用的比喻是，从将软件视为确定性机器转变为将软件视为有机体。

作者成为软件工程师时，环境鼓励理解机器，总有一层可深入挖掘以加深理解。不表现出确定性可观察行为的机器，也许可接受，但通常被认为不是最优的。在软件架构方面，朝着更具确定性的方向发展是可取的，理解代码的能力一直是不可否认的目标。在设计良好的系统中，工程师知道不变量位置、关键部分和安全更改，理想情况下这些都有很好的文档记录，缺乏这种理解通常被视为需要改进的地方。

这个理想一直面临挑战，许多软件系统，尤其是非常成功的系统，有团队工程师能保持其整洁的时期。大型软件系统庞大、动态，依赖外部服务，无法被任何人完全理解。即使没有大语言模型，诊断分布式系统的方式也像医生，观察症状、形成假设、“安排更多测试”、尝试补救措施、再次观察。

有了大语言模型，在这个方向上走得更远、更快。用它们编写代码、诊断和修复。很多工程师在生产环境出现问题后，第一步是让机器读取日志、提出根本原因并主动提交补丁，生成的补丁通常由另一台机器审查，有时甚至在无人工监督下直接合并到主分支。

这很强大且有吸引力，但接受这种想法，尤其是人工监督越来越少的情况下，意味着可能不再能以同样的方式理解整个系统，只能对它进行处理、监控、稳定，但不一定能理解它。对于某些软件，这是可以接受的，但作者希望所有软件都以这种方式编写吗？

你无法完全置身事外

完全拒绝机器驱动的未来可能不是一个选项。安全问题是明显例子，即使自己不使用循环构建软件，其他人会用循环攻击软件，攻击者和安全研究人员都会持续运行机器，这些自动化工作会带来干扰，也会发现真正问题，信息大量涌来，除非用机器处理，否则难以应对。

丹尼尔·斯滕伯格关于 curl 的 [幸福夏日] 的文章说明维护者面临的压力，目前 AI 在 curl 的核心开发中作用不大，但维护者仍被大量 AI 生成的报告淹没。

如果攻击者和报告者使用循环，防御者最终也需要使用循环跟上节奏，也许不是直接编写补丁，只是进行分类和重现，但压力会不断增加。

在竞争方面，一些团队会通过超高速度超越其他团队，一些项目会突然加速，因为一小群人找到了有效协调机器的方法，一些初创公司用五个人就能完成以前五十个人的工作，有些人甚至会用机器循环攻击产品，让它“变得和另一个产品一样”，如果用户满意，这真的重要吗？

并非所有软件都会受到同样影响，有些领域会惩罚草率做法，要求信任和责任，但很多软件所处环境中，速度、快速实验和广泛覆盖非常重要。

构建新的依赖关系

最可怕的是我们以新的方式依赖这些新机器。软件一直依赖工具，作者还记得曾经需要为编译器付费的日子。这些新工具让人回想起软件开发需要付出实际成本的时代，但现在不再是一次性付费，而是持续的依赖，不仅是钱包的依赖，还有认知上的依赖。

如果一个代码库由循环生成、审查、打补丁并维持运行，当无法再使用同类系统时会怎样？当贸易限制让人无法使用最强大的模型时会怎样？如果成本变得无法承受呢？如果和团队失去了不借助机器理解代码的能力呢？

可能会创建出不仅人类难以维护，而且维护模式本身就依赖机器参与的代码库，这种情况已经在发生！人们越来越多地合并无法完全解释的代码，在没有借助机器提供的上下文补充或改写消息的情况下，就无法创建问题报告或在聊天中讨论事情，越来越多人依赖机器总结或提供上下文，作者越来越多地遇到通过大语言模型间接与自己交流的人。也许这不会是错误的，但这与过去的做法有很大不同。

未来的管理程序

发展方向就是如此，但要实现这一点，需要在各个方面改进工具，而不仅仅是编码代理。仅仅协调更多的循环是不够的，更好的变更可视化、协调或代理展示并不能恢复理解能力。要么需要找到巧妙的方法，让人类重新参与到循环中，使循环的变更长期清晰易懂，要么需要找到更好的方法来组合这些日益复杂的系统。

这也是作者对 Pi 的角色的看法发生变化的地方。Pi 一直很谨慎，作者认为这种谨慎是有好处的。不希望未来的每一次交互都变成一群不受控制的机器进行无法理解的更改，不希望 Pi 为了在软件自动编写的竞赛中获胜而变成一个无法维护的混乱局面，也不希望 Pi 推广这种工程方式。同时，Pi 是一个管理程序，而管理程序是人们进行这些新型实验的核心。

编码任务的任务队列、代理的协调、子代理、持久会话将变得越来越重要。即使是有所保留、不盲目接受循环的人，也必须开始进行这些实验，因为需要了解如何让这个未来变得可控和可持续。

控制循环

作者对这个未来感到非常不安，这不是因为恐惧，而是基于目前对这项技术的经验而产生的谨慎态度。

采用管理程序循环意味着由管理程序决定工作何时完成。在代理循环中，模型最终会说“完成”，然后作者进行审查，甚至在此之前，作者通常也会在过程中进行引导，参与其中并享受学习的过程。在由管理程序操作的循环中，作者甚至不确定自己的角色是什么，“完成”的信号也失去了所有意义，只是被传达给另一个进行评判的机器，作者的角色沦为了信使。

目前，作者不太喜欢通过这种方式构建的系统生成的代码，也不太喜欢与太多由 AI 辅助构建的软件进行交互。循环很强大，但它越来越多地剥夺了我们的责任，至少在目前，它非常鼓励我们依赖机器。

然而，作者毫不怀疑，尽管目前有所抵触，但这个循环的未来将是我们的未来。已经看到规模极小的团队以惊人的速度进行开发，也看到代码库越来越像只能由更多机器诊断的模糊、混乱的有机体，这些代码库既有用又杂乱。

所以作者正在逐渐接受这个现实，问题不再是是否会使用循环，因为显然会。也许问题是，在一个循环的未来里，如何不放弃判断力，如何保持良好的工程原则，如何确保有责任心的人类能够继续监督，以及如何重新思考代码架构以保持理智。