Loop Engineering入门系列03：AI Agent自动化的5种Loop模式和决策表

上一篇拆了 Loop 的六块积木：Automations、Worktrees、Skills、MCP、Maker/Checker、Memory。 这一篇只解决一个更实际的问题：不同任务，到底该用哪种 Loop 模式？

选错模式，比不用 Loop 更浪费时间

很多人一开始做 AI Agent 自动化，最容易犯的错，是把所有任务都塞进同一种 Loop。

修一个 静态代码lint 错误，用一套复杂的长期工作流，太重。

排查一个线上偶发故障，只让 Agent 原地重试，太窄。

涉及支付、权限、生产发布，还想全自动跑到底，风险太高。

这篇文章给你一个直接可用的判断框架：

• 短任务怎么用最轻的 Retry Loop
• 多步骤任务什么时候要先规划再执行
• 原因未知的问题怎么探索和收窄
• 哪些节点必须让人介入
• 什么项目才值得升级成 Lifecycle Loop

你读完至少应该拿走两样东西：5 种 Loop 模式的适用边界，以及一张能直接对照使用的决策表。

上一篇我们拆了 Loop 的六块积木。这一篇解决下一个问题：积木齐了，具体任务到底怎么搭。

五种 Loop 模式总览图

这张图把 AI Agent 自动化常见的 5 种 Loop 模式放在一起：目标明确用 Retry，多步骤任务用 Plan-Execute-Verify，方案未知用 Explore-Narrow，高风险决策用 Human-in-the-Loop，长期项目再上 Lifecycle Loop。

5 种模式，对应 5 类任务

1. 目标明确：用 Retry Loop

最简单的 Loop。逻辑直白：

让 Agent 执行 → 检查 pass/fail → 失败则重试 → 通过则停止。

适用场景：

• 短、原子任务，有清晰的 pass/fail 标准
• 写一个通过指定测试的函数
• 修复 lint 错误
• 跑通一个已知的接口调用

示例提示词：

请写一个用于校验邮箱地址的函数。
写完后运行测试。
如果测试失败，请修复问题并重新运行，最多重试 3 次。

风险：

Retry Loop 最大的风险是——无限重试不改变策略。

如果 Agent 每次用同样的思路重试，结果大概率是一样的。你需要在提示词里加入"变化逻辑"的指令：

如果同一个测试连续失败 2 次，请换一种实现思路。
不要重复提交同一种修复方案。

一句话总结：

目标明确 + 验证标准清晰 → Retry Loop。

2. 步骤复杂：用 Plan-Execute-Verify

比 Retry Loop 多了一个前置步骤：先规划，再动手。

逻辑链路：

规划方案 → 执行 → 验证结果 → 如果验证失败，修订计划，重新执行。

适用场景：

• 多步骤任务，步骤之间有顺序依赖
• 重构一个模块（先理解结构 → 制定迁移方案 → 逐步替换 → 跑测试验证）
• 搭建新服务（先确定架构 → 逐层实现 → 集成测试）
• 数据库迁移（先分析影响面 → 写迁移脚本 → 验证数据一致性）

示例提示词：

请把认证模块从 session cookie 改成 JWT。
先阅读相关代码，列出需要修改的文件和修改顺序。
确认计划后，再按步骤执行。
每完成一步，都运行相关测试。
如果测试失败，先修订计划，再继续下一步。

风险：

对错误的计划过度承诺。

如果 Agent 一开始规划的方向就错了，后面的执行和验证只会在这个错误方向上越走越远。

解法：给计划阶段加约束。比如"先读这个文件，确认我的理解是对的，再出计划"。

一句话总结：

步骤多 + 顺序重要 + 早期错误会级联 → Plan-Execute-Verify。

3. 原因未知：用 Explore-Narrow

当你不知道正确答案是什么的时候用的模式。

逻辑链路：

并行探索多条路径 → 根据反馈剪掉失败路径 → 收窄到最有希望的路线 → 深入执行。

适用场景：

• 调试一个原因不明的错误（可能是数据库、可能是网络、可能是权限——先并行排查）
• 探索一个不熟悉的 API，不确定哪种调用方式最有效
• 性能优化，不确定瓶颈在哪里
• 技术选型，需要在几个方案之间做对比

示例提示词：

这个 API 偶尔返回 500 错误。
请并行排查 3 个可能原因：
1. 数据库连接池是否耗尽
2. 上游服务是否触发限流
3. 请求处理逻辑是否存在内存泄漏
每条路径都要查看对应日志和指标，并汇总发现。
最后根据证据判断最可能的原因，再集中深入排查。

风险：

上下文爆炸。

并行探索意味着同时维护多条线索，每条线索都要消耗上下文窗口。如果不及时剪枝，很快就会接近上限。

解法：尽早设置"停止规则"——某条路径如果前两步没发现线索，就放弃，转向下一条。

一句话总结：

方案未知 + 需要探索 → Explore-Narrow。

4. 影响很大：用 Human-in-the-Loop

它保留人工确认。Agent 在关键决策点停下来，等人确认，再继续。

逻辑链路：

Agent 执行 → 遇到高代价决策 → 停下来等人 → 人确认后 → Agent 继续。

适用场景：

• 需求无法完全提前指定（比如"你觉得这个 UI 怎么样？"）
• 生产环境变更，需要人工 review 再发布
• 涉及用户数据、计费、权限的修改
• 方向性选择（方案 A 激进、方案 B 保守，让 Agent 列出利弊，人来拍板）

示例提示词：

请重构支付处理模块。
凡是涉及扣款链路的修改，先展示拟修改的 diff，等待我确认后再执行。
日志、注释、测试这类低风险修改，可以自动处理。

风险：

打断过频。

如果 Agent 每走一步都问一次，你省下的时间可能还没有花在"审批"上的时间多。

解法：明确"哪些需要审批，哪些不需要"。把审批粒度控制在"影响面"层面，而不是"每个文件变更"层面。

一句话总结：

高代价决策 + 需求无法完全指定 → Human-in-the-Loop。

5. 长期项目：用 Lifecycle Loop

这是最完整、也最重的一套模式。你可以把它拆成三个阶段：

这里的 P/I/V 只是为了方便记忆：先规划，再迭代，最后验证和沉淀。

P — Planning（规划）

架构师角色。把产品需求分解为可执行的 sprint contract。

I — Iteration（迭代循环）

工程师角色。自主编程、测试、修复的循环。可以用 Retry、Plan-Execute-Verify 等作为子模式。

V — Verification & Evolution（验证与进化）

质量保障 + 系统进化。对照规格独立验证产出，并把经验沉淀回 Skill。

适用场景：

• 长期项目，需要持续迭代
• 从 0 到 1 构建一个功能或服务
• 需要积累项目知识的场景（Skill 会越用越厚）

结构示意：

Planning → Sprint Contract
    ↓
Iteration Loop (Retry / Plan-Execute-Verify / Explore-Narrow)
    ↓
Verification (Checker / Evaluator)
    ↓
Evolution (更新 Skill, 沉淀经验)
    ↓
回到 Planning，开始下一个 Sprint

风险：

太重。

小任务不要上 Lifecycle Loop。修一个 typo 用全生命周期循环，就像用起重机拧螺丝。

解法：把 Lifecycle Loop 留给"值得"的项目。小任务用 Retry 或 Plan-Execute-Verify 就够了。

一句话总结：

长期项目 + 持续改进 + 知识沉淀 → Lifecycle Loop。

一张表，快速选对模式

别凭感觉选。对照这张表：

Loop 模式决策流程图

这张图把 Loop 模式选择逻辑串起来：先判断任务目标是否明确，再看能否验证、是否多步骤、是否需要探索，最后再决定要不要升级到长期项目用的 Lifecycle Loop。

额外记住一条就够了：如果只是一次性任务，用轻量模式；如果是长期项目，才值得上 Lifecycle Loop，把规划、迭代、验证和沉淀连起来。

复杂项目，要把模式组合起来

实际工作中，你不会只用一种模式。更多时候是嵌套使用。

Loop 模式组合与嵌套图

这张图说明了复杂项目里的组合关系：Lifecycle Loop 管整体节奏，Iteration 阶段内部可以按任务特点嵌套 Retry、Plan-Execute-Verify 或 Explore-Narrow。

比如一个典型的 Lifecycle 工作流：

Planning 阶段 → 产出 Sprint Contract
    ↓
Iteration 阶段 → 子任务 A 用 Retry Loop
              → 子任务 B 用 Plan-Execute-Verify
              → 子任务 C 用 Explore-Narrow
    ↓
Verification 阶段 → Checker 对照测试验证（可以按 Retry Loop 执行）
    ↓
Evolution 阶段 → 把经验写入 Skill

再比如 Plan-Execute-Verify 内部：

Plan → 需要探索多个方案 → 内嵌 Explore-Narrow
Execute → 每步需要验证 → 内嵌 Retry Loop
Verify → 发现方向错了 → 回到 Plan 修订

Loop Engineering 的关键能力，是知道什么时候组合、什么时候升级。

第一次搭 Loop，从最小闭环开始

如果你是第一次搭 Loop，从 Retry Loop 开始。

找一个有测试的项目，让 Agent 修一个已知 bug，跑测试，失败了重试。

跑通一次之后，你会自然理解：

• 什么叫"好的 pass/fail 标准"
• 为什么"无限重试不改变策略"是坑
• 什么时候该升级到 Plan-Execute-Verify

别一上来就搞 Lifecycle Loop。那就像还没学会骑自行车就去考飞行执照。

先把最简单的 Loop 跑通。然后一步步往上加复杂度。

Loop Engineering 要靠跑通一个真实闭环来理解。

📌 下一篇预告

《Agent 不能自己评判自己：Planner / Generator / Evaluator 三角色架构》

这篇讲了 5 种模式怎么选。但有一个核心问题还没解决：

Agent 写出来的东西，谁来审？

把生成和评估放在同一个角色里，最容易出现的问题是：写代码的人顺手给自己打高分。

下一篇拆解一套更稳的三角色架构：

• Planner（规划器）→ 把目标拆成可执行任务
• Generator（生成器）→ 按任务生成方案、代码或内容
• Evaluator（评估器）→ 独立验证 Generator 的产出

为什么 Evaluator 必须和 Generator 分离？怎么写一个"够狠"的评估标准？这套架构如何从前端设计迁移到全栈开发？

有了这套分工，Loop 才有可验证、可纠错、可交付的闭环。

系列预告 第 4 篇：《Agent 不能自己评判自己：三角色架构让 Loop 真正闭环》 拆解 Planner、Generator、Evaluator，解决谁来规划、谁来生成、谁来验收的问题。 第 5 篇：《从零搭建你的第一个 Loop：CI 自动修复实战》 把前面的积木、模式和三角色架构合起来，搭一个可复制的 CI 自动修复 Loop。