Claude Loops 深度解析：从单次对话到自主智能体的工程实践
Claude Loops 深度解析：从单次对话到自主智能体的工程实践
原文参考：Loop engineering: Getting started with loops 作者：Delba de Oliveira & Michael Segner | 深度分析：AI 博客
1. 为什么需要 Loop？——从"一问一答"到"自主迭代"
想象你请一位实习生帮忙：你不会只说一句"把网站做好"就离开，而是会让他先理解需求、动手尝试、检查结果、修正问题，直到你满意为止。Claude 的 Loop（循环） 机制，本质上就是给 AI 装上了这种"自我修正"的能力。
在传统的 AI 对话中，你问一句，AI 答一句，任务结束。但如果任务复杂——比如"优化网站性能到 Lighthouse 90 分以上"——单次回答往往不够。AI 可能写错了代码、漏掉了测试、或者误解了需求。Loop 的核心思想是：让 AI 像人类工程师一样，反复执行、检查、修正，直到达标。
核心概念：Agentic Loop（智能体循环）
Loop 不是简单的重复，而是一个结构化的工作流：
你的指令 → 收集上下文 → 执行操作 → 验证结果 → 达标？→ 输出 / 继续循环
这个循环让 Claude 从"答题器"变成了"能干活儿的助手"。
2. Turn-based Loop：最基础的"手动驾驶"模式
2.1 通俗理解
这是 Claude 默认的工作方式。你发一条消息，Claude 开始工作：它先读懂你的代码库（Gather context），然后动手修改（Take action），接着自己检查一遍（Verify the work），最后把结果给你。如果它觉得还没做好，会自动继续循环。
类比：就像你站在厨师旁边，他每做一步菜都会给你尝一口，问"咸淡合适吗？"，根据你的反馈调整。
2.2 技术原理
Turn-based Loop 的触发和终止条件：
| 属性 | 说明 |
|---|---|
| 触发条件 | 用户发送一条 prompt |
| 停止条件 | Claude 判断任务已完成，或需要额外信息 |
| 适用场景 | 短任务、探索性工作、非定期流程 |
| 控制方式 | 通过精确的 prompt 和 Skill 文件优化验证步骤 |
2.3 代码示例：验证前端改动
Claude 官方推荐用 Skill 文件（SKILL.md）来标准化验证流程。以下是一个前端验证 Skill 的示例：
---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone.
Verify it the way a human reviewer would:
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input, toggle):
click it, confirm the expected state change, and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.
If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.
技术解读：这个 Skill 文件定义了一个"验证协议"，Claude 在每次修改后会自动执行这些步骤。它利用了 MCP（Model Context Protocol） 与浏览器工具交互，实现真正的端到端验证。
3. Goal-based Loop (/goal)：给 AI 设定"终点线"
3.1 通俗理解
Turn-based Loop 的问题是：Claude 自己决定什么时候停，可能停得太早。Goal-based Loop 就像给运动员设定了终点线——"跑到 100 米就停"，而不是让他自己觉得"差不多够了"。
你通过 /goal 命令明确告诉 Claude：做到什么标准、最多试几次。
3.2 技术原理
/goal [目标条件], stop after [最大轮数]
工作流程：
Claude 工作 → Evaluator Model（评估模型）检查条件
→ 达标？→ 结束 / 未达标 → 继续工作（最多 N 轮）
关键设计：引入了一个独立的 Evaluator Model（评估模型） 来判断是否达标。这避免了"自己给自己打分"的偏见问题。
3.3 代码示例：性能优化目标
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
技术解读：
- 确定性指标：Lighthouse score ≥ 90 是一个可量化的硬指标，评估模型可以客观判断
- 轮次上限：
stop after 5 tries防止无限循环，控制成本 - Evaluator 机制：每次 Claude 尝试停止时，评估模型会检查 Lighthouse 报告，未达标则打回重做
为什么确定性指标很重要？
因为 AI 对"好"的主观判断可能和人不同。"代码看起来不错"是主观的，"测试通过率 100%"是客观的。Goal-based Loop 的效率高度依赖于指标的可量化性。
4. Time-based Loop (/loop & /schedule)：让 AI "定时上班"
4.1 通俗理解
有些工作是周期性的：每天早上汇总 Slack 消息、每小时检查一次 PR 状态、每周清理一次日志。Time-based Loop 就是给 Claude 排班，让它按时间表自动执行。
/loop：在本地运行，电脑关机就停止（像临时工）/schedule：在云端运行，电脑关着也能干活（像正式员工）
4.2 技术原理与代码示例
/loop 5m check my PR, address review comments, and fix failing CI
参数解析：
5m：轮询间隔，每 5 分钟检查一次- 后续 prompt：每次触发时执行的任务
适用场景对比：
| 命令 | 运行位置 | 持久性 | 适用场景 |
|---|---|---|---|
/loop |
本地机器 | 临时，关机即停 | 开发调试、短期监控 |
/schedule |
云端 | 持久，24/7 运行 | 定期报告、长期运维 |
5. Proactive Loop：多智能体协作的"自动化工厂"
5.1 通俗理解
这是最高级的 Loop 形态。想象一个工厂流水线：
- 调度员（/schedule）每小时检查仓库（Slack/GitHub）有没有新订单
- 主工人（Main Agent）接到订单后，反复尝试修复，直到质检通过
- 质检员（Second Agent）独立审查主工人的成果，确保没有偷工减料
- 通知系统把完成的报告送给老板（你）审批
整个流程不需要你实时盯着，AI 们自己分工协作。
5.2 技术架构
┌─────────────────────────────────────────────────────────────┐
│ RUNS IN THE CLOUD │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ TRIGGER │───→│ GOAL + │───→│ REVIEW │───→ You │
│ │ /schedule│ │ Main │ │ Second │ decide │
│ │ watches │ │ Agent │ │ Agent │ what to │
│ │ Slack/Git│ │ loops │ │ reviews │ merge │
│ │ for bugs │ │ until │ │ notifies │ │
│ │ │ │ skill │ │ you │ │
│ │ │ │ passes │ │ │ │
│ └──────────┘ └────┬─────┘ └──────────┘ │
│ │ │
│ ↓ Opens a PR │
└─────────────────────────────────────────────────────────────┘
5.3 完整代码示例：自动化 Bug 处理流水线
/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged, actioned, and responded to.
When fixing a bug, use a workflow to explore three solutions in parallel worktrees
and have a judge adversarially review them.
技术组件拆解：
| 组件 | 作用 | 技术细节 |
|---|---|---|
/schedule |
定时触发 | 每小时轮询，云端持久运行 |
/goal |
定义完成标准 | "所有报告都被分类、处理、回复" |
| Dynamic Workflows | 并行探索 | 在三个独立 worktree 中并行尝试三种修复方案 |
| Judge Agent | 对抗性审查 | 独立智能体审查三种方案，选择最优 |
| Auto Mode | 免打扰运行 | 不需要每步都征求用户许可 |
并行工作树（Worktree）原理：
# 技术背景：Git worktree 允许在同一个仓库中创建多个独立工作目录
git worktree add ../solution-A main
git worktree add ../solution-B main
git worktree add ../solution-C main
# 三个 Agent 分别在三个目录中独立开发
# Judge Agent 对比三个结果，选择最佳方案合并回主分支
6. 工程实践：如何设计高质量的 Loop
6.1 代码质量保障体系
Loop 的输出质量取决于你构建的"系统"，而不是单次 prompt 的魔法：
1. 保持代码库整洁
Claude 会模仿你代码库中已有的模式和规范。
如果代码库本身混乱，AI 只会学得更快、乱得更专业。
2. 给 Claude 自验证的能力（Skills）
---
name: run-test-suite
description: Always run tests before marking work complete
---
Before declaring any task done:
1. Run `npm test` — all tests must pass
2. Run `npm run lint` — zero new warnings
3. Run `npm run typecheck` — zero TypeScript errors
4. If any step fails, fix and rerun from step 1
3. 文档可及性 确保框架和库的最新文档在上下文中可达，Claude 会遵循最佳实践。
4. 引入第二智能体审查
/code-review
内置的代码审查 Skill 或 GitHub Code Review 集成，让独立 Agent 做审查，避免主 Agent 的确认偏误。
6.2 Token 成本管理
Loop 的自动化是有代价的（Token = 钱）。以下是成本控制策略：
| 策略 | 具体做法 | 技术原理 |
|---|---|---|
| 选对原语 | 小任务不用 Loop，直接用单次对话 | 减少不必要的轮次开销 |
| 选对模型 | 简单任务用轻量模型，复杂判断用强模型 | 成本与能力匹配 |
| 明确停止条件 | 精确的 /goal 减少无效迭代 |
避免过度尝试 |
| 先试点再推广 | Dynamic Workflows 可能生成数百个 Agent，先小范围测试 | 控制规模风险 |
| 脚本化确定性工作 | 用脚本替代推理，如 PDF 处理 | 执行成本远低于推理成本 |
| 合理设置轮询间隔 | 不要比被监控对象的变化频率更频繁 | 避免空转 |
监控命令：
/usage # 查看各 Skill、Subagent、MCP 的 Token 消耗
/goal # 查看当前轮次和 Token 使用
/workflows # 查看每个 Agent 的 Token 消耗，可随时停止
7. 总结：Loop 选择决策树
你的任务是什么？
│
├─ 探索性/决策性工作 → Turn-based Loop（手动验证）
│
├─ 有明确达标条件的任务 → Goal-based Loop (/goal)
│ └─ 需要反复尝试优化 → 设定量化指标 + 轮次上限
│
├─ 周期性/外部系统交互 → Time-based Loop (/loop, /schedule)
│ └─ 需要 24/7 运行 → /schedule（云端）
│ └─ 临时本地监控 → /loop（本地）
│
└─ 复杂、重复、多步骤流水线 → Proactive Loop
└─ 组合：/schedule + /goal + Skills + Dynamic Workflows + Auto Mode
快速参考表
| Loop 类型 | 你移交的控制权 | 适用场景 | 关键工具 |
|---|---|---|---|
| Turn-based | 验证检查 | 探索、决策 | 自定义验证 Skills |
| Goal-based | 停止条件 | 知道"完成"长什么样 | /goal |
| Time-based | 触发时机 | 外部系统、定时任务 | /loop, /schedule |
| Proactive | 整个 Prompt | 重复性、定义明确的工作流 | 全部工具 + Dynamic Workflows |
8. 给初学者的建议：从"人"到"系统"
开始使用 Loop 的最佳方式是观察自己的工作：
- 找出瓶颈：哪项任务你是最慢的一环？
- 能否验证：你能写出检查标准吗？（"测试通过"、"Lighthouse 分数"、"无报错"）
- 目标清晰吗："完成"的定义具体、可量化吗？
- 定时触发吗：这项工作有固定的时间规律吗？
运行 → 观察 → 迭代：
- 第一次运行 Loop 时，仔细观察它在哪里卡住、哪里过度发挥
- 把观察到的问题编码成新的 Skill 规则
- 不要害怕调整，Loop 本身也需要迭代优化
最终目标：不是让 AI 替代你思考，而是让 AI 承担"执行-验证-修正"的循环，你把精力集中在定义问题和判断价值上。
延伸阅读：Claude Code 官方文档中的 Running agents in parallel、Loop、Schedule、Goal 和 Dynamic Workflows 页面。