Loop Engineering：让 AI 自主闭环运转（模式）

摘要：Loop Engineering（循环工程）的目标不是写得更快，而是让你从维护循环里撤出来。核心洞察：能跑起来的循环不等于有用的循环 —— 循环的本质是生成器接上验证器，没有验证器，自动化只是在更快地烧 token（stated）。实战效果：一周 ERROR 总量下降 96%、同类问题修复时间从 48 分钟降到 15 分钟、到预发 0 人工介入（stated）。

定义

Loop = 在 Harness 之上加上定时调度、子 Agent 并行、跨轮记忆三件事，让 AI 自主发现工作、验证结果、记住经验（stated）。

跨越单次对话的记忆，是"循环"和"一次性操作"的分界线（stated）。

与 Harness 的本质区别：Harness 是一次运行的武装（工具、动作、完成条件）；Loop 在 Harness 之上补上自动发现、验证、持久化与调度。

四代 AI 工程化范式演进

层	能力	典型
第 1 层 Prompt	教说话：单次问答式执行	ChatGPT 对话排查
第 2 层 Context	摆材料：喂代码库/文档/日志	Cursor 带 codebase 索引
第 3 层 Harness	配工具：Shell/MCP/Git 权限，自己干活	Claude Code 单次会话修 Bug
第 4 层 Loop	写 SOP 让他自己转：自动发现/修复/验证	本文实践

上层包含下层所有能力，每层解锁新瓶颈。选范式前先问：你的任务卡在哪一层瓶颈（stated）。

Loop 填上维护循环的三个断裂点（stated）：

• 看不见 → 发现（Connectors + Automations）
• 记不住 → 持久化（State + Skills）
• 没闭环 → 验证（Sub Agents）

五动作：Loop 持续运转的闭环

发现（找出该做的事）→ 交付（隔离交给 Agent）→ 验证（换个 Agent 说不）
→ 持久化（状态写到对话外）→ 调度（一圈圈自动转）

调度是最后一块拼图：没有自动化，循环就不是循环，只是一次性操作（stated）。

四格检验：该不该建 Loop

建 Loop 有 setup 成本（写 Skill、接 Connectors、调验证器），四格全满才值得建（stated）：

1. 任务会重复（如每天跑）
2. 验证能自动化（如 334 条测试 + 多层验证）
3. Token 预算可承受（单次耗费可预估）
4. Agent 有高级工程师的工具（日志/追踪/发布全通）

反例：一次性架构评审、"提升用户体验"这类目标模糊的探索 —— 任一条件缺失就不该建。

六组件：拼成完整闭环

组件	作用	解决痛点
Connectors	感知：MCP 打通日志/追踪/发布，让 Agent 看见线上世界	看不见
Automations	驱动：定时巡检（抓慢性）+ 实时告警（抓突发）	看不见
Skills	SOP 磁盘化：诊断/修复/发布经验固化为可复用操作手册	记不住
Worktrees	隔离：Git worktree 每 Bug 独立工作区，并行修复互不覆盖	并行冲突
Sub Agents	裁判：六层独立验证，修复者不能给自己打分	没闭环
State	记忆：修复方案/巡检结果/基础设施配置落盘	记不住

实施依赖顺序：Connectors（地基）→ Automations → Skills → Worktrees → Sub Agents → State。缺一个，后面的都站不住（stated）。

实战设计要点（日志诊断闭环）

诊断 Skill：8 阶段结构化诊断（760 行 SKILL.md）

• 每个 Phase 规定工具/数据/输出格式/不可跳步骤（不写死规则 Agent 就偷懒）
• Phase 2 git log 交叉验证：区分"新问题"还是"老毛病突然恶化"
• Phase 6 结构化根因推理链：[事实]→[推理]→[结论]，六类根因（外部系统/内部缺陷/基础设施/LLM 异常/预期行为/数据问题）各配修复方向

修复 Skill：6 步自动生成补丁

• 先查知识库再动手：30+ 条修复方案（YAML）命中直接复用（连接池问题首次 48 分钟，有知识库后 15 分钟）
• 修复原则：最小化改动、保持向后兼容；测试不过最多 3 轮重试，超 3 轮自动升级人工（stated）

发布 Skill：11 步到预发全自动（生产发布唯一人工环节）

• Step 0 安全校验（仓库+App ID 三重匹配）、Step 4 集成测试必须聚焦（指定 skill_names）、Step 5-7 自主回归三层验证（Trace 硬指标/独立诊断复查/预发 vs 线上对比）
• Langfuse Trace 四项硬指标：ERROR=0、主模型一致（无非预期 fallback）、token<150K、Agent finished=True

Sub Agents：六层独立验证

Lint → 单元测试 → 预发日志（无新增 ERROR 类型）→ 线上对比 → 集成测试 → UI 验证。

• 只靠单元测试，logger.error→warning 的假修复完全能过；第 3 层预发日志验证专抓日志降级类假修复（stated）

Worktrees：并行修复

Git worktree 同一仓库多工作目录物理隔离；三类问题串行 45 分钟 → 并行 17 分钟；冲突率从 ~30% 降到 <5%（stated）。

范式迁移：工程师角色的转变

Prompt 时代你是指令官，Context 时代你是材料员，Harness 时代你是工具配置师，Loop 时代你是循环设计师（stated）。

Boris Cherny 一天提交 150 个 PR —— 不是写代码更快，而是设计了让 Agent 自己转的循环（stated）。

四条血泪教训

1. 连续两周不看 diff 就合并 → Agent 把 retry=3 改成 retry=0 导致线上超时翻倍；对策：每周至少抽查 3 个 diff
2. 验证器覆盖不全 = 假安全感 → 初版只有单测，假修复全靠第 3 层预发日志验证兜底；对策：至少 3 层验证才能自动合并
3. Token 成本失控 → 全量诊断 200K+ token 烧爆预算；对策：分级策略（小模型初筛 5K token，高优问题才大模型深诊）+ 预算熔断
4. Connectors 建设被低估 → 工具链占总工作量 30%；对策：先花两周打地基再建上层

四周落地计划

周	做什么	验收标准
1	四格检验 + 选场景	四格全满
2-3	建 Connectors（日志/监控/发布）	一条命令跑通全链路
4	写第一个 Skill + 定时调度	连续 3 天无人值守运转

核心启示

别再当循环里最慢的那一环 —— 去设计循环（stated）。 Loop Engineering 不是一种产品，而是一种工程思维：不问"这条 prompt 怎么写更好"，而是问"这个循环能不能自己转"。

关联词条

• Harness（智能体执行框架）（concept）
• Harness 工程搭建式业务 Agent 评测（pattern）
• Harness Engineering 与知识工程：数据研发落地实践（pattern）
• Harness 专题总览（overview）