Loop Engineering实用指南：先写刹车，再写循环

很多团队一听到 Loop Engineering，第一反应是“让 Agent 持续跑起来”。但真正能落地的关键，不是转起来，而是停得住、交得回、验得过。

如果把它当成一套工程能力，最重要的不是多写几条 prompt，而是先把循环的边界写清楚：什么时候触发、能做什么、怎么验证、什么时候停止、失败后怎么交给人。

先给结论：Loop 不是自动化口号

Loop Engineering 可以理解成一个小型运行时系统。它不是单次对话，也不只是定时任务，而是“触发、执行、验证、记录、继续或停止”的完整闭环。

一个靠谱的 loop，至少要回答四个问题：

• 输入是什么，来源是否可靠；
• 权限到哪里，能不能隔离执行；
• 怎么判断做对了，验证依据是什么；
• 什么情况必须停下，什么情况必须交给人。

这也是为什么很多团队会先从 CI分流、事实核验、文档漂移这类低风险场景开始，而不是一上来就碰核心业务。

一个可用 Loop 的最小结构

要让 loop 真正可用，通常需要 6 个部件：

• 触发器：定时、事件、人工请求，或者目标未完成；
• 执行器：负责真正去读、改、提议；
• 验证器：用测试、lint、对账、审查去确认结果；
• 状态账本：记录每一轮做了什么、失败在哪；
• 权限边界：明确哪些目录、仓库、系统可读可写；
• 停止条件：轮数、时间、预算、无进展阈值。

其中最容易被忽略的是验证器和状态账本。没有验证器，Agent 很容易自我感觉良好；没有状态账本，上一轮做过的判断不会被记住，下一轮可能重新踩坑。

如果想给团队一个直观模板，可以直接记住一句话：先写刹车，再写循环。

三类常见 Loop，落地顺序别搞反

实际使用中，Loop Engineering 常见的形态可以分成三类，建议按难度递进。

1. 提醒型 Loop

它主要负责发现问题，不直接修改结果。典型例子有：

• 定时扫描失败 CI；
• 整理新增 issue；
• 汇总当天的线上错误；
• 生成技术选题候选。

这类 loop 最适合入门，因为它以读为主，输出的是待处理清单，风险最低。

2. 修复型 Loop

它会在隔离环境里尝试修复问题，比如自动修 flaky test、补测试、改文档链接、做小范围依赖升级。这里必须配好 worktree、测试和人工审查，不能直接合并。

如果团队还没有稳定的验证机制，先别把修复范围放大。很多失败不是 Agent 不够聪明，而是边界没画清。

3. 演进型 Loop

这一类最强，也最危险。它会持续发现新任务、规划、分派、验证，并把状态写回系统。它适合成熟团队，但前提是权限、预算、复盘都已经跑顺。

更稳的路径通常是：提醒型 -> 修复型 -> 演进型。顺序不要反。

最适合先落地的两个场景

如果团队准备做第一版 loop，最推荐从低风险、可验证、可回收的场景开始。

场景一：CI 分流

CI 场景天然适合 loop，因为它有明确反馈：日志、测试结果、退出码、commit 变化都能直接读到。

一个稳妥的设计可以这样写：

• 每天固定时间检查失败的 CI；
• 读取失败 job、最近几个 commit、相关测试文件；
• 先做归类，再尝试低风险修复；
• 验证目标测试、lint 和 type-check；
• 最多跑 3 轮，连续无进展就停止。

如果问题涉及权限、计费、数据库迁移、安全配置，直接升级给人处理，不要继续自动推进。

场景二：写作核验

内容团队也很适合做 loop，比如技术稿、产品稿、访谈稿的事实核验。它的优势是读取成本低，出错代价也相对可控。

一个核验 loop 可以做这些事：

• 抽取文稿中的事实断言；
• 对照官方文档、公开讨论、代码仓库；
• 标注哪些结论证据充分，哪些风险较高；
• 输出修改建议，而不是直接替作者定稿。

这类 loop 的价值不只是省时间，更是把“事实”和“观点”分开，减少转述误差。

成本要前置，不要后补

Loop 和普通 prompt 最大的差别，就是成本会乘法增长。一次 prompt 是一次性花费，loop 可能是几十轮、几百轮的持续调用。

所以在设计时，一定要提前写预算上限：

• 最大运行时长；
• 最大迭代轮数；
• 最大 token 或金额；
• 最大无进展轮数。

最重要的是“无进展检测”。如果连续两轮没有新增证据、没有缩小问题范围、也没有任何验证通过，就应该停下来，把结果交给人。

这比让系统继续“优化”更省钱，也更安全。

别自写自审，验证要拆开

Loop 最容易出问题的地方，是让同一个执行者既写又判。这样很容易把判断标准放松，最后看起来流程完整，实际上问题没解决。

更稳的方法是把验证拆开：

• 确定性验证：测试、lint、type-check、链接检查、schema 校验；
• 环境验证：截图、对账、只读检查；
• 主观验证：由 reviewer agent 或人工复核。

如果使用 reviewer agent，提示不要写成“看看有没有问题”，而要写成检查表。它的职责是判定，不是修复。

执行者和验证者边界越清楚，loop 越不容易跑偏。

什么时候别用 Loop

Loop Engineering 不是所有场景都适合。以下几种情况，建议先暂停：

• 目标每天都在变，系统会追着噪声跑；
• 验证只能靠感觉，无法形成证据；
• 需要生产写权限，错误影响太大；
• 团队没人愿意看结果，输出没人接；
• 一次性任务，自动化成本高于收益。

尤其是“团队没人读结果”这一条。很多 loop 失败，不是 Agent 不行，而是人的流程没有接住它。它开了 PR，没人 review；它写了报告，没人确认；最后只会堆出新的噪声。

一个能直接拿去用的设计表

如果要快速启动，可以先把下面这些信息写全：

• Loop 名称：一句话说明负责什么；
• 业务目标：降低哪类重复成本；
• 触发方式：定时、事件、人工、目标未完成；
• 输入来源：日志、issue、PR、文档、代码、监控；
• 可读范围：哪些仓库、目录、系统可访问；
• 可写范围：默认只读还是可写；
• 隔离方式：worktree、临时分支、沙箱；
• 验证方式：测试、lint、截图、reviewer agent；
• 状态账本：每轮结果写到哪里；
• 成本上限：时间、轮数、token、金额；
• 停止条件：失败、无进展、超预算、触碰禁区；
• 人工升级：哪些情况必须交给人；
• 复盘入口：失败经验如何回写规则。

这张表填不全很正常。填不出来的地方，往往就是系统还没准备好的地方。

最后的建议

Loop Engineering 的本质，不是让 Agent 一直跑，而是让它在正确的边界里跑，并且在该停的时候停。

对团队来说，最短的行动建议只有一句：先问清楚它跑偏时谁来发现，跑贵时谁来停，做完时谁来验收。答案明确了，再写循环。

如果把 Agent 当成能持续行动的协作对象，真正要补的不是“更强的 prompt”，而是目标、权限、证据和预算这四条线。边界写清了，循环才会成为生产力；边界写不清，它只会更快放大问题。