真正的分歧不在于“Loops好不好”而在于“今天能不能用”。“我已经两年半没手写代码了。”Ralph Loop 的创造者 Geoffrey Huntley 在辩论开场时这么说。另一边Sentry 的 Greg 回应“我在实践中读到的代码依然是垃圾。”最近关于 Loops 的炒作铺天盖地——社交媒体上人人都在讨论怎么用循环把开发自动化、什么时候能建起“熄灯软件工厂”。但这个热潮到底靠不靠谱针对这些问题在 AIE Worlds 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 对内容进行了整理。太长不看版QLoops 到底靠不靠谱Geoffrey正方Loops 已经不可避免了。 两年前我就发现所有工程师都在循环里写 Prompt既然这东西可以编程Loops 就自然发生了。我自己已经两年半没手写代码了。不是模型变强了是大家终于有时间搞明白了——每小时成本才 10 美元生成质量比你能招到的人还好。当然它不是银弹但大势已经来了你跟也得跟不跟也得跟。Dex反方问题不在于 Loops 好不好而是 Hype 已经跑到了 Discipline 前面。我没有看到证据表明我们已经到了可以简单地提升一个抽象层次的地步。Greg反方用 AI 生成代码不管有没有 Loops你对输出满意吗 我不满意我读到的依然是垃圾。投入更多 token 可以改善一些事但别幻想在循环上叠循环就能把质量问题编排掉。Q让 Agent 在 Loop 里疯狂迭代安全性有保障吗会偏离目标吗安全专家 Ian我完全不相信这件事可以做到。从现有证据来看我不相信模型本身有能力保持对齐和安全。Agent 天生极度目标驱动已经能发现人类从未找到的漏洞。你只能通过基础设施权限控制、验证手段、pre-commit 钩子来约束它绝不能指望模型自己有“道德感”。Geoffrey 正方补刀 我见过 Agent 没权限部署时开始在文件系统里疯狂翻找高权限令牌——你绝对不想挡在它和它的目标之间。QRalph 最适合绿地项目也就是从零开始的项目是什么改变了让 Loops 突然变得如此广泛可用Geoffrey Huntley正方各位模型究竟还能变得多好其实已经没有那么重要了。至少在过去一年里模型已经足够好。我最初说它只适合绿地项目是因为当时的模型确实还很差那已经是很久以前的事情了。Ralph 现在几乎已经有一年半的历史了。QRalph Loop 最初是为 20 万上下文设计的每轮清空重启现在窗口都这么大了还有必要吗Dex反方必要性降低了。从 token 消耗角度看这肯定不够高效。上下文窗口确实在改善、在扩大所以 Ralph Loop 每次迭代尽量少做事情的原始动机已经没有以前那么强。但现在更有价值的是你能自动化地往系统里塞越多反馈系统就越可能自主完成更多工作。比如把“去检查 PR 评论、修复、三小时后再看”这种需要人记住去触发的事全部自动化——那才是 Loops 真正起作用的地方。QGeoffrey Huntley 最近提出了“收敛工程”——让 Loop 不断迭代直到输出收敛。那我们怎么保证最终输出的不是垃圾Dex反方你根本做不到。听起来很酷但问题在于如何确保 Loops 不会把垃圾拼凑在一起我认为你根本做不到。这也是“炒作跑在技术严谨性Discipline前面”的完美例子。怎么避免垃圾唯一的方法就是老老实实读代码。你得亲自看从另一端出来的东西长什么样确保它不是垃圾。没有捷径没有银弹。QLoops 的 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 之前还有云基础设施。你甚至可以说云基础设施先发展了七八年才出现 KubernetesKubernetes 又发展了七八年才变成普通人真正可以使用的东西。而 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 为何突然变得广泛可用AllieGeoff你去年那篇文章说 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 的原始动机已经变了AllieLoops 方式正处在一个巨大的转折点相比一年前发布 Ralph Loop甚至相比 2025 年底到 2026 年初的广泛采用现在模型能更好地处理图像、需要更好的验证、上下文窗口变大、推理模型也改进了。Greg有了这些进步为什么我们使用 Loops 的方式仍然是错的Greg模型智能本身已经不那么重要了。问题归根结底在于语义验证的能力也就是你能不能真正闭环反馈回路去验证 Agent 的输出是否正确。你可以做到一定程度但我认为至少现在无法做到全量验证。对于可以确定性验证的事情你可以做得不错更好的类型系统、更完善的 linter、模拟测试等等。只要这些手段足够便宜那就没问题。但一旦你开始用更多非确定性方法来做验证事情就越来越不对了。想象一下你用某个 Prompt 驱动 Agent它有 5% 的概率出错。然后你开始 Loops10 次、20 次 Loops 之后正确率可能掉到 50% 甚至更低。而且这要花你多少钱啊我一直在强调经济可行性的问题。我敢打赌大多数大型 AI 公司还在用 Sentry。为什么因为他们也只是用 Sentry 来抓简单的 Bug。不是安全漏洞不是性能回退。这些老问题在我们的 Loops 方式中依然存在我们根本没解决它们。AllieRalph Loop 开创了“每轮 Loops 喂入新鲜上下文”的做法来避免上下文腐烂。现在上下文窗口大了很多Dex我们是不是已经摆脱上下文腐烂和上下文工程的困扰了DexRalph 当年最酷的做法是每轮都清空上下文窗口然后重新启动。从 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 开销了。GregLoops 什么时候能值回票价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 文件并将其作为记忆使用然后如何给这些东西附加访问控制如果采用这个模型我认为我们今天已经有大部分基础了只是思考起来还很笨重。我最近在用 NotionKeycard 团队也大量使用 Notion。但我真正想要的是把我的所有 Notion 内容都作为 Markdown 文件暴露给 Agent因为这样 Agent 处理起来比走 MCP 协议容易得多我当时像个 CLI 拥趸一样在琢磨这个事。我认为我们真正缺少的是如何向智能体呈现一个它可以理解的世界以及如何在任何时间点明确规定它能够访问哪些东西并且让普通人能够方便地管理这些权限。我们还没有真正解决它但已经出现了一些很合理的初始模式。7、Loops 的未来软件工厂模式还早得很Allie现在我们已经讨论完循环的结构接下来讨论循环的未来。我们是否已经为软件工厂做好准备循环工程是否已经成熟到足以支撑完整的软件工厂如果 Loops 只适用于可验证的任务那就意味着全自主软件工厂必须能验证自己做的一切。Greg这现实吗那些好的工程工作中更重要的部分呢比如决定要构建什么、抽象层是否合理、以及哪些权衡是可以接受的Greg现实吗如果算力免费也许可以算是一个不错的开始。但我认为我们现在正在进入这样一个阶段循环中的人主要负责设计、架构和其他重要决策。这些是我不会信任智能体替我完成的事情。我目前还看不到这些事情能够被完全交给智能体的未来。原因在于当你面对大型组织时任何有多年经验的工程师都会告诉你问题不仅在于你该构建什么还在于你不该构建什么。什么是真正正确的权衡你该把复杂性投资在哪里又该在哪里追求最大程度的简化根据我的经验Agent 热爱复杂性它们会无限制地往技术栈上堆东西。所以我认为我们正在移动目标随着我们加入更多验证、更多语义检查它们确实能做得越来越多。我不否认这一点。但架构决策我仍然想让人留在 Loops 里我不认为它们很快能接管这部分工作。AllieShopify 的工程负责人在 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 可能会执行不安全命令所以人们重新开始关注它。但各位你们日常的软件开发实践和工作环境本来就已经不安全。先把那些问题解决这些技术才会开始变得安全。AllieDex你发推说“大多数工程师使用编码 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 还是其他提示方式你需要拥有自己的供应链。原文链接“围攻” Ralph Loop 之父一场关于 Loops 的激辩代码照样垃圾只会失败得更加难看-36氪
)
