Loop Engineering：用系统设计取代手动提示，构建 AI 编码代理的自动化循环
Loop Engineering：用系统设计取代手动提示，构建 AI 编码代理的自动化循环
一、核心观点
"Stop prompting. Design the loop. Get a score."
— Loop Engineering 项目口号
Loop Engineering 的核心理念是：开发者不应再手动编写提示词（prompt）驱动 AI 编码代理，而应设计一套能自动编排代理的"控制系统"（Loop）。
两位行业领袖的表述高度一致：
- Peter Steinberger：「你不应该再去手动提示编码代理了，你应该设计一个能提示代理的循环系统。」
- Boris Cherny（Anthropic，Claude Code 负责人）：「我不再直接提示 Claude 了，我运行的是一套能提示 Claude 并自行决策的循环系统。我的工作是编写这些循环。」
杠杆点已经从"如何写好一个 prompt"转移到"如何设计能随时间编排代理的控制系统"。
二、关键信息
2.1 五大基础构建块 + 记忆层
| 原语（Primitive） | 在循环中的职责 |
|---|---|
| Automations / Scheduling | 按周期触发发现与分诊任务 |
| Worktrees | 安全的并行执行环境 |
| Skills | 持久化的项目知识 |
| Plugins & Connectors | 通过 MCP 接入真实工具 |
| Sub-agents | 制作者（Maker）/ 检查者（Checker）分工 |
| + Memory / State | 独立于任何对话之外的持久化状态脊梁 |
2.2 一个循环的完整解剖图
flowchart LR A[Schedule / Automation] --> B[Triage Skill] B --> C[Read + Write STATE / Memory] C --> D[Isolated Worktree] D --> E[Implementer Sub-agent] E --> F[Verifier Sub-agent: tests + gates] F --> G[MCP / Git / Tickets] G --> H{Human Gate?} H -->|safe / allowlisted| I[Commit / PR / Action] H -->|risky / ambiguous| J[Escalate to human with full context] I --> A J --> A核心流程：调度触发 → 分诊技能 → 读写状态记忆 → 隔离工作树 → 执行代理 → 验证代理 → 推送/升级 → 循环继续。
2.3 七大生产级模式（Patterns）
| 模式 | 执行周期 | 初始阶段建议 | Token 消耗 |
|---|---|---|---|
| Daily Triage（日常分诊） | 1天–2小时 | L1 仅报告 | 低 |
| PR Babysitter（PR 看护） | 5–15分钟 | L1 监视模式 | 高 |
| CI Sweeper（CI 清扫） | 5–15分钟 | L2 谨慎模式 | 非常高 |
| Dependency Sweeper（依赖扫描） | 6小时–1天 | L2 仅打补丁 | 中 |
| Changelog Drafter（变更日志起草） | 1天或打 tag | L1 起草 | 低 |
| Post-Merge Cleanup（合并后清理） | 1天–6小时 | L1 低峰期 | 低 |
| Issue Triage（Issue 分诊） | 2小时–1天 | L1 仅提案 | 低 |
2.4 CLI 工具生态
| 工具 | 功能简介 | 示例命令 |
|---|---|---|
loop-init | 脚手架：生成 skills、state、budget 文件，打印 Loop Ready 分数 | npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok |
loop-audit | 循环就绪度评分（含约束项评分） | npx @cobusgreyling/loop-audit . --suggest |
loop-cost | Token 消耗预估器 | npx @cobusgreyling/loop-cost --pattern daily-triage --level L1 |
loop-sync | 检测STATE.md与LOOP.md之间的漂移 | npx @cobusgreyling/loop-sync . |
loop-context | 长时运行的有状态记忆管理器 + 熔断器 | npx @cobusgreyling/loop-context --check --ledger run.json |
loop-mcp-server | MCP 运行时：查找 pattern、skills、state | npx @cobusgreyling/loop-mcp-server |
loop-worktree | 管理每次修复尝试的独立 Git 工作树 | npx @cobusgreyling/loop-worktree create --run-id <id> --pattern <p> |
2.5 分阶段上线策略（Phased Rollout）
L1（仅报告）→ L2（辅助修复）→ L3（无人值守）强烈建议从 L1 开始，先观察循环行为，建立信任后再逐步放权。
三、代码/示例
快速上手（5 分钟）
# 1. 脚手架初始化 + 获取 Loop Ready 分数 npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok # 2. 估算 Token 消耗 npx @cobusgreyling/loop-cost --pattern daily-triage --level L1 # 3. 优化后重新审计 npx @cobusgreyling/loop-audit . --suggest # 可选：将 Loop Ready 徽章写入 README npx @cobusgreyling/loop-audit . --badge # 4. 查看分数提升演示：empty → L1 → L2 bash scripts/before-after-demo.sh # 5. 以仅报告模式启动（Grok 示例） /loop 1d Run loop-triage. Update STATE.md. No auto-fix in week one.本地源码开发（Monorepo 贡献者）
cd tools/loop-init && npm ci && npm test && node dist/cli.js /path/to/project --pattern daily-triage --tool grok cd tools/loop-audit && npm ci && npm test && node dist/cli.js /path/to/project --suggest cd tools/loop-cost && npm ci && npm test && node dist/cli.js --pattern ci-sweeper --cadence 15m四、注意事项与风险（Caveats）
Addy Osmani：「构建这个循环，但要像一个打算长期负责的人那样去构建它。」
- 🚨Token 成本：引入子代理和长时运行循环后，成本可能爆炸式增长。
- 🔍验证责任仍在你：无人值守的循环会制造无人注意的错误。
- 📉理解债（Comprehension Debt）：如果你不仔细阅读循环所产出的内容，认知负债会比技术负债积累得更快。
- ⚖️结果因人而异：两个人运行完全相同的循环，可能得到截然相反的结果——循环不知道差别在哪里，但你应该知道。
五、个人启发
范式转变是真实的：从"写 prompt 用工具"到"设计系统用代理"，这不是微小的技巧升级，而是思维方式的根本转变——更像是软件架构师在设计一个自动化流水线，而非"更好地问问题"。
渐进式自动化是关键：L1→L2→L3 的分阶段策略极具工程智慧。AI 系统的信任需要通过可观测的行为积累，而不是一次性全部放权。这与微服务上线的金丝雀发布异曲同工。
"记忆/状态"是被严重忽视的维度：很多人在用 AI 编码助手时只关注单次对话质量，而 Loop Engineering 将持久化状态（STATE.md）视为整个系统的"脊梁"，这对于构建可靠的长期自动化至关重要。
可观测性先行：
loop-audit、loop-cost、loop-sync这三个工具本质上是在给 AI 循环系统建立可观测性体系，这与生产级软件监控的思路完全一致——没有可观测性，就没有可控性。
六、延伸思考
"理解债"如何量化与管理？
随着循环自动化程度越来越高，开发者对代码库的理解会不断稀释。是否存在一种机制（如强制 Code Review 门控、自动生成决策日志），能够系统性地防止开发者对自己代码库"失去感知"？多循环协同时如何避免竞争与冲突？
当 Daily Triage、PR Babysitter、CI Sweeper 等多个循环同时运行时，它们操作的是同一个代码仓库，是否会产生状态竞争、Git 冲突或重复修复？项目提到了"Multi-Loop Coordination"，这一领域值得深入研究。Loop Engineering 是否会催生新的"技术负债"形态？
传统技术负债源于人的决策捷径，而"循环负债"（Loop Debt）可能来自：设计不当的自动化逻辑被反复执行并累积副作用。如何在架构层面设计"可逆"的循环，使得错误决策可以被安全回滚，值得进一步探索。