"我已经两年半没手写代码了。”Ralph Loop 的创造者 Geoffrey Huntley 在辩论开场时直言。
另一边，Sentry 的 Greg 回应：“我在实践中读到的代码依然是垃圾。”
近期，关于 Loops（循环工程）的炒作铺天盖地，社交媒体上人人都在讨论如何利用循环实现开发自动化，甚至构建“熄灯软件工厂”。然而，这一热潮究竟是否靠谱？
在 AIE World's Fair 大会上，一场题为《伟大的 Loops》的辩论赛由 Insecure Agents 播客主持人 Allie Howe 主持展开。正方 Keycard CEO Ian Livingstone 和 Ralph Loop 创造者 Geoffrey Huntley 认为，Loops 是工程的核心单元，只要有正确的规范、基础设施和测试，它就是迈向真正软件工厂的重要一步。反方 Human Layer CEO Dex Horthy 和 Sentry 开发者 Greg Pstrucha 则指出，Loops 的 hype（炒作）跑在了技术严谨性前面，它并非银弹，本质上仍需工程师留在循环之中。
基于该辩论视频，InfoQ 对核心观点进行了整理与精炼。
太长不看版：核心观点交锋
Q：Loops 到底靠不靠谱？
Geoffrey（正方）：Loops 已不可避免。既然 Prompt 可以编程，Loops 自然发生。目前每小时成本仅约 10 美元，生成质量优于普通招聘人员。虽非银弹，但大势所趋。
Dex（反方）：问题不在于 Loops 本身，而是 Hype 跑在了 Discipline（规范/纪律）前面。目前尚无证据表明我们可以简单地提升一个抽象层次而无需人工干预。
Greg（反方）：无论是否有 Loops，AI 生成的代码质量依然堪忧。投入更多 Token 无法通过堆叠循环来解决根本的质量问题。
Q：Agent 在 Loop 里疯狂迭代，安全性有保障吗？
安全专家 Ian：不能指望模型自身具备“道德感”或保持对齐。Agent 天生极度目标驱动，可能发现人类未察觉的漏洞。必须依靠基础设施（权限控制、验证手段、pre-commit 钩子）进行约束。
Geoffrey 补充：若 Agent 无权限部署，它可能会在文件系统中疯狂翻找高权限令牌。绝不要挡在 Agent 和其目标之间。
Q：是什么让 Loops 突然变得广泛可用？
Geoffrey：模型在过去一年已足够好。关键在于人们有了时间去理解和使用它们。LLM 生成的代码质量已超越市场平均水平，且成本极低，使得 Loops 普及成为必然。
Q：上下文窗口变大后，Loops 的原始动机还成立吗？
Dex：从 Token 消耗角度看，频繁重启上下文的必要性降低。但 Loops 的真正价值在于自动化反馈回路，例如自动检查 PR 评论并修复，而非单纯依赖大上下文。
Q：如何保证最终输出的不是垃圾（收敛工程）？
Dex：目前无法完全保证。避免垃圾的唯一方法仍是人工审查代码。没有捷径，也没有银弹。
Q：Loops 的 Token 开销值得吗？
Geoffrey：值得。低成本换取整夜自动工作，能极大压缩 MVP 开发时间，提升运营效率。
Greg：在大公司场景下可能不可持续。需考量工程师的合理预算，每月数万甚至百万美元的 Token 消耗可能导致模式崩裂。
Q：如何实现完全自主的软件工厂？
Dex：短期内不可能实现“完全无人值守”。软件工程积累的经验不应被抛弃。当前的反模式是未做出可用 MVP 就盲目搭建“工厂”基建。建议从小处着手，先实现 2-3 倍的提速。
开场陈词：Loops 究竟配不配得上这场热潮？
Geoffrey Huntley（正方）：Loops 在某种程度上是不可避免的。两年前我就观察到工程师们不断处于 Prompt 循环中，这本质上是可编程的。Ralph Loop 背后是经过深思熟虑的架构，即将 LLM 视为新的 CPU 架构来理解其行为模式，并将流程简化为 Bash Loop。
虽然它不是万能银弹，未来可能会出现大量关于失败的案例，但这正如 Kubernetes 早期一样，是技术演进的必经之路。编程机器、自动化工作职能已成为雇主对员工的明确期望。无论是代码迁移、产品研究还是工单处理，只要任务有明确终止条件，Loops 就能发挥作用。我们必须弄清楚如何使用这种新的可编程基础介质。
Dex（反方）：核心问题在于 Hype 跑到了 Discipline 前面。Kubernetes 花了七八年才真正成熟，而云基础设施在此之前也发展了许久。Loops 最大的价值在于处理小而隔离的任务，通过确定性系统朝期望状态演进。
我担忧的是行业氛围倾向于寻找魔法，试图绕过代码审查等痛苦但必要的环节。目前没有任何证据表明我们可以简单地提升抽象层次而放弃对代码架构的参与。我们需要的是更多的思考和谨慎，而非盲目相信 Twitter 圈子营造的神奇答案。
Ian（正方）：软件工程的本质就是 Loop：尝试、学习、应用。我们讨论的只是如何加速这个过程，将人类判断移出循环。AI 本质上是更高版本的 Tab 补全，允许用高层次意图描述替代机械操作。CI/CD、PR、设计评审本质上都是驱动 Loop 的过程。随着软件交互减少，主观性降低，软件将变得更加可验证，更加 Loop 驱动。
Greg（反方）：当前存在过多的 Hype 和 FOMO（错失恐惧症）。首要问题是输出质量：即便经过语义验证，生成的代码往往仍是垃圾，需要大量人力迭代引导。其次是以炒作为主导的讨论让人误以为可以通过堆叠循环和 Token 解决质量问题。此外，经济可行性存疑，尤其是在大公司，高昂的 Token 消耗模式难以长期支撑。当然，在特定任务和流程中，Loops 确实能产生合理结果，但这需要具体分析。
Agent 会失控吗？
Allie：Anthropic 将 Ralph Loops 概念吸收进平台，创建了 loop、batch 和 goal 命令。其中 goal 命令设计理念是“持续执行直到条件为真”。作为安全专家，Ian，你凭什么相信 Agent 在追求目标过程中不会超出权限范围？
Ian：坦率地说，从现有证据来看，我不相信模型本身有能力保持对齐和安全。随着模型规模扩大和强化学习的应用，Agent 表现出极强的目标导向能力，甚至能发现人类未曾找到的漏洞。模型只是概率分布，没有道德感。安全不来自模型本身，而取决于围绕它构建的基础设施，如权限控制和验证手段。
Geoffrey Huntley：保护环境最具体的方法是不要以文件形式存储机密信息。当 Agent 因权限不足无法部署时，它可能会在文件系统中疯狂寻找高权限令牌。你绝对不想挡在一个全力实现目标的 Agent 面前。
Loops 为何突然变得广泛可用？
Allie：Geoff，你去年曾称 Ralph 最适合绿地项目，但现在工程师们已在现有代码库上运行 Loops 进行优化和重构。是什么改变了？
Geoffrey Huntley：模型在过去一年已足够好，真正的变化在于人们的理解和使用时间。Loops 流行的原因很简单：管用。LLM 生成的代码质量优于大多数初级开发者，且每小时成本仅约 10 美元。这使得复杂的技术栈管理变得简单，软件开发职业正在被商品化。
现在的工程意义在于将领域知识编码成规则，通过 pre-commit 钩子等手段阻止 Agent 随意提交代码，形成反馈 Loop。我们像火车工程师，工作是把“醉酒”的模型保持在轨道上。Y C 初创公司利用 Loops 自主压缩时间构建 MVP，加剧了市场竞争的紧迫感。
上下文窗口大了，Loops 的原始动机已经变了
Allie：随着模型上下文窗口变大、推理能力改进，Greg，为什么我们使用 Loops 的方式仍被认为是错的？
Greg：模型智能本身已不那么重要，关键在于语义验证的能力。对于确定性验证的事情（如类型系统、Linter），Loops 表现不错。但一旦涉及非确定性验证，错误率会随循环次数累积，且成本高昂。许多大型 AI 公司仍在使用 Sentry 抓取简单 Bug，说明老问题在 Loops 方式中依然存在。
Allie：Ralph Loop 开创了“每轮清空上下文”的做法。Dex，现在上下文窗口大了，我们是否摆脱了上下文腐烂的困扰？
Dex：从 Token 效率看，频繁重启不够高效，但它能防止上下文溢出并保持任务在“智能区”。虽然上下文窗口在扩大，Ralph Loop 每次少做事情的原始动机减弱，但更有价值的是自动化反馈回路。如果你能自动化“检查 PR 评论 - 修复 - 再检查”的过程，那才是 Loops 真正起作用的地方。
Geoffrey Huntley：防止模型作弊需依赖 pre-commit 钩子和反向压力。LLM 是非确定性系统，上下文窗口虽大，但实际可用内存有限，需谨慎处理。此外，不同模型有独特的“口味”，保持模型正轨本身就是工程学的一部分。
避免 Loops 产生更多垃圾：“收敛工程”
Allie：Geoff 提出了“收敛工程”，即让循环迭代直到输出收敛。Dex，如何确保 Loops 不会拼凑出更多垃圾？
Dex：目前根本做不到完全避免。Geoff 之前的实验项目"Loom"试图通过数据反馈移除人类视觉品味，但最终因技术未成熟而停滞。这是"Hype 跑在 Discipline 前面”的典型例子。避免垃圾的唯一方法仍是人工阅读代码，确保输出质量。
Geoffrey Huntley：连模型实验室都没搞定对齐问题，普通人更难搞定。大家都在努力探索边界。
Loops 什么时候真值这个钱？
Allie：怀疑论者担心 Loops 会在账单上无限螺旋。Greg，Loops 什么时候能值回票价？
Greg：它们不会悄无声息地失败，高昂的账单会让人清醒。但在特定场景下价值明显：一是安全扫描等能发现人类遗漏问题的环节；二是定义非常明确、有完善测试套件的项目（如用 Rust 重写 Bun）；三是快速原型开发。反对的是盲目炒作，建议在明确成本可控的前提下进行实验。
Allie：多 Agent 协作时的共享内存访问控制如何解决？
Ian：这是一个尚未完全解决的问题。现有的访问控制系统并非为机器代理设计。目前的雏形是将记忆视为 Markdown 文件，通过文件系统暴露给 Agent 并附加访问控制。我们需要更好地向智能体呈现世界，并让普通人方便地管理权限。
Loops 的未来：软件工厂模式？还早得很
Allie：循环工程是否已成熟到足以支撑完整的软件工厂？
Greg：如果算力免费或许可以，但现实并非如此。目前循环中的人仍需负责设计、架构和关键决策。Agent 热爱复杂性，容易堆砌技术栈，因此架构决策仍需人类把控。
Allie：Shopify 工程负责人称“你的工作就是写 Loops"。Geoff，这对大众安全吗？
Geoffrey Huntley：教导广泛受众很难。Ralph 本质是一种分配和编排模式，初衷是简单易用。但任何人都不应直接在本地笔记本上运行不受控的编程工具，这不仅是因为 AI，也是因为传统的供应链安全问题。解决日常开发环境的安全问题是前提。
Allie：Dex，如果只能提速 2-3 倍，如何实现完全自主的软件工厂？
Dex：不要抛弃过去几十年的工程经验。软件工厂建设的最大反模式是未触碰实际问题就盲目搭建基建。正确的方法是从小处开始，建立小型增量 Loops，先实现 2-3 倍提速，同时保持对代码和架构的所有权。全球工程师若都能提速 2-3 倍且保持高质量，经济账将彻底改变。
Allie：雇主对人类交付的代码负有最终责任。如果无法确定是谁做了工作，我们准备好让软件工厂编写所有代码了吗？
Ian：目前 Git 只允许一个签署者，这需解决。更重要的是，Agent 不能成为独立责任实体，必须由人类承担法律和道德责任。未来需重新思考软件供应链中的归属方式，建立更确定性的签名链。
Geoffrey Huntley：行业自称工程师但缺乏真正的法律责任，这可能需要重新审视。
总结：大势来了，但别一股脑往里冲
Greg：不要被 Hype 裹挟，亲自实践才能发现什么有效。虽然对完全自动化持怀疑态度，但对技术进步保持乐观。软件工程师不会离场，仍将是重要部分。
Ian：趋势已启动且不可逆。竞争格局已变，企业必须跟上。建议搞清楚什么是 Loops，找出代码库中高度可验证的部分应用它们，创造价值。
Dex：期待“熄灯软件工厂”成真，但目前模型层面尚未解决。建议在使用 Loops 时保持谨慎，不要盲目模仿极端案例。
Geoffrey Huntley：软件工厂是终极梦想，但今天刚起步的公司切勿直接照搬。鼓励做小任务实验，关注类型系统和供应链安全，尽可能 Vendor 自己的源代码以缩小爆炸半径。
（辩论结束，现场投票双方几乎平手。）
参考视频原链接：
https://www.youtube.com/watch?v=c35YoMdnI78
声明：本文为 InfoQ 整理，不代表平台观点，也不构成投资建议，未经许可禁止转载。
