详解Claude Code循环工程：如何构建高效AI代理工作流

我通常并行运行五到十个 AI 代理。对于边界清晰的任务，我会完全委托给代理；而对于复杂任务，则需密切审查其代码。这一方法论的核心在于循环工程（Loop Engineering）。

循环是一个自主的、自我纠正的反馈周期：AI 代理反复执行操作、测试结果并调整方法，直至达成特定目标。目前主要存在两种核心原语：目标（Goal）驱动单个受限任务直至达到可测量的终点；循环（Loop）则基于定时器或固定间隔重新运行，适用于调度变更。

在 Claude Code 和 Codex 内置这些原语之前，循环工程依赖自定义 Bash 脚本。今年早些时候，包括我在内的许多开发者曾尝试 Geoff Huntley 提出的 Ralph 循环，主要在个人项目中实验，因其试错成本可控。

随着模式梳理，我们对监管循环有了更清晰的认识。虽然可以很大程度上依赖原语输出，但若未明确定义最终目标或约束，放任循环独自运行可能导致状态异常。因此，在常青代码库与复杂遗留系统（如银行系统）中，循环的适用性存在细微差别。

Claude Code 团队将循环定义为“代理重复工作周期直到满足停止条件”的过程，并分为以下类别：

代理循环（Agentic Loop）：最基础的手动循环。用户发送提示，Claude 收集上下文、行动、检查并响应，随后用户手动检查结果并编写下一个提示。
基于目标的循环（Goal-based）：通过 /goal 定义“完成”标准，延长迭代时间。评估模型会检查确定性标准（如测试通过率、Lighthouse 分数），直到目标达成或达到设定轮数。例如：/goal Get the homepage Lighthouse score to 90 or above, stop after 5 tries.
基于时间的循环（Time-based）：适用于重复性或依赖外部系统的任务。使用 /loop 触发间隔运行，如定期检查 PR 评论或 CI 状态。例如：/loop 5m check my PR, address review comments, and fix failing CI. 此类循环在本地运行，关闭电脑即停止；可通过 /schedule 移至云端。
主动循环（Proactive Loop）：最高层级，由事件或时间表触发，无人类实时参与。适用于错误报告、问题分类、依赖升级等定义明确的工作流。通过将例行程序路由至更小、更快的模型，并使用强大模型进行判断，实现受控使用。

Claude Code 团队建议将手动检查转化为自动验证过程。例如，前端变更不应仅凭编辑成功就宣告完成，而应启动开发服务器、交互测试、截图对比、检查控制台错误及性能审计。若任何步骤失败，需修复并重跑，严禁交付部分验证的工作。

在实际应用中，我将目标（Goal）用于具体任务，如“确保页面五秒内加载”或“审查并关闭最近 10 个 GitHub Issue”。循环（Loop）则更像 Cron 任务，用于轮询日志、监控状态或定期签到。

关于委托与监督，我每日并发运行最多五个代理。对于文档编写、测试覆盖率检查等安全任务，可完全委托；涉及系统权限、安全或金融敏感领域，则必须严格监控。核心原则是：不要让执行代理自行判定质量。应由一个子代理起草更改，另一个独立代理进行验证，以防单一维度上的盲目自信（如仅关注桌面端而忽略移动端）。

我曾因未仔细审查代理生成的竞争对手分析 PR 而险些引入不必要的复杂性。这提醒我们：可以委托任务，但不能委托品味和判断力。此外，Goal 背后的评估器仅检查硬性规则是否满足，并不审查内容本身的好坏。

可将循环与目标结合：使用循环安排检查，使用目标解决问题。例如：“每 24 小时检查标记为 bug 的 Issue，若存在，则使用 Goal 实施修复直至测试通过并推送分支。”

在我的开源项目 Agent Skills（超 8 万星标）管理中，这种组合极大提升了效率。通过设置定时任务自动摘要新 Issue 紧急程度，或依据贡献指南自动关闭不符合要求的 PR（如不接受翻译），显著减少了人工审查量。

需注意，循环工程不适合模糊目标或需主观创意的任务。判断循环空转的标志是同一命令反复执行且结果无变化。此外，重复循环在创建后七天内有效（基于会话范围），若需超越会话生命周期，应使用 /schedule 在云端运行。