从Prompt到Loop,软件工程正在被重写

Peter Steinberger是一个奥地利开发者，PSPDFKit的创始人，后来做了OpenClaw。他现在的日常工作状态是这样的：同时跑4到10个agent，每个agent负责一块独立的代码任务，它们各自在自己的git分支里工作，互不干扰。每个月GitHub上能看到6600次commit。

6600次。按每月22个工作日算，每天300次提交。按8小时工作制算，每小时37次。差不多每两分钟一次commit。一个人的产出量，相当于一个15到20人的工程团队。

这个数字不是自己说的，是GitHub上可以查到的公开提交记录。打开他的GitHub profile，contribution graph上那片密密麻麻的绿色方块，比大多数创业团队的整个工程部门加起来还浓。他不是每天坐在电脑前敲18个小时的键盘。他的大部分工作时间花在了设计agent的工作流程、审查agent的产出、以及在agent需要判断时做决策。代码本身是agent写的。

吴恩达注意到了这件事。6月26日，他在DeepLearning.AI的The Batch newsletter里专门讨论了这种新的开发模式。那条推文被转发超过713次，获得3547个赞，20万次浏览。吴恩达在文章里提出了一个框架，叫"三层产品开发循环"：最内层是agent自主迭代的循环（agent loop），agent在这个循环里自己写代码、跑测试、修bug，一轮一轮地转，不需要人介入。中间层是人类审查和反馈的循环（human-in-the-loop），agent完成一个阶段性成果后，人来看一眼，给方向性的反馈，agent再继续。最外层是产品发布和用户反馈的循环（product loop），做出来的东西推给用户，收集反馈，下一轮迭代。三层嵌套，形成一个持续运转的系统。

同期被吴恩达引用的还有一个人，Boris Cherny，Anthropic的Claude Code负责人。Cherny说了一句后来被广泛引用的话："我不再prompt Claude了。我写循环，循环去prompt Claude，然后自己决定做什么。我的工作就是写循环。"

这句话的信息量很大。它不是说prompt不重要了，而是说prompt已经不是人直接写的了。人设计的是一个系统（循环），这个系统负责生成prompt、调用模型、检查结果、决定下一步。人从"prompt的作者"变成了"产生prompt的系统的架构师"。

这三个人各自从不同的位置看到了同一件事。Steinberger是实践者，用真实的commit数量证明这套方法能跑通。吴恩达是理论化的人，把它抽象成了三层循环框架。Cherny是工具的制造者，他直接说出了工作方式的根本变化。

这个变化有一个名字，叫Loop Engineering。

从手动挡到自动驾驶

两年前的AI辅助编程是这样的：打开ChatGPT或Copilot，写一段prompt，描述想要什么代码，等模型生成，然后人工检查，手动粘贴到IDE里，跑一下测试，不对再回去改prompt。整个过程中，人是主循环的驱动者。每一步都需要人来判断、操作、推进。模型是一个工具，像一把锤子，拿起来用一下，放下来想一下，再拿起来再用。

Boris Cherny现在的工作方式完全不同。

2025年11月，他卸载了自己的IDE。不是换了一个更好的IDE，是彻底卸载了。原因很简单，他发现自己已经整整一个月没有打开过了。所有的代码编辑都是agent在做，他不需要亲自看着某个文件的某一行在屏幕上闪烁。他的日常工具变成了终端和手机。

白天，他在本地终端里同时开5到10个Claude Code的交互session。每个session承担不同的角色：一个负责写新功能，一个负责跑测试，一个负责debug，一个负责重构，一个负责更新文档。它们像流水线上的不同工位，各自干各自的活。人在工位之间走来走去，看一下进度，偶尔给个方向性的指令，大部分时间让它们自己转。

晚上更夸张。他在Anthropic的云端跑Routines（持续运行的agent任务），即使笔记本合上了，这些agent依然在工作。几千个sub-agent分散在GitHub、Twitter、Slack等平台上巡逻，替他找产品创意、收集用户反馈、监控竞品动态、扫描技术社区的讨论。到第二天早上，他打开手机，看一眼通知，agent需要他做决定的时候会推送过来。他从手机上提交PR，审批合并，整个过程不需要打开电脑。

他还做了一个细节优化：自定义slash命令。把重复性高的操作流程打包成一条命令。比如/commit-push-pr，一次执行完"提交代码、推送到远端、创建Pull Request"这三步。这种小动作的打包看起来不起眼，但一天执行几十次上百次，省下来的认知负担和时间成本很可观。每次少想三秒，一天省出好几分钟的纯思考时间。

Photo by Homa Appliances on Unsplash

这个变化的本质是什么？

类比一下：手工作坊和流水线的区别。手工匠人一锤一锤打铁，每一锤的力度、角度、位置都靠经验判断。流水线工程师不亲自打铁，他设计工序、设定参数、配置夹具、安排质检站。他的工作是"设计一个能持续产出合格零件的系统"。

两年前的prompt engineering是手工匠人模式。现在的loop engineering是流水线工程师模式。人从"执行者"变成了"系统设计者"。不是"我来写代码"，而是"我来设计一个能持续产出代码的系统"。

产出效率的差距是数量级的。但流水线也有流水线的问题：成本结构完全不同，故障模式完全不同，对操作者的能力要求也完全不同。这些后面会讲到。

Loop的五个零件加一个记忆

一个Loop到底由什么组成？Addy Osmani（Google Chrome工程总监）在6月7日的一篇博文里做了详细的拆解。他把Loop分成了五个核心组件和一个额外的"第六件"。

拆开来看，这五个零件在目前最主流的两个coding agent（OpenAI的Codex和Anthropic的Claude Code）里，实现方式各有不同，但功能高度趋同。

第一个零件：Automation（自动化触发器）。

Codex的做法是提供一个Automations Tab。在界面上选一个项目，写一段prompt描述任务，设定触发频率（每小时跑一次、每天跑一次、或者每次git push自动触发），选择沙箱环境，agent的执行结果会进入一个叫Triage的收件箱等待人工审查。整个设置过程是点点点的GUI操作。

Claude Code的做法更接近Unix哲学：用cron定时任务做周期触发，用/loop命令做间隔循环，用hooks机制做事件触发（比如git push之后自动跑lint检查），也可以直接嵌入GitHub Actions的工作流里。全程命令行，没有图形界面。

功能一样，风格不同。Codex偏GUI，Claude Code偏CLI。但底层逻辑完全一致：定义触发条件，agent自动执行，结果等人审查。

第二个零件：Worktree（工作树隔离）。

这解决的是一个很实际的问题：多个agent同时在同一个代码仓库里干活，如果它们都在main分支上改文件，会互相冲突。你的agent刚改完一个文件，另一个agent把它覆盖了。或者两个agent同时改同一个函数的不同部分，合并时冲突。

Codex的处理方式是每个thread自动创建独立的worktree，天然隔离。开发者不需要操心这个事。Claude Code需要显式指定git worktree或者用--worktree参数，sub-agent也会自动隔离到独立的分支里。

这个设计直接对应制造业里的"工位隔离"。每个工人有自己的工作台，零件在自己的工位上加工完成后再汇入总装线。不隔离就会出现一个agent把另一个agent改好的文件覆盖掉的情况，轻则浪费token重跑，重则引入难以追踪的bug。

Photo by Chris Ried on Unsplash

第三个零件：Skills（技能文件）。

Codex使用一种叫Agent Skills的机制，本质上是一系列SKILL.md文件，里面写清楚了特定任务的操作步骤、注意事项、约束条件。可以用$name主动调用，也可以让agent根据任务描述自动匹配合适的skill。比如一个skill写的是"部署到生产环境的步骤"，当agent接到一个涉及部署的任务时，它会自动加载这个skill，按照里面的步骤执行。

Claude Code对应的是CLAUDE.md项目知识文件，同样的思路，把项目特有的知识写在文件里，agent每次启动时加载。

这个东西的意义在于：模型本身是通用的，但项目是特殊的。代码库用什么框架、遵循什么编码规范、有哪些特殊的部署流程、测试怎么跑、环境变量怎么配，模型不知道。Skill文件就是把这些项目特异性知识注入给agent，让它在这个特定项目里表现得像一个有经验的团队成员，而不是一个刚来的实习生。

第四个零件：Plugins/Connectors（外部连接器）。

两者都能接GitHub（读PR、提Issue、查commit历史）、Linear（任务管理、看板更新）、Slack（接收通知、发送消息）等外部服务。这部分是把agent的触手从代码仓库延伸到整个开发工具链，让它不只是能写代码，还能参与到工程团队的协作流程里。

第五个零件：Sub-agents（子代理）。

这是最关键的设计之一。一个agent写了代码，如果让同一个agent来review自己写的代码，结果可想而知：它倾向于合理化自己的决策，忽略自己的错误。这就是自我审查偏差，后面在技术陷阱那节会详细讲。

解决方案是分角色。写代码的agent和审代码的agent是不同的session，不共享上下文。审查agent只能看到代码本身和项目规范，看不到写代码agent的思考过程，所以能更客观地评估代码质量。Codex和Claude Code都支持spawn sub-agent来实现这种角色分离。

第六件：Memory（外部记忆）。

Osmani特别强调了这个"第六件"，因为它解决的是一个容易被忽略但极其关键的问题。agent的context window是临时的，session结束就清空了。它不记得上一次session做了什么决定、遇到了什么坑、进度到了哪一步。

外部记忆就是持久化在文件系统里的状态存储。形式可以很简单：一个markdown文件、一个Linear看板、甚至就是项目根目录下的TODO.md。agent在一个session里做了什么决定、遇到了什么问题、下一步计划做什么，都写进这个文件。下一个session启动时读取这个文件，就能接上之前的进度。像一个团队的交接文档，上一班的人写好了，下一班的人读完就知道从哪里继续。

Osmani的原话是："agent会忘，repo不会忘。"

这六件东西放在一起，构成了一个完整的Loop。Osmani观察到一个有意思的趋势：一年前想搭一个这样的Loop，需要自己写一堆bash脚本、配置webhook、搞CI pipeline，门槛很高。现在这五个零件已经内置在产品里了。你不需要争论用Codex还是Claude Code，因为它们的架构已经趋同。设计一个Loop的逻辑是通用的，底层换哪个引擎都能跑。

实战命令

说具体的。Loop在实际使用中长什么样？

两个核心命令：/goal和/loop。

/goal设定一个高层目标，让agent自主工作直到完成。语法很直白：

/goal "迁移用户认证模块到新API，确保所有测试通过且覆盖率保持80%以上"

设完这个goal之后，agent立即开始工作。它会自己分解任务，先读现有的认证模块代码，理解当前的实现方式，然后读新API的文档，设计迁移方案，一个文件一个文件地改代码，跑测试，看哪些用例失败了，修bug，再跑测试。整个过程不需要后续的prompt。人可以去喝咖啡，也可以开另一个session干别的事。

这里有一个重要的设计细节：完成度评估不是agent自己判断自己。Claude Code用一个独立的小模型（Haiku级别）来做"是否达成目标"的判断。这个评估模型看不到agent的推理过程，只看到当前代码状态和目标描述，所以能更客观。这直接解决了后面会讲到的自我审查偏差问题。如果让agent自己评估自己是否完成了任务，它大概率会说"完成了"，因为它能看到自己做了多少工作，倾向于高估自己的成果。独立评估模型没有这个偏见。

运行过程中可以看状态：已经跑了多久（elapsed time）、经过了多少轮迭代（turns）、花了多少token（token spend）。如果发现方向不对，随时可以用/goal clear中止。

Photo by Ilya Pavlov on Unsplash

/loop是周期性执行的命令。语法：

/loop 10m "检查部署是否完成，报告任何失败项"

每10分钟执行一次，agent检查部署状态，发现问题就报告。也可以不指定时间间隔，让agent自己判断什么时候需要重新检查。

适合的场景很明确：CI/CD监控（构建是否通过）、部署状态检查（服务是否正常启动）、定期生成状态报告、PR babysitting（代码合并后的集成测试是否通过）。

Boris Cherny自己的实际工作配置比这些基础命令复杂得多。本地终端5个Claude Code session，各自负责不同的角色（coding/testing/debugging/refactoring/docs）。云端再开5到10个session处理更耗时的任务。手机接收通知，agent需要人类输入时推送过来。

他的一个关键习惯是Plan Mode先行。在Claude Code里按两次Shift+Tab就进入Plan Mode，任何复杂任务先让agent想清楚执行计划：打算改哪些文件、用什么方案、预计会遇到什么问题。人审完计划再让它动手。这比直接让agent开干要可靠得多。因为在计划阶段纠正方向的成本很低（改一段文字），在执行阶段纠正方向的成本很高（可能已经改了几十个文件，回滚起来很痛苦）。

他还用自定义slash命令把重复流程打包。/commit-push-pr一条命令完成三步操作。这种封装的意义不只是省时间，更是降低出错率。手动操作三步，每一步都有敲错命令或漏掉参数的可能。打包成一条命令，出错的空间就小了。

真实战果

数据来源于多个独立的报告和案例，不是某一家的PR稿。

Y Combinator的一个hackathon里，有一个团队用loop的方式一夜之间shipping了6个完整的代码仓库。这6个repo不是demo级别的玩具项目，是有前后端、有数据库、有API、能跑通的完整产品。整晚的API消费总计297美元。这个产出如果外包给传统的开发团队，按市场价估算大约需要50000美元。成本效率差了170倍。

297美元和50000美元之间的差距不全是效率提升。hackathon场景有天然的加成：需求定义清晰（hackathon的题目是明确的）、不需要来回沟通（一个人拍板）、不需要考虑长期维护（做完就行）。实际production环境的ROI不会有170倍那么夸张。但即便打个很大的折扣，几十倍的效率差异是实打实的。

McKinsey对开发者做了一项调研，结果很有意思：73%的开发者报告说，从workflow架构设计中获得的生产力提升，大于从prompt质量提升中获得的。换句话说，怎么设计循环比怎么写prompt更重要。这和Loop Engineering的核心主张完全吻合。同一份调研里，90%的工程leader报告AI带来了生产力提升，平均净增幅为19.3%。

Google内部披露了一个数据：75%的新代码现在由AI生成。这个比例在一年前大概是30%左右。增长曲线很陡。AI从"辅助写代码"变成了"主力写代码"，人的角色越来越偏向审查、架构设计和需求定义。

Photo by Nick Chong on Unsplash

Kent C. Dodds，React Testing Library的作者，一个在JavaScript社区很有影响力的开发者，描述了他的日常工作流：晚上花半小时写一份详细的spec文档，描述清楚要做什么功能、要满足什么约束、要通过什么测试用例、边界条件是什么。然后设一个loop让agent跑通宵。第二天早上起来，打开电脑，看到的是一份working code，测试全绿。他review一遍，调整几个地方，合并，一个功能就完成了。他说日常平均有30%的代码是loop产出的。

这些数据从不同角度确认了同一件事：loop engineering不是概念验证阶段的东西，它已经在production环境里产出真实的商业价值了。争论"AI能不能写代码"这个问题已经没意义了。现在的问题是"怎么让AI更高效、更可靠地写代码"。

真实账单

效率数字很好看。但账单呢？

Loop产生的API调用量是单次prompt的10到100倍。原因很直观：每一轮迭代，agent需要重新发送完整的上下文给模型。这个上下文包括system prompt、工具定义、所有历史对话、之前的工具调用结果。随着循环轮次增加，上下文越滚越大，这个叫context snowball效应。第1轮可能发了5000个token，到第10轮可能每轮要发50000个token。

一个简单的agent任务，token消耗是传统chatbot对话的10到50倍。复杂的代码生成任务，涉及多轮编辑、测试、debug、重构的，消耗量能到chatbot的1000倍以上。一轮一轮地试、一遍一遍地改，每一轮都要把之前所有的上下文重新喂一遍。

这不是理论推算，已经有大厂交了学费。

Uber的案例在技术圈里被广泛讨论：四个月就烧光了2026全年的AI coding预算。整整一年的预算，四个月见底。Uber不是一家小公司，它的AI预算不会是个小数字。原因是开发者大规模采用agent coding之后，每人每天的token消耗远超预算模型的假设。预算是按"每个开发者每天用几次AI辅助"来算的，实际使用是"每个开发者每天跑几十个agent loop"。量级差了一个数量级，预算当然撑不住。

Meta的数据更惊人。内部员工在30天内消耗了73.7万亿个token。73.7万亿。这个数字大到需要停下来想一下才能感受它的规模。如果年化，光token成本就接近数十亿美元的量级。Meta的体量当然能承受这个数字，但它说明了一个趋势：一旦agent coding在企业内部铺开，token消耗的增速是爆炸性的。

Gartner在6月24日发布了一份报告，做出了一个引起广泛讨论的预测：到2028年，AI coding的token成本将超过开发者的平均年薪。也就是说，养一个AI编程agent的token费用，可能比雇一个人类开发者还贵。当然，一个agent的产出也远超一个人类开发者。但这个预测至少说明，"AI便宜"不是一个可以无限假设下去的前提。

这里面有一个反直觉的算术。

自2022年11月ChatGPT发布以来，每个token的单价降了大约280倍。GPT-4刚出来时的价格和现在GPT-4o mini的价格相比，差了几个数量级。这是好消息。模型越来越便宜了。

但坏消息是，Agentic AI普及之后，每个任务的token消耗量涨了一到两个数量级。单次prompt用几百个token就够了。一个agent loop跑下来，轻松烧掉几万甚至几十万个token。复杂任务能到上百万。

单价降两个数量级，消耗涨两个数量级，两边对冲的结果是：总账单不降反升。这是很多CTO在做AI预算时忽略的事情。他们看到了token单价的下降趋势，就假设AI会越来越便宜。但他们没有看到的是，使用方式从"每天问几个问题"变成了"全天候跑几十个agent"，消耗量的增长吃掉了单价下降的红利。

Goldman Sachs的预测是到2030年全球token消耗增长24倍。如果这个预测大致准确，即便token单价继续下降，总支出仍然会显著增长。

Photo by Luke Chesser on Unsplash

成本控制的方法不是没有。模型路由是最直接的：简单任务用小模型（Haiku级别），复杂任务才上大模型（Opus级别），成本能降60%到80%。语义缓存可以让相似的query命中缓存直接返回，跳过模型调用。上下文滑窗只保留最近的相关历史，旧的对话做总结压缩后丢掉原文，控制context的膨胀速度。硬刹车机制包括最大迭代次数限制、工具调用预算上限、实时花费告警、超额自动停机。RAG替代全文喂入，只检索相关的段落而不是把整个代码库塞进context，token能减60%到80%。Prompt瘦身，把冗余的指令和重复的说明精简掉，通常能压缩30%到50%。

这些方法都有效，但本质上都是在做同一件事：控制loop的"宽度"和"深度"。让每一轮的token消耗更小，让不必要的轮次更少。治的是症状，不是病因。病因在后面的翻转章节里讲。

技术陷阱

Loop不是银弹。跑起来之后会遇到一些特有的故障模式，和传统编程完全不同。这些不是边缘情况，是每天都会碰到的问题。

Context Rot（上下文腐烂）。

长循环里最常见的问题。agent跑了20轮30轮之后，它的context window被自己之前的输出塞满了。每一轮的思考过程、工具调用的输入和输出、编译器的错误信息、测试结果、中间版本的代码，全都堆积在context里。

这些信息越积越多，但模型的context window是有限的。更关键的是，模型对context中不同位置的信息注意力分布是不均匀的。一般来说，对靠近开头和靠近结尾的内容注意力较高，对中间部分的注意力较低。还有一个效应是：越近的信息权重越大。当context被大量中间过程填满之后，agent对最初始的目标描述的关注度会下降。它开始在自己生成的中间状态里打转，回应的是上一轮的输出，而不是最初的目标。

类比：开一个很长的会，到第三个小时，所有人都忘了最开始到底在讨论什么。会议纪要越来越厚，但每一页新增的内容都是在回应上一页的讨论，没人再翻回第一页去看最初的议题。议题早就漂了，但所有人都觉得自己在"推进讨论"。

Photo by Albert Stoynov on Unsplash

Drift Amplification（漂移放大）。

和context rot相关但不同。context rot是注意力的问题，drift amplification是误差累积的问题。

每一轮迭代，agent的决策都有一个微小的偏差。这个偏差可能来自模型的理解误差，也可能来自任务描述本身的模糊性，也可能来自上一轮错误输出的误导。第1轮偏了1度，如果没有被纠正，第2轮会在偏了1度的基础上再偏一点。不是回到正轨再偏，而是在偏离的方向上继续偏。到第10轮，累积偏差可能已经达到15度甚至更多。

agent越来越多地在推理自己之前的trace（推理痕迹），而不是推理实际的问题本身。它的每一步决策看起来都是"合理的"，因为每一步确实是基于上一步的结果做出的最优选择。但整体方向已经偏了。

结果是：agent看起来在高效地工作（每一轮都在做事、在修改、在提交），但实际上在高效地朝着错误的方向前进。它没有停下来、没有报错、没有求助，因为从它的视角看，一切正常。只是这个"正常"是相对于已经偏移的前几步而言的，不是相对于最初的目标。

这就是为什么Cherny强调Plan Mode先行。在计划阶段对齐方向，比在执行10轮之后发现跑偏了再纠正要便宜得多。

自我审查偏差。

同一个agent在同一个context window里生成代码然后review代码。这个设置天然有问题。

模型在生成代码时做了一系列决策：选择这个数据结构而不是那个，用这个算法而不是那个，在这里做异常处理而不是在那里。当它紧接着被要求review这段代码时，所有这些决策的推理过程还在context里。它很难站在一个"不知道这些决策背景"的角度去客观评估代码质量。它倾向于为自己的选择找理由，而不是质疑自己的选择。

人类code review的一个基本原则就是"不要review自己的代码"。不是说人做不到客观，而是说这个设置天然不利于客观性。agent也一样。

这就是为什么sub-agent设计很重要。用一个独立的、没有生成过程context的agent来做审查。/goal命令用独立的Haiku模型做完成度评估，也是同样的思路：评估者不应该是执行者。

Comprehension Debt（理解力负债）。

Addy Osmani提出的概念，很形象。

当loop越来越自主、越来越复杂，人类对系统实际行为的理解会逐渐减少。一开始你知道agent在做什么，因为它的每一步你都看了。后来你只看关键节点的输出，跳过中间过程。再后来你只看最终结果，中间完全不看。最后你连最终结果都只是扫一眼diff就merge了。

Osmani把这叫"cognitive surrender"：人类认知层面的投降。你不再试图理解底层发生了什么，而是选择信任系统。大多数时候这没问题，因为系统确实做对了。但当它做错的时候，你没有能力诊断问题出在哪里。是prompt写得不好？是skill文件有误？是context rot了？是drift了？是模型本身的能力限制？你不知道，因为你已经放弃了理解中间过程。

Osmani的总结很精准："a loop running unattended is also a loop making mistakes unattended"。无人值守的循环，也是无人值守的错误。

这四个陷阱不是理论上的风险，是实际跑loop的人每天都会碰到的问题。它们不致命，但它们决定了loop engineering的适用边界。能管理好这些陷阱的场景，loop engineering的生产力优势是碾压级的。管理不好的场景，loop跑得越久，产出的垃圾越多。

翻转：这还是模型视角，不是应用视角

前面七节讲了loop engineering的组件、实践、战果、成本和陷阱。现在退一步，看看这整套方法论到底在做什么。

所有的Loop设计，剥掉表面的工程细节，核心动作都是同一个：让模型多试几次。

agent写了代码跑不通，就改了再试。审查没过，就修了再审。测试失败，就debug再跑。目标没达成，就调整策略再来。每一轮循环的本质就是"采样一次，验证一次，不行就再采样"。

这个模式并不新鲜。它和大模型训练阶段的逻辑是同构的。

训练时，模型用海量数据的随机采样来逼近参数的最优解。每个mini-batch是一次随机采样，反向传播是一次修正，梯度下降是一次调整方向。几十万个step迭代下来，参数逐渐收敛到一个足够好的点。训练过程本质上就是一个巨大的loop：采样、计算loss、反向传播、更新参数、再来一轮。

推理时，模型用temperature采样来生成输出。temperature越高，随机性越大，输出越多样。temperature越低，随机性越小，输出越确定。但不管temperature设多低，每次生成都有随机性。同样的prompt跑两次，输出很可能不完全一样。

Loop Engineering是在应用层复刻了同样的模式。每一轮loop就是一次"生成+验证"的采样。多轮累积下来，输出质量趋向稳定。如果验证条件设得好（测试用例足够全、goal描述足够精确），最终产出的质量确实可以很高。

说白了，Loop Engineering的本质是用compute换quality。用更多的token消耗、更多的算力、更多的API调用来提高输出的确定性。这不是贬义。在很多场景里这是完全合理的策略。但它有适用范围。

Photo by Y on Unsplash

用compute换quality不是免费的。每多跑一轮loop就是多花一轮的token钱。问题是：这笔账什么时候划算？

coding场景划算。原因很简单也很硬：一个好的软件工程师年薪150K到300K美元。硅谷的senior engineer，加上股票和福利，总包可能到400K甚至500K。如果一个loop花297美元能产出50000美元的等价产出（YC hackathon的数据），ROI是170倍。

即使实际production环境的ROI没有hackathon那么夸张。production环境里需求沟通成本更高（product spec不是一句话能说清的），代码质量要求更严（不只是"能跑"，还要"能维护"），集成复杂度更大（要和现有系统兼容），测试覆盖率要求更高（不能有回归bug）。打个很大的折扣，假设ROI只有10倍。一个年薪200K的工程师，如果10倍ROI的agent loop一年花20K的token，这笔账仍然极其划算。因为被替代的人力成本太高了。

但换一个场景试试。

一次客服对话的经济价值是多少？几毛钱到几块钱。一个简单的咨询回复、一个退货流程的指引、一个订单状态的查询，单次对话的直接价值很低。用户不会因为客服的措辞优美了10%就多买一件商品。客服的核心价值是"快速解决问题"，不是"生成完美回复"。

如果用loop的方式来做客服怎么样？agent生成回复，用独立的sub-agent审查回复质量，发现语气不够好就修改，审查模型觉得信息不够全就补充，循环几轮直到达到质量标准。token消耗可能是直接生成一次回复的10到50倍。

单价按$1/M token算（已经是2026年中很便宜的价格了），一次直接回复可能消耗2000到5000个token，成本$0.002到$0.005。用loop方式，3到5轮迭代下来，消耗可能到5万甚至20万个token，成本变成$0.05到$0.2。

单次看，差距不大。但业务是要乘规模的。

日均100万次客服对话。直接回复方式，年化成本大约730K到1.8M美元。Loop方式，年化成本可能达到18M到73M美元。差了一到两个数量级。而每次对话带来的增量收入并没有因为用了loop就成比例增长。客服质量从80分提升到95分，对转化率的边际提升可能只有1%到2%。但token成本涨了10到50倍。

商品推荐的场景更极端。

跃盟的瞬知引擎每天处理的决策量级是每秒百万级的商品浏览决策。一个用户打开电商app的首页，引擎需要在毫秒级的时间内决定展示哪些商品、用什么排序、配什么标签和推荐理由。这个决策的单次价值极低（可能不到一分钱），但决策量极大（一天几十亿次）。

如果每个推荐决策都跑一个loop，哪怕是最轻量的两轮循环，每轮只用最小的模型，token消耗量也是完全不可承受的。日均几十亿次决策，每次消耗哪怕1000个token，一天就是万亿级的token量。按$0.1/M token的极低价格算，一天也是几亿美元。这个数字比整个电商平台的利润还高。

这不是技术做不到的问题。是经济上算不过来。

Loop Engineering代表的是一种思维方式，可以叫它"模型视角"的工程化。

模型视角的出发点是：我有一个强大的模型，怎么让它做更多、更好的事？

答案是给它更多轮次、更多工具、更多自主权。让它自己探索、自己试错、自己纠正。人只需要定义目标和验证条件，剩下的交给模型。模型不够好？多跑几轮。一轮不够？跑十轮。十轮不够？跑一百轮。总能收敛到一个可接受的结果。这是一种很自然的思路，尤其对于做模型的人来说：我造了一把强大的锤子，我当然想找更多的钉子来敲。

这条路在两个大趋势的支撑下是有道理的。第一，模型能力在持续增强。每一代新模型比上一代更聪明，同样的任务需要的loop轮次更少。第二，token单价在持续下降。两个趋势叠加，loop的经济可行性在逐步扩大。今天跑不起的场景，明年可能就跑得起了。

但还有另一种思维方式，叫"应用视角"的工程化。

应用视角的出发点完全不同：我有一个具体的业务问题，怎么用最经济的方式解决它？

答案不是让模型多试几次。而是在调用模型之前就把任务定义得足够精确，让模型的随机性不需要那么多轮来收敛。用工程化的方式把问题的空间缩小，让模型在一个高度受限的空间里做选择，而不是在一个无限大的空间里探索。

举个具体的例子。一个商品推荐场景。

模型视角的做法是：把用户画像（浏览历史、购买记录、兴趣标签）和候选商品库（几百万个SKU）扔给模型，让它生成推荐列表。输出不好？用另一个agent审查推荐质量，评估相关性和多样性。不满意就让第一个agent重排，循环几轮直到达到质量标准。这样确实能做出好的推荐，但每次推荐的成本很高，而且延迟也会很大（几轮loop下来，响应时间可能从毫秒级变成秒级）。

应用视角的做法是：先用传统的检索排序算法把候选集从几百万缩小到几十个。这一步不需要大模型，用向量检索加规则过滤就行，毫秒级完成。然后做特征工程，把用户意图解析清楚（是在逛还是在买？是找特定品类还是随便看看？），把商品属性结构化好（价格区间、品牌、评分、库存状态），把上下文信息提取出来（时间、设备、入口页面）。最后只在一个很小的决策空间里用模型做个性化微调。模型只需要在几十个候选里选出最合适的排列方式，不需要在几百万个商品里从零开始探索。一次调用就能产出足够好的结果，不需要loop。

这两种视角对应两条完全不同的技术路线。

模型视角的路线：更强的模型 → 更复杂的loop → 更多的token消耗 → 适用于高价值场景。coding、法律文书审查、医疗影像诊断、金融合规检查，这些领域有一个共同特征：被替代的人力成本极高，单次决策的经济价值很大，可以承受每次决策花几百甚至几千个token的成本。

应用视角的路线：更好的任务定义 → 更少的模型调用 → 更低的token消耗 → 适用于大规模场景。推荐系统、客服对话、内容分发、广告投放、搜索排序，这些领域的共同特征是：每次决策的经济价值很低，但决策量极大。一次推荐值一分钱，但一天有十亿次推荐。这种场景不可能每次决策都跑一个loop。

coding是少数能同时匹配两条路线的场景。模型视角能跑通（因为工程师贵），应用视角也在进化（更好的spec和eval让loop更快收敛）。但大多数业务场景只有应用视角这条路走得通。

大模型的核心能力来自统计学习。统计学习有一个基本特征：用大量样本的随机性来逼近总体的规律性。

训练阶段，这表现为用海量数据的随机mini-batch来逼近loss function的最优解。不是精确计算，是统计逼近。推理阶段，这表现为用temperature采样在概率分布中选择输出token。不是确定性计算，是概率采样。

Loop Engineering把推理阶段的迭代显式化了。每一轮loop就是一次"采样+验证"的循环。跑够多轮，输出质量在统计意义上趋向稳定。

但这种方式有一个数学上绕不过去的特性：边际收益递减。

第1轮到第3轮的质量提升通常很大。agent在第1轮可能写出一个能跑但有几个bug的方案，第2轮修了主要的bug，第3轮通过了所有测试。到这里，质量从60分提升到了90分，提升了30分，花了3轮的token。

但第10轮到第15轮呢？也许只是微调了一些代码风格（变量名从data改成userData）、优化了一些边界情况的处理（空数组的时候返回空列表而不是报错）、改善了一点错误信息的可读性（把"error"改成"Invalid input: expected non-empty array"）。质量从94分提升到了96分，提升了2分，又花了5轮的token。

如果画一条曲线，横轴是loop轮次（也就是token消耗），纵轴是输出质量，这条曲线前面很陡后面很平。一开始每多花一轮的token能换来很大的质量提升，后来每多花一轮换来的质量提升越来越小。但token消耗是线性增长的，每一轮都要重发完整的context。如果context在膨胀（context snowball效应），token消耗甚至是超线性增长的。

这意味着"用随机性换确定性"这条路有一个经济学上限。

在这个上限以内，多跑几轮loop是划算的。质量提升大于成本增加，净收益为正。超过这个上限，花再多token也换不来多少确定性提升，但账单会继续线性甚至超线性地涨。净收益为负。

对于coding场景，这个上限相对高。一个bug可能导致线上事故，事故的成本可能是几万到几百万美元。多花几千个token来多检查几轮，ROI仍然是正的。

但对于大多数业务场景，这个上限来得比想象的早。当一轮loop的成本已经接近甚至超过这次业务操作的全部经济价值时，就到了。一次客服对话值5毛钱，第4轮loop的成本已经超过5毛了，再跑下去就是亏钱了。

Loop Engineering是2025年下半年到2026年上半年最重要的工程方法论进化之一。它在coding场景里的战果是真实的，297美元换50000美元等价产出不是吹牛。它让一个人的生产力接近一个小型工程团队。吴恩达、Cherny、Steinberger从不同角度验证了这一点。

它的五个零件加一个记忆已经内置在主流工具里，任何开发者今天就能用起来。它的技术陷阱是真实的，但可管理的。它的成本问题是严峻的，但在高价值场景里仍然划算。

但它的适用范围比很多人以为的窄。

不是所有场景都需要agent跑10轮20轮来逼近正确答案。大多数业务场景需要的是另一种能力：在调用模型之前就把问题定义清楚，让模型一次做对或者更快收敛。

这两种能力不矛盾，但投资方向完全不同。

Loop Engineering投资在"模型调用之后"，核心问题是怎么让模型更好地自我纠正。任务定义能力投资在"模型调用之前"，核心问题是怎么让模型一次做对。

哪种投资的ROI更高，取决于场景的经济价值密度。年薪200K美元的工程师值得用loop。每次几毛钱的客服对话不值得。每秒百万级的商品推荐决策更不值得。

这是一个产业分叉点。Loop Engineering站在分叉的一侧，漂亮、有效、已经跑通。但另一侧的路可能更长，走的人可能更多。

王冉，跃盟科技创始人。连接稀缺人类岗位与AI劳动力。