@_avichawla: Karpathy说过你会后悔忽略的话：“把自己从瓶颈中移除。最大化你的杠杆。投入极少的…

Karpathy说过你会后悔忽略的话：“把自己从瓶颈中移除。最大化你的杠杆。投入极少的令牌，就会有一大堆事情替你去完成。”循环工程恰恰能做到这一点。在手动运行的过程中，操作员负责两件事： - 决定代理下一步运行什么 - 以及在下一步之前检查它的输出。这两项都是手动的，并且它们决定了代理在没有操作员的情况下能够自主走多远。循环工程将这两个步骤都移入系统中。一个核心运行结构包围着循环，下图描绘了它。 - 调度决定运行什么 - 循环是制造者，产生工作 - 一个独立的检查者代理对输出进行评分 - 磁盘上的一个文件保存着它们都读取的状态。循环运行直到完成、达到最大迭代次数或预算耗尽。以下是一些实际的工程考虑： 1) 模型对自己的输出进行评分会为其已经完成的工作辩护，而不是发现它失败的地方。这就是为什么独立的检查者的发现会作为下一步指令返回给制造者。循环重复直到检查者认为没有什么需要修复为止。 2) 没有停止条件的循环会消耗大量令牌，一旦子代理和长时间运行累积起来，成本就会快速攀升。这就是为什么必须在循环运行之前设置退出条件，而不是在运行期间设置。一个简单的退出条件可以是：↳ 只修复主要问题，运行一次最终检查，并在两轮循环后停止，以“所有测试通过且lint干净”作为结束规则。 3) 状态必须存在于磁盘上，而不是上下文中。模型在运行之间会忘记一切，因此一个MD文件或知识图谱保存了已完成和未完成的工作。每次运行时都会读取并写回，这使得循环可以在数天后再次接续。 4) 验证标准越低，循环越安全。无聊的重复性检查，如过期的版本字符串或缺失的测试，验证起来非常简单，因此循环可以在操作员不在时以较低风险运行它们。需要大量判断的工作也是可循环的，但仅限于检查者能够确认结果的程度。 让我们看看无人值守循环如何以两种方式失败。 1) 它在实际上什么都没有验证时报告完成。独立的检查者存在就是为了防止这种情况，但它合并代码的速度比任何人阅读它的速度都快，因此几周后，团队就不再理解自己的代码库，而所有检查仍然是绿色通过。绿色测试只说明代码通过了测试，并不表示有人知道发布了什么。仍然需要有人阅读循环合并的内容。 2) 检查者确保运行的循环诚实，但它只能捕获运行内部的失败。围绕循环的脚手架（如提示、工具和围绕模型的检查）仍然会随着模型的变化而在生产中发生偏移和故障。这个修复循环通常基于可观测性追踪手动运行。 我的联合创始人写了一篇详细的教程（附代码），关于如何让这个脚手架自我修复：诊断失败的追踪，针对确切的失败输入验证修复，并将该故障锁定为回归测试，使其不再发生。请阅读下文。