上一篇聊完 Harness Engineering（驾驭工程）之后，很多同学问小马：把 AI 套上"马具"是不是就到头了？其实还差一步——马套好了，但每走一步还得人吆喝一声"驾"。这一篇小马就来聊聊怎么让这匹马自己沿着轨道跑完全程，也就是在 Harness 之上再进一化的 Loop Engineering（循环工程）。

引言

在上一篇《Harness Engineering 落地实践方法论》里，小马把 mydemoPro 这个真实业务项目的驾驭工程环境从零搭了一遍——规则、技能包、工作流、Hooks、子 Agent、可观测性，六大要素齐活，AI 在轨道上不乱跑了。

但用了一段时间，小马发现一个新的"体感痛点"：流程虽然规范，可每一步都得我推一把。 AI 做完需求评审停下来问我，做完设计又停下来问我，写完代码还问我要不要测……这一连串"确认"里，有相当一部分我其实根本不需要看，纯粹是流程要求我点个头。单人开发、需求又明确的时候，这些等待就是纯摩擦。

于是小马就想：能不能让 AI 自己把整条流水线跑完，只在真正危险的地方（改业务代码、部署、提交）才回来找我？跑错了它自己重来，而不是停在那干等我？

这就是这一篇的主角——Loop Engineering。它不是要推翻 Harness，而是长在 Harness 之上的一层"自动挡"。小马已经在 mydemoPro 上把它跑通了，下面就来聊聊这个"自动挡"是什么、为什么要装、以及具体怎么装。

第一章：什么是 Loop Engineering

1.1 先讲人话

想象你带一个很能干的实习生做事，有两种带法：

带法 A（手动挡）：他每做完一步都停下来问你——“这步对吗？”“能下一步吗？”"要提交吗？“你得全程盯着，一句句"可以、继续、好的”。他很安全，但你很累。

带法 B（自动挡）：你把任务交给他，他自己一路做下去，只在真正重要的关口（要动线上数据、要花钱、要对外发布）才回来问你一句。做错了他自己重来，而不是卡在那等你。

Loop Engineering，就是把 AI 助手从"带法 A"升级到"带法 B"的一套工程方法。

1.2 定义

用一句正式点的话：

Loop = 让 AI 在一条有护栏的轨道上，自主地循环推进「做事 → 检查 → 修正 → 继续」，只在高风险关口请求人工，失败时能自我修复，而不是每一步都等人。

记住三个关键词，后面反复出现：

• 自主推进：AI 自己往前走，不用人一步步推。
• 护栏 / 关口：危险的地方有硬拦截，AI 越不过去。
• 自我修正：做错了自动重来，不是停下来等。

1.3 Loop 与 Harness 的关系

这一点最关键，也最容易被误解——Loop 不是 Harness 的替代品，而是它的"上一层"：

一句话：Harness 让 AI 不越界，Loop 让 AI 在界内自己跑完全程。 这俩是递进关系，不是二选一。

第二章：为什么要用 Loop

2.1 它解决的痛点：线性流程的"仪式性等待"

如果你已经建好了 Harness（像上一篇那样），一次典型的任务会长这样：

我：开始吧            → 等我确认
AI：需求理解好了      → 等我确认
AI：方案设计好了      → 等我确认
AI：代码写完了        → 等我确认
AI：要测试吗          → 等我确认
AI：要发布吗          → 等我确认

每个环节 AI 都停下来等一句"好的/继续"。问题是——这里面很多确认是仪式性的，我并不需要真的看，只是流程卡在那要我点头。

Loop 要干掉的就是这些摩擦：

一句话价值：Loop 把"人陪着 AI 走"变成"AI 自己走、人只在关键处出现"，在不牺牲安全的前提下，把仪式性等待砍掉。

2.2 一个必须强调的前提

⚠️ Loop 不是让 AI 脱缰。 恰恰相反——只有当你的约束足够可信（危险操作真的拦得住），你才敢放手让它自己跑。

所以这里有个反常识但很重要的结论：Loop 之所以能做得简单，正是因为 Harness 已经足够扎实。 后面第三章会展开。

第三章：做 Loop 的前提——先有"地基"，再修"传送带"

这是最容易被忽略、也最重要的一点：

Loop 不是从零开始的，它是长在一套已有约束体系（也就是上一篇的 Harness）之上的。

打个比方：

• Harness（地基） = 你把每个"零件"（需求评审、写代码、测试、部署……）都造好了、验证过了，还装上了安全阀（危险操作拦得住）。
• Loop（传送带） = 你加一条传送带，把这些零件按顺序串起来自动流转。

造传送带很简单，难的是先把零件造扎实。 所以做 Loop 之前，先确认你的 Harness 已经具备这三样地基：

如果这三样还没齐，先别急着做 Loop，回去把 Harness 补扎实——这部分正是上一篇讲的内容。

第四章：Loop 的四个核心要素

有了地基，一个 Loop 由四个部件组成。记住这句话，就记住了整个 Loop：

一个技能包驱动 AI 循环，一个状态机脚本控制流转，一条规则声明红线，而每个阶段的活儿都复用已有能力（引用，不重写）。

拆开看。

4.1 要素一：驱动器（技能包 Skill）——告诉 AI 怎么循环

这是给 AI 读的一份"说明书"，核心是一张 「阶段 → 用哪个已有能力」的委派表：

关键点：Loop 不重新实现任何一个阶段，它只负责"到第几步就去调第几个已有能力"。这张表就是 Loop 和 Harness 之间的"缝合线"，也是整个 Loop 工程最大的连接点——不是在规则里加逻辑，而是在这张委派表里做引用。

4.2 要素二：状态机（一个脚本）——控制"下一步走哪"

这是一个确定性的小程序（小马在 mydemoPro 里用几百行 Python 就写完了），它不干活，只做两件事：

• 记账：现在走到第几步、每步结果是啥、重试了几次——全部存到文件里（断电重启也不丢，可恢复）。
• 裁判：根据"当前在哪步 + 这步结果"，确定性地算出下一步该干嘛：
  • 成功 → 前进到下一步
  • 失败 → 回退到能修复的那一步，重来（有次数上限）
  • 遇到关口 → 拦住，等人放行
  • 试太多次 / 循环太久 → 暂停，叫人

严格说，这个脚本就是一个确定性有限状态机（DFSM）：给定"当前状态 + 输入"，下一状态唯一确定，没有随机性。这也是它能被信任去"裁判" AI 的前提。

这里有两个细节值得单独说说，因为它们是 Loop"能自愈、能恢复"的关键：

① 失败不是终点，而是一条"回边"。 Loop 最有价值的能力就是"失败自己修"。最典型的场景是测试失败——脚本不会停下来等人，而是自动把状态回退到"写代码"那一步，把失败信息回灌给 AI 让它修，修完再测，直到通过或用完重试次数：

写代码(通过) → 测试(失败，2 处)
             → 脚本自动回退到"写代码"（第 1/2 次重试）
             → 写代码(修复) → 测试(通过) → 继续前进

这就把过去"测试挂了 → 人工介入 → 手动重跑"的三步，压缩成了循环内部的一次自动重试。

② 状态落盘，断了能接上。 循环状态不藏在聊天记录里，而是写到文件（一份当前快照 + 一份追加式事件日志）。这样即便进程中断、会话断开，也能凭事件日志"重放"出当前进度接着跑。这一点和 Harness 的"可观测性"一脉相承——过程可查、可审计，不是黑盒。

为什么用脚本而不是让 AI 自己判断下一步？因为脚本是确定的、可测试的、不会"想偏"。AI 负责干活和报告结果，脚本负责裁判和记账，各司其职。用比喻说：AI 是司机，脚本是轨道 + 记录仪 + 闸机。

4.3 要素三：护栏规则（一条 Rule）——划死红线

明文声明哪些是绝对不能越过的红线，交给脚本强制执行。小马在 mydemoPro 里落了四道护栏：

任一护栏触发，循环立即暂停，并输出"为什么停 + 人工该怎么做"，绝不闷头往下跑。

其中要特别强调：

• "发布 / 提交"这类不可逆操作永远不能自动放行，必须人拍板——这是上一篇 Harness 里"Git 提交必须确认"规则的直接延续。
• 循环上限（步数 + 重试）是防"跑飞"的保命绳：没有它，AI 可能陷入"改了测、测了改"的死循环，或无限往下推。

4.4 要素四：复用已有能力——不重复造轮子

前面反复强调了：每个阶段的实际能力，全部引用 Harness 里已有的。好处是——Harness 的能力升级了，Loop 自动享受，不用改 Loop 一行代码。

第五章：通用实践方法论——六步落地一个 Loop

下面是通用步骤，不限技术栈，每步都给出"产出物"，照着做即可。这也是小马在 mydemoPro 上实际走过的路。

5.1 方法论框架

┌───────────────────────────────────────────────────┐
│                Loop Engineering 六步                │
├───────────────────────────────────────────────────┤
│  第 0 步：确认地基（阶段化 + 可信约束 + 可判定验收）  │
│  第 1 步：定义状态机契约（先写文档，不写代码）        │
│  第 2 步：实现状态机脚本（并自测一轮）               │
│  第 3 步：写驱动技能包（给 AI 的说明书 + 委派表）     │
│  第 4 步：写护栏规则（把红线写成明文并登记）          │
│  第 5 步：跑一个真实小任务（先玩具需求验证机制）      │
│  第 6 步：观测与迭代（记录耗时/重试，优化护栏）       │
└───────────────────────────────────────────────────┘

5.2 第 0 步：确认地基

问自己三个问题：流程能拆成清晰阶段吗？危险操作拦得住吗？每步有客观验收标准吗？——三个都"是"才继续。否则回去补 Harness。

5.3 第 1 步：定义状态机契约

先别写代码，先把这些写清楚：

• 有哪些阶段（状态），顺序是什么。
• 每步结果类型：成功 / 失败 / 阻塞 / 跳过。
• 失败回退到哪一步（比如"测试失败退回写代码"）。
• 哪些关口需要审批。
• 护栏参数：最多几步、每步最多重试几次、哪些路径受保护。

产出物：一份"状态机契约"文档，作为唯一权威源。

5.4 第 2 步：实现状态机脚本

按契约写一个小程序，提供几个命令：

loop init   --change <任务名>              # 开一个新循环
loop status                                # 看当前状态
loop advance --phase <阶段> --result <结果>  # 报告某步结果，脚本算下一步
loop gate    --name <关口> --decision <放行/拒绝>  # 记录审批决定
loop reset                                 # 结束

要点：状态落盘（存 JSON + 追加事件日志，支持中断恢复）；关口用返回码硬拦；跨平台注意编码（比如 Windows 控制台的字符编码坑，小马就踩过——状态图标 ✔/✘ 在 GBK 控制台直接报错，得强制 UTF-8）。

产出物：一个可独立运行、可测试的状态机脚本。写完先自测一轮（模拟"卡点拦截 + 失败重试 + 跑到结束"），确认逻辑对。

5.5 第 3 步：写驱动技能包

写清楚：每个阶段委派给哪个已有能力、遇到关口怎么问人、拿到脚本输出后怎么行动。

核心纪律：脚本是状态的唯一权威源，AI 必须听脚本的，不许自己算跳转。

5.6 第 4 步：写护栏规则

把红线写成规则文件，并登记进你的规则清单（比如上一篇的 manifest.json）。这一步让"约束"变成明文，团队可见、可审计。

5.7 第 5 步：跑一个真实小任务

挑一个极小的真实需求（比如"加一个返回固定字符串的接口"）走完整个循环，验证：

• 关口是否真的拦住了？（没放行就想写代码，脚本应该报错拦截）
• 失败是否真的自动回退重试了？
• 状态是否真的存下来了？

小马的建议：先用玩具需求验证机制，再上真需求。 用最小的变更把整条链路（评审→设计→写码→测试→部署→归档）跑通，确认卡点、回退、存档都如预期，再交给它做有价值的活。

5.8 第 6 步：观测与迭代

把循环的耗时、重试热点、暂停原因记录下来，逐步优化护栏参数和回退策略。这和上一篇 Harness 的"可观测性 + 闭环反馈"是一脉相承的。

第六章：常见误区（避坑）

第七章：Loop 在 mydemoPro 上的落地小结

小马在上一篇的 mydemoPro 项目上，按上面的六步实际搭了一套 Loop，交付物很轻量：

然后用一个"加一个返回固定字符串的接口"的玩具需求，端到端跑通了首个闭环——评审对齐、卡点在写代码前拦住等我放行、测试失败自动回退重试、跳过可选阶段、最后归档，全程按状态机走，一步没跑偏。

为什么这么轻量就搞定了？ 因为上一篇把 Harness 的"零件"都造扎实了，Loop 这条"传送带"只是把它们串起来——Loop 的简单，是 Harness 前期投入的一次低成本、高回报的兑现。

7.1 一段自测跑批实录（脱敏）

光说不练假把式。状态机脚本写完，小马先用一轮"含卡点拦截 + 失败重试 + 跳过可选阶段"的批命令自测了一遍，把机制逐条验证。大致长这样（命令已脱敏简化）：

# 1. 初始化一个循环
loop init --change selftest --goal "自测"

# 2. 评审、设计通过，正常前进
loop advance --phase review  --result pass
loop advance --phase propose --result pass

# 3. 没放行"写代码"关口就想写代码 → 被脚本硬拦（退出码 2）✔
loop advance --phase apply --result pass
   → BLOCKED: 进入 apply 需要先放行 apply_write 关口

# 4. 放行关口 → 写代码通过 → 测试失败 → 自动回退到写代码（第 1/2 次重试）✔
loop gate    --name apply_write --decision approve
loop advance --phase apply     --result pass
loop advance --phase unit_test --result fail --note "2 处失败"
   → 测试失败，自动回退到 apply 修复（retry 1/2）

# 5. 修复后通过 → 放行部署 → 跳过可选阶段 → 放行提交 → 归档 → 完成
loop advance --phase apply     --result pass
loop advance --phase unit_test --result pass
loop gate    --name deploy     --decision approve
loop advance --phase verify    --result skip
loop gate    --name commit_push --decision approve
loop advance --phase archive   --result pass
   → LOOP DONE：整条闭环走通

四个关键行为一次验证到位：卡点强制拦截、失败自动回退重试、可选阶段跳过、跑到 DONE。先用这种"手工喂结果"的方式验证状态机本身，再交给 AI 真正驱动——这样出了问题好定位是脚本的锅还是 AI 的锅。

7.2 几个刻意的设计取舍

小马落地时踩过、也想清楚了几个点，分享给你少走弯路：

• 脚本是权威源，AI 不许自己算跳转：所有前进/回退/暂停都由脚本说了算，AI 只按脚本输出行动。这是避免"AI 自作主张跳过失败阶段"的关键。
• 提交/发布关口永不自动放行：不可逆动作必须人拍板，哪怕测试全绿。
• 部署关口可"条件预放行"：当测试全部通过时，可以由规则自动放行部署关口，少一次仪式性确认；但部署这个动作本身仍在关口体系内可控。
• 跨平台编码坑：状态图标（✔/✘）在 Windows 的 GBK 控制台会直接报错，脚本启动时得强制把输出设成 UTF-8。这类跨平台小坑，和当年 Hook 从 Bash 改 Python 是同一类教训。

7.3 老实交代：已知边界

Loop 不是银弹，小马目前这版还有几处没做完，一并说清楚：

• 审批还是同步的：关口放行目前是"当面点头"，多人协作场景需要改成异步审批（比如消息待办），否则没人响应就卡住。
• 自愈还比较浅：失败目前只做"回退重试"，还没做到"把失败根因自动固化成一条新规则"——那是闭环反馈的下一步。
• 观测面板还没接 Loop 视图：循环耗时、重试热点这些数据已经落盘了，但还没在仪表盘上画出来。

把边界摊开讲，是因为 Loop 本来就是"一边实践一边进化"的东西——先跑通最小闭环，再逐步补齐，这本身就符合上一篇讲的"闭环反馈"精神。

7.4 后续路线

规划中的演进：

Phase 0~1（已完成）：状态机 + 编排器 + 技能包 + 护栏  ← 本次
        ↓
Phase 2：自动反馈回路 —— 失败根因固化为规则/记忆
        ↓
Phase 3：企微异步审批 —— 卡点放行改为异步待办，无人值守
        ↓
Phase 4：仪表盘 Loop 视图 —— 循环次数/收敛率/重试热点可视化

总结

有同学可能又要问了：讲了这么多，Loop 到底难不难？小马的答案是——Loop 本身不难，难的是它下面的 Harness。 只要你上一篇的驾驭工程搭扎实了（阶段清晰、约束可信、验收可判定），加一层 Loop 往往就是"临门一脚"。

再浓缩成三句话给你带走：

• 什么是 Loop：让 AI 在有护栏的轨道上自主循环推进，只在高风险关口找人，失败能自愈。
• 为什么用 Loop：砍掉线性流程里大量仪式性等待，让 AI 自己跑完全程——前提是约束已经可信。
• 怎么做 Loop：先确认地基，再搭四件套（技能包驱动 + 状态机脚本 + 护栏规则 + 复用已有能力），六步落地。

最后送一句小马自己很喜欢的心法：

Harness 让 AI 不越界，Loop 让 AI 在界内自己跑完全程；脚本给它轨道，Skill 给它路线，规则给它红线。

跟上一篇一样，Loop 目前也没有什么官方标准框架，都是一边实践一边进化的。理解了概念，完全可以借助 AI 一步步把自己的 Loop 环境搭起来——挑个最小的任务，照着六步跑一遍，你就迈出第一步了。

不懂的、想交流的，还是老规矩，可以联系小马哈。这算是上一篇《Harness Engineering 落地实践方法论》的续写第二篇，建议两篇结合着看。