并行代理工作流与控制粒度

作者通常同时运行 5到10个 AI代理以并行处理任务，这种工作流的核心在于根据任务的确定性程度分配控制权。对于边界清晰的任务，只要明确 停止条件 和约束范围，作者乐于完全委托给代理；而对于需要代码审查或更紧密监控的任务，则保留人工介入。这种分层策略建立在“循环工程”（Loop Engineering）的基础之上，即让AI代理在 自主、自我纠正的反馈循环 中反复行动、测试并调整，直到达成特定目标。目前主流工具如Claude Code提供了两种核心原语：一种是驱动单一有界任务直到达成可测量终点的 目标（Goal）原语，另一种是基于定时器或固定间隔运行的 循环重跑（Loop Reruns）原语，用于调度周期性变更。

从手工脚本到内置原语的演进

在Claude Code和Codex将循环功能内建之前，开发者主要依赖手写的 Bash脚本 或如Geoff Huntley提出的“Ralph循环”等实验性方案。这些早期实践多局限于个人项目，因为即使遇到死胡同或错误，其 试错成本 相对较低。随着循环工程模式的成熟和内置原语的普及，开发者现在能更清晰地掌握如何“ babysit”（监护）这些自动化流程。虽然可以更多地依赖内置原语的输出，但作者强调必须保持 高度警惕：如果未明确定义最终目标或约束条件，让循环无人看管地运行在复杂的遗留代码库（如银行系统）中会导致严重问题。相比之下，在无用户且历史复杂度较低的 常青代码库 中使用循环则更为安全。

Claude Code团队定义的四种循环模式

Claude Code官方将循环定义为代理重复工作直到满足停止条件的过程，并根据触发方式、停止条件和适用任务进行了分类。首先是 代理循环（Agentic Loop），即每次发送提示时由人工主导的迭代：AI收集上下文、执行操作并自检，随后等待人工检查并输入下一条指令。其次是 基于目标的循环（Goal-based Loops），适用于复杂任务，通过 /goal 命令定义成功标准（如“Lighthouse评分达到90以上”），AI会在每次尝试停止时由评估模型检查条件，直到目标达成或达到最大重试次数（如 5次）。这种确定性标准比主观判断更有效。第三是 基于时间的循环（Time-based Loops），通过 /loop 命令在指定间隔（如 5分钟）重跑提示，适用于处理外部系统状态变化或定期任务；若需云端运行则使用 /schedule。最后是 主动循环（Proactive Loops），由事件或调度触发且无需人工实时参与，适用于 bug 报告、问题分类等重复性工作流。

自动化验证与具体应用场景

为确保代码质量，官方建议将手动检查转化为AI自我执行的 端到端验证流程。例如，在验证前端更改时，不应仅凭编辑成功就宣布完成，而应模拟人类审查者：启动开发服务器并在浏览器中直接交互（如点击按钮并截图对比状态），检查 零错误/警告 的控制台输出，并使用Chrome Devtools MCP运行性能追踪和核心Web指标审计。若任何步骤失败，AI需自行修复并重新从第一步开始验证，绝不交付部分完成的工作。在实际应用中，作者利用 /goal 原语处理具体任务，如确保页面加载时间控制在 5秒 内，或尝试将页面速度提升 50%。此外，该原语也用于半开放式的GitHub Issue管理任务，如审查并关闭或推进最近的 10个 问题。这些实践表明，明确的目标定义和自动化的验证步骤是循环工程落地的关键。

Loop作为调度器的核心定位与适用场景

Loop在架构中扮演着类似Cron的任务调度器角色。它的核心机制是监控特定状态或按照既定节奏重复执行某种模式，因此最适合用于轮询日志、监测外部系统状态或定期检查任务。当开发者发现自己在固定频率下需要执行重复性操作时，Loop是理想的选择。这种自动化机制能够显著降低人工介入的频率，让开发者从机械性的监控工作中解放出来。

代理委托的分级策略与风险控制

作者日常使用5到10个AI Agent，通常并发不超过五个。在任务委托上采取分级策略：对于实现既定功能后编写文档、检查测试覆盖率等低风险任务，可以较大程度地放手；但对于涉及复杂逻辑或安全敏感领域（如认证、金融模块）的任务，即使提供了详尽的规范，仍存在偏差风险，因此必须密切监控。作者强调，随着对AI信任度的提升，人们会更倾向于委托任务，但前提是必须拥有清晰的验证机制和停止条件。人类开发者不能因为信任算法而放弃对生成代码的最终审查。

独立验证机制与“品味”保留原则

一个关键的工作习惯是禁止执行任务的Agent自行判定工作完成。必须引入独立的验证代理（Verifier）来审查成果。因为执行者往往对特定维度过于自信，而忽略其他关键指标（例如仅关注桌面端性能却忽视移动端体验）。作者分享了一个深刻教训：他曾委托Agent分析竞品并生成PR，虽阅读了研究报告却未仔细审查代码实现。结果发现这些改动增加了用户复杂性但收益有限。这让他意识到，开发者不能将“品味”和最终判断力也委托给AI。Goal中的Evaluator仅检查是否满足硬性规则（如Lighthouse分数），并不评估代码质量或用户体验，因此人工复核不可或缺。Goal指令示例展示了严格的停止条件：

/goal Refactor the data-fetching layer in Dashboard.tsx until Lighthouse performance score is >= 92 and LCP is under 1.8s as shown by the Lighthouse CLI output. Do not change the public API of any hooks. Each turn must improve at least one reported metric; abort if two consecutive turns show no improvement. Stop after 10 turns.

Loop与Goal的组合工作流实践

在日常工作中，Loop和Goal可以组合使用以实现自动化闭环。例如，作者维护着拥有80,000+ Star的开源项目Agent Skills，过去每天需处理近90个PR。现在利用Loop每12或24小时自动检查GitHub仓库，生成新Issue的紧急程度摘要：

/loop every 1h "Check the GitHub repository for any new open issues. Provide a bulleted summary of their urgency."

更进一步，可以将Loop与Goal结合：Loop负责每24小时检查标记为“bug”的Issue，一旦发现则触发Goal自动修复直至本地测试通过并推送分支。这种组合极大地提升了维护效率，使开发者能够持续接受PR和Issue的同时保持对项目的掌控。未来趋势如动态工作流（Dynamic Workflows）将进一步整合调度、目标定义和并行验证，实现更复杂的自动化闭环。

The primitives above, along with other Claude Code features like auto mode and dynamic workflows (research preview) can be composed into a loop for long-running work. For example, to handle incoming feedback, you can use: /schedule (research preview) to run a routine that checks for new reports, /goal to define what done looks like, and skills to document how to verify it. Dynamic workflows to orchestrate agents that triage each report, fix it, and review the fix.

通过这种系统化的分工，作者实现了高效的PR分类与交叉引用管理。当进行大规模重构时，能确保相关Issue被正确关闭且不干扰其他工作流，从而在保持高吞吐量的同时维持代码质量与项目秩序。

利用定时任务自动化处理非核心贡献

循环工程（Loop Engineering）在定期审查新拉取请求（PRs）并关闭明显不符合规范的内容时极具价值。一个典型的停止条件案例涉及贡献指南中的特定条款，例如“目前不接受翻译”。这并非因为团队不重视多语言支持，而是由于维护成本过高且缺乏相应语言能力。通过设定自动化规则，让循环任务自动关闭触及该指南条款的 Issue 或 PRs，能显著减少人工审查的总体批次规模。这种基于明确规则的自动化筛选，使得团队能够将精力集中在真正需要人类判断的核心代码逻辑上。

明确目标与主观创作的不兼容性

循环工程并非万能，其核心局限在于对“完成状态”定义的清晰度要求。如果用户无法明确界定什么是“好”或“已完成”，该模式便不适用。例如，模糊的目标如“继续直到 UI 设计变好”缺乏可量化的评估标准。文中指出，涉及人类审美、主观设计决策或开放式创意探索的任务不适合循环工程。只有当目标具有明确的验收标准时，自动化循环才能有效运作。这一界限强调了在引入自动化工具前，必须先将模糊的创意需求转化为可执行、可验证的具体指令。

结论

循环工程通过内置原语将AI代理从被动执行者转化为具备自我纠正能力的自动化工作流，显著提升了代码维护与验证效率。其核心优势在于利用明确定义的停止条件和独立验证机制，在低风险任务（如文档编写、Issue分类）中实现高度自动化，从而释放开发者精力。然而，该模式严格依赖可量化的验收标准，无法处理涉及主观审美或创意探索的模糊需求。此外，尽管能提升吞吐量，但AI仍无法替代人类对代码质量、用户体验及复杂逻辑的最终判断。因此，循环工程并非万能解药，而是需与人工监护紧密结合的工具：仅在边界清晰、目标明确且具备严格验证流程的场景下，才能安全有效地发挥其调度与执行价值。