Loop Engineering: Getting Started with Loops（循环工程：从循环入门）
📄 来自 Claude 官方博客
- 原文标题
- Loop Engineering: Getting Started with Loops（循环工程：从循环入门）
- 原文链接
- https://claude.com/blog/getting-started-with-loops
- 作者
- Delba de Oliveira、Michael Segner（Claude Code 团队）
- 发布日期
- 2026-06-30
⚠️ 本页是原文的中文结构化整理笔记（保留架构、数据、案例、结论），并非逐字翻译。具体参数与功能名更新很快，落地前请点击上方链接核对原文。
🎯 一句话
循环工程的关键不在于「让它循环」，而在于给循环一个可靠的退出条件和一个客观的进度信号。⭐ 没有客观信号的循环，只会让模型在自我感觉良好中原地打转。
从传统的「写提示词」转向循环工程（loop engineering）——把 Agent 工作组织成有明确停止条件的重复周期。不同类型的循环服务于不同目的，理解何时用哪种，能同时优化代码质量和 token 效率。
四类循环
| 类型 | 如何启动 | 何时终止 | 适合什么 |
|---|---|---|---|
| 回合制循环（Turn-based） | 用户手动输入 | Claude 认为工作完成时 | 短期探索性任务 |
目标制循环（/goal） |
实时手动触发 | 达成目标或超过最大回合数 | 有可衡量成功标准的任务 |
时间制循环（/loop、/schedule） |
按指定间隔 | 用户取消或任务完成 | 重复性工作或监控外部系统 |
| 主动循环（Proactive） | 事件或计划触发，无需人工介入 | 单个任务目标达成；例程本身长期存在 | 定义明确的重复工作流（bug 分诊、依赖升级） |
目标制循环示例： 「把首页的 Lighthouse 分数提到 90 以上，试 5 次后停止」
时间制循环示例： 每 5 分钟检查一次 PR 的审查评论
主动循环架构： 组合 /schedule + /goal + skills + 动态工作流 + auto mode。例如处理用户反馈的完整主动循环——每小时检查一次、定义完成标准、通过工作流并行探索方案、对抗式审查，全程自动执行无需逐步批准。
回合制循环的关键技巧： 把验证检查编码为 skills，能减少不必要的迭代（详见 验证循环）。
保证质量的最佳实践
- 保持既有代码库整洁——为 Claude 建立可遵循的模式
- 通过 skills 建立验证机制，让 Agent 自我评估工作
- 维护反映当前最佳实践的可访问文档
- 用第二个 Agent 做代码审查以减少自我偏袒
控制 token 消耗
- 循环原语和模型要匹配任务复杂度
- 建立明确的成功与停止标准
- 动态工作流先在小数据集上试点再放大
- 常规操作用确定性脚本而非基于推理的方式
- 监控频率要匹配实际变化速率（别每 5 分钟查一件每天才变一次的事）
- 用
/usage和/workflows命令监控消耗
核心要点
成功的关键是把正确的循环类型匹配到具体工作的特征上。团队应当从简单开始，识别瓶颈，逐步实施合适的自动化模式，同时保持对资源消耗和产出质量的监督。
✅ 检查点
- 循环工程里最关键的两个设计是什么？
- 为什么「让模型自己判断做完了没有」是不可靠的？
- 什么样的任务适合放进自动循环？
👀 答案
- ①可靠的退出条件 ②客观的进度信号。前者防止无限循环，后者让每一轮都能判断是否真的前进了。
- 因为模型对自己输出的评价是有系统性偏差的——它倾向于认为自己已经完成了。⭐ 可靠的信号必须来自模型之外：测试通过与否、编译是否成功、检查脚本的返回码、diff 是否为空。这些是环境给的事实，不是模型的自我评价。
- 三个特征：①有自动化的验证手段（测试、编译、lint）②单轮失败的代价低（可回滚）③进展可度量（通过的测试数、剩余的报错数）。⚠️ 反过来，没有客观验收标准的创造性任务不适合放进自动循环——它会在没有方向的情况下反复重写。
🛑 可以停在这里
⚡ 走神救援
⭐循环工程的关键不是「让它循环」，是给循环一个可靠的退出条件和客观的进度信号。⭐⭐「让模型自己判断做完了没」不可靠——模型对自己输出的评价有系统性偏差，倾向于认为已经完成；可靠信号必须来自模型之外：测试通过与否、编译成功与否、检查脚本返回码、diff 是否为空——这些是环境给的事实，不是自我评价。适合放进自动循环的任务三特征：有自动化验证手段、单轮失败代价低（可回滚）、进展可度量；⚠️没有客观验收标准的创造性任务不适合——它会没有方向地反复重写。