即将到来的循环
撰写于2026年6月23日 我不再主动提示Claude了。我已经有循环在运作,提示Claude并逐步确定该做什么。我的工作就是编写循环。— Boris Cherny 在过去的几个月里,我看到越来越多的人在编码代理上构建一些感觉与单纯使用编码代理有显著不同的东西。一些事情确实发生在Pi之上,这当然很好看到!不过,到处的模式都是一样的:工作被放入一种排队中,一个机器尝试处理它,停下来,然后某个工具决定这是否真的结束了。如果没有,工具就继续同一会话,注入另一个消息,启动一个带有修改上下文的新会话,或将任务发送到另一台机器。任务会在模型通常会说“我完成了”的时刻继续存在。我想了这种循环,超过我愿意承认的程度。每个编码代理内部已经有一个代理循环。模型调用一个工具,包含结果,调用另一个工具,读取文件,编辑文件,运行测试,最后产生一些答案。对我们而言,这种循环已经非常熟悉。另一个循环是工具层的循环:代理循环之外的循环。这个循环也并不新鲜。我们自早期的Claude代码时代就一直在进行这种版本,但这个循环在智能工程中越来越常见,最近几周开始主导Twitter话语。我对此还不太擅长 我目前的状态是,我在这种我非常关心的代码工作方式上没有取得太多成功,而这貌似是相当多的代码。部分原因是品味,部分是控制。我试图为我想要的代码设定一个较高的标准,我想理解我交付的代码。在压力下,或与其他人讨论时,我希望能够解释系统的功能,而无需首先让一个笨拙的工具来解释给我。现在显然有一个问题,即这种理解代码的愿望是否会在几年后仍然存在。就目前而言,我还没有超越理解对我重要的这个点。鉴于这种愿望,在我没有关注的情况下写的代码中,尤其是来自循环的代码中,有某种东西是我所缺乏的。如今的模型往往生成过于防御性、过于复杂、推理过于局限的代码。它们避免强的不变性。它们添加后备方案,而不是让不良状态变得不可能。它们复制代码,发明糟糕的抽象,并用更多的机器设备掩盖不清晰的设计。更糟的是:到目前为止,我看到这方面几乎没有进展。如果有的话,在这一方面我觉得我们可能在朝错误的方向迈进。至少对我而言,目前的非干预工具,如Claude Code与超代码相比,生成的代码质量比去年秋天差。这是因为Claude Code,比如Fable,将在问题上不间断地工作三十分钟或更长时间,而之前的过程会更人性化。此外,人们普遍了解到,模型往往观察某些局部失败并添加局部防御。Karpathy提到他们“对例外情况感到致命的恐惧”。在具有重要不变性的系统中,特别是持久数据格式或核心基础设施,正确的修复并不是“处理每个格式不正确的情况”。正确的修复是使这种不良情况无法表示或根本不可能编写。然而,即使在大量人工干预下,这种类型的代码也并不会自然地从大型语言模型中产生,即使代码自然地以这种方式产生,它们仍会试图处理现在不可能的错误。当你将这种行为放在循环后面时,它往往会被放大。如果每次迭代添加另一个小的防御,系统就会逐渐变得难以理解,同时看起来更具稳健性。你越不干预,这种情况发生得越多。当像这样的工具在没有明确指导的情况下提供给初学者时,它还会教授非常糟糕的实践。因为如果你问他们,他们为什么这样做,他们会非常有说服力地论证自己的观点。 与此同时,假装循环模式不起作用是欺骗性的,因为它在一些领域已经惊人地有效。代码移植就是其中之一。已经有令人印象深刻的自动移植工作的例子,包括有关将Bun的部分从Zig移植到Rust的报告。我自己也成功使用它将MiniJinja移植到Go。性能探索是另一个适用的例子,机器可以尝试实验、基准测试、丢弃失败并继续搜索。安全扫描也自然而然地适配,几乎任何类型的研究也是如此:让系统探索复杂的问题空间并反馈,而不一定需要提交持久的代码。许多这些都有一个共同点,要么没有
本站免费、广告极少。如果觉得有帮助,可以请我们喝杯咖啡 —— 任何金额都对持续运营有实际帮助。
☕请我喝杯咖啡