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）可能来自：设计不当的自动化逻辑被反复执行并累积副作用。如何在架构层面设计"可逆"的循环，使得错误决策可以被安全回滚，值得进一步探索。