Loop Engineering 的六块积木：让 Agent 循环真正跑起来

上一篇讲了AI编程范式转移，工程师的工作正在从“写提示词”变成“写循环”。

这一篇只解决一个问题：

一个 Loop 到底靠什么跑起来？

如果你真的开始搭 Loop，很快会遇到这些情况：

• Agent 跑了一次，下次又从零开始，因为状态没存下来。
• 两个 Agent 同时改一个文件，互相覆盖，因为没有隔离。
• 每次启动都要重新解释项目结构，因为知识没有沉淀。
• Agent 只能读写本地文件，碰不到 CI、issue、数据库和协作工具，因为没有连接器。
• Agent 写完代码后自己检查自己，然后说“没问题”，结果你一看还是有 bug。

这些问题不是模型不够聪明。

它们说明你的 Loop 缺少基础积木。

一个能真正转起来的 Loop，至少需要六块积木：

• Automations：让循环再次启动
• Worktrees：让尝试互不污染
• Skills：让知识沉淀下来
• Connectors：让 Agent 接触真实工具链
• Sub-agents：让生成和验证分开
• Memory：让状态留在模型外面

为了不讲成工具说明书，我们用一个贯穿例子：

每天早上检查 CI 失败和 open issues，挑一个低风险问题起草修复，跑测试，通过后生成 PR 说明，卡住就停下来交给人。

看完这篇，你应该能判断：自己的 Loop 缺的是哪块积木，下一步该补什么。

01 Automations：让 Loop 有心跳

没有 Automations，Loop 只能跑一次。

Automations 解决的是：

什么时候再来一轮。

比如这个任务：

每天早上检查 CI 失败和 open issues。
如果有低风险问题，起草一个修复计划。
如果没有新问题，只更新状态摘要。

这里需要一个触发机制。

在 Claude Code 里，可以用 /loop 创建会话内的重复任务。官方文档里的示例类似：

/loop 5m check if the deploy has finished and tell me what happened

你可以指定固定间隔，也可以用自然语言描述调度需求。需要注意的是，/loop 更适合会话内的快速轮询；如果要做更长期、脱离当前会话的任务，要看 Routines、桌面端任务、云端任务或 GitHub Actions 这类外部执行环境。

在 Codex 里，也可以用 Automations 做 recurring tasks，比如 morning brief、weekly review、文件巡检、项目状态更新。它适合把重复性检查变成周期任务，再把结果交给你 review。

但 Automations 本身不保证结果正确。

一个坏流程自动运行，只会更稳定地制造坏结果。

所以第一条实操建议是：

从慢频率开始。

每天一次，比每小时一次更适合起步。

先看三件事：

• 它有没有真的找到有价值的问题。
• 它有没有反复制造噪音。
• 它消耗的 token 和注意力是否值得。

自动化之前，先确认这个循环值得自动化。

02 Worktrees：让多个尝试互不污染

第二块积木是 Worktrees。

它解决的是：

多个 Agent 或多条尝试怎么隔离。

想象你让三个 Agent 同时工作：

• Agent A 修认证模块。
• Agent B 排查 billing 问题。
• Agent C 修改测试。

如果它们都在同一个目录里改文件，很容易互相覆盖、互相污染，最后你连哪个改动引入了问题都分不清。

Git worktree 的价值，就是给每条尝试一个独立工作目录和独立分支，同时共享同一个 repo 历史。

可以理解成：

main
├── worktree-auth：修认证问题
├── worktree-billing：排查计费问题
└── worktree-ci：修 CI 失败

在我们的贯穿例子里，如果早上发现三个 CI 失败，你不应该让一个 Agent 在同一个目录里连续乱改。

更稳的方式是：

• 每个问题一个 worktree。
• 每个 worktree 只处理一个目标。
• 最后统一 review、测试、合并。

这里有一个常见误解：

Worktrees 解决的是机械碰撞，不解决审阅瓶颈。

你能同时开 10 个 Agent，不代表你能认真 review 10 组改动。

真正的并行上限，往往取决于人的判断带宽。

起步阶段，两个并行 worktree 通常比十个更稳。

03 Skills：让知识不再每次从零开始

第三块积木是 Skills。

它解决的是：

哪些知识应该长期留在项目里。

每个项目都有一些你不想反复解释的东西：

• 怎么跑测试。
• 怎么启动本地环境。
• 哪些目录不能随便改。
• API 有什么约定。
• Review 时优先看什么。
• 上次踩过哪些坑。

如果每次启动 Agent 都重新解释这些内容，你会浪费 token，也会增加跑偏概率。

Skills 的价值是把这些稳定知识沉淀下来。

可以把它理解成项目的“可调用说明书”。

比如在我们的 CI 例子里，可以有几个 Skill：

how-to-run-tests
how-to-triage-ci-failures
api-contract-rules
review-checklist

需要区分两类东西：

Skill vs Memory 对照图

Skill vs Memory 对照图

• Skill：稳定知识
• Memory：变化状态

Skill 记录“这个项目通常怎么做”。 Memory 记录“这一次已经做到哪里”。

例如：

• “测试命令是 npm test -- auth”属于 Skill。
• “今天 auth/login.test.ts 已修复，token.test.ts 还失败”属于 Memory。

一个好 Loop 跑完以后，不应该只留下代码改动。

它还应该留下新的项目经验：

• 这次失败怎么定位。
• 哪个测试最能复现问题。
• 哪个目录不要乱动。
• 下次遇到同类问题先查哪里。

这些东西沉淀下来，下一轮 Loop 才会更聪明。

04 Connectors：让 Loop 接触真实工具链

第四块积木是 Connectors。

它解决的是：

Agent 怎么接触真实世界。

只会读本地文件的 Loop，能力有限。

真实工作里的信息往往散在很多地方：

CI 巡检 Loop 流程图

CI 巡检 Loop 流程图

• GitHub / GitLab 里有 PR、issue、CI。
• Linear / Jira 里有需求和任务。
• 数据库里有迁移结果。
• 日志系统里有错误堆栈。
• 飞书 / Slack 里有协作消息。
• 浏览器里有线上页面和控制台错误。

Connectors 或 MCP 的意义，是让 Agent 能读到这些真实状态，调用真实工具，拿到真实反馈。

在我们的贯穿例子里，Loop 至少需要接触三类工具：

CI：知道哪里失败
Issue tracker：知道哪些问题开放
Git hosting：提交分支、生成 PR 摘要

没有连接器时，Agent 只能根据你贴过来的片段判断。

有连接器时，它可以自己读状态、查日志、看上下文，再给出更接近真实工作的判断。

但这块能力越强，风险越高。

一旦 Agent 可以操作真实系统，就必须提前写清楚：

• 哪些只读。
• 哪些可以自动修改。
• 哪些必须人工审批。
• 哪些永远禁止。

Connectors 不是越多越好。

起步时先接一个最常用、风险最低、反馈最清晰的工具。

通常是 CI 或 issue tracker。

05 Sub-agents：让生成和验证分开

第五块积木是 Sub-agents。

它解决的是：

谁来干活，谁来验收。

让同一个 Agent 写代码，再让它自己检查，风险很高。

因为它在生成时已经形成了一条思路，检查时很容易沿着原来的思路证明自己没错。

在 Loop 里，更稳的结构是 Maker / Checker 分工：

Maker：负责生成方案、代码、草稿、修复。
Checker：负责对照测试、spec、diff、日志进行验证。

在我们的 CI 例子里：

• Maker 读取失败日志，起草最小修复。
• Checker 跑测试，看 diff，检查有没有改无关文件。
• 如果 Checker 不通过，Maker 才进入下一轮。
• 如果同一问题连续失败两轮，停止并交还给人。

这比“Agent 写完后自己说通过了”可靠得多。

这里先不用把系统做得很复杂。

你可以从一句简单规则开始：

生成和验证分开。
生成阶段不要评价自己。
验证阶段只根据测试、日志和 diff 判断。

下一篇会专门讲三角色架构：

Planner：拆目标、定验收标准。
Generator：按计划生成产物。
Evaluator：独立判断是否达标。

Sub-agents 是这套架构的基础。

06 Memory：让Loop记得昨天做到哪

第六块积木是 Memory。

它解决的是：

下一轮从哪里接着做。

模型会遗忘。

上下文会压缩。

会话会结束。

所以重要状态不能只放在模型脑子里。

Memory 可以很简单。

一个 Markdown 文件就够：

## 目标
- [ ] test/auth 全部通过
- [ ] lint 无错误

## 当前状态
- [x] 已修复 test/auth/login.test.ts
- [ ] 待处理 test/auth/token.test.ts

## 运行日志
| 时间 | 动作 | 结果 | 下一步 |
|---|---|---|---|
| 09:00 | 修复 login 测试 | 通过 | 处理 token 测试 |

在我们的贯穿例子里，每次 Loop 结束，都应该写入：

• 本轮发现了什么。
• 做了哪些修改。
• 哪些测试通过。
• 哪些问题还开放。
• 下一轮应该从哪里开始。

没有 Memory 的 Loop，像一个每天失忆的工人。

它可能很聪明，但每天早上都要重新问：

我今天该干什么？

这不是智能系统。

这是重复消耗。

07 六块积木的最小装配顺序

知道六块积木之后，不要一口气全装上。

这一节不展开完整实操，只给你一张装配顺序图。

真正从零搭一个 CI 自动修复 Loop，会放到后面的实战篇。这里先回答一个更基础的问题：第一次搭 Loop，先装哪几块，后装哪几块。

继续用我们的 CI 例子。

第一步：写清项目基础

先准备两个文件：

AGENTS.md / CLAUDE.md：项目规则、构建方式、测试命令、禁止事项。
loop-state.md：本次 Loop 的目标、状态、日志。

这一步对应 Skills 和 Memory。

这一步的目标很简单：先让 Agent 知道项目规则和当前状态。

• 这个项目怎么跑测试。
• 哪些目录不能动。
• 这次目标是什么。
• 当前进度在哪里。

第二步：定义可验证目标

好目标：

test/auth 中所有测试通过，并且 lint 无错误。

坏目标：

让 app 更好。

一个目标能不能放进 Loop，先看三件事：

• 能不能验证。
• 能不能拆分。
• 范围是否可控。

目标模糊时，先不要自动化。

先让人把目标讲清楚。

第三步：设调度和刹车

调度要慢一点。

比如每天早上跑一次。

刹车要硬一点。

至少写清楚：

最多尝试 3 轮。
同一错误连续出现 2 次就停止。
diff 超过约定范围就停止。
涉及生产配置、密钥、删除操作时必须人工确认。
每天 token 或运行时间有上限。

没有刹车的 Loop，是一辆开上路却没装制动系统的车。

第四步：隔离执行环境

每次 run 尽量在独立 worktree 里执行。

这样即使 Agent 改错，也不会污染主工作区。

轻量任务可以不用并行。

但只要你开始让多个 Agent 同时做事，隔离就不是可选项。

第五步：接入一个真实反馈源

先接一个就够。

比如 CI。

Loop 读取 CI 失败，判断是否有清晰可验证的问题，再把结果写回状态文件。

不要一开始就接满 GitHub、Linear、数据库、Slack、飞书。

连接器越多，权限和故障点越多。

先把一个反馈源跑稳定。

第六步：把经验写回项目

每次跑完，问 Agent 三个问题：

这次学到了什么项目约定？
下次遇到同类问题应该先查哪里？
有没有值得写进 Skill 或 AGENTS.md 的内容？

这一步决定 Loop 有没有复利。

没有沉淀的自动化，只是重复执行。

有沉淀的 Loop，会越来越懂你的项目。

08 最后记住这张图

如果只能记一张图，就记这个：

六块积木总览图

Loop Engineering 的核心，不是把 Agent 放出去自己跑。

它的核心是：让 Agent 在一个有状态、有反馈、有边界、有沉淀的系统里工作。

第一篇讲了为什么要写循环。

这一篇讲了一个循环靠什么跑起来。

这篇不是完整搭建教程。你只需要记住六块积木的位置：什么时候触发、在哪里尝试、读什么知识、接什么工具、谁来验证、状态放哪里。

下一篇，我们进入模式选择：

不同任务，需要不同循环。到那一篇，你就会知道：修 bug、做重构、查故障、改生产配置、维护长期项目，分别该用哪种 Loop。

后面的实战篇，会把这些积木和模式合起来，完整搭一个 CI 自动修复 Loop。

系列预告 这是《Loop Engineering 从入门到进阶手册》系列第 2 篇。 第 1 篇：《我不再提示 AI 了，我的工作是写循环》 第 2 篇：《Loop Engineering 的六块积木：让 Agent 循环真正跑起来》 拆开 Automations、Worktrees、Skills、Connectors、Sub-agents、Memory，先看懂一个 Loop 靠什么运转。 第 3 篇：《别乱上自动化：5 种 Loop 模式和一张决策表》 修 bug、做重构、查故障、改生产配置、长期维护项目，分别该用哪种循环。 第 4 篇：《Agent 不能自己评判自己：三角色架构让 Loop 真正闭环》 拆解 Planner、Generator、Evaluator，解决谁来规划、谁来生成、谁来验收的问题。 第 5 篇：《从零搭建你的第一个 Loop：CI 自动修复实战》

注意：本文没有写死未核实的 CLI flag、Codex 内部 UI 字段或具体私有实现名。工具版本变化很快，发布前应以官方文档为准。