一个反直觉的观点
Boris Cherny，Anthropic 的 Claude Code 负责人，说了这么一句话：
我不再 prompt Claude 了。我有循环在运行，让循环去 prompt Claude、让循环去决定下一步做什么。我的工作是写循环。
听起来有点玄。但如果你用过 Cursor、Claude Code、Codex 这些 AI 编程 Agent，你应该能感受到一个趋势：手动 prompt 这件事正在变成瓶颈。
每次你写一个详细的 prompt，告诉 Agent「先看这个文件，再改那个函数，记得跑测试，如果有报错就修」，你本质上是在充当一个调度器。你把任务拆开、喂给 Agent、看结果、再给下一步指令。
这个过程能不能自动化？
2026 年 6 月，Cobus Greyling 开源了 loop-engineering 这个项目（目前 3000+ star），把这个问题的回答变成了可以跑的代码。它不是又一个 Agent 框架，而是一套「怎么设计循环」的方法论 + 工具链。
什么是「循环」
Loop Engineering 里的「loop」不是一个简单的 while 循环。它是一个递归目标：你定义一个目的，AI Agent 反复迭代，带着子 Agent、验证步骤和外部状态，直到目标完成或者决定把控制权交还给你。
最简单的例子：每天早上 9 点跑一个 Agent，扫描仓库里的 issue 和 PR，更新一个 STATE.md 文件，列出优先级。不改代码，只报告。
再进一步：Agent 发现 CI 挂了，自动创建工作分支，写修复代码，跑测试，提 PR。如果测试通过，标记为「等人工审核」；如果失败，记录原因，等下一轮再处理。
更激进：多个循环同时跑，一个管 issue 分诊，一个管依赖更新，一个管 CI 修复，各自有子 Agent 做 maker/checker 拆分。
这就是 Loop Engineering 要解决的问题：怎么设计这些循环，让它们可靠地运行，而不是制造一堆半成品 PR 和 token 账单。
五个构建块
这个项目定义了五个核心原语，加一个「+1」。不是什么新发明，而是从 Grok、Claude Code、Codex 等工具的实际使用中提炼出来的结构。
1. 调度（Automations）
循环的心跳。没有调度，你就只是一次性的 Agent 调用。
不同工具的实现方式不一样。Grok 用 /loop 1d 这样的命令，Claude Code 有 scheduled tasks，Codex 可以用 GitHub Actions + repository dispatch。核心是一个东西：定期触发，带着上下文。
调度的关键属性：间隔（5 分钟还是 1 天）、是否立即触发第一次、单次还是循环、是否持久化（机器重启后还在不在）。
2. Worktree（隔离工作目录）
两个 Agent 同时改同一个文件，灾难就来了。Git worktree 让每个 Agent 有自己的工作目录，共享历史但不共享工作区。
Grok 里可以传 isolation: "worktree" 启动子 Agent。Claude Code 和 Codex 也有类似机制。
容易忽略的一点：任务完成后要清理 worktree。如果不清理，磁盘和分支管理都会出问题。
3. Skills（技能文件）
循环的持久记忆。一个 skill 通常是 SKILL.md 加一些脚本和参考文档，记录：
- 项目的编码规范
- 「去年因为 X 事故，我们不这样做」
- 构建、测试、lint 的命令
- Review 标准
- 领域知识
没有 skill，循环每次运行都要从零推导这些信息。Cobus 管这叫「意图债」（intent debt）——你欠了循环太多没说清楚的上下文，它就靠猜。
其实 Hermes Agent 的 skill 机制就是这个思路的实践。
4. 连接器（Plugins & MCP）
一个只能读文件系统的 Agent，能力有限。连接器让 Agent 可以：
- 读写 Linear / Jira ticket
- 在 Slack / Discord 发消息
- 查数据库、调内部 API
- 在 GitHub 上创建分支和 PR
- 触发部署流水线
MCP（Model Context Protocol）正在成为连接器的标准协议。为一个工具写的 MCP server，其他支持 MCP 的 Agent 也能用。
5. 子 Agent（Maker / Checker 拆分）
这是可靠循环最重要的结构性模式。
写代码的 Agent 判断自己写得好不好，这件事本身就不太靠谱。所以需要第二个 Agent 来验证——用不同的指令，有时候用更强的模型。
常见的拆分方式：
- 探索者 → 实现者 → 验证者
- 实现者 → 安全审查员
- 实现者 → 测试编写 + 执行者
在无人值守的循环里，验证者是你（人类）能放心走开的关键。
+1：状态（State）
模型没有跨会话的长期记忆。循环必须读写某种持久化的东西：仓库里的 STATE.md、Linear board 的一个 section、或者一个小数据库。
好的状态文件回答三个问题：
- 当前在处理什么？
- 上次试了什么，结果怎样？
- 有什么在等人工处理？
这个文件通常是循环产出的最重要的一件工件。
七个生产模式
这个项目提供了 7 个可以开箱即用的循环模式：
| 模式 | 频率 | 第一周目标 | Token 消耗 |
|---|---|---|---|
| Daily Triage（每日分诊） | 1 天 | 只报告，不改代码 | 低 |
| PR Babysitter（PR 守护） | 5-15 分钟 | 观察 PR 状态 | 高 |
| CI Sweeper（CI 清扫） | 5-15 分钟 | 谨慎修复 CI 失败 | 很高 |
| Dependency Sweeper（依赖更新） | 6 小时-1 天 | 只 patch 版本 | 中 |
| Changelog Drafter（更新日志） | 1 天或打 tag | 只写草稿 | 低 |
| Post-Merge Cleanup（合并后清理） | 1 天-6 小时 | 低峰期执行 | 低 |
| Issue Triage（Issue 分诊） | 2 小时-1 天 | 只建议，不操作 | 低 |
建议从 Daily Triage 开始。风险低，token 消耗少，能帮你理解循环的工作方式。
实际怎么跑
这个项目提供了三个 CLI 工具，全部可以通过 npx 直接用，不需要 clone 仓库。
第一步：初始化
npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok
这会在你的仓库里创建 STATE.md、LOOP.md、loop-budget.md 和 loop-run-log.md。
第二步：估算 token 消耗
npx @cobusgreyling/loop-cost --pattern daily-triage --level L1 --cadence 1d
高频循环（比如 CI Sweeper 每 5 分钟一次）token 消耗会爆炸。先算清楚再上。
第三步：审计就绪度
npx @cobusgreyling/loop-audit . --suggest
评分 0-100，给出具体改进建议。
第四步：第一周只报告
Grok 的例子：
/loop 1d Run loop-triage. Update STATE.md. No auto-fix in week one.
Claude Code 的例子：
/loop 1d Run $loop-triage. Read STATE.md. Merge findings into High Priority and Watch List. Do not edit code.
第一周不改代码。只让循环产出报告，你来读、来判断。这是建立信任的过程。
分阶段推进
L1（报告）→ L2（辅助修复）→ L3（无人值守）
别跳级。每一个级别都要验证循环的判断能力，再考虑让它自己动手。
现实中的坑
Token 成本可能失控
子 Agent + 长时间运行的循环 = 账单惊喜。loop-cost 工具能帮你估算，但实际消耗往往比估算高 20-50%。尤其是 PR Babysitter 和 CI Sweeper 这种高频模式。
验证还是你的事
无人值守的循环会犯无人值守的错误。你给它多少自主权，它就能制造多少麻烦。
理解债（Comprehension Debt）
循环帮你做的事越多，你读它的输出就越少。积累下来，你不知道仓库里多了什么代码、改了什么逻辑。这和代码债一样危险。
同一个循环，两个人跑，结果可能相反
循环不知道你的项目有什么隐含约束。你跑 daily-triage 会发现它列出的优先级跟你直觉一致，因为你有上下文。换个人跑，结果可能完全不同。
跟传统 Prompt Engineering 的区别
Prompt Engineering 的核心是「怎么写出好的 prompt」。Loop Engineering 的核心是「怎么设计一个系统，让系统来写 prompt」。
这不是说 prompt 不重要了。而是 prompt 的编写本身变成了一个可以自动化、可以迭代、可以版本控制的工程问题。
一个好的循环里，prompt 可能是个 skill 文件，版本化管理，每次运行前由调度器组装上下文、注入状态、选择合适的工具。人类的职责变成了设计这个组装过程，而不是每次都手动写指令。
Addy Osmani 在他的文章里给了一个判断标准：
建循环。但要像一个打算继续当工程师的人那样去建，而不是一个只想按按钮的人。
对 51domino 的启示
如果你在用 AI Agent 做日常开发，loop-engineering 的几个核心思路可以直接迁移：
-
从报告模式开始。先让 Agent 每天给你一份分析报告（代码质量、依赖状态、issue 趋势），不改任何东西。建立信任后再逐步授权。
-
状态文件是关键。不管你用不用这个项目的工具，在仓库里维护一个
STATE.md记录 Agent 的决策历史，是一个简单但有效的习惯。 -
子 Agent 做验证。如果你的 Agent 要自动改代码，至少用一个独立的验证步骤检查结果。可以是另一个 Agent，可以是 CI 流水线。
-
先慢后快。从每天一次的低频循环开始，确认可靠后再提高频率。高频循环的 token 成本和错误累积速度都会指数增长。
-
MCP 连接器放大能力。一个能读写 Linear ticket、发 Slack 通知、触发 CI 的 Agent，比只能读写文件的 Agent 有用得多。
工具链速查
| 工具 | 用途 | 命令 |
|---|---|---|
| loop-init | 初始化循环脚手架 | npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok |
| loop-cost | 估算 token 消耗 | npx @cobusgreyling/loop-cost --pattern daily-triage --level L1 |
| loop-audit | 审计就绪度 | npx @cobusgreyling/loop-audit . --suggest |
三个工具都发布在 npm 上，不需要 clone 仓库。支持 Grok、Claude Code、Codex 三种工具的模式映射。
GitHub 仓库：cobusgreyling/loop-engineering
参考文章： - Cobus Greyling 原文：Loop Engineering (Substack) - Addy Osmani：Loop Engineering