最近技术圈又冒出一个新概念：Loop Engineering。Addy Osmani 写了一篇长文论述它，Anthropic 的 Claude Code 负责人 Boris Cherny 甚至说："I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."这话如果放在半年前听起来像宣言，放在今天，更像一份已经发生的现场报告。
正好近期的一次系统开发实践，让我对这个概念有了切实的感受。这篇文章不是概念解读，而是一次从"驾驭工程"到"循环工程"的演进记录。
Loop Engineering 是什么
简单说，Loop Engineering 是设计、运营和优化反馈闭环的实践——让 AI 编码智能体自己规划工作、修改代码、观察结果、修正方案，直到任务完成。它与 Prompt Engineering 的核心区别在于：前者关注如何写好一次输入，后者关注如何设计一个持续自我修正的系统。
Addy Osmani 把 Loop 的构成拆成五块积木加一个记忆：
第六样东西是 状态文件——一个存在于对话之外的 Markdown 或任务看板，记录"做了什么、下一步是什么"。Agent 每轮会话结束就失去记忆，但仓库不会。
这五块积木放在一起，构成了一条自运转的研发流水线：自动化发现任务 → 工作树隔离并行 → 技能注入项目上下文 → 子代理实现与校验 → 连接器写入真实系统 → 状态文件串起迭代。
Kilo 的定义更聚焦在"闭环"本身：Intent → Context → Action → Observation → Adjustment。举例来说，开发者让 Agent 修复一个含单引号的公司名导致计费设置保存失败的 Bug。弱闭环会猜测问题出在 SQL 转义上，直接修补查询语句。强闭环则会先定位表单、API 路由、校验 Schema 和数据库更新路径，复现失败，观察问题究竟出在客户端校验、服务端校验、序列化、SQL 还是展示层，然后修改最小相关代码路径并运行针对性回归测试。一个强大的初版回答不等于一个正确的最终交付，真正重要的信号往往出现在第一次行动之后——编译错误、测试失败、类型不匹配、部署日志里的异常。Loop Engineering 将这些信号纳入系统逻辑，而非留给人来事后补救。
驾驭工程的实践升级
这个概念让我想起了此前一直在实践的一个思路：驾驭工程（Harness Engineering）。
驾驭工程的核心是"设置环境和围栏，然后让其在约束内自主发展"。它不是手把手指挥每一步操作，而是铺设轨道、设定边界条件、提供验证手段，让 AI 在轨道内完成从意图到交付的闭环。
Loop Engineering 站在驾驭工程之上一层。如果说驾驭工程是为单个 Agent 搭建运行环境，那么 Loop Engineering 是让这个环境自主运转——它定时启动、自动分配任务、校验产出、记录进度、决定下一步。驾驭工程回答"Agent 在哪里跑"，Loop Engineering 回答"谁能确保整个流程不需要人守在旁边"。
两者的关系不是替代，而是叠加。驾驭工程是底盘，Loop Engineering 是变速箱。没有底盘，变速箱无从挂载；没有变速箱，底盘只是一个静态容器。
自下而上的管理隐喻
Loop Engineering 的思路如果映射到团队管理上，恰好与"自下而上"的管理路径吻合。
传统的自上而下管理，是管理者逐一分解任务、指派人员、检查进度、修正偏差。管理者是信息中枢，也是瓶颈。而自下而上的管理，是把目标讲清楚、边界划好、工具给到位，然后让团队自己拆解、自己对齐、自己验证，管理者只在例外情况下介入。
这里有一个关键判断：自下而上不等于放任。它恰恰对管理者的架构能力提出了更高要求——你需要把"意图"写得更清晰，把"边界"画得更精确，把"校验标准"定得更可操作。这和 Loop Engineering 的设计要求完全一致：一个模糊的 Goal（比如"改善仪表盘"）会让 Agent 在无意义的探索中消耗 Token，而一个包含范围、行为约束、验证命令和可接受权衡的 Goal 才能驱动有效的闭环。
所以 Loop Engineering 真正的门槛不在工具，而在于你是否能够把意图精确地翻译为可验证的系统指令。这要求管理者（无论是管人还是管 Agent）具备两个能力：一是"拆解"——把模糊的期望拆成可观测的目标；二是"设限"——明确什么不能动、什么必须保持、什么可以妥协。两者缺一不可，缺一则 Agent 的循环要么跑偏，要么跑飞。
一次实践：四阶段计费系统的完整闭环
下面记录一次真实的 Loop Engineering 实践。目标是基于已有的 MCP Gateway 基础设施，构建一个完整的用户计费系统。
设计先行。首先产出了一份详细设计文档，明确了四个 Phase 的交付边界：Phase 1 计费基础设施（定价服务 + Credit 计算器 + 数据库建表），Phase 2 台账日志（Redis Streams 消费 + JSON-lines 落盘 + 30 天滚动清理），Phase 3 计费 API（7 个端点覆盖消费查询、日汇总、导出、账单、费率、LLM 成本、对账），Phase 4 管理端（计费 Admin Agent + Gateway 代理路由 + 客户端技能包）。设计文档同时规划了 31 条测试用例，覆盖台账、API、Agent 和安全四个场景。
这份设计文档就是 Loop 中的 Intent——它不是一句"做个计费系统"，而是一套包含架构决策、数据流设计、接口定义和验收标准的完整规范。
四阶段编码。设计文档交付给 LLM 后，四个 Phase 的工程实现依次展开。每个 Phase 都严格遵循"提交最小可验证变更"的原则：搭建骨架 → 编写核心逻辑 → 创建部署配置 → 编写测试。最终交付物包括三个独立微服务（billing-service、ledger-log-service、billing-admin-agent）、一个客户端技能包，以及对应的 Dockerfile 和集成测试。值得一提的是，四个 Phase 之间并非线性串行——Phase 1 的定价服务为 Phase 3 的 API 提供底层能力，Phase 2 的日志服务为 Phase 4 的管理端提供数据源，各模块的接口在设计阶段就已经约定，实现时可以并行推进。
部署闭环。代码写完只是开始。接下来是将整套系统部署到 ECS，环境包括：部署 PostgreSQL Stack 并初始化表结构、构建三个 Docker 镜像并上传、更新 docker-compose.yml 加入计费服务、Nginx 新增 /billing/mcp 路由。部署完成后，8 个服务全部 Running。
测试与回归。31 条测试用例从台账日志、Agent MCP 工具、计费 API 到安全认证逐条验证。这个过程中发现了 4 个阻塞级 Bug：
每发现一个 Bug，系统自动修复 → 重新构建镜像 → 重新部署 → 重新验证，循环迭代直到 31 条用例全部通过。整个过程耗时约两小时，涵盖台账日志、Agent MCP 工具、计费 API 和安全认证四大验证场景。8 个服务稳定运行，回归闭环完成。
这条闭环的本质就是 Loop Engineering：Intent（设计文档）→ Context（代码仓与已有基础设施）→ Action（编码与部署）→ Observation（测试结果与运行时日志）→ Adjustment（Bug 修复）→ 循环至目标达成。整个过程人作为设计者和判断者参与其中，但每一次 Action 到 Adjustment 的循环由系统自身驱动。
结语
Loop Engineering 不是一个需要重新学习的全新范式，它是已有工程实践在 AI 编码时代的自然演化。驾驭工程提供了"环境与围栏"的底盘，Loop Engineering 在此基础上添加了"定时器、分配器和校验器"的传动系统。
它的核心价值不在于让工程师少写代码，而在于把工程师的时间从"盯着每一次 Agent 操作"中解放出来，转到更高杠杆的活动上：定义目标、设计架构、制定验收标准、审视结果。Cherny 说的"My job is to write loops"，指的不是工作变简单了，而是杠杆点移动了。
但有一件事必须清醒：Loop 再自动化，理解代码的责任没有消失。代码越是以你不直接参与的方式产出，你越需要有判断它的能力。一个运转良好的 Loop 不会取代工程师的判断力，它只是让这份判断力作用在更关键的地方。
设计你的 Loop。但以一个工程师的身份去设计它，而不是一个只会按下启动按钮的人。
