本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《OpenClaw 创始人吹的 Loop 工程到底是个撒？不用写提示词了？》
来，又来，AI领域又来新名词了！这次是Loop Engineering。
借此机会，大家也顺便复习下过去3年一些火过的名词，看还记得撒：
Prompt Engineering、RAG、Context Engineering、ReAct、Agent、MCP、Skills、Harness...
如果对AI工程有一定认知的同学会了解：上述名词很多都是在炒冷饭，他们很有点对某个概念再包装的嫌疑，比如：
提示词工程往前走一步，做得更复杂、更系统一点就会变成上下文工程；而如果要维护好整个Agent/AI所依赖的上下文环境，就会变成Harness工程。
所以，这次出现的名词Loop大概率也不会是新的，因为Agent的经典架构ReAct本来就行一个循环执行框架。
所以，这个Loop Engineering到底是怎么个事呢？
Loop Engineering
6月7日，OpenClaw创始人发了一条消息，大概意思是：
你不再需要为编码智能体编写提示词了，你应该设计循环来提示你的Agent
所以，对于我这种喜欢脑补的选手，我第一反应就是这人又在“胡吹”了，OpenClaw在生产环境实际运行的稳定性、效率和成本，你自己心里没一点逼数吗，还在扯循环...
Peter本身是某产品的负责人，他说话是带有立场和产品IP效应的，他跟我们在说的软件日抛是一个事，这只是观点、想法，并不是真的，大家不要说风就是雨
但这次有些不一样，他不是“一家之言”，Claude Code、Google的Addy Osmani也在对Loop Engineering做各种补充说明
于是，Loop又火了，他成功击中了人类想要更简单、想要大力出奇迹的美好愿望。
那么Loop的价值到底在哪，他为什么要出现，他出现是为了解决什么问题呢？
Why Loop Engineering？
首先需要澄清的是：ReAct和Loop Engineering不是一个事，或者不是一个层面的事。
ReAct是Agent内部经典的循环架构：推理—行动—观察模式，他回答的是Agent每一步如何思考、如何和外部有效交互的问题；
而Loop Engineering不解决Agent架构层面的事，他在回答另一个问题：
当ReAct（Agent Loop）已经存在后，谁来持续驱动这个Loop？
谁来给它目标、状态、反馈、验收、停止条件和恢复机制？
所以，这里的ReAct是内部框架循环，他可能是AI工程师的活、隶属于Agent RunTime的范畴；
而Loop Engineering是外循环工程，他是需要让Agent持续干正事的策略、他解决的是外部任务如何持续的问题，这可以是Agent产品经理的工作：
大家这里听起来应该是有点懵，我举个案例做说明。传统客服BUG反馈链路是这样的：
客服在群里反馈一个问题，值班的测试看到后先判断这是操作问题、Bug还是需求；
如果是BUG就转给研发，研发看代码、看日志、然后开发上线；
如果不严重（体验问题）且短时间改不了就变成Todolist第二天处理；
我们这里只关注BUG链路，其他逻辑略去...
这是经常会发生的流程，而程序员对此也是很烦的，谁也不想爱爱的时候被打扰；如果这里按照Loop Engineering的定义，逻辑就变了：
客服在群里反馈问题后（甚至客服也可以用Agent替代，但我们这里不讨论那么复杂的场景），Agent自动监听并接管后续链路。
它会先判断问题类型，再收集足够的上下文：
如果问题简单、低风险，Agent可以自己修改代码、上线，并同步给程序员和客服群。
如果问题有一定复杂度，Agent会先改好代码，但不直接上线，而是发给程序员确认；程序员确认后，再继续上线；
如果问题不清楚或风险较高，Agent就停止自动执行，转人工判断；
而整个这套机制，就是我们所谓的Loop Engineering。
至此，我相信大家也看懂了，这跟我们各个企业在推行的AI原生，其实是一个事情，换句话说：
Loop Engineering不是个工程技术的事，他是个如何与Agent合作的事，并且这里的关注点要从人上升到组织
这个案例是我方便大家理解而类比做的说明，接下来我们看看国外大佬的案例：
Loop的五个组件
Addy在他那篇长文里，把一个完整的loop拆成了五个组件+一个外部记忆：
其实Addy也有个案例说明，但我读下来觉得太程序员了就没用，大家可以自己感受下：
一、Automations
Automations解决的是：Agent为什么会启动，也就是什么时候被触发的问题。
比如传统链路里，客服在群里反馈问题，得等测试、研发或者负责人看到，才会有人处理。
Loop里第一件事，就是让Agent有自己的任务入口。比如客服群出现报错、打不开、支付失败、提交不了这类信息，Agent自动监听、自动识别、自动创建任务。
所以Automations就没那么神秘，他就是一个规则，只要规则合理，代码就是分分钟的事情，
二、Connectors
Connectors解决的是：Agent如何接入真实业务系统？也就是连接机制的问题。
这东西的背后其实很不简单的，往小了说需要构建整个研发团队的信息流、往大了说需要构造整个公司体系的信息通道。
比如，客服简单一句：用户说按钮点不动，这句话本身不够处理问题。
我们去处理的时候可能需要，查订单、查日志、看用户截图、看最近发布记录...
Agent要处理问题也是一样的，所以它必须能连接客服群、订单系统、日志系统、监控系统、代码仓库、工单系统和发布系统。
所以Connectors的本质是信息通道和动作通道，并且在这里大家就可以看出来了：Addy举的案例太狭窄了，如果一般企业要用好他这个所谓的Loop，其实需要做很多工作的。
三、Worktrees
Worktrees解决的是：多个Agent或多个任务同时执行时，怎么不互相污染？
比如客服群同时反馈三个问题：支付失败（这个会直接升级为人工）、优惠券不展示、订单状态异常，Agent不能在同一个环境里乱改。
在代码场景里，Worktrees是独立分支和独立工作区；放到业务场景里，就是每个问题独立工单、独立分支、独立测试、独立发布判断。
Worktrees是系统的隔离机制、也是边界的控制，我相信无论Agent多智能，这两年也一定不会有人胆敢用他在支付系统上面去搞事情。
四、Skills
Skills解决的是：Agent做事时依据什么经验、规范和SOP？这也是我们常见的朋友了，我们知道他承担的是团队工作流的执行：
Agent从怎么去拿上下文到拿到上下文如何去做，这都要依赖与公司的处理规则，这个规则就是Skills：
比如什么问题算BUG，什么问题是操作问题，什么问题是需求；
什么问题可以自动修，什么问题只能提方案；
哪些模块低风险，哪些模块涉及支付、订单、权限、资金，必须人工确认。
在Loop的真实使用过程中，大家多数的工作都会变成准备各种skill。
五、sub-agents
Sub-agents解决的是：一个Agent不应该既当运动员又当裁判。其实就是工程解耦的思维，有点之前提示词一事一议的感觉，核心逻辑是分工：
传统流程里，本来就有分工：客服反馈、研发修复、测试验证......
Agent接管链路后，也不能让同一个Agent自己判断、自己修改、自己验证。
更合理的是：一个Agent做问题分诊，一个Agent做修复，一个Agent做测试或Review，复杂场景再交给程序员确认。
这里倒不是说Agent能力不行，多Agent架构是为了符合我们的习惯，毕竟单Agent维护起来要简单很多。
六、Memory
Memory解决的是：Agent如何不失忆，如何接力，如何恢复？
其实无论对于Agent架构，还是对于机制流程，做状态机制都是很烧脑细胞的事情。
一个BUG从客服反馈到最终上线，中间会经历很多状态：已监听、已分类、已查日志、已定位、已修复、测试通过、等待人工确认、已上线、已通知客服、已沉淀规则...
这里应该是Connectors的延续，或者说整个企业信息通道建设在这个场景可以被打散为Memory与Connectors。
好了，上述就是Addy关于Loop的实践方法论。
Loop到底是什么？
综上，我们在这里就可以为Loop Engineering下一个真正的定义了：
Loop Engineering可以被看作一次AI原生研发团队的实践案例
或者说，是AI原生在研发协作场景里的一个具体切面
它甚至都不是一次完整的AI原生组织实践，这里切的是已从个人使用AI工具进入了团队流程被Agent接管的阶段，大家可以参考这张图：
所以，你如果问我对Addy《Loop Engineering》
https://addyosmani.com/blog/loop-engineering/
这篇文章怎么看？我会说如果就我这几个月的企业咨询视角的话：
Addy巧妙的用了一个coding agent的案例，展示了一次AI原生研发团队的雏形，并给这个案例取了一个名字Loop Engineering
然后大家也就知道了，这个案例居然TMD火了：
而我真正打开去看了下，貌似大家并不了解他的内涵，甚至有人说什么提示词已死，这个犊子就扯大了......
结语
那么问题来了：为什么一个AI原生研发团队雏形的案例，能在国内外技术圈引发如此广泛的讨论？
答案或许有些反直觉：因为绝大多数人还停留在第一层，而Addy已经把镜头拉到了第三层。
当前多数开发者还停留在第一层（个人工具适配层），他们的目光还聚焦在：怎么写提示词让Agent把代码写对；
而Addy在思考如何设计一套系统，让Agent在无人值守的情况下持续产出可用代码，这是接近第三层（组织适配）要考虑的问题。
这侧面说明当前AI行业的认知差距可能还是不小的，依旧是鱼龙混杂啊！
所以，为什么Loop会火？因为它踩中了一个沉默的痛点
AI Coding工具普及后，团队效率并没有等比提升
为什么会这样呢，因为机制没有匹配、因为组织结构没有匹配，而这里Loop的本质，还是在走机制流程的爬坡，他的目标是把隐性流程变成显式代码。
什么意思呢？意思是把每一步隐性的判断标准显性化，比如：
什么样的问题算BUG？什么样的算需求变更？
哪块代码可以快速修复？哪块必须经过Code Review？
什么情况可以自动上线？什么情况必须等人工确认？
因为Agent必须依赖完整的规则和上下文才能能力最大化，所以这里Loop真正在做的事其实是在构造AI需要的舒适环境。
最后也吐槽一句，Loop Engineering又在炒冷饭，我觉得这个概念是没必要存在的...