打造 Claude Code 可持续推进的工作流：Loop Engineering 完整上手攻略
公众号名称：技术极简主义
作者名称：兔兔AGI
发布时间：2026-07-01 11:22
如果你还在「一问一答」地使用 Claude Code，那么你可能错过了一个更重要的能力——让工作自己推进。
Claude Code 负责人 Boris Cherny 说过一句话：
I’m no longer prompting Claude. I’m just running a loop that prompts him and then thinks about what to do next. My job is to write loops.
意思很简单：我不再亲自给 Claude 写提示词了。我只是在跑一个循环，让它自己给自己写提示词，自己思考下一步。我的工作是设计这个循环。
用 AI 和设计 AI 的工作方式，已经是两件完全不同的事了。
在上一篇文章《一文看懂 AI 编程智能体工程化新范式：Loop Engineering》中，我们介绍了 Loop Engineering 的核心设计理念。接下来，结合实际工程案例，看看它是如何落地应用的。
为什么「设计循环」取代了「写好提示词」
2024 年，大家聊的是「写好 Prompt」。
2025 年，话题变成了「同时跑多个 Agent」。
到了 2026 年 6 月，又变了。
最近「Loop」这个词在社区突然火了起来。事情起点是 OpenClaw 作者 Peter Steinberger 发的一条对比图：
在 AI 智能体的圈子里，Loop Engineering 这个术语突然被广泛讨论。
原因不复杂——我们受够了「人肉 Loop」。
传统模式下，AI 是工人，人是导演、监工、质检员。你输入一个 prompt，等着看结果，不满意就再输入下一个 prompt，再等，再看……每一轮循环都需要你手动触发。表面上你在用 AI，实际上你才是那个被卡在循环里的人。
Loop Engineering 要做的，就是把这个局面翻转过来。
不再是每次手动输入指令，而是设计一个系统——把任务交给 AI，让它自己执行、自己审查结果、判断是否完成、如未完成就继续下一轮。这整个迭代过程被设计为一个自治系统。
人要完成的身份转变：从「输入提示词的人」变成「设计提示词系统的人」。
2024 到 2026 的三年，这样看比较清楚：
-
- 2024：Prompt Engineering——解决「一句话怎么问得好」
-
- 2025：Multi-Agent Orchestration——解决「多个任务怎么分派得开」
-
- 2026：Loop Engineering——解决「整个流程怎么自己转得动」
Prompt Engineering 解决的是这一轮怎么问好，Loop Engineering 解决的是整个流程怎么持续变好。
Loop 的三种形态
Loop 是可以自己设计的。它可以跑在绝大多数 Agent Harness 上。问题在于「怎么接线」，不在于「用什么工具」。
单 Agent 循环
最简单的一种形态：一个 Agent 自己在循环中反复迭代。
研究 → 起草初稿 → 对照目标检查 → 修复薄弱区域 → 重复，直到超出标准你不需要在每个步骤点「继续」。Agent 自己跑完整条轨迹。就好像一个人反复修改自己的稿子，改到满意才交出来。这是最入门的形态，但已经能解放重复的手动操作。
多 Agent 舰队循环（Fleet Loop）
更大规模的配置下，一群 Agent 协同运转。
目标交到 Orchestrator（编排 Agent）手里。Orchestrator 把大目标拆成多个碎片，分派给不同的 Specialist（专家 Agent）。每个 Specialist 再把更细粒度的任务下发给 Sub-agent。
整个树状结构构成一个「发现 → 规划 → 执行 → 验证」的持续闭环，直到目标达成。
单 Agent 循环是「一个人反复改稿」，Fleet Loop 是「一支团队端到端跑完整个项目」。
核心区分：Open-loop 与 Closed-loop
理解这两种 Loop 的差异，实战中会少踩很多坑。
| 维度 | Open-loop（开环） | Closed-loop（闭环） |
|---|---|---|
| 自由度 | 高，Agent 可自主探索多条路径 | 低，在人类预设的路径内运行 |
| Token 消耗 | 极高，自由探索吞掉大量 Token | 可控，路径受限所以预算可控 |
| 适用场景 | 探索性任务，创造未预先定义的结果 | 执行性任务，有明确目标和验收标准 |
| 当前成熟度 | 前景广阔，但成本是硬伤 | 这是当前真正产出成果的模式 |
| 核心风险 | 预算不设限的团队才玩得起；标准模糊时变成 slop machine | 创造力被限制在框架内 |
Open-loop：给 Agent 宽广的探索空间，让它可以尝试多条路径，创造出启动时没有完整定义的东西。方向是对的，但现实是——90% 的人没有无限预算，Open-loop 在当下不现实。
Closed-loop：人预先设计端到端的 pass，Agent 在人类搭好的轨道上跑。
明确目标
↓
定义好的步骤
↓
每步都有评估关卡
↓
到达停止条件，或交接给人（附带性能数据反馈）每轮执行把学习传给下一轮，精度随执行次数递增。
Closed-loop 中的角色分工可以简化为四层：
-
- Orchestrator——掌握整体目标
-
- Specialist——拥有并执行特定步骤
-
- Sub-agent——执行细节任务
-
- Evaluation Gate——防止低质量或草率输出通过
先跑稳 Closed-loop，再考虑 Open-loop 做探索。这个次序别搞反。
理论基础：ReAct 与 Reflexion
Loop Engineering 不是凭空冒出来的概念。它扎根于两个重要的研究脉络。
ReAct：推理 + 行动
来自 Princeton 和 Google 联合研究的 ReAct 模式，是一种推理与行动交替进行的架构。
思考（Thought）
↓
行动（Action）— 执行工具
↓
观察（Observation）— 接收结果
↓
思考（Thought）— 回到这里
...
最终答案（Final Answer）映射到编码场景：
-
1. 理解目标
-
2. 写代码
-
3. 跑代码，观察输出（或报错）
-
4. 推断问题出在哪
-
5. 修正并重新运行
-
- 重复，直到测试通过
ReAct 是 Loop 的引擎。每一次「改 → 跑 → 看 → 改」就是一次循环迭代。
Reflexion：失败即燃料
Reflexion 是 ReAct 的进阶版本，核心模式是把失败口头化，变成下一次尝试的依据。
任务执行
↓
失败
↓
用自然语言反思失败原因
↓
将反思存入记忆
↓
下一次尝试时使用反思以提升成功率在 Loop Engineering 中，Reflexion 的落地形式就是 SKILL.md 和 progress.txt——这些文件存储了跨轮次的学习，让每一次失败都转化为可复用的经验。
ReAct 是 Loop 的引擎，Reflexion 是 Loop 的学习机制。两者缺一不可。
Claude Code 内置的 Loop 工具
「重复执行同一任务」的概念已经被直接内置到了 Claude Code 中。不需要从零造轮子。
| 命令 | 触发方式 | 适用场景 | 版本要求 |
|---|---|---|---|
/loop | 时间驱动，定时重复 | 轮询检查类任务（如「每 5 分钟检查一次构建状态」） | — |
/goal | 目标驱动，持续工作直到满足条件 | 有明确完成标准的任务（如「修复所有失败的测试」） | v2.1.139（2026.5.11） |
| Dynamic Workflows | AI 自己编写工作流程，拆分为数十到数百个 Sub-agent 并行执行 | 超大规模复杂任务编排，通过 ultracode 关键词触发 | v2.1.154（2026.5.28） |
三者的共同点：减少了「人给指令 → 看结果 → 再给指令」的来回拉扯。你把条件和流程提前设定好，剩下的 AI 自己搞定。
从 /goal 开始试，最不容易出错。
Loop 的双层结构：Inner Loop 与 Outer Loop
Loop 有两层。理解这个区分，Loop Engineering 才算入了门。
Inner Loop：单任务内的自我验证
同一个任务内，Agent 在交付结果前自己验证了自己的工作。
❌ 弱 Agent：改完文件 → 「完成了！」
✅ 强 Agent：改完文件 → 写测试 → 跑测试 → 发现边界失败 → 修边界 → 重新跑 → 全部绿灯 → 「完成了！」关键点：强 Agent 和弱 Agent 用的是完全相同的工具基础设施。区别在于模型是否「选择」了去调用那个验证工具。
Inner Loop 不需要额外配置。它靠的是 Agent 自身的自驱验证行为。
Outer Loop：跨会话的经验沉淀
多个会话之间，Agent 从过去的经历中学习。
Session 1：处理分页逻辑时失败了
↓
把「分页最佳实践」记入 SKILL.md
↓
Session 2：遇到同类任务
↓
读取 SKILL.md，直接跳过上次踩的坑| 维度 | Inner Loop | Outer Loop |
|---|---|---|
| 范围 | 单任务内 | 跨会话 |
| 目的 | 提升任务可靠性 | 随时间持续改进 |
| 状态维护 | 在上下文窗口内 | 持久化文件（SKILL.md、progress.md 等） |
| 当前成熟度 | 很多 Agent 已实现 | 仍在快速发展中 |
Loop Engineering 在设计上同时涵盖这两层。Inner Loop 决定你这一轮跑不跑得通，Outer Loop 决定你下一轮还踩不踩同一个坑。
Loop 的「5+1」工程组件
Addy Osmani 总结了一个可运转的 Loop 由五个组件加记忆构成。这是搭建 Loop 的工具箱。
| 组件 | 解决的问题 | 实现方式 | 关键提醒 |
|---|---|---|---|
| ① Automations | 让 Loop 自己跑起来 | cron + bash 脚本 | 必须有停止条件 |
| ② Worktrees | 多个 Agent 并行时避免文件冲突 | Git worktree 隔离分支 | 只解决机械冲突，不解决审查带宽 |
| ③ Skills | 项目知识不丢失 | .claude/skills/*.md | 没有 Skills，每轮都在重新理解项目 |
| ④ Plugins | 让 Agent 接入真实工具链 | MCP Server 配置 | 权限边界要提前锁死 |
| ⑤ Sub-agents | 分离生成与验证 | Generator/Evaluator GAN 模式 | 高风险环节才启用 |
| +⑥ Memory | 跨会话不遗忘 | progress.md / lessons.md | 没有 Memory，每次都是从头再来 |
① Automations：循环的起搏器
最简形式的自动化循环——死循环 + sleep：
while true; do
claude --print \
--system-prompt "$(cat system_prompt.md)" \
"$(cat task_prompt.md)" \
>> output.log
sleep 300 # 每 5 分钟执行一次
done关键是停止条件。没有停止条件的 Loop 就是一个吞噬 Token 的黑洞。
② Worktrees：并行工作的隔离层
当多个 Agent 同时在一个仓库上工作时，Git Worktree 提供独立的工作空间：
git worktree add ../agent-1-workspace feature/auth-fix
git worktree add ../agent-2-workspace feature/api-refactor
# agent-1 和 agent-2 在不同分支上同时工作 → 不会互相踩文件③ Skills：项目知识的沉淀池
把「这个项目怎么写代码」这件事沉淀为可复用文件，不用每次从头解释：
# Testing Guidelines
- 测试框架：Vitest
- 文件命名规范：*.test.ts
- Mock 库：MSW
- 覆盖率目标：≥ 80%
- 边界用例：始终包含边界和错误场景的测试没有 Skills，Loop 每轮都在重新理解项目；有了 Skills，项目意图开始形成复利。
④ Plugins / Connectors：接入真实工具链
让 Agent 不仅能「给你一个建议」，还能「直接参与流程」：
# MCP Server 配置示例
mcp_servers:
github:
command: "github-mcp-server"
env:
GITHUB_TOKEN: "${GITHUB_TOKEN}"
slack:
command: "slack-mcp-server"
env:
SLACK_BOT_TOKEN: "${SLACK_BOT_TOKEN}"Agent 从「给你建议」变成了「参与流程」。它可以自己看 Issue、自己发 PR、自己通知 Slack 频道。
⚠️ 权限边界要提前锁死。Agent 能操作 GitHub 不等于它可以 force push 到 main。
⑤ Sub-agents：分离生成者与检验者
这个模式从 GAN（生成对抗网络）借鉴了灵感：让「写的」和「查的」分开由不同 Agent 承担。
┌───────────┐ 生成代码 ┌───────────┐
│ Generator │ ──────────────→ │ Evaluator │
│（生成者） │ │（检验者） │
│ │ ←────────────── │ │
└───────────┘ 反馈 └───────────┘
↑ │
│ 提供计划 │
│ ┌───────────┐ │
└────→ │ Planner │ ←─────────┘
│（规划者） │ 评估结果
└───────────┘最危险的结构，就是让写代码的人自己去验证自己的代码。Anthropic 内部采纳了这三 Agent 循环，达到了单 Agent 无法企及的质量水平。
💡 提醒：Sub-agent 模式只在高风险环节启用，普通 CRUD 没必要上这个复杂度。
⑥ +1 Memory：让循环不失忆
循环的生命线。通过在对话之外持久化状态，突破上下文窗口的限制。
## 已完成任务
- [x] 重构认证模块（PR #142）
- [x] 为 API 端点补充测试（PR #143）
## 进行中
- [ ] 数据库迁移
## 经验教训
- PostgreSQL 16 中 JSON 路径语法已变更
- 测试环境必须提供 Redis mockThe agent forgets, the repository doesn’t.
—— Addy Osmani
没有 Memory，每次启动 Loop 都像从头再来。有了 Memory，Loop 是一个持续累积的进程。
端到端实战：每日 Issue 自动分诊修复 Loop
理论讲了这么多，不如动手搭一个。以「每天早上 6 点自动检查新 Issue、修复、发 PR」为例。
Step 1：定义目标与停止条件
-
- 目标：自动发现项目中的新 Issue，尝试修复，创建 PR
-
- 停止条件：（a）所有 Issue 处理完毕，输出 DONE；（b）达到最大重试次数（5 轮）
-
- 最大迭代次数：
MAX_ITERATIONS=5
- 最大迭代次数：
Step 2：搭建目录结构
project/
├── .loop/
│ ├── progress.md # Memory 文件
│ └── run.log # 执行日志
├── .claude/
│ ├── loop_system.md # 系统提示词
│ └── skills/
│ └── testing.md # 测试规范
└── daily_loop.sh # 入口脚本Step 3：编写循环入口脚本
#!/bin/bash
# daily_loop.sh — 每天早上 6 点由 cron 触发
REPO_DIR="/path/to/project"
PROGRESS_FILE="$REPO_DIR/.loop/progress.md"
MAX_ITERATIONS=5
cd "$REPO_DIR"
for i in $(seq 1 $MAX_ITERATIONS); do
echo "=== 第 $i 轮 / 共 $MAX_ITERATIONS 轮 ==="
claude --print \
--system-prompt "$(cat .claude/loop_system.md)" \
"读取 progress 文件，处理下一个未完成的 Issue。
完成修复后更新 progress 文件。
如果所有 Issue 已处理完毕，输出 DONE。" \
2>&1 | tee -a .loop/run.log
# 硬停止：检测到 DONE 就退出
if grep -q "DONE" .loop/run.log; then
echo "所有任务已完成。"
break
fi
doneStep 4：Memory 文件设计
progress.md 就是 Loop 的记忆。每次运行先读它，知道「上次跑到哪了、踩过什么坑」，再继续推进。
Step 5：配置 cron 触发
# 每天早上 6:00 触发
0 6 * * * /path/to/project/daily_loop.sh完整流转图
[cron 每天早上 6:00] ──→ 启动 daily_loop.sh
│
┌───────────▼────────────┐
│ progress.md │ ← 读取上次进度
│（加载状态） │
└───────────┬────────────┘
│
┌───────────▼────────────┐
│ 拉取 GitHub Issues │ ← Plugin 接入
│ 筛选未解决的 Issue │
└───────────┬────────────┘
│
┌───────────▼────────────┐
│ 创建 Git Worktree │ ← 隔离工作区
│ 在独立分支上工作 │
└───────────┬────────────┘
│
┌───────────▼────────────┐
│ 参考 Skills/ 规范 │ ← Skills 层
│ 应用代码修改 │
└───────────┬────────────┘
│
┌───────────▼────────────┐
│ 跑测试 & Lint │ ← 机械验证
│ npm test && npm run lint│
└───────────┬────────────┘
│
测试通过？
否 ──→ 重试修复
是 │
│ ┌────▼────────────┐
│ │ Sub-agent 交叉 │
│ │ 验证修复质量 │
│ └────┬────────────┘
│ │
┌──▼────────▼───────────┐
│ 创建 Pull Request │
│ 更新 progress.md │ ← Memory 更新
└───────────┬───────────┘
│
下一个 Issue 或终止调优建议
-
- 调整迭代次数：从
MAX_ITERATIONS=3起步，观察实际需求后再放宽
- 调整迭代次数：从
-
- 增加特定 Issue 类型的 Skill：比如常见的安全修复可以写一个
security-fix.mdskill，提高修复质量
- 增加特定 Issue 类型的 Skill：比如常见的安全修复可以写一个
-
- 设置告警通知：在
done循环里最后加一句 Slack webhook，完成后通知你
- 设置告警通知：在
让 Loop 持续变好的四个设计原则
原则一：从小闭环开始
别一上来就想建一个全自主 Agent 舰队。从最简单的 Closed-loop 开始——定义一个清晰的目标，设置好停止条件，让它在有限范围内跑。先跑通一个「10 分钟内能验证」的小 Loop。
原则二：每个 Loop 必须有停止条件
三种最常用的终止方式：
-
- 验证通过停止——所有测试绿灯，lint 零告警
-
- 达到上限停止——迭代次数到上限，自动挂起并通知人类
-
- 标记挂起——Agent 判断当前任务超出能力范围，将 Issue 标记为
needs-human并附上已完成的分析
- 标记挂起——Agent 判断当前任务超出能力范围，将 Issue 标记为
没有停止条件的 Loop 不是系统，是 bug。
原则三：让 Outer Loop 形成经验复利
Inner Loop 让你跑完这一轮，Outer Loop 让你下一轮跑得更快。每次循环结束后花 30 秒更新 lessons.md，写下「这次遇到了什么问题、最终怎么解决的」。写那一行的成本极低，但下一轮读到它的 Agent 能直接跳过一个坑。
这是 Loop Engineering 区别于普通脚本的地方——系统随着运行的次数变得越来越聪明。
原则四：认知要跟得上代码
这是最后也是最重要的一条。
Loop 跑起来之后，你最容易犯的错误就是「不管了，让它在后台跑就是了」。但 Loop 是杠杆——
它能放大一个工程师的判断力，也能放大一个工程师的缺席。
每隔一段时间，Review 一下你的 Loop 的产出。看它做的决策对不对，看它的经验教训写得有没有价值。设计 Loop 的人，仍然是最终对输出质量负责的人。
结语
从 2024 年大家琢磨「怎么写好 Prompt」，到 2025 年开始「同时跑多个 Agent」，再到 2026 年认真讨论「设计能自己转的循环」——每一年，人跟 AI 协作的方式都在往深里走一步。
如果把 Loop Engineering 概括为一句话：
把精力从「给高能力的个体无限放权」转移到「为它搭建一个能持续产出的环境」。
同样的道理也适用于人类团队——你招了聪明人不等于团队能有效运转，上下文、规则、反馈、评估标准、进度管理，这些东西一样不能少。
AI 时代的管理，正在从「给出详细指令」转向「设计好的约束」。
设计循环，而不是提示词。
既然看到这里了，如果觉得有启发，随手点个赞、推荐、转发三连吧，你的支持是我持续分享干货的动力。
推荐阅读：打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略
内容效果不满意？点此反馈