什么是 Loop Engineering

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 现在都凑齐了。

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 每次跑都读得到。

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，能逮到第一个 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 草稿。

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

循环帮不了你的三件事

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

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

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

杠杆点移动了

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

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

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

几句不太一样的话

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

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

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

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

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

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

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