【AI】Loop Engineering 实践指南：从手动提示到自主循环系统
Loop Engineering 实践指南：从手动提示到自主循环系统
PS:我给自己本地的项目增加了loop-engineering的逻辑，寻思让AI总结一下也挺好，下面全都是AI总结的
"我已经不给 Claude 写提示词了，我有 Loop 在跑，它们自己决定该干什么。我的工作是写 Loop。"
— Boris Cherny, Claude Code 负责人
一、什么是 Loop Engineering
Loop Engineering（循环工程） 是 AI 编程的最新范式，由 Google Cloud AI 总监 Addy Osmani 系统阐述。它回答一个根本问题：
如何让 AI Agent 不是"一次性完成任务"，而是"持续地、可观测地、可治理地长期运行"？
简单说：你不再手写提示词，而是设计一套系统（Loop），让系统替你去驱动 Agent。
演进路径
Prompt Engineering → 怎么问模型（单次交互优化）
Context Engineering → 模型能看到什么状态/知识
Harness Engineering → 单次 Agent 的工具、权限、沙箱
Loop Engineering → 跨时间的重复系统：发现→委派→验证→记录→再运行
前三层解决"一次跑好"，Loop Engineering 解决"长期跑稳"。
二、核心架构：六大构建模块
┌─────────────────────────────────────────────────┐
│ Loop Engine │
│ │
│ ┌──────────┐ ┌──────────┐ ┌───────────────┐ │
│ │①Automation│ │② Worktree│ │ ③ Skills │ │
│ │ 定时/事件 │ │ 隔离执行 │ │ 固化项目知识 │ │
│ └─────┬─────┘ └─────┬────┘ └───────┬───────┘ │
│ │ │ │ │
│ ┌─────▼─────┐ ┌─────▼────┐ ┌───────▼───────┐ │
│ │④ Plugins │ │⑤SubAgent │ │ ⑥ Memory │ │
│ │ 外部工具 │ │ 对抗验证 │ │ 跨会话状态 │ │
│ └───────────┘ └──────────┘ └───────────────┘ │
└─────────────────────────────────────────────────┘
| 模块 | 为什么重要 | 怎么实现 |
|---|---|---|
| ① 自动化 | Loop 的心跳——没它，Loop 不会自己动 | /loop 指令、cron 表达式、GitHub Actions、webhook |
| ② 工作树 | Agent 之间的"沙箱"——并行干活不打架 | git worktree，每个 Agent 一个独立目录 |
| ③ 技能 | 项目知识外置——Agent 换了，规则还在 | SKILL.md 或 CLAUDE.md，Agent 每次启动自动读取 |
| ④ 插件 | 打通真实世界——Agent 需要连接 Issue、CI、数据库 | MCP 协议、自定义 Tool |
| ⑤ 子 Agent | 生成者和检查者分离——防止"自己写的自己审" | .claude/agents/ 定义审查 Agent，用不同模型 |
| ⑥ 记忆 | Agent 会忘，磁盘不会——跨会话状态持久化 | Memory 文件、状态 Markdown、看板 |
完整闭环
目标(Objective)
│
▼
触发器(Trigger) ← cron / hook / 事件
│
▼
发现工作(Discover) ← 读取 Issue、Commit、状态文件
│
▼
委派 Agent(Delegate) → 隔离执行(Worktree)
│
▼
验证(Verify) ← 测试断言 / 审查 Agent / diff 检查
│
├── 失败 → 反馈给 Agent 重试（最多 N 次）
│
└── 通过 → 记录状态(state.md) → 合入 → 循环回到发现
三、三种驱动模式
| 模式 | 驱动方式 | 什么时候停 | 一句话场景 |
|---|---|---|---|
/goal |
条件驱动 | 独立评估器判定目标达成 | "把这个模块的重构做完，直到测试全绿" |
/loop |
时间驱动 | 手动停止 / 模型判定无须继续 | "每 30 分钟检查 CI 有没有新的失败" |
| Cron 规则 | 定时表达式 | 永久运行 / 设有效期 | "每天早上 9 点巡检所有服务健康状态" |
选择哪个模式？
有明确终态 → /goal
需要持续监控 → /loop 或 Cron
一次性任务 → 普通 Agent
四、停止规则：Loop 最容易被忽略的一环
停止规则（Stop Rules）是 Loop 工程中最关键也最容易被忽略的设计决策。 一个没有停止规则的 Loop，就像一个没有刹车的高速列车——要么永远跑下去烧光 Token，要么在错误的时间停下来。
为什么不能靠 Agent 自己说"完成了"？
Agent 最常见的两个问题：
- 过早完成（Premature Completion）：Agent 做了 80% 就宣告完成，实际上测试还没跑、边界条件没处理
- 无限空转（Infinite Spinning）：Agent 在多轮迭代中原地打转，反复修改同一个文件却没有任何实际进展
七层停止规则
| 层级 | 规则 | 作用 | 示例 |
|---|---|---|---|
| 1. 硬性迭代上限 | 最大循环次数 | 安全网——无论完成与否都必须停 | "最多 20 轮" |
| 2. Token/成本预算 | 单次运行消耗上限 | 防止烧钱 | "本轮预算 $0.50" |
| 3. 停滞检测（断路器） | N 轮无进展则终止 | 防止原地空转 | "连续 3 轮文件无变化则停止" |
| 4. 确定性验证门 | 外部客观标准 | 最重要的停止规则 | 测试全绿 / 类型检查通过 / 构建成功 |
| 5. 目标达成检查 | 客观条件判定 | 任务是否真正完成 | "所有 API 返回 200" |
| 6. 超时控制 | 任务级+调用级超时 | 防止单步卡死 | "单个工具调用 30s 超时" |
| 7. 人类审查节点 | 不可逆操作前需审批 | 安全阀门 | "部署前 / 删库前 / 外部调用前确认" |
两层架构（推荐）
Sonar 提出了一个简洁的两层模型：
第一层：LLM 验证子代理（概率性）
→ 检查意图、语义、"是否真的解决了问题"
→ 这层是建议性的，帮助发现问题
第二层：确定性代码验证（硬门）
→ 测试、构建、类型检查——Agent 无法绕过
→ 这层是真正决定停止的硬门
核心原则：第一层辅助判断，第二层一票否决。
六大停止条件（生产级标准）
来自 loop-engineering 社区的最佳实践，每个 Loop 都应配置：
| # | 停止条件 | 触发条件 | 停止后的动作 |
|---|---|---|---|
| 1. ALL GREEN | 所有验证门通过 | ✅ 停止，附通过证明 | |
| 2. 轮次用尽 | 达到最大迭代上限（通常 5-10 轮） | 🛑 停止，报告每轮尝试了什么 | |
| 3. 连续相同失败 | 同一错误连续 2 轮未变 | 🛑 停止，builder 在"瞎猜"而非修复 | |
| 4. 回归检测 | 修复导致之前通过的检查失败 | 🛑 停止，报告"拆东墙补西墙" | |
| 5. 无实质进展 | 连续 2 轮失败项数量未减少 | 🛑 停止，任务可能需拆分为更小粒 | |
| 6. 超出能力边界 | 失败涉及外部依赖/环境问题 | 🛑 停止，报告阻塞点 + 建议人工介入 |
三条红线（不可违反）
🚫 永远不：在没有 checker 输出的情况下报告成功
🚫 永远不：弱化、删除、跳过检查来"达到" ALL GREEN
🚫 永远不：修改 checker 的工具白名单
这三条红线的本质：Agent 不能既是球员又是裁判。
升级协议
停止时必须携带的信息：
## Cycle 3/5 — 停止报告
### 仍失败的检查项
- [ ] test/user-service.test.ts: 3 个测试超时
- [ ] typecheck: 2 个类型错误
### 已尝试的修复
1. Cycle 1: 修复超时 → 失败（mock 未生效）
2. Cycle 2: 修复 mock 配置 → 仍超时（需数据库连接）
3. Cycle 3: 尝试连接测试数据库 → 环境不可用
### 判断
继续循环不会解决问题。阻塞点是测试数据库需要 DBA 开通。
建议：人工开通测试数据库后重新触发 Loop。
一句话总结
"让 Agent 自己决定何时完成"是一种可能迅速耗尽 Token 的策略。每个生产级 Loop 都需要硬性的、可验证的停止条件，而非依赖 Agent 的自我评估。
五、Loop 成熟度模型
| 级别 | 名称 | 一句话描述 |
|---|---|---|
| L0 | 手动提示 | 人读取状态，手写下一句提示词 |
| L1 | 脚本重试 | Shell 循环把错误日志喂回给 Agent |
| L2 | 定时循环 | Agent 按 cron 运行并报告发现 |
| L3 | 有状态循环 | 进度通过文件跨会话保持，断点续传 |
| L4 | 自验证循环 | 确定性检查或 Agent 跑测试把关 |
| L5 | 多 Agent 循环 | 专用 Agent 分工：发现/实现/审查/判定 |
| L6 | 生产监管 | 可观测性 + 预算 + 审批 + 回滚全覆盖 |
大多数项目从 L2/L3 开始就能获得明显收益。
六、实战：搭建你的第一个 Loop
第 1 步：创建状态文件（L3 — 跨会话记忆）
# .claude/state.md
## 当前阶段
用户模块开发中
## 已完成
- [x] 登录接口
- [x] 数据库迁移
## 下一步
- [ ] 用户 CRUD 接口
- [ ] 前端用户列表页
## 上次会话结束状态
- 后端：运行中 (8080)
- 前端：运行中 (3000)
- 数据库：已迁移，种子数据就绪
第 2 步：创建技能文件（Agent 的"入职文档"）
# .claude/SKILL.md
## 项目约定
- 提交格式: feat:/fix:/docs: 前缀
- 一次只做一个模块
- 每个模块完成后写 DevLog
## 启动后自动执行
1. 读取 state.md 了解上次进度
2. 检查服务是否运行
3. 继续推进"下一步"中的第一个任务
第 3 步：设置定时 Loop（L2 — 自动触发）
# 每天早上的健康检查
/gloop 9:00 "检查所有服务状态：Docker容器、后端、前端。如有异常尝试自动恢复并报告。"
# 每 30 分钟的 PR 监控
/loop 30m "检查是否有新的 Review Comment，如有则自动修复并回复。"
第 4 步：配置对抗验证（L4/L5 — 质量把关）
# 一个 Agent 实现功能
agent "实现用户删除接口，包含软删除和回收站逻辑" --worktree
# 另一个 Agent 审查（可用不同模型）
agent "审查代码：检查SQL注入风险、边界条件、权限校验" --worktree
第 5 步：连接外部工具（MCP）
让 Agent 连接真实世界：
- 连接 Issue Tracker → 自动读取待办
- 连接 CI/CD → 自动响应构建失败
- 连接 Slack → 完成后通知团队
七、7 种生产级 Loop 模式
| 模式 | 做什么 | 触发 | 成本 |
|---|---|---|---|
| Daily Triage | 每天早上自动巡检 | 定时 | 低 |
| PR Babysitter | 监控 PR Review，自动修复反馈 | PR 更新 | 高 |
| CI Sweeper | 构建失败自动定位+修复 | CI 失败 | 非常高 |
| Dependency Sweeper | 扫描过时依赖，自动开 PR 升级 | 定时 | 中 |
| Changelog Drafter | 合并后自动起草更新日志 | Merge 事件 | 低 |
| Post-Merge Cleanup | 合并后清理 TODO/临时代码 | Merge 事件 | 低 |
| Issue Triage | 自动标记+分类 Issue | 定时 | 低 |
八、三个致命陷阱
1. 验证仍然是你的责任
"完成了"只是一个声明，不是证明。
无人值守的 Loop 也是无人值守犯错的 Loop。每个 Loop 都应该配验证步骤——测试断言、审查 Agent、diff 检查。Agent 说"完成了"不代表真的完成了。
2. 理解债务（Comprehension Debt）
Loop 产出越快，你没写过的代码越多。
代码总量与你真正理解的代码量之间的差距，就是理解债务。积累到一定程度，你就变成了自己系统的局外人。定期阅读 Loop 产出的代码，保持理解。
3. 认知投降（Cognitive Surrender）
当 Loop 自动运转时，最危险的事就是停止独立判断。
Loop 不会质疑你的设计。如果方向错了，Loop 会高效地帮你把错误的方向跑得更远。永远保持质疑——Loop 是副驾驶，不是自动驾驶。
"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."
— Addy Osmani
九、总结
Loop Engineering 的本质是从"操作者"变成"设计者"：
| 角色 | 做什么 | 思考方式 |
|---|---|---|
| Prompt Engineer | 写提示词 | "这次我问什么？" |
| Loop Engineer | 设计系统 | "Agent 下次该干什么？如何验证？状态存在哪？" |
核心公式：
Loop Engineering = 触发器 + 状态持久化 + 隔离执行 + 验证反馈 + 记忆层
一句话判断：如果你每天都要对 AI Agent 说"继续做昨天的事"，你就需要一个 Loop。
参考资源
- Addy Osmani: Loop Engineering — Designing Systems for AI Coding Agents
- cobusgreyling/loop-engineering — CLI 工具与实践模式 (GitHub)
- awesome-loop-engineering — 精选资源列表 (GitHub)
- Boris Cherny: Claude Code 内部架构与实践
浙公网安备 33010602011771号