Loop Engineering 完全指南：从 ReAct 到 /goal 的范式演进
一只阿木木约 30 分钟目录
一条推文与一个范式转变 什么是 Loop Engineering？第一性原理 技术谱系：四年暗线，一脉相承 循环架构全景：10 种 Loop 类型深度拆解 /goal 与 /loop：原生循环原语的诞生 生产级 Loop 的五块基石 循环工程的七大死法（及防御方案） 成本现实：数字不说谎 多 Agent 编排：Loop Engineering 的下一层 从零开始：30 天入门实践路径 未来推演：Loop Engineering 之后是什么？
第一章：一条推文与一个范式转变
2026 年 6 月 8 日凌晨 12:28，Peter Steinberger（@steipete）——OpenClaw 的创建者，现就职于 OpenAI——在 X 平台发布了两句话，获得了 650 万次浏览：
"你不应该再手动提示 AI 编程代理了。你应该设计提示你的代理的循环。"
就这两句话。没有图表，没有代码仓库链接。
但这两句话刺穿了整个开发者社区的神经。评论区爆炸了：这意味着什么？怎么做？
随后，Anthropic Claude Code 的创建者 Boris Cherny 补充说："我不再提示 Claude 了。我有循环在运行，它们才是在提示 Claude 并决定要做什么的。我的工作是写循环。"
两个处于 AI 编程工具最核心位置的人，几乎同时在说同一件事。这不是巧合，这是一个范式正在临界点爆破。
Loop Engineering 这个名字，由 Google 工程师 Addy Osmani 在 2026 年 6 月正式命名和结构化。 这篇文章的目标，是把这个概念从"一条推文的感悟"，还原成一张完整的技术地图。
第二章：什么是 Loop Engineering？第一性原理
在学习任何新概念时，最危险的事是被定义绑架。我们先从第一性原理推导。
2.1 软件工作的本质
真正的软件项目很少能用一次提示解决。它包含隐藏的约束、不稳定的测试、遗留代码规范、部署规则、产品权衡和不完整的需求。
所以，当你把一个真实任务交给 AI 时，你实际上是在做什么？你在迭代。你提示，读结果，发现问题，再提示，再读……这个过程，你就是那个循环的控制器。
Loop Engineering 要做的，就是把你从这个位置替换掉。
2.2 核心定义
Loop Engineering 是设计、运营和改进反馈循环的实践——这些循环让 AI 编程代理规划工作、修改代码、观察结果，并持续修正其方法，直到软件任务完成。它不是把 AI 工具当作一次性代码生成器，而是把软件工作视为一个迭代系统：定义目标、检查代码库、做出修改、运行验证、读取结果、决定下一步。
用最简洁的一句话：Loop Engineering 是构建一个系统，在你的代理上按计划和目标运行，而不是你自己手动输入每条提示。杠杆从单次提示的质量，转移到了生成和验证提示的系统设计。
2.3 与 Prompt Engineering 的本质区别
| 控制者 | ||
| 时间尺度 | ||
| 技能核心 | ||
| 类比 | ||
| 瓶颈 |
2.4 Loop 与 Automation 的区别
这是一个关键区分，很多人混淆了这两个概念。
自动化（Automation）执行一系列步骤。循环（Loop）内部有决策——代理主动评估目标是否达成，并基于这个评估决定是否继续循环。关键区别在于目标验证步骤。
简单地说：Automation 是脚本，Loop 是带判断力的脚本。
第三章：技术谱系——四年暗线，一脉相承
Loop Engineering 不是凭空出现的。它有清晰的技术血缘：ReAct (2022) → AutoGPT (2023) → ralph (2025) → /goal (2026 春) → 编排循环（现在）。
让我们逐层解剖。
3.1 奠基石：Chain of Thought（2022 之前）
在 ReAct 之前，有一个更基础的突破：Chain of Thought（CoT）提示。
CoT 通过引导 LLM 生成中间推理步骤，激发了模型解决复杂推理任务的能力，为模型转变为具有涌现规划能力的 Agent 提供了可能。
但 CoT 的问题是：它只能思考，不能行动。思考完了，任务还得靠外部工具执行。这个鸿沟，由 ReAct 来跨越。
3.2 第一范式：ReAct（2022）
ReAct 代表 Reasoning + Acting（推理 + 行动），这个概念来自 2022 年 Yao 等人的研究论文。ReAct 建立了核心的 Thought—Action—Observation 循环。它将 Thought（源自 CoT）与 Action-Observation 相结合，首次构建了一个现代 Agent 范式，能够主动思考、做决策并执行复杂任务。
ReAct 循环的节拍如下：
text
Thought: 我需要找到用户数据库中的所有过期 token
Action: search_database(query="tokens WHERE expiry < NOW()")
Observation: 找到 1,247 条过期记录
Thought: 现在我需要删除它们，但应先备份
Action: backup_table("user_tokens")
Observation: 备份成功，文件：backup_20260617.sql
Thought: 现在可以安全删除了
Action: delete_records(condition="expiry < NOW()")
Observation: 已删除 1,247 条记录
Thought: 任务完成，清理成功。
FINISH
循环按照 Thought → Action → Observation → Thought → Action → Observation 运行，直到 Agent 判断它有足够信息来回答为止。
ReAct 的核心优势：
一些 Agent 框架让模型提前生成完整计划，然后依次执行每个步骤。这对可预测任务有效，但当早期步骤产生意外结果时就会出问题——计划无法适应。ReAct 在每一步重新评估，使其在动态环境中更加健壮。
ReAct 是 LangChain AgentExecutor 和大多数生产级编程 Agent 内部的模式，是任何循环工程工作的默认起点。
ReAct 的局限：
虽然 ReAct 循环是完整的，但其 Thought 步骤依赖模型的内部知识，缺乏从失败中学习的机制。
换句话说：ReAct 每次都从零开始，失败了也不记得为什么失败。这是 Reflexion 要解决的问题。
3.3 自我进化：Reflexion（2023）
Reflexion 在 ReAct 基础上增加了记忆和自我批评层——在一次尝试失败后，Agent 将一条语言化的教训写入情节记忆缓冲区，后续尝试读取这些记忆，从而在会话内跨试验中不断改进，无需重新训练。 3 简而言之：ReAct 是单次循环；Reflexion 是一个能从自身失败中学习的循环。
Reflexion 的工作流：
text
第一次尝试 → 失败
↓
自我反思："我用了错误的 API 端点，应该用 v2 而不是 v1"
↓ 写入记忆
第二次尝试（携带反思记忆）→ 更接近成功
↓
自我反思："token 格式正确了，但缺少 Authorization header"
↓ 写入记忆
第三次尝试（携带累积记忆）→ 成功
何时使用 Reflexion vs ReAct？
Reflexion 是带自我评估层的 ReAct。任务完成或失败后，Agent 生成一个关于哪里出了问题的批评，该批评被存储在记忆中并注入到下一次尝试的上下文中。它比 ReAct 更昂贵（需要额外的 LLM 调用进行反思），在需要试错的任务上表现更好：调试、不熟悉的代码库、创造性问题解决。对于简单的检索任务，通常不值得增加这个开销。
3.4 长记忆扩展：CoALA 与 MPR（2023-2025）
Reflexion 的自我反思是短期的——只在当前会话内有效，下一个 session 就消失了。
为了解决 Reflexion 只有短期反思的局限，CoALA（Sumers et al., 2023）提供了一个包含长期记忆的认知蓝图。Meta-Policy Reflexion（MPR，Wu and Qu, 2025）将这个想法更进一步，通过提取谓词式的通用规则，将碎片化的经验提炼和固化为可跨任务复用的元策略。
这意味着：一个 Agent 在项目 A 中学到的教训，可以被保留并应用于项目 B。
3.5 平行加速：ReWOO 与 LLMCompiler（2024）
当你的任务有多个独立子任务时，顺序执行 ReAct 效率低下。
LangChain 的 LLMCompiler 通过并行运行独立步骤，报告了相比顺序 ReAct 3.6 倍的速度提升（Kim et al., ICML 2024）。权衡是：当早期步骤产生意外结果时，适应性不如 ReAct。
3.6 Ralph Loop：极简主义的胜利（2025）
Ralph 技术由 Geoffrey Huntley 在 2026 年初命名（以《辛普森一家》中的 Ralph Wiggum 命名），在一个普通的 while 循环中运行编程 Agent：将相同的提示输入到一份写好的规格文档，让 Agent 完成一项任务并提交，然后用干净的上下文启动一个新实例，再次输入相同的提示，重复直到成功标准满足。智能来自清晰的规格和可验证的结果，加上一个外部状态文件，而不是一次漫长的会话。
Ralph 的本质洞察是：上下文窗口是敌人。每次迭代都用新鲜的上下文重新开始，比让一个充满历史包袱的 Agent 继续工作效率更高。
3.7 技术谱系全图
text
Chain of Thought (2020)
│
▼
ReAct: Thought→Action→Observation (2022)
│
├──→ Reflexion: +自我批评记忆层 (2023)
│ │
│ └──→ CoALA: +长期记忆蓝图 (2023)
│ │
│ └──→ MPR: +跨任务元策略 (2025)
│
├──→ Plan-and-Execute: +预规划 (2023)
│
├──→ ReWOO/LLMCompiler: +并行执行 (2024)
│
└──→ Ralph Loop: +外部 while 循环 (2025)
│
▼
/goal & /loop 原语 (2026)
│
▼
Multi-Agent Orchestration Loops (现在)
第四章：循环架构全景——10 种 Loop 类型深度拆解
目前存在 10 种不同类型的 Agent 循环，从 ReAct (2022) 到 Ralph Loop 和 OpenAI 的 /goal 命令。
下面是完整的分类与使用场景指南：
类型 1：Basic ReAct Loop（基础 ReAct 循环）
核心结构：Thought → Action → Observation → 重复
适用场景：
任务需要动态决策（不能预先规划所有步骤） 单一 Agent，工具调用频繁 中等复杂度任务（10-50 步以内）
代码骨架：
Python
from langchain.agents import create_react_agent, AgentExecutor
agent = create_react_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, max_iterations=20)
result = executor.invoke({"input": "修复所有 TypeScript 类型错误"})
优点：最简单、最有文档、调试最容易
缺点：不从失败中学习；长任务会撑满上下文窗口
类型 2：Reflexion Loop（反思循环）
核心结构：ReAct + 失败后自我批评 → 记忆注入 → 再试
适用场景：
调试不明原因的 bug 处理不熟悉的大型代码库 需要多次试错才能找到正确路径的任务
代码骨架：
Python
memory_buffer = []
for attempt in range(max_attempts):
result = react_agent.run(task, context=memory_buffer)
if is_success(result):
break
# 自我批评步骤
critique = llm.invoke(f"""
任务：{task}
尝试结果：{result}
问题所在：请分析失败原因，给出下次应避免的具体教训。
""")
memory_buffer.append(critique)
优点：跨试验持续改进；适合复杂调试
缺点：token 消耗较高；批评质量取决于提示设计
类型 3：Plan-and-Execute Loop（规划执行循环）
核心结构：先规划完整步骤 → 按序执行每步
适用场景：
步骤可预测的工作流（如：生成财务报告、处理保险理赔） 你能提前写出人类检查清单的任何任务
最适合定义明确的多步工作流，其中你能合理预测步骤顺序。处理保险理赔、生成财务报告、编排数据管道任务——任何你能为人类写清单的事情。
局限：当问题空间过于动态或模糊，无法提前规划时就会失效。如果重新规划在大多数任务中都会触发，你同时在承受规划成本和适应成本。这时最好用 ReAct 的逐步灵活性，或能原生处理分支的图式 Agent。
类型 4：ReWOO Loop（并行推理循环）
核心结构：提前推理所有工具调用 → 并行执行 → 综合结果
适用场景：
多个独立子任务可以同时运行 需要从多个 API 聚合信息
优点：LLMCompiler 实现的并行执行报告了相比顺序 ReAct 3.6 倍的速度提升。
缺点：早期步骤失败时无法灵活调整
类型 5：Ralph Loop（极简外部循环）
核心结构：while True: 新实例 + 相同提示 + 外部状态检查
Bash
#!/bin/bash
MAX_ITER=20
iter=0
while [ $iter -lt $MAX_ITER ]; do
claude -p < task_prompt.md
# 外部验证
if npm test 2>&1 | grep -q "All tests passed"; then
echo "✅ 任务完成，共迭代 $iter 次"
break
fi
iter=$((iter + 1))
echo "第 $iter 次迭代，测试未通过，继续..."
done
核心洞察：每次都用新鲜上下文，比让一个"疲惫"的 Agent 继续更有效
适用场景：测试修复、代码生成对齐规格、反复执行直到验证通过的任务
类型 6：/goal Loop（原生目标循环）
Claude Code 的 /goal 命令于 2026 年 5 月 12 日在版本 2.1.139 中发布。你设定一个完成条件，Claude 跨多轮自主工作直到该条件满足——追踪经过的时间、轮次和 token 数量。
Bash
# 在 Claude Code 中
/goal 所有 TypeScript 编译错误被修复，npm run build 返回退出码 0
/goal 原语已成为 2026 年讨论最多的 Agent 原语，正因为它是让循环在没有人类在场的情况下判断自己完成了的那个部件。
关键认识："目标的质量等于证明它的证据质量。'让结账流程更好'给了循环什么都没有可以自我评分，所以它随时都可能停下来。运行无人值守 Agent 的从业者已经收敛到同一个解决方案：指定期望的最终状态、证明成功所需的证据、不得违反的约束，以及轮次或预算的硬性上限。Agent 只是执行者；你编写它在允许声明'完成'之前必须通过的验收测试。"
类型 7：/loop Loop（调度循环）
Claude Code 的 /loop 用于定期调度的重复提示，/goal 用于运行直到可验证条件成立，加上 hooks、子代理和 worktree 隔离。
Bash
# 监控所有 PR，有新评论时自动修复
/loop babysit all my PRs
动态间隔：当你省略间隔时，Claude 根据观察到的情况选择一分钟到一小时之间的延迟——构建完成时等待时间短，没有待处理任务时等待时间长。自定义默认值：项目中的 loop.md 文件替换了裸 /loop 的内置维护提示。
类型 8：Stop Hook Loop（终止拦截循环）
这是 /goal 的底层机制之一。
过早退出——LLM 会在主观认为任务完成时停止。Stop Hook 拦截退出尝试，检查完成标准是否真正满足（测试通过、覆盖率超过阈值、类型检查清晰），如果不满足则重新注入任务提示。
YAML
# .claude/hooks.yaml
stop_hook:
command: "npm test && npx tsc --noEmit"
on_nonzero: reinject # 测试失败时，重新注入任务
on_zero: allow_stop # 测试通过时，允许退出
类型 9：Maker-Checker Loop（生产-验证双 Agent 循环）
单个模型实例存在确认偏差；它会乐于为自己的作业评分，无法发现自己的 bug。解决方案：分离工作。将一个子代理（"maker"）专门用于起草代码，另一个独立的子代理（"checker"）专门用于对照测试、规格和 linter 验证代码。
Python
maker_agent = Agent(
model="claude-opus-4",
system_prompt="你是一个专注于实现功能的编程 Agent，不负责评判质量。"
)
checker_agent = Agent(
model="claude-sonnet-4",
system_prompt="你是一个严苛的代码审查 Agent，只评判是否通过测试和规格，不参与实现。"
)
# maker 生成代码
code = maker_agent.run(task)
# checker 独立验证
verdict = checker_agent.run(f"验证以下代码是否符合规格：\n{code}")
if not verdict.passes:
# 循环：带反馈重试
code = maker_agent.run(task + f"\n上次尝试的问题：{verdict.feedback}")
类型 10：Multi-Agent Orchestration Loop（多 Agent 编排循环）
最高级形态。一个 Orchestrator Agent 管理多个专业子 Agent，形成嵌套循环结构。
Boris 在 2026 年 6 月发布了自主运行 Opus 数小时甚至数天的五个技巧：Auto 权限模式——Claude 不会在每次文件写入时停下来请求批准；动态工作流——为大型任务编排数百或数千个子代理。
这种模式我们在第九章详细展开。
第五章：/goal 与 /loop——原生循环原语的诞生
5.1 为什么这是历史性节点
让早期采用者感到惊讶的是，这不再是一个从零构建的工作。一年前，一个循环意味着一堆只有你自己理解的 bash 脚本。到 2026 年中，这些组件已经内置在产品中了。
Peter Steinberger 关于循环需要什么的清单，几乎完全映射到 OpenAI Codex 应用程序，以及几乎相同的列表映射到 Anthropic 的 Claude Code。一旦你注意到这个形态在工具间是相同的，你就不再争论哪个 Agent 最好，而是开始设计一个无论你用哪个工具都能运行的循环。
5.2 Claude Code /goal 深度解析
/goal 在 2026 年 5 月 11 日的 v2.1.139 版本中被加入 Claude Code，这是一个跨轮次运行的原生循环，直到你写的条件为真，并由一个独立的快速模型在每轮结束后评分工作。
/goal 的工作机制：
text
用户: /goal 所有单元测试通过，没有 TypeScript 错误，覆盖率 > 80%
Claude 内部:
轮次 1: 修复 TypeError in auth.ts → 运行测试 → 5/20 通过
评分模型: "距离目标还远，继续"
轮次 2: 修复 null reference in user.service.ts → 测试 → 12/20 通过
评分模型: "有进展，继续"
轮次 3: 修复 async/await 错误 → 测试 → 19/20 通过，覆盖率 75%
评分模型: "测试接近通过，覆盖率不足，继续"
轮次 4: 增加测试 → 20/20 通过，覆盖率 83%
评分模型: "所有条件满足，允许停止"
Claude: ✅ 目标达成。
写好 /goal 条件的模板：
Bash
/goal [期望的最终状态], [证明成功的可验证证据],
[不得违反的约束], [硬性上限]
# 例子：
/goal 结账流程重构完成，
npm test 全部通过 + npm run build 无错误 + 手动测试用例列表通过，
不得修改 payment/ 目录中的文件，
最多 30 轮迭代或 $5 token 预算
# ❌ 坏的例子：
/goal 让代码更好 # 无法验证，循环永远不知道何时停止
5.3 Claude Code /loop 深度解析
/loop 用于定期调度的重复提示，持续运行直到你手动停止。
Bash
# 最经典的 Boris Cherny 示例
/loop babysit all my PRs
# 等价于：
# - 每隔 X 分钟检查所有打开的 PR
# - 发现 CI 失败 → 自动修复 → 推送
# - 发现新评论 → 启动独立 worktree 子代理处理
# - 没有任务时 → 动态延长等待时间
用 loop.md 自定义行为：
Markdown
# loop.md（项目根目录）
# 覆盖 /loop 的默认提示
## 我的循环任务
1. 检查 GitHub Actions 中的失败 CI
2. 阅读错误日志，识别根本原因
3. 创建一个 worktree 隔离的子代理来修复
4. 如果修复需要超过 10 分钟，暂停并通知我
5. 检查有新评论的 PR，判断是否可自动响应
## 不允许做
- 不得合并任何 PR，即使 CI 通过
- 不得修改 .env 文件
- 不得安装新的 npm 依赖
5.4 OpenAI Codex /goal（对比参考）
OpenAI Codex 有 Automations 用于无提示的重复工作，一个 /goal 命令（于 2026 年 4 月 30 日在 Codex CLI 0.128.0 中添加），内置 worktrees、skills 和 TOML 定义的子代理。
两个平台的收敛证明：这不是某一家公司的产品决策，而是 Agent 时代的必然架构选择。
第六章：生产级 Loop 的五块基石
一个实用的循环有五个组成部分加一个记忆存储：执行发现和分类的调度自动化、防止并行 Agent 冲突的 git worktrees、捕获项目知识的技能、将 Agent 接入真实工具的插件和 MCP 连接器，以及将生产者与检查者分离的子代理。
让我们逐一深入。
基石 1：Worktrees——并行 Agent 的隔离边界
问题：两个 Agent 同时修改同一个文件会造成状态损坏。
Bash
# ❌ 危险：两个 Agent 在同一工作目录
agent_1: 修改 src/auth.ts（行 45）
agent_2: 修改 src/auth.ts（行 47）
# 结果：git 冲突，或更糟——静默覆盖
Bash
# ✅ 安全：每个 Agent 有隔离的 worktree
git worktree add /tmp/agent-auth-fix feature/fix-auth
git worktree add /tmp/agent-test-fix feature/fix-tests
# Agent 1 在 /tmp/agent-auth-fix 工作
# Agent 2 在 /tmp/agent-test-fix 工作
# 互不干扰，完成后 PR 合并
将并行任务隔离到专用目录中，使用原生 Git worktrees。在 Claude Code 中，你可以传递 --worktree 标志或配置子代理使用 isolation: worktree，这样 runner 会生成一个干净的 checkout，执行任务，然后在完成时销毁该 worktree。
基石 2：Skills / CLAUDE.md——消除冷启动问题
问题：在运行自主循环之前，你必须消除"冷启动"问题。Agent 在不同运行之间会忘记一切，这意味着它们会信心十足地猜测你的项目规范，除非你把这些规范写下来。
解决方案：CLAUDE.md——一个放在项目根目录的 Markdown 文件，每次 Agent 启动时自动读取。
Markdown
# CLAUDE.md
## 项目概况
这是一个 Next.js 14 + TypeScript + Prisma 的 SaaS 项目。
数据库：PostgreSQL（开发环境：localhost:5432）
## 代码规范
- 所有新文件必须有 TypeScript 类型
- API 路由在 /app/api/ 下，使用 Next.js Route Handlers
- 数据库操作只能通过 /lib/db.ts 的封装函数进行
- 禁止直接 import Prisma client，使用 `import { db } from '@/lib/db'`
## 测试规范
- 单元测试：Vitest，文件命名 *.test.ts
- 运行：`npm test`
- 覆盖率要求：> 80%
## 不允许修改的文件
- /lib/auth.ts（认证逻辑，需人工审查）
- /prisma/schema.prisma（数据库结构变更需 DBA 审批）
- .env*（环境变量）
## 提交规范
格式：`type(scope): description`
例如：`fix(auth): handle expired token refresh`
基石 3：MCP Servers——工具表面扩展
Agent 工具工程有七个平面框架：循环策略、工具表面、上下文、沙箱、多 Agent 路由、可观测性、模型路由。
MCP（Model Context Protocol）是这个"工具表面"层的标准化实现。一个只能读取文件的 Agent 是受限的。通过 MCP，你可以给 Agent 接入：
JSON
// .claude/mcp.json
{
"servers": {
"github": {
"command": "npx @modelcontextprotocol/server-github",
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
},
"postgres": {
"command": "npx @modelcontextprotocol/server-postgres",
"args": ["postgresql://localhost/mydb"]
},
"filesystem": {
"command": "npx @modelcontextprotocol/server-filesystem",
"args": ["/workspace"]
}
}
}
现在你的 Agent 可以：读取 GitHub PR、查询数据库、管理文件——全部在一个统一的工具接口下。
基石 4：Sub-Agents——专业化分工
Claude Code 子代理是专门处理特定类型任务的专业 Claude 实例。每个实例在自己的上下文窗口中运行，有自定义的系统提示、有范围限制的工具列表和独立的权限。
你把旁支任务委托给一个有自己上下文窗口、工具和模型的子实例，而不是把每次研究都倒进同一个对话。主会话保持专注在重要工作上。
实际的子代理配置：
Markdown
# .claude/agents/code-reviewer.md
---
name: code-reviewer
model: claude-sonnet-4
tools: [read_file, list_directory]
description: "代码审查专家。触发条件：当主 Agent 完成代码修改后请求审查时。"
---
你是一个严格的代码审查 Agent。你只做以下事情：
1. 检查代码是否符合项目规范（参考 CLAUDE.md）
2. 检查是否有明显的安全漏洞
3. 检查测试覆盖率是否充足
你不编写代码，只评判代码。
输出格式：PASS / FAIL，以及具体理由。
子代理的成本现实：
每个子代理、团队成员、工作流代理和后台会话都从相同的计划配额中扣除，所以十个并行代理会以十倍速度消耗配额。CloudZero 的 2026 年 5 月分析估计，单个开发者正常的单会话工作流大约每天 $13，三个并行代理为 $30-40/天，五到十个代理为 $50-130/天。
基石 5：Observability——让循环变得可见
一个无法观察的循环，和一个没有循环没什么区别——你不知道它在做什么，也不知道它在哪里出了问题。
Python
import logging
from dataclasses import dataclass
from typing import List
@dataclass
class LoopTelemetry:
iteration: int
action_taken: str
observation: str
state_hash: str # 用于检测"原地转圈"
token_cost: float
timestamp: str
class ObservableLoop:
def __init__(self, max_iter=20, budget_usd=5.0):
self.max_iter = max_iter
self.budget_usd = budget_usd
self.telemetry: List[LoopTelemetry] = []
self.total_cost = 0.0
def run(self, goal: str):
for i in range(self.max_iter):
# 执行一步
result = self.agent.step(goal)
# 记录遥测
t = LoopTelemetry(
iteration=i,
action_taken=result.action,
observation=result.observation,
state_hash=hash(str(result.state)),
token_cost=result.cost,
timestamp=datetime.now().isoformat()
)
self.telemetry.append(t)
self.total_cost += result.cost
# 检测原地转圈
if i > 2:
recent_states = [t.state_hash for t in self.telemetry[-3:]]
if len(set(recent_states)) == 1:
logging.warning(f"🔄 检测到循环停滞（连续 3 步状态相同），中止")
break
# 预算检查
if self.total_cost > self.budget_usd:
logging.warning(f"💰 预算超限（${self.total_cost:.2f}），中止")
break
# 目标验证
if self.verify_goal(goal, result):
logging.info(f"✅ 目标达成，共 {i+1} 步，花费 ${self.total_cost:.2f}")
break
常见模式：停止前运行测试、阻止对生成文件的编辑、提交前 lint、在分支名称中要求 issue ID、依赖变更后运行安全扫描。Hooks 让 Agent 工作流感觉像 CI，但更接近编辑循环。
第七章：循环工程的七大死法（及防御方案）
大多数失败可追溯到四个原因：没有硬性停止条件、目标规格不明、长会话中的上下文溢出，以及缺少成本控制。
但在真实生产环境中，失败模式远不止这四种。
死法 1：无限循环（Infinite Loop）
症状：循环运行了 2 小时，账单来了，什么都没完成。
根源：LLM 没有完成的概念。模型不知道何时该停止，只知道继续似乎是合理的。
案例警示：Uber 在工程师用 Claude Code 和 Cursor 四个月内烧光了年度 AI 预算，随后将每人每工具每月限额设为 1500 美元。有人说："没有护栏，你会得到无限循环和比预算高几个数量级的账单。"
防御方案：
Python
# 三道防线
MAX_ITERATIONS = 20 # 1. 硬性迭代上限
MAX_BUDGET_USD = 5.0 # 2. 美元预算上限
MAX_STAGNATION = 3 # 3. 连续无进展步骤上限
# 实现
iter, cost, stagnation = 0, 0.0, 0
prev_state = None
while iter < MAX_ITERATIONS and cost < MAX_BUDGET_USD:
result = agent.step()
cost += result.token_cost
iter += 1
# 无进展检测
if result.state == prev_state:
stagnation += 1
if stagnation >= MAX_STAGNATION:
break # 死法3的防御
else:
stagnation = 0
prev_state = result.state
if verify_goal(result):
break
死法 2：目标漂移（Goal Drift）
症状：你让 Agent 修复登录 bug，它最后重构了整个认证系统。
根源：目标定义模糊，Agent 自行解读"更好"的含义。
防御方案：目标必须包含"不能做什么"：
Bash
/goal 修复 auth.ts 第 127 行的 null reference 错误，
单元测试全部通过，
不得修改任何其他文件，
不得重构或重命名任何函数
死法 3：上下文溢出（Context Overflow）
症状：长会话后 Agent 开始"忘记"早期的指令，做出前后矛盾的修改。
根源：上下文窗口是有限的，长会话中早期信息被逐渐压缩或丢失。
你让它"检查这些是否涉及认证管道"，看着上下文窗口膨胀到 70% 以上。再过两个提示，它开始自动压缩，你失去了思路。这正是子代理要解决的问题。
防御方案：
Python
# Ralph Loop 策略：每次迭代用新鲜上下文
def ralph_loop(spec_file, max_iter=20):
for i in range(max_iter):
# 每次都是全新的 Agent 实例
agent = create_fresh_agent()
# 上下文来自外部状态文件，不是对话历史
context = load_external_state("loop_state.json")
result = agent.run(
spec=open(spec_file).read(),
context=context
)
# 把进度保存到外部状态，而不是对话中
save_external_state("loop_state.json", result.progress)
if result.complete:
break
死法 4：自我认同偏差（Self-Grading Bias）
症状：Agent 报告"任务完成"，但实际上问题没有解决。
根源：单个模型实例存在确认偏差；它会乐于为自己的作业评分，无法发现自己的 bug。
防御方案：Maker-Checker 分离（见第四章类型 9），或使用外部验证：
Python
# 永远不要用同一个模型验证自己的工作
# ❌ 错误
result = agent.run(task)
verdict = agent.run(f"你刚才的工作做得对吗？{result}") # 必然说"对"
# ✅ 正确
result = maker_agent.run(task)
verdict = subprocess.run(["npm", "test"]) # 机械验证
# 或
verdict = checker_agent.run(f"独立验证：{result}") # 不同模型
死法 5：子代理递归爆炸（Sub-agent Recursion Explosion）
症状：主 Agent 派生子代理，子代理又派生子代理，形成失控的树状爆炸。
最需要密切关注的失败模式是子-子代理递归，即子 Agent 在没有硬性上限的情况下开始派生更多 Agent。
防御方案：
Python
# 在每个子代理 prompt 中明确声明
system_prompt = """
你是一个专业的测试修复子代理。
规则：
- 你只能修复你被分配的一个测试文件
- 你不能派生任何子代理
- 最多尝试 5 次，然后报告失败原因
- 超过 10 分钟自动中止
"""
死法 6：静默失败（Silent Failure）
症状：循环正常退出，但实际上什么都没做，或做错了，你完全不知道。
根源：沉默 ≠ 成功。没有护栏的情况下，Agent 默认继续执行。
防御方案：强制要求结构化输出：
Python
from pydantic import BaseModel
class LoopResult(BaseModel):
status: Literal["success", "failure", "partial"]
completed_tasks: List[str]
failed_tasks: List[str]
evidence: str # 必须提供可验证的证据
next_steps: List[str]
# Agent 必须按此格式输出，否则视为失败
result = agent.run_structured(task, output_schema=LoopResult)
assert result.evidence != "", "拒绝没有证据的'成功'"
死法 7：权限蔓延（Permission Creep）
症状：Agent 访问了它不应该访问的生产数据库，或意外推送了代码到 main 分支。
安全问题需要直接说明： 一个无人值守的循环也是一个无人值守地犯错的循环。
防御方案：最小权限原则：
JSON
// .claude/agents/bug-fixer.json
{
"tools": [
"read_file",
"write_file", // 只能写，不能删
"run_bash" // 只能运行 npm test，不能 git push
],
"permissions": {
"allow": ["src/**", "tests/**"],
"deny": [".env*", "prisma/**", ".git/**"]
},
"bash_allowlist": ["npm test", "npm run lint", "tsc --noEmit"]
}
第八章：成本现实——数字不说谎
Loop Engineering 的最大隐患之一是成本。多轮、多 Agent 的运行可以将费用以指数级放大。
8.1 单 vs 多 Agent 的成本对比
每个子代理都从相同的计划配额中扣除，所以十个并行代理会以十倍速度消耗配额。估计显示：正常单会话工作流大约每天 $13，三个并行代理为 $30-40/天，五到十个代理为 $50-130/天。
8.2 成本估算心智模型
text
基础成本估算（以 Claude Opus 为例）：
- 单次简单提示：$0.01-0.05
- 一个 ReAct 循环（20 步）：$0.5-2.0
- 一个带 Reflexion 的循环（5 次尝试）：$2.0-8.0
- 一个 /goal 运行（30 轮）：$3.0-15.0
- 并行 5 个 /goal 循环：$15-75
月度成本场景：
- 轻度使用（每天 2-3 个循环）：$50-150/月
- 中度使用（每天 5-10 个循环）：$200-500/月
- 重度使用（Uber 级别）：可能 $1000+/月
8.3 成本控制的四道防线
Python
class BudgetedLoop:
def __init__(self):
self.daily_budget = 10.0 # 每日预算 $10
self.loop_budget = 2.0 # 单次循环预算 $2
self.alert_threshold = 0.8 # 80% 时预警
def pre_flight_check(self):
"""运行前估算成本"""
estimated = self.estimate_cost()
if estimated > self.loop_budget:
raise BudgetException(f"预估成本 ${estimated} 超过预算 ${self.loop_budget}")
def on_each_step(self, cost):
"""每步检查"""
self.spent += cost
if self.spent > self.loop_budget * self.alert_threshold:
logging.warning(f"⚠️ 已用 {self.spent/self.loop_budget*100:.0f}% 预算")
if self.spent > self.loop_budget:
raise BudgetExceededException("预算耗尽，中止循环")
def use_model_routing(self, task_complexity):
"""根据任务复杂度选择模型"""
if task_complexity == "simple":
return "claude-haiku-3" # 最便宜
elif task_complexity == "medium":
return "claude-sonnet-4" # 平衡
else:
return "claude-opus-4" # 最强但最贵
第九章：多 Agent 编排——Loop Engineering 的下一层
单 Agent 循环是 Loop Engineering 的入门。真正强大的系统是多 Agent 编排循环。
9.1 为什么单 Agent 有上限？
单 Agent 的 ralph 模式已经过时；多 Agent 监督是新的层级。
单 Agent 的本质限制：
上下文窗口是线性的，无法真正并行 认知边界：一个 Agent 不能同时是专家和审判者 故障单点：一个 Agent 崩溃，整个任务失败
9.2 多 Agent 编排的基本形态
text
┌─────────────────┐
│ Orchestrator │
│ (任务分解/路由) │
└────────┬────────┘
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Worker A │ │ Worker B │ │ Worker C │
│ (后端修复) │ │ (前端修复) │ │ (测试生成) │
│ worktree: A │ │ worktree: B │ │ worktree: C │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└────────────────┼────────────────┘
▼
┌──────────────────┐
│ Checker/Verifier │
│ (独立验证所有结果)│
└──────────────────┘
9.3 用 LangGraph 实现多 Agent 编排
没有 Agent 可以直接调用另一个 Agent——所有路由都是显式的。LangGraph 控制流程，CrewAI 控制思考，这种分离在生产环境中至关重要。
Python
from langgraph.graph import StateGraph, END
from typing import TypedDict, List
class OrchestratorState(TypedDict):
task: str
subtasks: List[str]
results: dict
final_result: str
verified: bool
# 定义节点
def decompose(state):
"""分解任务为并行子任务"""
subtasks = orchestrator_llm.invoke(f"将任务分解为独立子任务：{state['task']}")
return {"subtasks": subtasks.list}
def execute_parallel(state):
"""并行执行所有子任务"""
with ThreadPoolExecutor() as executor:
futures = {
task: executor.submit(worker_agent.run, task)
for task in state['subtasks']
}
results = {task: future.result() for task, future in futures.items()}
return {"results": results}
def verify(state):
"""独立验证所有结果"""
# 重要：使用不同于 worker 的模型
verdict = checker_llm.invoke(
f"独立验证以下结果是否满足原始目标：\n"
f"目标：{state['task']}\n"
f"结果：{state['results']}"
)
return {"verified": verdict.passes, "final_result": verdict.summary}
def route_after_verify(state):
if state['verified']:
return END
else:
return "decompose" # 失败则重新分解任务
# 构建图
graph = StateGraph(OrchestratorState)
graph.add_node("decompose", decompose)
graph.add_node("execute", execute_parallel)
graph.add_node("verify", verify)
graph.set_entry_point("decompose")
graph.add_edge("decompose", "execute")
graph.add_edge("execute", "verify")
graph.add_conditional_edges("verify", route_after_verify)
app = graph.compile()
9.4 多 Agent 编排的设计原则
大多数任务不需要五个 Agent。从一个主 Agent 开始，只在上下文分离提供明确价值时才添加专家。一个实际的重构团队：主 Agent（规划/集成）、一到两个实现子代理（后端/前端）、测试子代理和审查子代理。目标是减少瓶颈，而不是让工作流显得华丽。
第十章：从零开始——快速入门实践路径
S1：理解循环本质
Day 1：精读奠基论文
D2：用 LangChain 运行你的第一个 ReAct Agent
Python
# 最小 ReAct Agent
pip install langchain langchain-anthropic
from langchain_anthropic import ChatAnthropic
from langchain.agents import create_react_agent, AgentExecutor
from langchain.tools import tool
@tool
def run_tests() -> str:
"""运行项目测试，返回结果"""
import subprocess
result = subprocess.run(["npm", "test"], capture_output=True, text=True)
return result.stdout + result.stderr
@tool
def read_file(path: str) -> str:
"""读取文件内容"""
return open(path).read()
llm = ChatAnthropic(model="claude-sonnet-4-5")
agent = create_react_agent(llm, [run_tests, read_file], prompt)
executor = AgentExecutor(agent=agent, tools=[run_tests, read_file], max_iterations=10)
result = executor.invoke({"input": "找出测试失败的原因并修复"})
D3：观察循环行为，不干预
运行 Agent，全程观察它的 Thought-Action-Observation 流程。记录：
它在哪里做出了好的决策？ 它在哪里卡住了？ 它什么时候应该停但没停？
这种观察比任何教程都有价值。
S2：添加 Reflexion 和护栏
D1：实现 Reflexion 循环
Python
def reflexion_loop(task: str, max_attempts: int = 5):
memory = []
for attempt in range(max_attempts):
# 构建带记忆的上下文
context = "\n".join([f"教训 {i+1}: {lesson}" for i, lesson in enumerate(memory)])
# 执行一次 ReAct
result = react_agent.run(task, additional_context=context)
if verify(result):
print(f"✅ 第 {attempt+1} 次尝试成功")
return result
# 自我批评
critique = llm.invoke(f"""
任务：{task}
这次尝试的结果：{result}
请分析：为什么这次失败了？下次应该做什么不同？
给出一条具体的、可操作的教训（不超过 50 字）。
""")
memory.append(critique.content)
print(f"📝 第 {attempt+1} 次失败，教训：{critique.content}")
return None
D2：构建你的第一个 CLAUDE.md
为你现有的一个项目写 CLAUDE.md，包含：
项目技术栈 代码规范 不允许修改的文件 测试运行方式
D3：添加三层护栏
实现迭代上限、预算上限、停滞检测（参考第七章代码示例）。
S3：原生工具实操
D1：Claude Code /goal 入门
Bash
# 安装
npm install -g @anthropic-ai/claude-code
# 基础 /goal 实验
cd your-project
claude
# 在 Claude Code 中：
/goal 修复 src/utils.ts 中的所有 TypeScript 类型错误，tsc --noEmit 返回退出码 0，最多 15 轮
观察：
它如何验证目标？ 什么时候它认为"完成了"？ Stop Hook 是否被触发？
D2：实验 /loop
Bash
# 在 Claude Code 中尝试
/loop 每 30 分钟检查一次 CI 状态，如果有失败，尝试修复
# 或：
/loop babysit my open PRs
D3：设置第一个 Sub-Agent
按照第六章基石 4 的配置，创建一个专门的 code-reviewer.md 子代理，并在实际任务中使用它。
S4：多 Agent 系统实战
D1：构建 Maker-Checker 系统
选择一个你经常做的重复性任务（如写单元测试），实现一个完整的 Maker-Checker 循环：
Maker Agent 生成测试 Checker Agent 评审 如果不通过，Maker 修改 直到 Checker 通过或达到上限
D2：加入 Worktree 隔离
当有两个并行任务时，实践使用独立 worktree 隔离，然后合并结果。
D3：设计你的第一个自动化 Loop
选择一个你现在手动在做的重复任务（PR 检查、依赖更新、测试修复……），将它自动化为一个每日运行的 /loop。
里程碑检查
text
□ Week 1: 能用代码解释 ReAct 循环的每一步
□ Week 1: 运行过至少 3 个 ReAct Agent 实验
□ Week 2: 实现了带 Reflexion 的循环
□ Week 2: 自己的项目有完整的 CLAUDE.md
□ Week 2: 实现了三层护栏
□ Week 3: 用 /goal 完成了一个真实任务
□ Week 3: 用 /loop 自动化了一个重复任务
□ Week 3: 配置并使用了一个子代理
□ Week 4: 实现了完整的 Maker-Checker 系统
□ Week 4: 有一个每天自动运行的 Loop
第十一章：未来推演——Loop Engineering 之后是什么？
11.1 现在：Loop Engineering 的成熟期（2026）
现在从 Agent AI 中获益最多的开发者不是写出最巧妙提示的人——他们是构建有良好边界的、可靠完成任务的循环的人，并在 Loop Engineering 成为主流之前就在学习它。
11.2 接下来：Swarm Engineering（2026 下半年-2027）
在 2026 年 6 月的讨论中有人说："现在不是 ralph/goal 循环了，那已经过时了。现在是某种……"
这个句子没有说完，但方向已经清晰：从单一循环编排，到循环的循环——多个 Agent 系统彼此协调，形成 Swarm（蜂群）式架构。
Swarm Engineering 的特征预测：
动态角色分配：Agent 不再有固定角色，根据任务需要动态成为 Maker 或 Checker 去中心化编排：没有中央 Orchestrator，Agent 之间点对点协商 跨 session 持久记忆：真正的组织级 AI 记忆，不只是单次会话
11.3 对从业者的影响
text
2022-2024：写好提示 = 核心竞争力
2025：懂 Context Engineering = 差异化优势
2026：会 Loop Engineering = 必要技能
2027：掌握 Swarm Engineering = 下一个差异化优势
职能转变预测：
11.4 不会消失的事情
Loop Engineering 不是"AI 取代开发者"的故事。真正的软件项目包含隐藏的约束、不稳定的测试、遗留代码规范、部署规则、产品权衡和不完整的需求。
这些模糊性、权衡判断、业务理解——依然需要人类。
Loop Engineering 改变的是：你花在哪里的时间。从手动执行每一步，到设计执行每一步的系统。
结语：你现在应该做什么
从 ReAct 开始。需要自我纠错时加入 Reflexion。长时间运行的任务触及上下文极限时，使用 Ralph Loop 或 /goal。运行前先明确定义你的目标。在构建复杂度之前，先构建护栏。
Loop Engineering 本质上是一个关于设计层级的转变：从做工作，到管理做工作的系统。这个转变在历史上反复发生过——从手工作坊到流水线，从手写代码到 CI/CD，现在是从手动提示到自治循环。
每次转变，那些最先搞懂新层级的人，都获得了不成比例的杠杆。
现在是 2026 年 6 月。 你有一个很小的时间窗口，在这个技能还稀缺的时候掌握它。
参考资源
/goal 官方文档 | ||
本文写于 2026 年 6 月。所有工具版本号和功能以官方最新文档为准。欢迎转发给你认为值得知道这件事的工程师朋友。
欢迎加入行动营👇获取更多Obsidian + AI数字大脑实践
关注【一只阿木木】。
我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统
去做，才是真的学。🌊