2026 年 6 月，硅谷 AI 圈被两句话点燃。Anthropic 的 Boris Cherny 说：” 我不再给 Claude 写提示词了，我有一堆循环在运行，它们自己给 Claude 发指令。我的工作变成了写循环。”OpenAI 的 Peter Steinberger 说：” 你不应该再给编程 Agent 写提示词了，你应该设计循环来提示你的 Agent。”
这两句话，开启了 AI 工程一个新的范式——循环工程（Loop Engineering）。
而今天我们要调研的这个仓库，是目前最实用的工程化落地工具包：cobusgreyling/loop-engineering。
一、它到底是什么
loop-engineering 是一个开源项目，由 Cobus Greyling 创建于 2026 年 6 月 9 日，目前 704 stars / 90 forks / MIT 协议，仅 5 个 open issues，项目活跃度极高（今天 6/23 还在更新）。
它不是又一个提示词模板库，而是一套 把 AI Agent 从 ” 问答工具 ” 变成 ” 自主系统 ” 的工程方法论，附带了可直接跑的生产级代码。
核心理念可以用一句话概括：
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
（循环工程取代的是你本人作为 ” 提示 Agent 的人 ” 的角色。你设计的是一套系统，让它来代替你做这件事。）
翻译成人话就是：你不需要每次都写提示词，你只需要设计好一套 ” 循环系统 ” 让它自己去跑。
二、为什么 Prompt Engineering 不够用了
要理解 Loop Engineering 的价值，先得明白为什么传统的 ” 写提示词 ” 方式在生产环境里撑不住。
CSDN 一篇深度分析文章很好地梳理了 AI 工程的四层演进：
| 层级 | 核心问题 | 人的角色 | AI 的角色 | 核心局限 |
|---|---|---|---|---|
| Prompt Engineering | 怎么问得好 | 提问者 | 回答问题 | 人是循环核心，无法多步自主执行 |
| Context Engineering | 给模型看什么 | 信息架构师 | 基于信息生成结果 | 有信息但无自主推进能力 |
| Harness Engineering | 给 Agent 搭什么环境 | 系统设计者 | 在约束环境中工作 | 静态架构，无法自主调度决策 |
| Loop Engineering | 设计什么循环让 Agent 自主跑 | 目标制定者 | 自主完成全流程 | 结构静态，跨循环协调依赖人 |
真实场景有多痛？一个典型的慢查询优化任务，在 ” 人即发动机 ” 模式下是这样的：
- 工程师发现问题 → 打开 AI 助手 → 输入需求
- AI 给出优化方案 → 工程师评估 → 发现遗漏 → 人工补充
- AI 修正 → 工程师测试 → 还有问题 → 再改
- 五六轮循环下来，耗时远超纯手动操作
核心矛盾： Prompt Engineering 优化的是单次交互质量，但生产级任务需要的是 连续、自主、可验收的闭环。人作为循环发动机，本身就是瓶颈。
而 Loop Engineering 的答案很简单：把人和 AI 的交互模式从 ” 问答式 ” 升级为 ” 闭环式 ”——人给目标，系统自己跑完。
三、五个基础构件 + 记忆
loop-engineering 把完整循环拆成 6 个独立构件，在 Grok、Claude Code、Codex 里名字不同但能力趋同：
① Scheduling（调度器）
没有调度，Agent 跑一次就停了。调度器决定：
- 触发频率：每天一次？2 小时一次？5 分钟一次？
- 立即执行：启动时先跑一次，还是等周期到来？
- 持久性：会话中断后能否恢复？
Grok 里是 /loop 命令；Claude Code 里是 cron 任务；GitHub Actions 里是 workflow cron 表达式。
② Worktrees（隔离工作区）
两个 Agent 同时改同一个文件 = 合并地狱。Worktree 给每个 Agent 一个 独立的文件系统视图，共享历史但不共享工作区。任务完成后自动清理。
Grok 里 spawn isolation: "worktree"；Git 里 git worktree add。
③ Skills（技能包）
一个 Skill = SKILL.md + 可选脚本，写清楚：
- 项目约定
- 不这么做的原因（” 上次因为 X 踩坑了 ”）
- 构建 / 测试命令
- 审查标准
没有 Skills，Agent 每次启动都从零推导——这叫 ” 意图债务 ”（intent debt），比技术债务更隐蔽。
④ Connectors / MCP（连接器）
只读文件系统的 Agent 能力有限。Connector 让它：
- 读写 Linear / Jira 工单
- 发 Slack / Discord 消息
- 查询数据库、调用内部 API
- 创建 Git branch 和 PR
- 触发部署或 runbook
MCP（Model Context Protocol）已经成了通用协议，一个 Connector 写一次可以在多个工具里复用。
⑤ Sub-agents（子代理）—— maker / checker 分离
写代码的 Agent 不能评判自己的代码。Maker / Checker 分离 是最重要的可靠性模式：
- Explorer → Implementer → Verifier（探索 → 实施 → 验证）
- Implementer → Security Reviewer（实施 → 安全审查）
- Implementer → Test Writer + Runner（实施 → 测试生成与执行）
在无人值守的循环里，Verifier 是你敢 ” 放手不管 ” 的唯一理由。
⑥ State / Memory（状态文件）
模型没有跨会话的长期记忆。循环必须从某个 可持久化的地方读写状态：
STATE.md或LOOP-STATE.json（仓库里）- Linear 看板 / GitHub Project 某个分区
- 数据库某一行
好的状态文件必须回答三个问题：
- 当前在做什么？
- 上次尝试了什么、结果如何？
- 哪些在等人处理？
最小可行的循环 = 调度器 + 1 个 triage skill + 状态文件。其他构件按需添加，添加顺序很重要：
先证明调度 + triage + state 有价值了，再加 worktree isolation；再证明工作可靠了，再加 verifier；有驱动 PR 需求了，再加 connectors。
四、七条生产级模式
loop-engineering 目前文档化了 7 条生产级循环模式，每条都含排期建议、推荐技能、验证策略和人工交接策略：
| 模式 | 排期 | 风险 | 一句话描述 |
|---|---|---|---|
| Daily Triage | 1 天–2 小时 | 低 | 每天早上的 CI/Issue/Commit 扫描，只报告不自动修复 |
| PR Babysitter | 5–15 分钟 | 中 | 把 PR 从 Review → CI → Rebase → Merge 全程走完，人只做判断 |
| Issue Triage | 2 小时–1 天 | 低 | 自动发现、去重、分类 Issue，只提案不自动修复 |
| CI Sweeper | 5–15 分钟 | 中 | CI 失败立刻 worktree + fix + verify + PR，自动化程度高 |
| Dependency Sweeper | 6 小时–1 天 | 中 | 扫描依赖更新，只提交 patch PR 不破坏现有逻辑 |
| Changelog Drafter | 1 天或每个 tag | 低 | 扫描合并的 PR/commits，自动起草分类变更日志，人审核后发布 |
| Post-Merge Cleanup | 1 天–6 小时 | 低 | 合并 PR 后自动清理 worktree、更新 CHANGELOG、关闭关联 Issue |
作者把每条模式的难度分三级（L1 报告 / L2 辅助 / L3 无人值守），并明确要求 第一周必须跑在 L1 报告模式，验证 triage 质量稳定了再开启自动修复。
五、三个实用 CLI 工具
除了方法论文档，项目还发布了 3 个 npm 包，都是可以直接 npx 跑的命令行工具：
| 工具 | 用途 | 典型用法 |
|---|---|---|
| loop-audit | 循环就绪度评分（v1.4，含活动检测） | npx @cobusgreyling/loop-audit . --suggest |
| loop-init | 脚手架 Starter（v1.2） | npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok |
| loop-cost | Token 消耗估算 | npx @cobusgreyling/loop-cost |
loop-init 一步到位，从 7 种模式和 3 种工具（Grok / Claude Code / Codex）组合出一个完整的 LOOP.md + STATE.md + 技能文件，复制粘贴即可跑。
六、Loop 设计的 40 项检查清单
项目提供了一份极其详细的 loop-design-checklist.md，将循环就绪度分为三级：
- L0 — 草稿：只写清楚了意图
- L1 — 报告：Triage → 写状态，不自动行动
- L2 — 辅助：小修复 + verifier 双重验证
- L3 — 无人值守：不看着也能跑
检查清单涵盖：目标定义、范围锁定、排期选择、是否 fire-immediately、是否持久化、triage skill 是否存在、implementer 和 verifier 是否分离、状态文件 schema 是否定义、denylist 是否覆盖 auth/payments/secrets/infra、token budget 是否估算……共计 40+ 条。
这个清单的价值在于：它把 ” 如何判断一个循环能不能上线 ” 这个问题，从经验判断变成了可量化打分。
七、与其他 AI 编程方法论的区别
| 维度 | Prompt Engineering | Harness Engineering | Loop Engineering |
|---|---|---|---|
| 关注点 | 单次交互质量 | 运行环境可靠性 | 自主闭环机制 |
| 人角色 | 提问者 | 系统设计者 | 目标制定者 |
| AI 角色 | 回答问题 | 在约束中执行 | 自主全流程 |
| 执行方式 | 人工每轮触发 | 静态基础设施 | 动态循环系统 |
| 典型工具 | prompt templates | MCP / skills / verifier | /loop / cron / GitHub Actions |
| 适合阶段 | 探索 / 原型 | 提升可靠性 | 生产 / 规模化 |
四层是 叠压关系，不是替代关系。Loop Engineering 建立在前三层的基础之上——没有好的提示词、精准的上下文、可靠的运行环境，再完美的循环也产不出好结果。
八、项目背景与行业定位
loop-engineering 的灵感来自两条公开发言：
- Addy Osmani（Google 工程总监，2026-06-07）：正式命名并定义这一领域
- Boris Cherny（Anthropic Claude Code 负责人）：公开说自己的工作是 ” 写循环，而不是写提示词 ”
Cobus Greyling 把这些概念落地为 可执行、可量化、可复用 的开源工具，项目本身也在 dogfood——它的 CI 里跑着自己的 validate-patterns + audit 工作流，每条模式都经历过真实项目的检验。
中国开发者社区的反馈也很积极。CSDN 一篇 6 月 19 日的文章称其为 ”AI Agent 自主闭环的完整落地指南 ”，OSCHINA 6 月 16 日的深度解读认为 Loop Engineering 是 ”2026 年最热 AI 工程方法论 ”。
九、优势和风险
✅ 优势
- 工具链完整：从方法论（checklist / pattern docs）到脚手架（loop-init）到监控（loop-audit / loop-cost），一条链路走到底
- 平台无关：Grok / Claude Code / Codex / GitHub Actions 全覆盖，cross-tool matrix 很清晰
- 成熟度分级：L0→L1→L2→L3 的渐进路径，不会让你一步跨到无人值守翻车
- dogfood 验证：项目自己的 CI 就是跑 loop-engineering，不是纸上谈兵
- 社区活跃：创建仅 14 天已 704 stars，issue 处理快
⚠️ 风险和局限
- 项目非常新（2026-06-09 创建），7 条模式虽已文档化但真实大规模验证尚少
- 强依赖 AI coding agent 生态（Grok / Claude Code / Codex），不使用这些工具的团队拿不到直接价值
- 学习曲线：5 个基础构件 + 7 条模式 + 40 项检查清单，新手上手需要时间
- Token 成本：loop-cost 工具帮你估算，但无限制循环跑在 CI 里费用不低
- 自主修复的风险：L2/L3 模式赋予 Agent 一定的自动修复能力，denylist（auth/payments/secrets/infra）配置有误可能造成真实破坏
十、总结
Loop Engineering 不是一个 hype 概念，它是一个 把 AI Agent 从 ” 对话模式 ” 升级为 ” 工作模式 ” 的工程框架。
当你在 Claude Code 里跑 /loop 让它每天自动 triage CI 失败，当你在 GitHub Actions 里配置 cron 触发 Issue Triage，当 loop-init 一行命令搭出完整 STATE.md + LOOP.md + Skills——你已经从 ” 写提示词的人 ” 变成了 ” 设计系统的人 ”。
对于已经在使用 AI coding agent 的团队，这个仓库值得花一个下午读完所有模式文档、跑一次 npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok，亲身体验一次 ” 让 Agent 自己跑 ” 的感觉。
而对于技术 leader 和架构师，loop-engineering 提供的 Loop Readiness Score 和 40 项检查清单，是目前市场上少有的、能把 ”AI Agent 能不能上线 ” 这个问题从主观判断变成客观打分的工具。
一句话结论：如果 2026 年是 AI Agent 从实验室走向生产的元年，那么 Loop Engineering 就是这门工程学的第一本教科书——而且是带配套 CLI 工具和实践 Starter 的那种。
本文基于公开资料整理，部分中文引用来自 CSDN 深度分析文章。