七种 AI 编程智能体循环及其适用场景

循环让 AI 编程智能体围绕指定目标反复工作。我认为循环很有用，因为智能体可以持续迭代，而不需要人每一步都手动提示。这种自主性并不意味着结果自动正确，也不意味着工作不需要监督。

我把循环分为两部分：触发条件和目标。触发可以是人手动启动、定时运行，或打开拉取请求等事件。周期性触发适合维护工作；只有在需要时才开始的工作则适合手动触发。

目标可以用具体条件检查，也可以由语言模型判断。例如，覆盖率可以用数字衡量，而“重构直到满意”则让模型评估主观结果。即使覆盖率这样的指标可以量化，它本身也不能证明测试有意义。

我整理了一个免费的 Loop Library，方便大家复制或改写提示词。下面的例子展示不同的触发条件和停止条件；它们只是起点，需要根据项目及其约束调整。

第一个是页面加载优化循环。每次重大修改后，智能体在相同且可重复的条件下测量每个目标页面，持续优化，直到每个页面都低于 50 毫秒。明确测量方式和测试条件至关重要：一个环境中的结果不能证明所有用户都有同样的体验。

这个循环可以手动启动、定时运行或由拉取请求触发。我演示将提示词复制到 Codex 并设为目标。智能体可能工作几分钟或几小时，因此 token 预算有限的用户需要关注用量并设定适当边界。

我展示了一次围绕生产环境性能目标运行近 50 分钟的任务。可见的智能体输出指出了网络延迟下限和数据库往返耗时，并称在所述条件下真正的冷加载无法达到 50 毫秒。这个片段展示的是一次调查，不能独立证明所有生产页面都达到了目标。

夜间文档巡检要求智能体每晚审查代码库、更新文档以反映最近的修改，并创建拉取请求。目标是让实现与文档保持一致，同时产出可供人审查的修改。

这部分属于用大语言模型作评判者的任务：即使某些覆盖检查可以自动化，判断文档是否完整仍需要判断。我演示用复制的提示词创建周期性 Codex 自动化。定时审查是一种工作流提议，不能证明每份文档都会始终正确。

Peter Steinberger 的架构满意度循环要求智能体持续重构，直到它对架构满意。提示词增加了一些结构：每个重大步骤之后，在实际运行的系统上测试、运行自动审查、提交一个检查点，并在 Markdown 文件中跟踪进度。

由于满意度具有主观性，我建议提供额外指导，例如优先选择简单方案或减少重复。智能体的判断仍可能与团队的架构目标不同，因此测试、审查和记录的检查点都很重要。

日志覆盖循环审查系统并补充缺失日志，直到重要路径都能产生有用且经过测试的事件。“重要”使停止条件部分具有主观性：智能体必须决定哪些路径重要。这个循环也为后续使用这些日志的工作流做好准备。

生产错误巡检按计划运行，检查生产日志。发现可处理的问题时，提示词要求智能体追踪原因、修复并验证，然后创建拉取请求，再通过 Slack 报告发现和链接。如果没有可处理的错误，它也会报告这一结果。

SEO/GEO 可见性循环审计可抓取性、索引情况、页面意图、标题、内部链接、结构化数据、引用和先回答问题的内容。它对缺口排序，修复影响最大的一个，再以相同方式重新抓取和测试，持续重复，直到解决指定的关键缺口。

完整产品评估循环首先针对主要能力创建真实场景。测试之前，它定义成功标准和一致的方法，例如通过／失败检查或评分标准。它在相同条件下运行场景，并记录每个结果的证据。

对于失败的结果，智能体调查根因、修改，再重跑受影响的场景，之后重跑完整场景集。我认为这不只是传统的确定性测试套件，因为部分质量判断可以由模型完成。

我说这个循环可能需要 12 小时甚至更久，并举了一个必须提供准确且有来源的回答的问答产品例子。智能体可以创建广泛的测试问题、评判结果并迭代，但它的判断和所选场景仍需要审视。

有两个主要注意事项。首先，设计有用的停止条件很难，循环并不适合所有问题。具体、可验证的目标比让模型自行判断工作是否足够好的主观目标更容易评估。

功能开发尤其难以完全开放地交给循环。要求智能体构建完整的权限系统，却不说明期望行为，会给它太多自由来决定什么重要以及何时停止。我不倾向于从零开始对一个未明确规定的功能使用这种循环。

我曾要求一个智能体克隆 Excel，达到功能对等。它使用电脑控制功能检查 Excel，但任务运行了好几天，最后我把它停了。我不推荐这种做法：过于宽泛的目标可能让工作持续产生，却没有实际可行的终点。

其次，循环可能很昂贵。智能体工作时会消耗 token，一次运行可能持续几分钟、几小时或几天。在让自主循环持续运行之前，要考虑预算和任务价值。