# 什么是 Loop Engineering

> Claude Code 的 Boris Cherny 说他不再提示 Claude,而是写循环。Loop Engineering 是什么、一个循环需要哪五块东西、它帮不了你的三件事,以及为什么它只奖励已经想明白的人。

- 原文链接: https://laojin.blog/blog/20260610_loop_engineering
- 作者: 老金
- 发布日期: 2026-06-10
- 标签: Loop Engineering, Claude Code, AI Agent, 自动化, 工作流

---

![什么是 Loop Engineering](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260610/00_cover.png)

Claude Code 的 Boris Cherny 最近在红杉资本 AI Ascent 2026 大会上说了一句话：“我不再提示 Claude 了。我有运行中的循环在提示 Claude，并决定接下来做什么。我的工作是写循环。”

他一天提交 150 个 PR，全程用手机完成，没有亲手写过一行代码。

这不是在炫产量，他想说的是，写代码这件事的入口，已经不在 Prompt 上了。

## Loop Engineering 亮相

过去一年，从 AI 编程工具那里拿结果的方式都一样：你写一个提示词，喂够上下文，等它输出，读返回的内容，再写下一条。Agent 是个工具，你始终握在手里，一轮接一轮。

如果你还采用这种方式，就已经落后了。

现在的做法是：你搭一个小系统，让它去发现工作、分发工作、检验结果、记录进度、决定下一步。由小系统去调 Agent，你不再亲自上手。

这就是 Loop Engineering（循环工程）。

Google Chrome 工程总监 Addy Osmani 的说法更直白：Loop Engineering 就是把你自己从"提示 Agent 的那个人"的位置上挪开，改成设计一个系统替你干这件事。

说到底，循环就是一个递归目标——你定义要什么，AI 自己迭代到完成为止。

## 一个循环需要什么

循环大致由五块东西拼起来，Claude Code 和 Codex 现在都凑齐了。

![一个循环的解剖：五块构件围成自转的环，第六样是落在磁盘上的记忆](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260610/01_loop_anatomy.png)

**1. 自动化任务——这是心跳**

有了它，循环才会自己转起来，而不是你手动跑过一次就停了。

Claude Code 给了两个核心原语：

- `/loop`：按节奏重复跑，用来做周期性检查
- `/goal`：一直跑，直到你写的条件真的成立——每轮跑完，一个独立的小模型来判断算不算完成，所以给代码打分的不是写代码那个 Agent

```
/loop 30m /goal All tests in test/auth pass and lint is clean.
Scan src/auth for new failures, propose fixes in claude/auth-fixes,
open draft PR when goal condition holds.
```

这其实就是循环工程最核心的一招——创作者和检验者分开——只不过这回用在了"什么时候算完成"上。

**2. Worktrees——让并行不变成混乱**

只要你同时跑多个 Agent，文件就开始打架。两个 Agent 写同一个文件，跟两个工程师不打招呼往同一行代码上提交，是一模一样的麻烦。

`git worktree` 治的就是这个：各自一个独立工作目录，各在自己的分支上，共享同一份仓库历史，一个 Agent 的改动碰不到另一个的检出。

Claude Code 用 `--worktree` 标志、子 Agent 上的 `isolation: worktree` 提供同样的隔离，每个辅助 Agent 拿一份干净的检出，干完自动清理。

**3. Skills——让你不必每次重新解释你的项目**

Skills 解决的是这个尴尬：你不用每开一个新会话，就把项目背景从头讲一遍，像得了健忘症。

它就是一个带 `SKILL.md` 的文件夹，里面放指令和元数据，外加可选的脚本、参考资料、资产。

没有 Skills，循环每一轮都得重新摸清你的项目；写下来之后，这些认知就攒住了。约定、构建步骤、"这事我们不这么干，因为上次出过事故"——写一次，Agent 每次跑都读得到。

```yaml
name: ci-triage
description: 分类 CI 失败原因（环境/偶发/真实 bug/依赖/基础设施），
 为简单问题起草修复方案，其余升级处理。
 当工作流运行失败或在晨间分诊循环中触发。
```

分类规则：

- `env`：缺密钥、环境变量错了 → 人工处理
- `flake`：重试就过、代码没动 → 重试一次后归档
- `bug`：跟最近提交相关的确定性失败 → 起草修复
- `dependency`：跟版本升级相关的失败 → 起草回滚

**4. 插件与连接器——循环触及你的真实工具**

只能看到文件系统的循环，是个微型循环。

基于 MCP 的连接器让 Agent 能读你的问题追踪器、查数据库、调测试 API、往 Slack 发消息。

"一个能告诉你'这是修复方案'的 Agent"，和"一个能自己开 PR、关联 Linear 工单、CI 一变绿就在频道里吱一声的循环"，差的就是这一层。

接哪个回报最快，大致是：GitHub → Linear/Jira → Slack → Sentry。

**5. 子 Agent——让创作者远离检验者**

循环里最有用的一个结构性设计，没有之一：把写代码的和验代码的分开。

![创作者 Agent 在隔离的 worktree 里产出,再交给一个独立的检验者](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260610/02_creator_verifier.png)

写代码的模型给自己的作业打分，手太松。换一个指令不同、有时候连模型都不同的第二个 Agent，能逮到第一个 Agent 说服自己忽略掉的问题。

Claude Code 靠 `.claude/agents/` 里的子 Agent、以及在它们之间传递工作的 Agent 团队来做这件事。常见的分工是：

> 探索 Agent → 实现 Agent → 验证 Agent（对照规格检验）

子 Agent 是更烧 Token 的，所以把它们用在真正值得第二意见的地方。

## 还有第六样东西：记忆

一个 Markdown 文件，或者一块 Linear 看板，反正是任何活在单次对话之外、记着"干完了什么、还剩什么"的东西。

听着简单到不值一提，可每个长时间跑的 Agent 都靠这一招。模型每次重启都忘光，所以记忆必须落在磁盘上，不能留在上下文里。Agent 会忘，仓库不会。

```
Loop state · ci-triage

上次运行
2026-06-09 03:30 UTC · 7 个失败已分类，3 个修复已起草，4 个已升级

进行中
· claude/fix-auth-token-refresh — 本地测试通过，等待 CI
· claude/fix-flaky-payment-webhook — 已应用重试模式，监控中

今日完成
· claude/bump-axios-1.7.4 → 已合并（CI 通过）

升级给人工处理
· src/billing/refund.ts — 测试以三种方式失败，根因不明

经验教训（写在这里，不写在聊天里）
· 2026-06-08: PowerShell 在此 Windows runner 上遇到 TLS 1.2 问题，改用 bash
```

## 一个循环实际长什么样

把这五块拼到一起，一条对话线就变成了一个小控制台：

每天早上，一个自动化任务在仓库上跑起来。它的提示词调用分诊 Skill，读昨天的 CI 失败、开着的 Issue、最近的提交，把发现写进状态文件。

每一条值得处理的发现，循环就开一个隔离的 Worktree，派一个子 Agent 起草修复，再派第二个子 Agent 对照项目 Skills 和现有测试审一遍那份草稿。

连接器让它能开 PR、能更新工单。循环搞不定的，统统落进分诊收件箱，等你。

你做了什么？你把它设计出来，就一次。中间每一步，你都没去提示。

## 在你建循环之前，先过这道检查

不是所有任务都适合做成循环。下面四条都满足，才值得：

| 条件 | 说明 |
|------|------|
| 任务重复 | 至少每周一次，否则设置成本永远摊不平 |
| 验证能自动化 | 有测试、类型检查、构建或 Linter 能自动判断对错 |
| Token 预算够 | 循环要重读上下文、重试、探索，比单次对话烧得多 |
| Agent 工具齐 | 看得到日志、跑得了代码、看得见运行结果 |

适合做循环：CI 失败分诊、依赖升级 PR、Lint 修复、Issue 转 PR 草稿。

不适合：架构重写、鉴权支付这种核心代码、生产部署、"做好看点就行"这类要拍脑袋的活。

## 循环帮不了你的三件事

验证还是你的活。 没人盯着跑的循环，也是没人盯着犯错的循环。它报"完成了"，那是它的说法，不是事实。

理解债会越欠越快。 循环发代码越快，你没亲手写的代码就越多，"代码库里有什么"和"你真懂什么"之间的口子就越大。你要是不读它产出的东西，这就是在用复利借理解债。

最隐蔽的是认知上的偷懒。 循环自己转起来之后，人很容易跟着放下判断，它返回什么就收什么。同样是设计循环，你带着判断力去做，它是帮手；你拿它来躲开思考，它就成了帮凶。

## 杠杆点移动了

![杠杆的支点从"提示词"挪到了"循环设计"](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260610/03_leverage_shift.png)

Boris 想说的不是活变轻松了。活没变轻松，只是吃劲的地方挪了位置——从怎么写提示词，挪到了怎么设计循环。

两个人搭出一模一样的循环，结果可能完全相反。一个拿它在自己吃透的活上跑得更快，一个拿它来绕开"吃透"这件事本身。循环分不出这两者，你分得出。

所以循环设计其实比提示词工程更难。

## 几句不太一样的话

这套叙事很顺，顺到值得停下来戳几个洞。

先说那个"一天 150 个 PR、全程用手机"。那是工具作者干出来的——他脑子里装着 Claude Code 的完整心智模型，他跑循环那个仓库八成也被收拾得干干净净、专门为循环调过。拿创造者在理想环境里的吞吐量，去对标你在一坨十年祖传代码里的预期，没什么参考价值。真正卡住大多数人的，不是"会不会写循环"，是"你那个仓库配不配得上一个循环"。多数企业代码库的答案，是还不配。

再说工作量。文章一直暗示循环帮你省了事，其实它只是把事挪了个地方。你不写提示词了，换成维护 Skills、调连接器、搭验证脚手架、盯状态文件。"你只设计了一次"这话在现实里从来不成立——Skill 会过期，连接器会断，验证条件会被下一个需求绕过去，状态文件会跟代码慢慢对不上。任务不够重复、又难自动验证的团队，也就是大多数团队，这套设置成本根本摊不平。你只是把调 prompt 的工时，换成了调 loop 的工时。

"创作者和检验者分离"这个设计，我也没那么信。问题出在两边都是 LLM。第二个 Agent 不是独立审计员，是个跟第一个高度相关的审计员——同一批训练数据、同一批盲区、同样的过度自信。它能挑出低级笔误，可碰上"整个方向就错了"这种系统性问题，两个模型很可能一起点头放行。让一个会犯同样错的人去 review 另一个会犯同样错的人，这不叫质量保证。

验证这件事本身也得多想一层。能自动跑通，不等于对。一旦停止条件写成"测试通过、lint 干净"，Goodhart 那一套就来了：循环会去找一切让测试变绿的捷径——把断言改松、给 mock 注水、拿 try/catch 把异常吞掉。你以为自己在量"代码对没对"，其实量的是"检查器闭没闭嘴"。条件越机械，循环越擅长在不解决问题的前提下把它满足掉。

最别扭的一点：真正值钱的工程，恰好是循环干不了的那部分。判断、架构、在一堆烂选项里做权衡——这些循环自己都明说排除掉了。于是它替你把那点杂活工业化了，副产品是一堆等着人来 review 的低价值 PR。写代码的速度一旦超过读代码的速度，瓶颈就从"写"挪到了"读"，而 review 的人手不会因为你建了个循环就自动多出来。最后你多半不是更快了，是被自己循环吐出来的合并队列淹了。

循环是好东西，但它只奖励已经想明白的人。指望它替你想，它会很乐意带着你一起想错。