loop-engineering教程
更新于 2026年7月17日
# Loop Engineering 教程：停止 Prompting，设计 Loop
目录
- 痛点导入：AI 编程的下一个瓶颈
- Loop Engineering 是什么
- 核心理念：从提问者到控制系统设计者
- 六大构建模块
- 七种生产 Loop 模式
- 快速入门：三步启动第一个 Loop
- CLI 工具链详解
- 三阶段推进策略（L1 → L2 → L3）
- 常见失败模式与避坑指南
- 最佳实践
1. 痛点导入
1.1 我们已经走到哪了？
你已经会用 Trae、Qoder、Claude Code 写代码了。每次需要，打开工具，输入 prompt，得到代码，合并，继续。
但当项目规模变大，你会发现一个新问题：
| 场景 | 现实 |
|---|---|
| PR 积压了 20 个 | 你得逐个打开看，决定是否跟进 |
| CI 每天失败几次 | 你得手动看报错、定位原因、派人修 |
| issue 越来越多 | 没人分类，没有优先级，越堆越高 |
| 依赖库有安全漏洞 | 两周前的告警还没处理 |
这些事情本质上是重复的、有规律的、不需要人决策的。
1.2 现有 AI 工具的局限
| 工具 | 解决了什么 | 解决不了什么 |
|---|---|---|
| Claude Code / Cursor | 当下这个任务 | 无法持续运行、自动发现任务 |
| GitHub Actions | 持续运行 | 不够智能，无法理解上下文 |
| 人工 | 有判断力 | 效率低、容易忘、不持续 |
1.3 Loop Engineering 的答案
"I don't prompt Claude anymore. I have loops running that prompt Claude..."
— Boris Cherny，Anthropic Claude Code 负责人
核心转变：
传统模式：工程师 → 写 prompt → AI 执行 → 工程师看结果
Loop 模式：工程师设计控制系统 → 系统自动发现任务 → AI 自动执行 → 异常时叫人
2. Loop Engineering 是什么
2.1 一句话定义
Loop Engineering 是一套让 AI Agent 持续自动运行、发现并处理工程任务的方法论和工具链，核心是"设计控制系统"而不是"写 prompt"。
2.2 项目档案
| 属性 | 内容 |
|---|---|
| GitHub | cobusgreyling/loop-engineering |
| 主要语言 | JavaScript 54.5%、TypeScript 35.2%、Shell 5.2% |
| 许可证 | MIT |
| 安装方式 | 无需安装，全部通过 npx 使用 |
2.3 核心口号
"Stop prompting. Design the loop. Get a score."
3. 核心理念
3.1 工程师角色的转变
| 旧角色 | 新角色 |
|---|---|
| Prompt 工程师：写一条好的 prompt | 控制系统设计者：设计一套自动运行的循环 |
| 手动触发，人工判断 | 系统自动发现，只在异常时介入 |
| 每次都要盯着 | 持续运行，偶尔审查 |
3.2 两个关键警告
警告一：Token 债务
Loop 一旦跑起来，Token 消耗会超出预期。Sub-agent 模式和高频 loop 会让成本快速膨胀。必须在启动前用 loop-cost 估算，用 loop-budget.md 约束。
警告二：理解债务（Comprehension Debt）
"要像打算长期当工程师的人来构建 loop，而不是只按下启动键的人。"
— Addy Osmani
你必须持续读懂 loop 的输出。无人值守的 loop 会制造无人值守的错误。
3.3 验证责任永远在工程师手中
无论 loop 多聪明，验证最终结果是人的责任。Loop 负责发现和执行，工程师负责确认和放行。
4. 六大构建模块
每个生产级 Loop 都由以下模块组合而成：
4.1 Automations / Scheduling — 节拍器
职责：周期性发现与分类任务，驱动整个 loop 的运转。
通过 GitHub Actions cron 或本地调度器定时触发，是 loop 的心跳。
# GitHub Actions 示例
on:
schedule:
- cron: '0 9 * * 1-5' # 工作日每天 9:00 运行
4.2 Worktrees — 隔离执行环境
职责：基于 git worktree 为每个任务创建独立的工作目录，防止并行修改相互干扰。
npx @cobusgreyling/loop-worktree create
为什么重要：多个 Agent 并行修复不同 bug 时，如果共用同一工作区，改动会相互覆盖。Worktree 是生产级 loop 的必备组件。
4.3 Skills — 持久化项目知识
职责：将 Agent 需要的项目知识保存为文件，跨会话复用，不用每次重新解释。
skills/
├── tech-stack.md # 技术栈说明
├── code-style.md # 编码规范
├── deploy-guide.md # 部署步骤
└── common-patterns.md # 常见模式
原则：Skills 是 loop 的长期记忆，一次沉淀，永久生效。
4.4 Plugins & Connectors（MCP）— 工具接入
职责：通过 MCP 协议将 Agent 接入真实工具链（GitHub、JIRA、Slack 等）。
npx @cobusgreyling/loop-mcp-server # 启动 MCP 服务，运行时查询 patterns/skills/state
4.5 Sub-agents — Maker/Checker 分工
职责：一个 Agent 生成（Maker），另一个验证（Checker），防止单点错误。
Maker Agent → 生成 PR 修复
↓
Checker Agent → 审查修复是否正确
↓
人工确认 → 合并
适用场景：CI 修复、安全漏洞修复等高风险任务。
4.6 Memory / State — 跨会话状态
职责：用 Markdown 文件作为跨会话的状态载体。
| 文件 | 内容 |
|---|---|
STATE.md |
当前 loop 的运行状态、已处理的任务 |
LOOP.md |
描述这个 loop 本身的运作方式 |
loop-budget.md |
Token 预算约束 |
5. 七种生产 Loop 模式
按风险/成本/节奏分层选择适合的 pattern：
| Pattern | 触发节奏 | Token消耗 | 风险 | 适用场景 |
|---|---|---|---|---|
| Daily Triage | 1次/天 | 低 | 低 | 每日整理新增 issue 和通知 |
| Issue Triage | 每 2-24小时 | 低 | 低 | 自动给 issue 打标签、标优先级 |
| Changelog Drafter | 每次 tag | 低 | 低 | 根据合并记录起草版本日志 |
| Post-Merge Cleanup | 每 6-24小时 | 低 | 低 | 合并后清理分支、关闭关联 issue |
| Dependency Sweeper | 每 6-24小时 | 中 | 中 | 扫描并更新过期/有漏洞的依赖 |
| PR Babysitter | 每 5-15分钟 | 高 | 中 | 监控 PR，自动跟进停滞请求 |
| CI Sweeper | 每 5-15分钟 | 极高 | 高 | 扫描失败 CI，尝试自动修复 |
新手建议：从 Daily Triage 或 Issue Triage 开始，风险最低，价值立竿见影。
6. 快速入门
6.1 三步启动第一个 Loop
Step 1：初始化
# 在你的项目根目录运行
npx @cobusgreyling/loop-init . --pattern daily-triage --tool claude
这会生成：
skills/目录（项目知识）STATE.md（状态跟踪）LOOP.md（loop 描述）loop-budget.md（Token 预算）- 对应 AI 工具的配置文件
Step 2：审计就绪度
npx @cobusgreyling/loop-audit . --suggest
输出"Loop Ready 分数"和改进建议，告诉你还缺什么。
Step 3：估算成本
npx @cobusgreyling/loop-cost
在启动前了解这个 loop 每次运行大概消耗多少 Token，做好预算。
6.2 选择合适的 AI 工具
| 工具 | 初始化命令 |
|---|---|
| Claude Code | --tool claude |
| Grok | --tool grok |
| Codex CLI | --tool codex |
| OpenCode | --tool opencode |
| Cursor | --tool cursor |
6.3 接入 GitHub Actions
生成的配置文件中包含 GitHub Actions workflow，直接提交即可启用自动调度：
# .github/workflows/daily-triage.yml（loop-init 自动生成）
name: Daily Triage Loop
on:
schedule:
- cron: '0 9 * * 1-5'
jobs:
triage:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npx @cobusgreyling/loop-init . --pattern daily-triage --run
7. CLI 工具链详解
所有工具无需安装，直接 npx 使用：
| 工具 | 命令 | 用途 |
|---|---|---|
| loop-init | npx @cobusgreyling/loop-init . --pattern <name> --tool <tool> |
脚手架：初始化 loop 配置 |
| loop-audit | npx @cobusgreyling/loop-audit . --suggest |
审计仓库就绪度，给出建议 |
| loop-cost | npx @cobusgreyling/loop-cost |
估算 Token 消耗 |
| loop-sync | npx @cobusgreyling/loop-sync . |
检测 STATE.md 与 LOOP.md 的状态漂移 |
| loop-context | npx @cobusgreyling/loop-context --check |
长运行状态记忆管理 + 熔断器 |
| loop-mcp-server | npx @cobusgreyling/loop-mcp-server |
MCP 服务：运行时查询 patterns/skills/state |
| loop-worktree | npx @cobusgreyling/loop-worktree create |
为每次任务创建隔离的 git worktree |
8. 三阶段推进策略
不要第一天就全自动。 按阶段推进，每阶段至少观察一周。
L1：仅报告（第一周）
Loop 运行 → 生成报告 → 工程师阅读 → 不执行任何修改
目标：理解 loop 的输出质量，建立信任感。
配置：在 loop-budget.md 中设置 mode: report-only。
L2：辅助修复（第二周起）
Loop 运行 → 生成修复建议 → 工程师确认 → 执行修复
目标：验证 AI 建议的准确性，建立审批流程。
配置：mode: suggest，所有变更需人工 approve。
L3：无人值守（稳定后）
Loop 运行 → 自动执行 → 仅异常时通知工程师
目标：真正释放工程师精力。
前提：L1/L2 阶段积累了足够的信任数据，错误率低于阈值。
配置：mode: auto，配合 loop-context 熔断器防止失控。
9. 常见失败模式与避坑指南
9.1 Token 爆炸
症状：运行两天后账单暴涨。
原因：Sub-agent 链路太长、loop 频率太高、上下文没有裁剪。
预防：
- 启动前必跑
loop-cost loop-budget.md设置每日 Token 上限- CI Sweeper / PR Babysitter 这类高频 loop 谨慎启用
9.2 理解债务积累
症状：loop 在跑，但你不知道它在干什么。
原因：跳过 L1 阶段，直接上 L3。
预防：
- 严格执行三阶段推进
- 每周用
loop-sync检查状态漂移 - 定期阅读 STATE.md
9.3 Worktree 冲突
症状：多个 Agent 并行修复，代码互相覆盖。
原因：没有启用 Worktree 隔离。
预防：任何并行执行场景都必须使用 loop-worktree create。
9.4 State 漂移
症状：Loop 重复处理已完成的任务，或跳过未完成的任务。
原因：STATE.md 和实际仓库状态不同步。
预防：定期运行 npx @cobusgreyling/loop-sync .
10. 最佳实践
10.1 从低风险 Pattern 起步
| 推荐顺序 | Pattern | 理由 |
|---|---|---|
| 第一个 | Daily Triage | 只读，零风险，立竿见影 |
| 第二个 | Issue Triage | 只打标签，不修代码 |
| 第三个 | Dependency Sweeper | 有明确验证标准 |
| 最后 | CI Sweeper | Token 消耗最高，需要充分信任 |
10.2 Skills 沉淀是 ROI 最高的投入
花 30 分钟把项目的技术栈、编码规范、部署流程写进 skills/，之后每次 loop 运行都能直接用，不用重复解释。
10.3 熔断器不是可选项
在 loop-context 中配置熔断条件：
如果连续 3 次修复后 CI 仍失败 → 停止 loop，通知工程师
如果单次 Token 消耗超过预算 2 倍 → 停止 loop，发出告警
无人值守 loop 必须有熔断器，否则出了问题没人知道。
10.4 检查清单
| 启动前 | 运行中 | 稳定后 |
|---|---|---|
| ✅ 跑过 loop-audit | ✅ 每周读 STATE.md | ✅ 每月 loop-cost 复盘 |
| ✅ 估算了 loop-cost | ✅ 定期 loop-sync | ✅ 更新 Skills |
| ✅ 设置了 loop-budget | ✅ 配置了熔断器 | ✅ 逐步从 L1 升级到 L3 |
| ✅ 从 L1 模式启动 | ✅ 异常时人工介入 | ✅ 复盘失败案例 |
附录
A. 资源链接
| 资源 | 地址 |
|---|---|
| GitHub 仓库 | https://github.com/cobusgreyling/loop-engineering |
| 失败模式分析 | docs/failure-modes.md |
| 反模式指南 | docs/anti-patterns.md |
| 安全指南 | docs/safety.md |
| 多 Loop 协调 | docs/multi-loop.md |
B. Loop Engineering vs 传统 AI 编程工具对比
| 维度 | 传统 AI 工具（Claude Code/Cursor） | Loop Engineering |
|---|---|---|
| 触发方式 | 手动触发 | 自动调度 |
| 任务来源 | 工程师指定 | 系统自动发现 |
| 持续性 | 单次会话 | 持续运行 |
| 人工介入 | 每次都要盯着 | 仅异常时 |
| 适用场景 | 当下的开发任务 | 持续运营类任务 |
| 上手门槛 | 低 | 中（需要理解控制系统设计） |
C. 支持的 AI 工具
Claude Code、Grok、Codex CLI、OpenCode、Cursor、GitHub Actions、Factory Droid、Slate、Kiro
教程版本：v1.0
参考来源：https://github.com/cobusgreyling/loop-engineering
最后更新：2026-07-10