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 五大基础构建块 + 记忆层

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）

2.4 CLI 工具生态

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）：如果你不仔细阅读循环所产出的内容，认知负债会比技术负债积累得更快。
• ⚖️ 结果因人而异：两个人运行完全相同的循环，可能得到截然相反的结果——循环不知道差别在哪里，但你应该知道。

五、个人启发

1. 范式转变是真实的：从"写 prompt 用工具"到"设计系统用代理"，这不是微小的技巧升级，而是思维方式的根本转变——更像是软件架构师在设计一个自动化流水线，而非"更好地问问题"。
2. 渐进式自动化是关键：L1→L2→L3 的分阶段策略极具工程智慧。AI 系统的信任需要通过可观测的行为积累，而不是一次性全部放权。这与微服务上线的金丝雀发布异曲同工。
3. "记忆/状态"是被严重忽视的维度：很多人在用 AI 编码助手时只关注单次对话质量，而 Loop Engineering 将持久化状态（STATE.md）视为整个系统的"脊梁"，这对于构建可靠的长期自动化至关重要。
4. 可观测性先行：loop-audit、loop-cost、loop-sync 这三个工具本质上是在给 AI 循环系统建立可观测性体系，这与生产级软件监控的思路完全一致——没有可观测性，就没有可控性。

六、延伸思考

1. "理解债"如何量化与管理？ 随着循环自动化程度越来越高，开发者对代码库的理解会不断稀释。是否存在一种机制（如强制 Code Review 门控、自动生成决策日志），能够系统性地防止开发者对自己代码库"失去感知"？
2. 多循环协同时如何避免竞争与冲突？ 当 Daily Triage、PR Babysitter、CI Sweeper 等多个循环同时运行时，它们操作的是同一个代码仓库，是否会产生状态竞争、Git 冲突或重复修复？项目提到了"Multi-Loop Coordination"，这一领域值得深入研究。
3. Loop Engineering 是否会催生新的"技术负债"形态？ 传统技术负债源于人的决策捷径，而"循环负债"（Loop Debt）可能来自：设计不当的自动化逻辑被反复执行并累积副作用。如何在架构层面设计"可逆"的循环，使得错误决策可以被安全回滚，值得进一步探索。