Loop Engineering：把 AI Agent 从接收 Prompt 变成可验证的工作系统

观察日期：2026 年 6 月 27 日。

Loop Engineering 最近开始被频繁讨论，尤其是在 Codex、Claude Code、OpenClaw、agentic coding 这些语境里。

它听起来像一个新词，但背后的问题很老：当 AI Agent 不再只是回答问题，而是可以持续读代码、改文件、运行命令、调用工具、分派子任务、等待反馈并继续执行时，人应该怎样设计它的工作方式？

我的定义很直接：

Loop Engineering 是为 AI Agent 设计可重复工作循环的工程方法。

它不是更会写 prompt，也不是把一句话改得更漂亮。它关注的是一整套循环：目标是什么，输入从哪里来，Agent 可以做什么，做完如何验证，失败如何修复，什么时候停止，什么时候必须交还给人。

Prompt Engineering 解决的是“这一轮怎么问”。Loop Engineering 解决的是“这个系统怎样持续工作且不失控”。

这两者不是替代关系，而是层级不同。Prompt 是一次交互；Loop 是一个小型生产系统。

一、为什么现在会出现 Loop Engineering

过去的 AI Coding 主要是对话式的：人提出需求，模型生成代码，人看结果，再继续追问。这个过程仍然有效，但它有一个明显瓶颈：人要不断把当前状态重新组织成下一条 prompt。

Agentic coding 改变了这件事。工具开始能自己读仓库、修改文件、运行测试、查看错误、继续修复。Business Insider 最近把这个趋势总结为：一些 AI 工程师正在从直接写 prompt，转向设计让 agent 自己循环执行的系统。报道里提到的例子包括 Claude Code 的 /loops、类似 /goal 的持续执行指令、以及把一个 agent 用作协调者，让它继续提示和调度其他 agent。

Google Cloud 的 Addy Osmani 也把 loop 拆成几个关键组件：automation、worktrees、skills、plugins/connectors、sub-agents。这个拆法很有工程意义，因为它把“让 AI 自己干活”从一句口号，拆回到可执行的系统结构。

更具体地说，Loop Engineering 兴起有三个原因。

第一，模型工具调用能力提高了。Agent 不只是生成文本，而是能读文件、跑命令、查日志、改代码、提交 patch。

第二，任务变长了。一次性 prompt 适合小修小改，但复杂需求需要规划、执行、验证、返工、再验证。

第三，人的瓶颈从“写代码”变成“组织反馈”。AI 能很快产出实现，但如果没有明确验证，速度只会把错误放大。

所以 Loop Engineering 的本质不是自动化更多，而是把“反馈”变成一等公民。

二、一个好的 Loop 长什么样

一个最小可用的工程 loop，应该包含七个部分。

第一，明确目标。目标不能只是“优化这个项目”或“修一下问题”。它需要说明预期结果、修改范围、非目标、验收方式。比如“让首页只展示最近 10 篇文章，移除项目模块，并保持 i18n 校验通过”就是可执行目标。

第二，限定上下文。Agent 需要知道哪些文件、哪些文档、哪些命令、哪些风格约束是可信上下文。上下文越大不一定越好，关键是能让它稳定做对决策。

第三，定义工具边界。Agent 能不能联网，能不能写文件，能不能跑测试，能不能安装依赖，能不能 push，能不能访问生产环境，这些必须提前决定。

第四，提供执行环境。worktree、临时分支、容器、沙箱、测试数据库、mock 服务，都是为了让 agent 能做真实验证，同时不污染主环境。

第五，建立验证器。测试、lint、typecheck、build、截图、日志检查、安全扫描、diff review、端到端流程，这些是 loop 的刹车系统。

第六，设计反馈路径。验证失败后，Agent 应该读取错误、定位原因、修改、再验证；如果连续失败，要收敛范围或交还给人，而不是无限尝试。

第七，设置停止条件。完成标准、预算上限、时间上限、最大迭代次数、人工审批点，都属于停止条件。没有停止条件的 loop 不是自动化，是消耗资源。

这里最关键的是第五点：验证器。

没有验证器的 loop，本质上只是更长的幻觉。Agent 可以不停地改、不停地解释、不停地给出自信结论，但没有外部检查，它只是在生成更多看起来合理的文本。

这也是为什么我认为 Loop Engineering 更接近系统工程，而不是提示词技巧。

三、最佳实践方案：从一个小 loop 开始

如果要在真实项目里落地 Loop Engineering，我建议从一个很小、很硬的 loop 开始，不要一上来就做“全自动维护整个仓库”。

1. 先选低风险、高重复、可验证的任务

适合第一批 loop 的任务：

修复 lint/typecheck/build 错误
补充或更新文章、文档、release notes
按固定规则迁移 API 调用
根据失败测试修复局部 bug
生成 changelog 或 PR summary
扫描待办项、过期链接、无效引用
在独立 worktree 里探索重构方案

不适合作为第一批 loop 的任务：

直接改认证、支付、权限、删除、迁移、生产配置
自动升级大量依赖并合并
让 Agent 自主决定产品方向
让 Agent 在没有测试的核心业务里连续改动
让 Agent 自己审自己、自己通过自己

第一批 loop 的原则是：失败成本低，成功标准清楚，验证能自动化。

2. 把 loop 写成可复用协议，而不是临时口头指令

一个 loop 最好沉淀成项目内的 runbook、skill、script 或命令模板。

比如一个内容更新 loop 可以这样定义：

读取 AGENTS.md 和相关文章风格
核验来源
新增 MDX 文件
检查 frontmatter
检查 related slug
检查非法标签
运行 pnpm typecheck && pnpm lint && pnpm build
自我 review
提交并 push

这比每次手写“帮我写一篇文章，顺便检查一下”可靠得多。

Loop Engineering 的一个关键价值，就是把人的隐性经验变成 agent 可执行的显性流程。

3. Builder 和 Reviewer 必须分开

同一个模型刚写完代码，通常会倾向于相信自己的结果。让它自评当然有用，但不能把它当作唯一审查。

更好的结构是：

Builder agent 负责实现。
Reviewer agent 只看 diff、风险、测试缺口和边界条件。
Human 负责最终判断产品意图和风险接受。

如果预算有限，至少也要让同一个 agent 切换到不同模式：实现模式只负责改，review 模式必须按 bug、风险、测试缺口的方式审。更理想的是使用不同模型或不同上下文隔离，避免同一套错误假设在 loop 里自我强化。

这也是 Loop Engineering 和 Vibe Coding 的分界线。Vibe Coding 很容易变成“生成一个能跑的结果”；Loop Engineering 必须把“反对意见”和“失败反馈”放进流程。

4. Worktree 隔离是严肃 loop 的基本配置

只要 loop 会持续修改代码，就应该优先使用独立分支或 worktree。

原因很简单：Agent 很擅长局部执行，但不擅长天然保护人的工作区。它可能生成中间文件、格式化大量文件、修改无关模块、运行脚本产生缓存。隔离环境可以让探索更激进，也让回滚更简单。

理想设置是：

每个 loop 一个分支或 worktree。
每个 loop 有明确任务 ID。
生成的文件、日志和验证结果可追踪。
合并前必须过 review 和测试。

这听起来像传统工程流程，但正因为 Agent 更快，隔离才更重要。

5. 给 loop 预算和权限，不要给它无限自由

Loop 最容易被低估的成本是 token、时间和注意力。

一个包含多个 sub-agent、联网搜索、构建、测试、review 的 loop，很容易消耗大量 token 和计算资源。更危险的是，Agent 如果没有明确停止条件，会在局部错误上反复尝试，生成越来越复杂的修复。

实践上应该设置：

最大迭代次数
最大运行时间
最大 token 或 API 成本
最大文件修改范围
必须人工确认的操作列表
连续失败后的停止规则

权限也一样。能读代码不等于能改代码，能改代码不等于能提交，能提交不等于能 push，能 push 不等于能部署。

一个成熟 loop 的权限应该是逐级开放，而不是默认全开。

6. 记录 loop 的过程，而不只是结果

传统开发里，commit 和 PR 记录了结果，但 Agent 工作还需要记录过程。

至少应该保留：

初始目标
使用的上下文
关键决策
运行过的命令
验证结果
没解决的问题
人工介入点
成本和耗时

这不是为了形式主义，而是为了复盘。Loop Engineering 如果不能被复盘，就无法优化。你不知道哪个步骤浪费 token，哪个验证最有效，哪个上下文最容易误导 Agent，哪个权限边界最危险。

四、一个实际可用的 Loop 模板

我会把日常软件开发里的 loop 设计成这样：

Plan

读取项目约束、用户目标、相关文件和历史实现。输出不超过 5 步的执行计划，明确非目标和验证方式。

Act

按最小可行修改执行，不做无关重构。每次修改后记录改了什么、为什么改。

Verify

运行项目规定的最小验证集。比如 TypeScript 项目至少跑 typecheck、lint、相关测试；前端改动再跑 build 和截图检查。

Review

切换到 reviewer 视角，只看 diff。重点查四类问题：行为回归、边界条件、测试缺口、长期维护风险。

Repair

如果 review 或验证失败，回到 Act，但只修复已发现问题，不扩大范围。

Stop

满足验收标准后停止；连续失败超过阈值也停止；遇到权限、生产数据、破坏性命令必须停止并请求人确认。

这个模板看起来朴素，但可执行。Loop Engineering 不需要一开始很复杂，重点是每个环节都有明确输入和输出。

五、Loop Engineering 的误区

第一个误区是把 loop 当成无限自动驾驶。

真正可靠的 loop 不是不需要人，而是减少人做重复调度的次数。人仍然要定义目标、设定边界、判断取舍、批准高风险动作。

第二个误区是用更多 agent 解决所有问题。

Sub-agent 很有用，但每增加一个 agent，就增加一次上下文分裂、成本消耗和协调复杂度。只有当第二视角能提供明确价值时，才值得加 sub-agent。比如安全 review、架构审查、视觉检查、测试生成。

第三个误区是过早追求通用 loop。

“维护整个仓库”“每天自动优化项目”听起来很酷，但边界过宽，验证困难，容易产出噪音。更好的路线是从小 loop 开始，逐步积累可复用协议。

第四个误区是让 Agent 自己决定正确性。

Agent 可以解释为什么它认为自己做对了，但正确性必须尽量交给外部系统：测试、类型系统、构建、静态分析、截图、真实数据回放、人工 review。

第五个误区是忽略组织责任。

Loop 做错了，责任不会落到模型身上。代码是谁合并的，系统是谁部署的，数据是谁泄露的，事故是谁处理的，最终仍然是人和组织负责。

六、我对 Loop Engineering 的观点

我认可 Loop Engineering 这个方向，但不认为它是一个神奇新范式。

更准确地说，它是软件工程在 AI Agent 时代的一次回归：回归反馈、验证、隔离、权限、日志和责任。

过去大家过度关注 prompt，因为模型主要通过对话交付结果。现在模型能调用工具、持续执行、分派任务，于是工程重点自然从“怎么问得更好”转向“怎么让它在一个可靠系统里工作”。

这不是弱化工程师，而是提高了工程师的要求。

会写 prompt 只是入口。真正有价值的是会设计 loop：知道哪些任务可以自动化，哪些任务必须人工判断，哪些验证可以机器完成，哪些风险必须提前阻断，哪些上下文应该沉淀成 skill，哪些成本值得花，哪些成本只是噪音。

我最警惕的是一种反向幻觉：因为 Agent 能自己循环，所以人可以放弃理解。这个想法很危险。Loop 越强，人越应该理解系统边界；Agent 越自主，验证和权限越重要。

如果说 Vibe Coding 的风险是“它能跑，所以我就信了”，那么 Loop Engineering 的风险是“它会反复跑，所以我更信了”。但重复不等于正确，自动化也不等于可靠。

真正成熟的 Loop Engineering，应该让 Agent 更快暴露问题，而不是更快掩盖问题。

七、最适合落地 LE 的团队画像

不是所有团队都应该马上上复杂 loop。

最适合的团队通常有几个特征：

已经有稳定测试、lint、build 和 CI。
任务有大量重复模式。
代码库边界清楚。
团队愿意写 runbook 和工程约定。
有人能 review Agent 结果。
对成本和权限有基本治理。

最不适合的团队也很明显：

没有测试。
没有代码规范。
需求经常靠口头变化。
权限和数据边界混乱。
管理层只想用 AI 降低人力成本。
出问题后没人能负责。

Loop Engineering 会放大组织已有的工程能力。工程纪律好的团队会被放大；工程纪律差的团队也会被放大，只是放大出来的是混乱。

结论

Loop Engineering 的价值不在于让人少写几条 prompt，而在于把 AI Agent 放进一个可重复、可验证、可复盘的工作系统里。

它的核心不是“让 Agent 自己干”，而是“让 Agent 在正确边界里反复改进”。

最佳实践可以概括成一句话：

小 loop 起步，硬验证兜底，权限逐级开放，builder/reviewer 分离，失败必须停止。

我对 LE 的最终判断是：它会成为 AI Coding 进入真实工程后的关键能力，但它不会取代软件工程。相反，它会让软件工程里最朴素的东西变得更重要：清晰目标、可靠反馈、可控权限、自动验证、人工责任。

会设计 loop 的工程师，不是在把工作交给 AI，而是在把 AI 纳入工程系统。

这才是它真正有价值的地方。

文章摘要

Loop Engineering 是为 AI Agent 设计可重复工作循环的工程方法，不是更高级的 prompt 写法。
一个好的 loop 至少包含目标、上下文、工具边界、执行环境、验证器、反馈路径和停止条件。
最佳实践是从低风险、高重复、可验证的小任务开始，而不是直接让 Agent 维护整个仓库。
Builder 和 Reviewer 应该分离，worktree 隔离、预算限制、权限分层和过程日志都是严肃 loop 的基本能力。
Loop Engineering 的最大风险是把自动循环误当成正确性；真正的正确性必须依赖外部验证和人工责任。
核心观点：LE 不会取代软件工程，它会让反馈、验证、隔离、权限和责任这些传统工程能力更重要。