Loop Engineering火了：AI Agent开始自己干活，公司准备好背锅了吗？

文 | wiwi AI 圈又开始制造新名词了。 过去半个月，一个叫做 Loop Engineering 的概念突然在开发者和 AI 圈层中扩散。直译过来，它可以叫“循环工程”或“闭环工程”，但这两个中文词都不太准确。因为它真正引发争议的地方，并不是提出了一套全新的技术架构，而是用一个新名字，把 AI Coding 发展到今天的一个深层矛盾重新摆到了台前： AI 已经让个人写代码更快，但还没有真正让组织交付变得更稳定。 过去两年，AI 编程工具最动人的叙事，是个人效率的跃迁。Copilot 帮你补全代码，Cursor 帮你理解项目，Claude Code 帮你改文件，Codex 帮你处理任务。一个开发者借助 AI 一天写出更多代码，一个周末做出一个产品，一个人完成过去需要几个人协作的原型，这些故事足够振奋，也足够适合传播。 但当 AI Coding 从个人工作台进入公司研发体系，问题很快变得复杂。 企业真正关心的，不只是代码生成速度，而是交付链路是否可控，风险是否可追溯，权限是否清晰，知识是否沉淀，成本是否可预算。一名工程师用 AI 提效 30%，并不必然意味着整个团队交付效率提升 30%。很多时候，更多代码反而带来了更重的 Review 压力，更快的原型反而制造了更多维护成本，更强的 Agent 反而暴露了更混乱的流程。 Loop Engineering 正是在这个背景下被推到台前。 它看似是在讨论一种新的 Agent 使用方式，实质上是在讨论一个更大的问题：当 Agent 已经具备持续循环执行任务的能力之后，组织是否有能力、也是否有意愿，重新设计自己的生产流程。 它没有发明“循环” Loop Engineering 的导火索，是 OpenClaw 创始人 Peter Steinberger 的一句判断：你不应该继续给编码 Agent 写提示词了，你应该设计循环，让循环去提示你的 Agent。随后，Google Chrome 团队工程领袖 Addy Osmani 写下《Loop Engineering》，进一步将这个概念系统化。他将 Loop Engineering 概括为：不再由人持续提示 Agent，而是设计一个系统替人去提示 Agent。 这句话之所以容易传播，是因为它几乎是在宣判 Prompt Engineering 的退场。过去，提示词是人与 AI 协作的基本界面。用户提出需求，模型给出结果；开发者描述问题，Agent 修改代码；测试失败，人再把报错复制回去，让模型继续修。提示词在很长一段时间里，被视为 AI 应用层最重要的操作技能。 但这种工作方式有一个天然上限：人必须一直坐在驾驶位上。 Agent 每前进一步，都需要人给下一条指令；上下文变化了，需要人重新整理；测试失败了，需要人判断下一步；任务跑偏了，需要人停下来纠偏。表面上看 AI 在执行，实际上真正驱动工作流的仍然是人。 Loop Engineering 试图改变这种关系。它不再把提示词视为中心，而是把提示词嵌入一套持续运行的外部系统：任务如何触发，Agent 如何获取上下文，能调用哪些工具，在哪些环节必须停下来，失败后如何恢复，结果如何验收，经验如何沉淀到下一次执行中。 但这里必须先讲清楚一个容易被过度包装的问题：Loop Engineering 并没有发明“循环”。 早在 ReAct 框架里，Agent 就已经可以通过“推理—行动—观察”的方式与外部环境持续交互。ReAct 的核心不是单纯的内部推理，而是让模型在 reasoning traces 与 task-specific actions 之间交替运行；actions 本身就允许模型连接外部来源或环境，获取新的信息，再根据观察结果继续调整下一步行动。 也就是说，一个设计良好的 ReAct Agent，本来就可以读取日志、调用工具、运行测试、观察失败结果，并进入下一轮修复。它并不需要等到 Loop Engineering 这个新词出现，才具备“持续行动—观察—修正”的能力。 因此，如果把 Loop Engineering 说成是 ReAct 之后出现的全新循环架构，技术上并不严谨。它更像是对既有 Agent 能力的一次工程化、产品化和组织化再包装。 这也是它引发争议的根本原因：一方面，它确实像旧概念换皮；另一方面，它又确实击中了一个新阶段的问题。 Agent Reasoning Loop 新意不在技术，而在生产组织 Loop Engineering 真正的新意，不在于 Agent 会不会循环，而在于这个循环被放进了真实生产系统之后，会触发一系列过去单个 Agent 框架无法独立回答的问题。 任务由谁触发？权限由谁授予？哪些系统可以连接？哪些动作必须人工确认？什么时候停止？失败以后如何回滚？结果由谁验收？事故由谁负责？ 这些问题不属于某一个 Agent 框架的内部逻辑，而属于生产级 Agent 系统的工程化与组织治理。 Addy Osmani 在文章中将 Loop Engineering 拆成了自动化触发、工作区隔离、Skills、连接器、子 Agent 等组件。单独看这些组件，也都不新。自动化触发像事件驱动和工作流，工作区隔离像 Git 分支和 worktree，Skills 像团队规范、Runbook 和知识库，连接器像 API 集成和 MCP，子 Agent 像多角色协作，外部记忆像状态机、日志和事件记录。 所以，那些吐槽“这不就是几个 Agent 加状态机吗”的人，并不完全错。 但科技行业的新概念之所以能够传播，往往不取决于它在技术上有多原创，而取决于它是否准确命中了某个阶段的共同焦虑。Loop Engineering 的价值就在这里：它把过去分散在 DevOps、自动化、Agent 架构、知识管理和组织流程中的实践，重新放到了 AI Coding 的语境下，并给出了一个更容易传播的框架。 更准确地说，Loop Engineering 不是技术革命，而是一个阶段性标签。 它标记的是 AI Coding 的重心正在外移：从“模型如何回答”转向“系统如何持续驱动模型”；从“一个 Agent 能否完成任务”转向“一个组织能否承受 Agent 持续完成任务”。 这才是它真正值得讨论的地方。 Bug 修复案例说明的不是新技术，而是新冲突 一个典型的软件团队场景，可以说明 Loop Engineering 的真实矛盾。 在传统研发团队里，一个线上 Bug 往往是这样流转的：客服在群里反馈用户打不开页面，测试先判断是不是操作问题，产品补充业务背景，研发查日志并定位代码，修复后交给测试验证，最后上线。复杂一点的问题，还会被转成工单，进入排期。 这条链路看起来普通，但里面包含大量隐性判断。它是不是 Bug？影响范围有多大？是否涉及支付、订单、账户等高风险模块？能不能直接修？谁有权限上线？失败以后谁兜底？同类问题之前有没有发生过？ 过去，这些判断散落在人的经验里。一个老研发、一个熟悉业务的测试、一个反应快的产品经理，靠经验和默契把流程跑起来。 现在，如果将 Agent 接入这条链路，事情会变成另一种样子。客服群出现“支付失败”“页面打不开”“按钮点不动”等关键词后，Agent