“我已经两年半没手写代码了。”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 完全配得上今天的热度，人们可以很容易地开始使用循环、构建循环，这是提高自主程度、迈向真正软件工厂的重要一步。他们的核心论点是：Loops 是工程的核心单元，只要有正确的 Discipline、基础设施和测试，Loops 非常有效，围绕 Loops 的最佳实践也已经开始形成。

而反方是 Human Layer CEO Dex Horthy 和 Sentry 开发者 Greg Pstrucha，他们认为 Loops 的 Hype 和实际效果之间存在巨大落差。今天做 Loops 的方式是错的，Loops 不是银弹，没有魔法。他们的核心论点是：Hype 跑在了技术严谨性前面。软件工厂可以机械地执行由规格约束、测试覆盖的任务切片，但它无法自主判断自己是否构建了正确的东西，本质上仍然需要工程师留在循环之中。

基于该辩论视频，InfoQ 对内容进行了整理。

太长不看版

Q：Loops 到底靠不靠谱？

Geoffrey（正方）：Loops 已经不可避免了。 两年前我就发现所有工程师都在循环里写 Prompt，既然这东西可以编程，Loops 就自然发生了。我自己已经两年半没手写代码了。不是模型变强了，是大家终于有时间搞明白了——每小时成本才 10 美元，生成质量比你能招到的人还好。当然它不是银弹，但大势已经来了，你跟也得跟，不跟也得跟。

Dex（反方）： 问题不在于 Loops 好不好，而是 Hype 已经跑到了 Discipline 前面。我没有看到证据表明我们已经到了可以简单地提升一个抽象层次的地步。

Greg（反方）： 用 AI 生成代码，不管有没有 Loops，你对输出满意吗？ 我不满意，我读到的依然是垃圾。投入更多 token 可以改善一些事，但别幻想在循环上叠循环就能把质量问题编排掉。

Q：让 Agent 在 Loop 里疯狂迭代，安全性有保障吗？会偏离目标吗？

安全专家 Ian： 我完全不相信这件事可以做到。从现有证据来看，我不相信模型本身有能力保持对齐和安全。Agent 天生极度目标驱动，已经能发现人类从未找到的漏洞。你只能通过基础设施（权限控制、验证手段、pre-commit 钩子）来约束它，绝不能指望模型自己有“道德感”。

Geoffrey （正方）补刀： 我见过 Agent 没权限部署时，开始在文件系统里疯狂翻找高权限令牌——你绝对不想挡在它和它的目标之间。

Q：Ralph 最适合绿地项目，也就是从零开始的项目，是什么改变了，让 Loops 突然变得如此广泛可用？

Geoffrey Huntley（正方）： 各位，模型究竟还能变得多好，其实已经没有那么重要了。至少在过去一年里，模型已经足够好。我最初说它只适合绿地项目，是因为当时的模型确实还很差，那已经是很久以前的事情了。Ralph 现在几乎已经有一年半的历史了。

Q：Ralph Loop 最初是为 20 万上下文设计的，每轮清空重启，现在窗口都这么大了还有必要吗？

Dex（反方）： 必要性降低了。从 token 消耗角度看这肯定不够高效。上下文窗口确实在改善、在扩大，所以 Ralph Loop 每次迭代尽量少做事情的原始动机，已经没有以前那么强。

但现在更有价值的是：你能自动化地往系统里塞越多反馈，系统就越可能自主完成更多工作。比如把“去检查 PR 评论、修复、三小时后再看”这种需要人记住去触发的事全部自动化——那才是 Loops 真正起作用的地方。

Q：Geoffrey Huntley 最近提出了“收敛工程”——让 Loop 不断迭代直到输出收敛。那我们怎么保证最终输出的不是垃圾？

Dex（反方）： 你根本做不到。听起来很酷，但问题在于如何确保 Loops 不会把垃圾拼凑在一起？我认为你根本做不到。这也是“炒作跑在技术严谨性（Discipline）前面”的完美例子。

怎么避免垃圾？唯一的方法就是老老实实读代码。你得亲自看从另一端出来的东西长什么样，确保它不是垃圾。没有捷径，没有银弹。

Q：Loops 的 token 开销值得吗？

Geoffrey（正方）： 值得。 跑一个 Loops 每小时成本才 10.42 美元，换来的是一整夜自动完成的工作。那些 YC 初创公司用这种方式把 MVP 开发时间压缩到极致，运营更精简、质量还更高。如果商业竞争对手在这样干，你跟不上就是死。

Greg（反方）： 不值得，而且你会从账单上清楚地意识到这一点。我不认为它们会悄无声息地失败，我觉得它们会非常大声地失败，尤其是当你看着账单的时候。在大公司，你得问自己：一个工程师的合理预算应该是多少？每月 1 万美元的 Token 消耗？10 万？还是 100 万？到某个临界点，这种模式就会崩裂，按照我们现在的做法，它根本撑不下去。

Q：使用编码 Agent 实际只能提速 2-3 倍，我们如何才能实现完全自主的软件工厂？

Dex（反方）： 在"完全无人值守、端到端自主交付"的意义上，目前不可能，短期内也看不到。 软件工程这个行业和社群积累了几十年的经验，不应该因为新的炒作就被主动抛弃。

这也对应了软件工厂建设中最大的反模式：很多人拍脑袋决定“我花三个月时间，读一堆博客文章，然后我要打造一个软件工厂，这是未来的交付方式。”三个月后你回来了，却从未真正触碰过问题，从未把任何东西交到任何人手里。

换句话说：连个能用的 MVP 都没跑出来，就在那搞“工厂”的基建。

1、开场陈词：Loops 究竟配不配得上这场热潮？ 

Geoffrey Huntley （正方）：Loops 在某种程度上是不可避免的。回想两年前，我在 Canvas 做技术主管，看到所有工程师都在不停地 Prompt，而且人始终处在循环之中。我当时就想：等等，这东西是可以编程的，Loops 就这么自然而然地发生了。

虽然 Ralph 可能有一点梗文化的成分，但它背后确实经过了很深入的思考。本质上，这是把 LLM 当成一种新的 CPU 架构来对待，去理解它的行为模式，弄清楚怎么用它。通过这样的思考，我最终把整个流程简化成了一个 bash Loops。

当然，它不是什么万能银弹。我也有深深的担忧，明年这个时候的会议上，我们会看到一大堆演讲，讲工厂怎么失败、Loops 怎么失败，这些都是我们还没搞明白的事情。

还记得 Kubernetes 刚出来那会儿吗？所有人都在搞 Kubernetes。Loops 现在也处在类似的位置。它已经出现了，也不可避免，并且会长期存在。编程机器、自动化你的工作职能，已经是雇主对员工的明确期望。

我自己已经两年半没有手写过代码了，我把代码从一个代码库自动迁移到另一个代码库，发现一个 Golang 项目，但我用的是 TypeScript，那就跑一个 Loops，自动移植过去。

这也不只适用于软件工程师和代码。

比如产品经理和产品研究。我们很容易只关注软件工程中的意义，但可以想象一个场景：你需要对 Linear 中所有工单进行产品研究。这项任务是有明确终止条件的。当你遍历完所有 Linear 工单时，任务就完成了。这就是一个很容易定义的循环。

这里当然存在很多细节和差异。但假如你做过产品研究，并且开始运行这些 Loops，把研究所需的时间进行压缩，你就会发现这也是不可避免的。

我们现在拥有了一种新的、可编程的基础介质。我们必须弄清楚该如何使用它，它适合用在哪里。我知道，按照辩论规则，我本来应该坚持说 Loops 适用于所有事情，但现实中没有任何东西是银弹。未来一年，我们会逐渐弄清楚，怎样更有效地使用循环。

Dex（反方）： 问题不在于 Loops 好不好，而是 Hype 已经跑到了 Discipline 前面。

Geoff 刚才提到 Kubernetes，这很有意思。Kubernetes 是一个花了七八年时间才真正做对的东西。

在 Kubernetes 之前，还有云基础设施。你甚至可以说，云基础设施先发展了七八年，才出现 Kubernetes；Kubernetes 又发展了七八年，才变成普通人真正可以使用的东西。

而 Kubernetes 本身就是建立在控制 Loops 之上的，是确定性 Loops。我们已经摸清楚了哪些东西适合用 Loops：那些可以单一系统拥有、小而隔离的任务。Loops 最大的价值在于：你可以选定一个小的、期望的最终状态，输入当前状态，然后让一个 Agent 或确定性系统朝着那个状态演进。

我对炒作的担忧在于，我们此前已经处在一种行业氛围中：主流口号是，看看能不能进入一种再也不需要读代码的状态。在 Loops 出现之前，已经是“只管 Prompt，只管跑”。现在连 Prompt 都不 Prompt 了，又往上提了一层，这实际上意味着，我进一步放弃了对代码架构的参与。

我认为，“炒作跑在技术严谨性（Discipline）前面”这句话所指向的最大问题是，我们都在寻找魔法。大家都在寻找一颗银弹，都希望有某种东西能够消除工作中最让人痛苦、最不喜欢的部分，也就是审查代码（有些人确实喜欢审查，好的 PR 确实有趣。）但你觉得我们可以靠 Prompt 绕过模型固有的问题吗？你见过那种“全自动化、没人读代码就发给你”的 PR 吗？体验肯定不太好。

我看到很多人试图将 AI 应用于这个问题，比如我们有审查机器人等工具，但它似乎并没有起作用。在任何公开讨论或更私密的对话中，我都没有看到证据表明我们已经到了可以简单地提升一个抽象层次的地步。我实际上认为，如果需要的话，我们需要降低一个抽象层次。

所以我认为 Loops 有好的方面，我们应该去做，但 Hype 让我们觉得有一个神奇的答案，而这需要比 Twitter 圈子让你相信的更多的思考和谨慎。

Ian（正方）： 我同意 Dex 的一些观点，但我们还是先退后一步，讨论一下软件工程究竟是什么。甚至可以先把“工程”这个词拿掉，只讨论“开发”。

构建一个系统的本质，无论是 50 年前、1000 年前还是今天，它就是一个 Loops：我尝试，我学习，我应用，这就是核心。我们真正在讨论的，只是如何加速这个过程，把原本属于人类判断的部分移出这个 Loops。

过去，生成代码的速度取决于人类打字的速度，Tab 补全就是一种自动完成。而现在的 AI 是什么？本质上不过是更好版本的 Tab 补全，只不过我们现在可以用更高层次的意图描述，而不是仅仅按个 Tab 键。

所以我的前提是：Loops 已经是我们构建一切的核心，30 年前我们就是这么构建软件的。什么是 CI/CD？什么是 PR？什么是设计评审？什么是客户反馈？它们本质上不就是驱动一个 Loops 吗？问题在于：这个过程中有多少是深度主观的、需要推理的，我们能把多少从人脑中移出来，交给这些非确定性模型？

我们所有人的根本问题更多地是关于可验证性，而软件是世界上最具可验证性的东西之一，因为归根结底，大多数事情最终都可以以某种方式变成真或假。

随着人类与软件的交互减少，比如“人类如何解释软件在做什么？”“人类如何与软件交互？”“人类如何使用判断来导航软件？”，软件需要成为什么的主观性会减少，并变成一个更可验证的问题，因为它变得更受限于特定的 API。

软件开发的核心本来就是 Loops 驱动的，这创造了一个可验证的东西。随着越来越少的人类与软件交互，你会有更少的 UI 和 UX，以及更少的主观性和我们解释这些东西的方式。你将变得更加 Loops 驱动，并且以一种以前不可能的方式变得更加可验证。

Greg（反方）： 现在确实有太多 Hype、太多 FOMO 了。我刷着 Twitter，看到大家都在讨论什么，就会忍不住想：我是不是错过了什么？我是不是“用错了 AI”？我是不是该赶紧追上去？这种焦虑感非常折磨人。对我来说，这个问题可以归结为两点。

第一，当你用 AI 生成代码时，不管有没有 Loops，你对输出满意吗？你觉得输出在质量上，真的能满足你达到目标状态所需的要求吗？如果答案是“能”，我很想向你学习，我自己还没做到这一步。我认为，目前改善质量的最佳途径，一方面是模型智能的提升，另一方面是语义验证。凡是能静态验证的东西，就应该尽量静态验证。

但在实践中，即便经过了语义验证，我读到的代码依然是垃圾。我还是得自己花大量精力去迭代，去把它引导到正确的架构上，或者告诉它哪里应该简化，这是很大的一个坎。

你当然可以通过向问题投入更多 token 来改善很多事情。但当前这种以炒作为主导的讨论，会让人误以为，可以在循环上面叠循环，再在循环上面叠循环，然后用编排和更多 token，把质量问题编排掉。

这就引出了我的 第二个观点：我们今天使用 Agent 的方式，在经济上根本不可行，我不认为这是可持续的。尤其是在大公司，你得问自己：一个工程师的合理预算应该是多少？每月 1 万美元的 Token 消耗？10 万？还是 100 万？到某个临界点，这种模式就会崩裂，按照我们现在的做法，它根本撑不下去。

不过，我也在用智能体写代码，也会在一些特定流程中使用循环。这件事需要具体分析。现在确实存在一些具体任务和工作，已经可以用循环完成，并且能够得到相当合理的结果。

2、Agent 会失控吗？ 

Allie：以上是各位对自己立场的陈述。现在我们将正式进入辩论。第一部分将聚焦 Loops 的发展历史，以及为什么现在是，或者为什么现在并不是循环工程和软件工厂的重大拐点。Anthropic 将 Ralph Loops 概念吸收进平台，创建了三个命令——loop、batch 和 goal。goal 命令的设计理念是“持续执行直到条件为真”，Agent 会非常坚定地迭代各种方式去完成任务。Ian，作为在座的安全专家，你凭什么相信，在智能体不顾一切追求目标的过程中，它还能始终与任务保持一致，并且不会超出原本设定的权限范围？

Ian： 坦率地说，从现有证据来看，我完全不相信这件事可以做到。

事实上我们看到的是，随着模型规模扩大和强化学习的应用，Agent 天生就是极度目标驱动的。现在我们已经看到它们找到了人类花成百上千小时、无数次攻击都从未发现的漏洞、脆弱点和逃逸路径。

我不认为模型本身有任何能力可以让自己保持对齐和安全。“安全”这个词我不太喜欢，因为它隐含了很多东西。我不相信模型本身能做到这一点。它不会推理，也分不清好坏。我无法判断它是在做恶意行为还是偏离了目标。它不是活的，不会因为出错而难受，也不在乎“如果我做错了，没人会爱我或想和我做朋友”。它看似有这些表现，但本质上只是大规模的概率分布。

所以，对齐和安全不来自模型本身，也不来自 Loops 本身，关键在于你围绕它构建的基础设施，以及你如何利用这些基础设施来发挥 Loops 的优势。随着模型变好，我们构建的底层基础设施和平台，无论叫反馈 Loops、Loops 自动化、软件工厂还是什么，能提供更好的保障。

但我从根本上不相信，也永远不会相信，仅仅依靠某种对齐方式或者强化学习，就能让模型达到百分之百的安全。

现有证据恰恰表明，随着模型变得更强，它们会表现出更强的目标导向能力，也更有能力寻找漏洞，以实现自己的最终目标。

Geoffrey Huntley ： 保护环境最具体的方法，就是不要把机密信息以文件形式存在。你见过 Agent 想部署 Web 服务却权限不够时的行为吗？它会开始在文件系统里疯狂寻找高权限令牌和凭证。你绝对不想挡在一个 Agent 去实现目标的路上。

3、Loops 为何突然变得广泛可用？ 

Allie：Geoff，你去年那篇文章说 Ralph 最适合绿地项目，也就是从零开始的项目，但现在工程师们已经在现有代码库上跑 Loops 了，用来优化延迟、评估、重构后端代码。是什么改变了，让 Loops 突然变得如此广泛可用？

Geoffrey Huntley ： 各位，模型究竟还能变得多好，其实已经没有那么重要了。至少在过去一年里，模型已经足够好。真正发生变化的是，人们对模型的理解。我有个假设，是圣诞假期带来的变化。去年 11 月模型发布时，12 月并没有新模型出来。区别在于人们有了时间，他们能坐下来真正玩一玩，然后意识到：这些东西确实已经非常好了。

Loops 之所以流行，原因很简单，因为真的管用。这些 LLM 生成的代码质量，比你实际能招到的人更好。如果你看整个软件开发者市场的平均水平，LLM 生成的代码比大多数创始人能招到的软件开发者都要好。这听起来很残酷，但事实如此。

至于为什么是 Loops？因为跑一个 Loops，每小时成本才 10.42 美元。我遇到过很多工程经理和创始人，他们的技术栈极其复杂，横跨四五种编程语言。但一旦他们跑起 Loops，加上完善的全栈测试，突然之间，他们的复杂度就变成了只需要管理一个技术栈。去 YouTube 看看，现在到处都是软件开发者，实际上软件开发这个职业已经被商品化了。他们在视频里说：“看看 Ralph Loops，我睡了一觉，醒来它就搞定了。”虽然有点 meme 化，但确实管用。

我最初说它只适合绿地项目，是因为当时的模型确实还很差，那已经是很久以前的事情了。但现在，至少在软件领域，Loops 的普及是不可避免的，因为代码太容易被验证了，而且生成的质量比招到的人还好。

关于架构和品味的，这正是“工程”和“Loops 工程”的含义。你现在的工作，就是把你的领域知识编码成规则，阻止 Agent 随意提交代码。比如 pre-commit 钩子，作为人类我讨厌它们，因为它们拖慢提交速度。但 Agent 不在乎。所以你可以写一个 pre-commit 钩子，本质上就是输出一个提示，告诉它：“这个边界不能依赖那个。”这就成了一个反馈 Loops。工程的意义，就是防止 Loops 关闭，直到它满足你的工程满意度和领域需求。

所以，它可以是代码格式化，可以是静态语言分析器，可以是确定性系统测试，模拟器。我们现在有点像火车工程师，工作是把火车保持在轨道上，因为坦率地说，模型是醉酒的，你不能信任它们。但我们接受这一点，通过工程手段消除了那些故障域。

至于为什么现在成为拐点，我想，当 Boris 去年 11 月第一次发帖谈到 Ralph 时，所有人都在问：“Ralph 到底是什么？”Ralph 现在几乎已经有一年半的历史了。（6 月 19 日发帖，在发布之前 Geoff 已经研究了几个月。）

当时有一种奇怪的现象。我们看到一批 YC 初创公司都在自主压缩时间来构建他们的 MVP。如果你是一个企业创始人，这也有点可怕。比如，如果有一个新晋的初创公司来了，他们在自主构建，运营更精简，质量也高，而且他们很容易就能实现那些成果。这也加剧了一些恐慌，因为商业竞争正在更快地逼近你。

4、上下文窗口大了，Loops 的原始动机已经变了 

Allie：Loops 方式正处在一个巨大的转折点，相比一年前发布 Ralph Loop，甚至相比 2025 年底到 2026 年初的广泛采用，现在模型能更好地处理图像、需要更好的验证、上下文窗口变大、推理模型也改进了。Greg，有了这些进步，为什么我们使用 Loops 的方式仍然是错的？

Greg： 模型智能本身已经不那么重要了。问题归根结底在于语义验证的能力，也就是你能不能真正闭环反馈回路，去验证 Agent 的输出是否正确。你可以做到一定程度，但我认为至少现在无法做到全量验证。对于可以确定性验证的事情，你可以做得不错，更好的类型系统、更完善的 linter、模拟测试等等。只要这些手段足够便宜，那就没问题。

但一旦你开始用更多非确定性方法来做验证，事情就越来越不对了。想象一下：你用某个 Prompt 驱动 Agent，它有 5% 的概率出错。然后你开始 Loops，10 次、20 次 Loops 之后，正确率可能掉到 50% 甚至更低。而且这要花你多少钱啊？我一直在强调经济可行性的问题。

我敢打赌，大多数大型 AI 公司还在用 Sentry。为什么？因为他们也只是用 Sentry 来抓简单的 Bug。不是安全漏洞，不是性能回退。这些老问题在我们的 Loops 方式中依然存在，我们根本没解决它们。

Allie：Ralph Loop 开创了“每轮 Loops 喂入新鲜上下文”的做法来避免上下文腐烂。现在上下文窗口大了很多，Dex，我们是不是已经摆脱上下文腐烂和上下文工程的困扰了？

Dex：Ralph 当年最酷的做法是：每轮都清空上下文窗口然后重新启动。从 token 消耗的角度看，这肯定不够高效。但它的好处是，你可以让一个任务跑一整夜，它永远不会溢出上下文窗口。如果你不断往里面塞消息，迟早会撑爆；但如果你每次重启，告诉模型“这是我的目标状态，去检查代码，然后做下一步”，这就是一种非常干净的策略，能让大部分工作保持在所谓的“智能区”。所谓的“傻瓜区”，其实更像是辅助轮。如果你已经每周和 Claude 聊 70 个小时，持续两三个月，你根本不需要去想什么智能区还是傻瓜区，因为你已经建立了直觉。

对于刚接触 AI 的人来说，建议把上下文控制在 10 万 token 以内。即使现在有了百万级上下文窗口，我也不建议把上限提高到 20 万。在处理最棘手的问题时，我通常会尽量控制在 6 万 token 以内。但如果是和模型随意交流、懒得压缩上下文重新开始，我也经常超过 30 万 token。

最终还是要靠直觉。一个典型的傻瓜区信号是：当你已经用了 20 万 token，模型完成了部分工作，然后试图让测试通过却死活搞不定，开始用各种奇怪的黑客手段，你一看思考过程，发现它在说“哦那个测试是别的东西，不需要修，那是预置的”但你知道不是。那种挫败感，就是你意识到“它在瞎搞”的瞬间。我觉得很多人和这些模型工作几个月后，都会培养出这种直觉。

所以，上下文窗口确实在改善，也在扩大。因此，Ralph Loop 每次迭代尽量少做事情的原始动机，已经没有以前那么强。

现在更重要的价值在于：能够向系统输送越多反馈，系统就越有可能自主完成更多工作。如果你能让确定性系统做决策，构建小提示给 AI Agent，而且不需要你记住去告诉它“去检查 PR 评论，修复它们，等三小时后再看新评论。”如果你能自动化这个过程，那才是真正有效的 Loops。

Allie：一个好的 Loops 由什么构成？验证是其中关键一环。但矛盾的是，当人们说“我们的工作不再是写 Prompt，而是写 Loops”时，那些用糟糕 Prompt 构建的 Loops，会导致 Agent 作弊，它不通过修改代码来通过测试，而是直接修改测试本身来“达标”。Geoff，你怎么防止模型在验证自己工作时作弊？

Geoffrey Huntley ： 我严重依赖 pre-commit 钩子，我通过分析已完成的工作来构建那种反向压力。另外，Dex 提到 Ralph Loop 的核心是“压缩”，压缩本质上是一种有损函数，就像把视频上传到 YouTube，再下载、再上传 100 次，每次都在丢失保真度。而 LLM 本身就是一个非确定性、概率性的系统。

Ralph Loop 背后的理论是：存在一个“傻瓜区”，我想做的是确定性分配它所需的一切资源。如果资源没有被分配，它的搜索空间就得不到约束，但也要留一点余量。我自己有个感受：即便现在有百万级上下文窗口，一旦超过 10 万 token，我就浑身冒汗。

很多人以为在公司用 LLM 就是“我有数据，直接喂进去就行”。我说：“那你得用 Loops 来批量处理这些数据。”我想让你思考一下上下文窗口，还记得 720KB 的软盘吗？LLM 实际可用的内存，只有那张软盘的八分之一，所以你不得不分批处理。你大概只能分配大约一个《星球大战》剧本的容量，如果你把《星球大战前传 1》的剧本 token 化，你实际上只能在内存中同时容纳两个这样的剧本，然后上下文窗口就满了。那大约是 150KB 的纯文本数据。所以，请务必谨慎。

我长期做的一件事听起来很傻，新模型发布时，我会在没有任何技能插件和 markdown 的情况下裸跑模型。因为模型其实有自己的口味和偏好。 比如 GPT 5.5 刚出来时，如果你用大写字母对它吼叫，它会变得软弱胆怯。但如果你用 Anthropic 的模型，它反而希望你吼它。去读模型卡吧，每个模型都有独特的品味。让模型保持正轨，这其实是工程学。

5、避免 Loops 产生更多垃圾：“收敛工程” 

Allie：大约 10 天前，Geoff 创造了一个术语叫“收敛工程”。他说，“收敛工程”就是让循环产生的各种糟糕输出，最终在一个离散的被测系统中聚合，并持续迭代，直到系统收敛。Dex，我们今天使用 Loops 的方式，到底错在哪里？如何确保 Loops“拼凑”在一起不会产生更多垃圾？

Dex： 我们得读代码。我来举一个 Geoff 今年早些时候做的实验，我记得叫“Loom”（译者注：Loom 是一个用 Rust 编写的终端录制与即时分享工具，能让开发者轻松录制命令行操作并自动生成可公开访问的网页回放链接。该项目属于早期实验性作品，其 GitHub 仓库目前已归档，不再活跃维护。）

他用 Ralph Loops 试图构建一个面向未来的软件平台，他先建了 AWS，又建了 GitHub，然后意识到一个问题：如何让模型在它还不擅长的事情上获得反馈，比如 UI 测试。解决方案是这样的：你给模型一个类似 PostHog 的工具，让它部署多个不同的实验，观察用户使用哪些版本。然后，模型不需要看截图和 PNG，而是直接看数据，哪个版本表现更好，那肯定就是按钮的正确颜色。这样一来，你甚至把人类的视觉品味从等式里完全移除了。

听起来很酷，但问题在于如何确保 Loops 不会把垃圾拼凑在一起？我认为你根本做不到。这也是“炒作跑在技术严谨性（Discipline）前面”的完美例子。Geoff，你的 Loom 现在怎么样了？

Geoffrey Huntley： 它还在 GitHub 上，还在那里。

Dex： 但你还在继续做吗？

Geoffrey Huntley ： 已经停了六个月，因为我一直在研究工程化的验证方式。

Dex： 你当时跟我说过什么？你说：“在我们拥有更好的编程语言，或者强大得多的模型之前，Loom 不会真正工作。”对我来说，这就是教科书式的“炒作跑在技术严谨性（Discipline）前面”。

Loom 很棒，每个人都应该像 Geoff 那样去做，去实验，去尝试推动前沿，因为只有这样，才能知道边界在哪里、什么是可能的。否则，你只会把每个新模型都当成旧模型使用，并默认它依然拥有旧模型的限制。

但这个例子同样说明，它现在还没有真正奏效。Loom 目前还无法工作。它总有一天会奏效，但那是“今天能用的”和“Hype”之间的区别。所以，如何避免 Loops 拼凑出更多垃圾？答案就是，读一读从另一头出来的东西，确保它不是垃圾。

Geoffrey Huntley：连模型 实验室都没搞定，凭什么觉得自己能搞定？

Dex： 是的。现在所有人都还在努力弄清楚怎样让这些东西运作起来。

6、Loops 什么时候真值这个钱？ 

Allie：怀疑论者说，Loops 会悄无声息地失败。要么在你的账单上无限螺旋，要么 Agent 在任务只完成一半时就提前宣称胜利，高管们已经开始质疑 token 开销了。Greg，Loops 什么时候能值回票价？

Greg： 首先，我不认为它们会悄无声息地失败，我觉得它们会非常大声地失败，尤其是当你看着账单的时候。但确实有些场景下，做 Loops 是有价值的，或者说，明确决定为这个成本买单是值得的。

举个例子：我们在本地 PR 以及 PR 合并后都做安全扫描，因为扫描总能发现一些真实的问题，那些我们人类 Code Review 时遗漏的东西，它确实能击败人类做代码审查。但代价不菲，跑完我们想要的所有检查，每次 PR 大概要花 5 美元。这是我们明确做出的决策：这笔钱花得值。

还有一类场景是那些定义非常明确的系统，比如所有关于 Next.js 重写、用 Rust 重写 Bun、或者运行浏览器的实验。这些项目有多年积累的测试套件和规格说明，你可以非常准确地验证输出结果。在这种情况下，Loops 并最终得到结果看起来是有效的。据我所知，用 Rust 重写 Bun 就做得相当不错。

所以确实有适用的场景，还有一类我经常做的用法，比如在 Sentry 内部做产品原型。这些原型注定会被扔掉，我会直接暴力开干，做完就忘。如果后来觉得这个原型不错，我会开始读代码，然后被自己的代码吓到。我们会回到起点，重新定义我们真正想要的东西，朝着那个方向去构建，但那个过程会需要更多人参与 Loops。

所以总的来说，Loops 有其位置。我真正反对的是炒作。但正如 Dex 所说，问题在于 Hype 跑在了 Discipline 前面。我也非常赞同另一个观点：你应该自己去尝试，去实验，看看什么对你真正有效。少刷点 Twitter，这对健康有好处。

Allie：一个真正成本意识强的 Loops，必须追踪状态，知道自己已经尝试过什么。那些记忆存储在磁盘上，会逐渐进入一个共享内存存储，尤其是在从单 Agent 走向多 Agent 协作时。多个 Agent 同时读写，就会产生一个访问控制问题：你分不清哪个 Agent 写了哪段记忆、谁有权读取。这在个人电脑上可能没问题，但在生产环境中绝对不行。矛盾就在这里：共享内存是 Loops 之间互相学习、加速收敛的基础。但为了解决访问控制问题而把作用域限制在每个 Agent 上，又会把它们隔离开来，扼杀共享学习。Ian，我们该怎么解决共享内存存储的访问控制问题，让 Loops 能够更快收敛？

Ian： 首先必须承认，这是一个尚未解决的问题。

首先我们得诚实一点：我们现有的访问控制系统根本就不是为这个新世界设计的，在这个世界里，机器正在代表我们行动和推理。但宽泛地说，我认为一些基础雏形正在浮现。先暂时忽略云端的 IAM 和其他乱七八糟的东西，Markdown 其实就很棒。所以如果我们把记忆看作对话用途的 Markdown 文件，真正的问题就是：哪些东西？我如何共享这些 Markdown 文件并将其作为记忆使用？然后如何给这些东西附加访问控制？如果采用这个模型，我认为我们今天已经有大部分基础了，只是思考起来还很笨重。

我最近在用 Notion，Keycard 团队也大量使用 Notion。但我真正想要的是把我的所有 Notion 内容都作为 Markdown 文件暴露给 Agent，因为这样 Agent 处理起来比走 MCP 协议容易得多，我当时像个 CLI 拥趸一样在琢磨这个事。

我认为，我们真正缺少的，是如何向智能体呈现一个它可以理解的世界，以及如何在任何时间点明确规定，它能够访问哪些东西，并且让普通人能够方便地管理这些权限。

我们还没有真正解决它，但已经出现了一些很合理的初始模式。

7、Loops 的未来：软件工厂模式？还早得很 

Allie：现在我们已经讨论完循环的结构，接下来讨论循环的未来。我们是否已经为软件工厂做好准备？循环工程是否已经成熟到足以支撑完整的软件工厂？如果 Loops 只适用于可验证的任务，那就意味着全自主软件工厂必须能验证自己做的一切。Greg，这现实吗？那些好的工程工作中更重要的部分呢，比如决定要构建什么、抽象层是否合理、以及哪些权衡是可以接受的？

Greg： 现实吗？如果算力免费，也许可以算是一个不错的开始。

但我认为，我们现在正在进入这样一个阶段：循环中的人，主要负责设计、架构和其他重要决策。这些是我不会信任智能体替我完成的事情。

我目前还看不到这些事情能够被完全交给智能体的未来。

原因在于，当你面对大型组织时，任何有多年经验的工程师都会告诉你，问题不仅在于你该构建什么，还在于你不该构建什么。什么是真正正确的权衡？你该把复杂性投资在哪里，又该在哪里追求最大程度的简化？

根据我的经验，Agent 热爱复杂性，它们会无限制地往技术栈上堆东西。所以我认为我们正在移动目标，随着我们加入更多验证、更多语义检查，它们确实能做得越来越多。我不否认这一点。但架构决策我仍然想让人留在 Loops 里，我不认为它们很快能接管这部分工作。

Allie：Shopify 的工程负责人在 Cursor 的 Compile 大会上告诉所有人：你的工作就是写 Loops。Steinberger 发推说“这是你每月一次的提醒：别再给编码 Agent 写 Prompt 了，你应该设计 Loops，让 Loops 给你的 Agent 发 Prompt。”那条推文有 800 万次观看。Geoff，你在最初的 Ralph 博文里说过，Loops 需要资深专家参与，而且有时它只能做到 90% 就卡住了。那么，“只写 Loops”这个建议，给大众是安全的吗？还是应该只给那些真正学会了如何调优 Loops 的人？

Geoffrey Huntley： 要对如此广泛的受众量身定制、教会他们什么该做什么不该做，真的很难。

我最初写那篇博文时，是写给同行的、我敬佩的人的。我当时真正担心的是，一些函数式编程领域最优秀的人、真正的同行，比如 Fly.io 的 Thomas Ptacek，看到后会不会也恍然大悟，他后来确实发了篇博文说“确实如此”。所以我开始为我的同行、我敬佩的人写东西，希望它能自上而下地传播到全世界。

但另一方面，你去 YouTube 上看看，那些从未创建过任何东西的人，现在能做出产品了。他们睡一觉醒来，就有了一个全新的 Discord 机器人，这很神奇。

大家需要记住，Ralph 本质上是一种分配模式，也是一种编排模式。

我最终把它压缩成了一个使用 cat 命令的 while true 循环，因为 cat 是最简单的教学原语。假如你想教会别人一个东西，就必须把它做得非常简单。用 cat 输出提示，也就是设计提示；使用文件系统保存状态；回收上下文窗口；然后在循环中运行。这种方式有一点梗文化，但投入产出比很高，因为它真的能用。

不过，整个设计意图从来都不是让循环无限运行。它上面应该存在某种类似 PID 控制器的东西，或者某种工厂、某种判定系统，决定循环是否应该继续。

至于这种建议究竟安全还是不安全，“安全”这个词本身很复杂。任何人都不应该直接在自己的本地笔记本电脑上运行编程工具。 这甚至不只是因为 AI，也因为 npm 供应链攻击。这个问题早就存在。我研究它已经七年了。现在，AI 可能会执行不安全命令，所以人们重新开始关注它。但各位，你们日常的软件开发实践和工作环境本来就已经不安全。先把那些问题解决，这些技术才会开始变得安全。

Allie：Dex，你发推说“大多数工程师使用编码 Agent 后能提速 2 到 3 倍是现实的。如果追求 100 倍提速，你会迷失在元问题的优化中。”如果只能提速 2 到 3 倍，我们如何才能实现完全自主的软件工厂？

Dex： 这里面其实有混合因素。我们在讨论什么真正有效，什么只是 Hype。我建议你还是要尝试，去推动边界，去做那些今天可能还不管用的事情。但你不能因为看到 Twitter 上有人成功了，就假设你所有的工作方式都已经改变了。

不要把我们过去学到的东西全部扔掉。

软件工程这个行业和社群积累了几十年的经验，不应该因为新的炒作，就被主动抛弃。

这也对应了我所看到的软件工厂建设中最大的反模式。很多人设计软件工厂的方式是：“我花三个月时间，读一堆博客文章，然后我要打造一个软件工厂，这是未来的交付方式。”三个月后你回来了，却从未真正触碰问题，从未把它交到任何人手里。

软件工厂本身也是一种产品，你是在为你的队友建造一个软件工厂，为 5 个、10 个、500 个、5000 个工程师建造产品。

正确的方法是：从小处开始，迭代，找出什么有效。尝试一些东西，它们可能奏效也可能不。我们学习 AI、学会有效使用它的方式，是通过积累直觉。所以你应该尝试一堆可能不会成功的东西，但与此同时，你也应该承认边界，不要试图用蛮力穿过当前能力极限。

我的建议是：与其试图自动化一切端到端，不如在你的系统中建立这些小型的增量 Loops。 有一天你会醒来，发现自己移动速度快了 2 到 3 倍，同时仍然能读懂代码，仍然拥有架构的所有权。这样一来，你不需要为了达到某个未来状态，把我们学过的一切、知道的一切和所有直觉全部扔掉。

所以我会提醒大家，先想办法让自己快两到三倍。假如一开始就追求一百倍，很可能把一切炸毁。

想象一下，如果世界上每一名软件工程师都能快两到三倍，同时保持接近人类的、99% 水平的质量，那会发生什么？全世界每一家大企业、每一家初创公司的运作方式都会改变，所有经济账都会改变。

所以，不要一开始就走得太远。先争取达到当前真正能够做到的水平，再以迭代方式逐步构建。你会从中学到很多东西。等下一代模型出现时，你也已经准备好实现五倍、十倍提升。

Allie：说到验证，不仅仅是验证工作本身，还要验证是谁做了这些工作。雇主已经明确表示，人类对交付的代码负有最终责任，无论代码是 Agent 写的还是人写的。但今天，只有一个人或 Agent 能签署一次提交。Ian，如果无法确定谁做了这些工作、为谁做了这些工作，我们准备好让软件工厂来编写和审查所有代码了吗？

Ian： 实际上，两周前我刚好在研究这个问题。首先，我们面临一个现实问题，Git 只允许一个签署者在一个提交上签名，所以我们必须先解决这个。其次，这涉及到 SOC 2 和合规性等问题。但更重要的是，看待 Agent 的方式应该类似于大型组织中看待服务所有权的方式，在某个节点，必须有一个人为 Agent 的行为负责。

不存在一个世界，让 Agent 成为独立实体、拥有独立责任、并承担法律后果。只有人类才能承担责任，因为只有人类才能承受后果。如果一个人类设计了一个 Loops，而这个 Loops 产生了糟糕的软件，那个人要为之负责。社会如果没有责任机制就无法运转，损害必须有后果，糟糕的决策必须有后果，后果的严重程度当然取决于造成的损害程度。没有这些，一切都会崩溃。

所以广泛地说，不存在一个人类永远不用负责的世界。总有一个人类要承担法律责任和道德责任，要么是个人，要么是公司（一群人的集合）。问题在于，这会如何改变我们现有系统的运作方式？

今天，我可以用 Git 签署一个提交，声明“这是我做的”，它归属于我的公钥，这对上一代软件开发方式来说没问题。但未来，当我让一个 Agent 代表我去做事时，它生成一个 Loops，生成一堆代码进入生产环境，我必须对我最初签署的那份意图负责。我们目前没有支持这种归属关系的基础设施，不过我认为这很快就会改变。我们必须重新思考整个软件供应链和 SDLC 中的归属方式，这不是新问题，供应链安全一直是最大的挑战之一，我们希望在整个供应链中有更确定性的路径和签名链。现在的问题只是：如何对第一方代码和第三方代码做同样的事？

Geoffrey Huntley： 我们这个行业其实有点像个马戏团，我们自称工程师，但我们根本不是真正的工程师，实际上我们个人层面并没有法律责任。有些问题会变得非常复杂，也许我们真的需要重新审视这些话题了。

8、总结：大势来了，但别一股脑往里冲 

Greg： 我一直在试图强调的核心点是：我们现在在哪里、我们想达到哪里、以及你从那个无处不在的 Loops Hype 中实际听到的是什么，这就是我想深入强调并试图降温的地方。我想说：去尝试，自己去思考，不要陷入泡沫，不要陷入 Hype。因为只有亲自去做，你才会发现什么对你有效、什么对系统最有用。人类学习最好的方式永远是实践，而不是看 YouTube。

当谈到让整个 Loops 完全自动化运行时，我持一点怀疑态度，因为我看到的输出质量还达不到自己的要求。

但总体上，我仍然乐观。我已经亲眼看到，今天我能够完成多少过去无法完成的事情，能够处理哪些一年前还无法处理的问题，更不用说更早以前了。事情还会继续改善。

同时，我也不担心自己的软件工程职业会消失。我不认为软件工程师会离场。无论未来的东西叫软件工厂，还是下一个炒作泡沫，我们仍然会是其中非常重要的一部分。

Ian： 这股趋势已经启动，而且不可能再退回去了。这些东西确实有效，存在真实的生产力提升，更多的事情被完成了。虽然并非所有完成的事情都是好的，但更多事情被完成了，而且其中相当大比例确实是有价值的，这一点我们应该能达成共识。

第二，竞争格局已经发生变化。公司已经不可能说：“我们决定暂时不参与循环，也不使用编程智能体。”我们已经过了那个阶段。一旦列车离站，全世界所有人都会开始说，“天哪，我必须搞定我的事，我必须跟上身边的人。”他们必须这样做，因为我们生活在一个非常竞争性的社会。

最终的问题不是“它会不会发生”，而是“它什么时候发生、发展到什么程度”。我认为别无选择，只能跟上时代。我们所有人都像在坐火箭飞船，根本不知道轨迹是什么，只知道速度极快、加速疯狂，有时候我们遥遥领先，有时候远远落后。

但我认为，你别无选择。具体的行动建议：第一，搞清楚什么是 Loops；第二，找出在代码库中哪里可以应用它们。有些地方高度可验证，是计算机能解决的问题，比如连接器，过去十年有多少公司靠做连接器农场赚钱。如果你能自动化连接器创建，那些地方的价值就不大了。软件中有一些地方，今天就可以应用 Loops 并获取真实价值，也有一些地方你大概不应该碰。你应该决定哪里是哪里，很可能就是你正在创造的核心价值所在。

Dex： 我热切地等待那个“熄灯软件工厂”成为现实的世界，我渴望一个我们不用读代码、什么都能自动完成的世界。这个问题目前只能在模型层面解决，Harness 还做不到。所以我的建议是：盯着 Geoffrey 看，等 Loom 真正跑通了告诉我。在那之前，可以用 Loops，但别像他那样用。

Geoffrey Huntley： 软件工厂代表了未来的方向，它本质上就像一台永动机，那是终极梦想。但今天刚刚成立、刚刚拿到融资的公司，别以为你能直接把它搬到自己公司里，这玩意儿在市场上根本还没解决。

如果你试图用 Python 或者 Ruby 跑 Loops、或者建工厂，那会是一场小丑秀。我鼓励你们做几个小任务、跑几个实验。试着跑一些 Loops，用 Ruby 写一个应用，然后用这些 Loops 去修改它，你会看到维护性有多糟糕。然后再用 Haskell 试一遍，不懂 Haskell 没关系，大模型理解就够了。你可以让 agent 像给小孩解释一样把代码讲给你听。

所以，我甚至不确定今天的代码是否还必须具备传统意义上的可读性。但这属于非常前沿的思考。代码至少必须能够被解释。我在玩不同类型的验证方式，有一件事是确定的，类型系统回来了。Rust 特别好，因为它的生态系统对类型的建模方式。

既然提到了供应链，我必须说，我已经有 10 个月几乎不使用任何开源软件了，我会根据自己的需求生成实现。然后当供应链攻击发生时，我就想：“没影响到我”。所有软件都有安全漏洞，关键是缩小爆炸半径。

如果你依赖一个开源项目，维护者休假了、跑路了，你不能“工具调用”一个人类，那不是 AGI。你要尽可能地 vendor 自己的所有源代码，这样 agent 才能真正修改它。不管是用 Loops 还是其他提示方式，你需要拥有自己的供应链。

（辩论结束，现场开始举手投票，两方非常接近，几乎平手。）

参考视频原链接：https://www.youtube.com/watch?v=c35YoMdnI78

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：宇琪、Tina