一个 Loop 由哪些部分组成？

安逸Ai2026/7/16大约 22 分钟Loop EngineeringAgent

一个 Loop 由哪些部分组成？

一句话核心：Loop Engineering 通过六大核心模块（任务自动化、并行隔离、Skills、MCP、子Agent、记忆）构建自动化循环体系，让 AI 从被动工具升级为主动执行者，彻底解决复杂任务中人工瓶颈问题。

核心概念（术语表）

Loop Engineering（循环工程）：设定一个终极任务目标，让 AI 持续递归迭代、自主运转，直到任务彻底完成的工程化方法论。核心转变是人从循环主体退位，AI 成为循环主体。
任务自动化（Task Automation）：Loop 的核心引擎，系统按设定时间自动启动、自主检索待执行任务，全程无需人工手动触发。与传统需要人工逐条发送指令的模式本质区别在于「自动化程度」。
并行隔离（Parallel Isolation）：利用 Git 的 worktree 功能，为每个并行运行的 Agent 分配独立分支目录，避免多 Agent 同时修改同一文件引发并发冲突。关键价值是保障多 Agent 协同的稳定性。
Skills（技能模块）：适配各类任务的流程规范和执行标准，提前配置在专属文件中，大模型执行任务时有清晰的决策依据和执行准则。相当于给 AI 配备的「标准化操作手册」。
MCP（Model Context Protocol）：打通 Loop 与各类工具的连接通道协议，让 Agent 具备读取工单 issue、查询数据库、向通讯软件推送消息等能力。核心价值是扩展 Loop 的实际落地场景边界。
子 Agent（Sub-Agent）：将复杂任务拆解后分配给不同专业 Agent 分别执行。典型模式是编码 Agent 只负责编码，专属检查 Agent 负责代码审查，避免同一模型的思维惯性。
记忆（Memory）：将任务记忆整理为 markdown 文件持久化存储在本地硬盘，保障跨对话、跨任务重启时的状态连续性。Loop 稳定运行的关键保障机制。
Git worktree：Git 的工作树功能，允许在同一个仓库的不同目录中同时处理不同分支，实现文件级别的任务隔离。是并行隔离的技术基础。
Claude Code：Anthropic 推出的 AI 编程工具，其负责人 Boris Cherny 提出「写循环」替代「写提示词」的核心工作范式转变，是 Loop Engineering 概念的推动者。

阅读全文

Loop Engineering 概念诞生于 2025-2026 年 AI Agent 快速发展的背景下，由 Claude Code 负责人 Boris Cherny 首次系统提出。他公开表示日常工作已从「写提示词」转变为「搭循环」，核心工作变成构建各类循环驱动 AI 自主运行。这标志着 AI 编程领域从 Prompt Engineering（提示词工程）向 Loop Engineering（循环工程）的范式转移。

这一转变的根本原因是：大模型能力持续增强，单次对话运行时长可达数十分钟甚至数小时，AI 完全具备自主持续运行能力；而人工反复编写调整提示词变得性价比极低。行业核心思路因此转变为：与其耗费精力琢磨提示词怎么写更精准，不如直接搭建一套小型自动化系统。

工作原理 / 核心机制

整体思路

Loop Engineering 的核心思路是构建一套「设定目标 → AI 自主执行 → 结果校验 → 持续迭代」的自动化闭环，让 AI 成为循环的执行主体而非被动响应者。系统通过六大模块协同，实现任务的全自动流转与持续优化。

输入与输出

输入：一个或多个明确的任务目标（如「修复昨日 CI 失败的所有用例」）、预配置的 Skills 规则、MCP 工具连接、以及持久化的历史记忆文件
输出：任务执行结果（PR、工单更新、修复报告）、状态记录文件、以及需要人工处理的复杂问题清单

核心步骤详解

第一步：定时触发与任务发现

系统按预设时间自动启动（无需人工干预），通过 Skills 中定义的规则自动检索待执行任务。例如：每天固定时间自动检查前一天失败的 CI 任务、未关闭的 issue、以及最新代码提交记录。输入是预设的时间规则和 Skills 配置，输出是待处理任务清单。

第二步：任务拆分与并行执行

针对每个待处理问题，Loop 单独创建独立的 worktree 环境，为其分配专属分支目录。启动第一个子 Agent 执行初步修复工作。输入是任务清单和 worktree 环境，输出是每个问题的初始修复方案和代码变更。

第三步：结果校验与迭代优化

启动第二个子 Agent（通常是指令不同、模型不同的专职检查 Agent），对照项目规则和测试用例全面核查修复结果。发现问题则返回第二步继续迭代。输入是修复方案和校验规则，输出是验证通过或需要返工的通知。

第四步：状态持久化与外部联动

完成验证后，系统通过 MCP 协议自动创建 PR、更新工单状态，同时将任务状态和关键信息写入 markdown 文件持久化存储。遇到 AI 无法独立解决的复杂问题时，自动整理成待处理清单留给人工。输入是验证结果和任务状态，输出是 PR、工单更新、以及需要人工介入的问题清单。

关键知识点

Loop Engineering 的本质转变是「人从循环主体退位，AI 成为循环主体」
一个完整 Loop 必须包含六大核心模块，缺一不可
任务自动化是整个循环的「核心核心」，没有自动化能力就只是单次运行的脚本
并行隔离的最优方案是 Git worktree，为每个 Agent 分配独立分支目录
多个 Agent 同时修改同一文件会引发并发冲突，直接导致任务失败
Skills 是适配各类任务的流程规范和执行标准，相当于给 AI 看的「标准化操作手册」
MCP 协议让 Loop 能对接工单系统、数据库、通讯软件等实际工作场景
子 Agent 核心逻辑是「任务拆分、各司其职」，编码和检查应由不同 Agent 承担
同一模型容易出现思维惯性，同一 Agent 很难发现自己的代码漏洞
记忆模块将任务状态持久化为 markdown 文件，支持跨对话恢复
设计 Loop 的核心关键是「当前任务是否具备大模型可自动识别、可精准判断的明确校验信号」
测试驱动类任务最适合 Loop，因为「所有测试用例全部通过」就是明确的完成信号
编译器驱动类任务也适合 Loop，以「类型错误清单清零」为核心目标
产品迭代类场景难以完全自动化，因为缺乏统一的量化校验标准
传统 AI Agent 是被动工具，Loop 是自动化系统，这是本质区别

应用场景

场景 1：Bug 修复自动化循环

在代码仓库中设置每日定时任务，系统自动核查失败 CI 任务 → 单独创建 worktree → 子 Agent 起草修复方案 → 第二个 Agent 全面核查 → 通过 MCP 自动创建 PR。传统模式需要人工逐条跟进每个失败用例，Loop 将人力从重复性工作中解放。

场景 2：代码审查持续优化

建立编码 Agent + 检查 Agent 的双 Agent 协同模式。编码 Agent 专注实现功能，检查 Agent 专职发现漏洞。由于检查模型与编码模型指令不同，能有效突破同一模型的思维惯性，排查出更多隐藏问题。

场景 3：CI/CD 流水线守护

在持续集成流程中嵌入 Loop，监控每次代码提交后的测试结果。发现问题自动启动修复循环，直到所有测试通过才允许合并。这种闭环机制将人工守夜变成了自动化值守。

场景 4：工单 Issue 自动流转

通过 MCP 协议连接工单系统，Loop 自动读取未关闭 issue → 智能分类优先级 → 分配给对应子 Agent 处理 → 自动更新工单状态 → 复杂问题转人工。整个流转过程无需人工干预，大幅提升响应效率。

场景 5：测试驱动开发闭环

在测试驱动开发场景中，Loop 可以自动运行测试用例 → 分析失败原因 → 修改代码 → 再次运行测试 → 持续迭代直到全部通过。这种循环天然具备明确的校验信号，是 Loop Engineering 的最佳实践场景之一。

常见误区 / 踩坑

❌ 误区 1：以为有了提示词就算是 Loop
✅ 正解：传统提示词模式下，人才是循环的执行主体，每一步都需要人工输入指令。真正的 Loop 必须具备任务自动化能力，AI 自主驱动整个循环，不需要人工逐条跟进。

❌ 误区 2：多 Agent 并行时忽略文件隔离
✅ 正解：多个 Agent 同时修改同一个文件会引发并发冲突，导致任务失败。必须使用 Git worktree 为每个 Agent 分配独立分支目录，实现真正的并行隔离。

❌ 误区 3：让同一个 Agent 既编码又检查
✅ 正解：同一模型容易产生思维惯性，很难发现自己的问题。应该拆分给指令不同、模型不同的专属检查 Agent，才能有效排查隐藏漏洞。

❌ 误区 4：忽视记忆模块导致任务状态丢失
✅ 正解：Loop 的长期运行依赖于状态连续性，必须将任务记忆持久化为 markdown 文件存储在本地，否则重启后无法恢复任务背景和历史进度。

❌ 误区 5：所有场景都适合用 Loop
✅ 正解：Loop 适用于具备明确校验信号的任务（如测试通过/失败、类型错误数量）。对于缺乏量化标准的任务（如页面与设计稿对齐），Loop 无法完全脱离人工，关键节点仍需人工把关。

❌ 误区 6：把 MCP 当成可选项
✅ 正解：MCP 是 Loop 连接真实工作场景的关键通道。没有 MCP，Loop 只能做纯文本对话，无法对接工单系统、数据库、CI/CD 流水线等实际工具，落地价值大打折扣。

性能 / 复杂度

Loop Engineering 的性能评估与传统软件系统不同，核心指标是「人工介入频率」和「任务自动化覆盖率」：

人工介入频率：理想状态下，成熟的 Loop 可以将人工介入从「每轮对话」降低到「仅复杂问题」
任务自动化覆盖率：具备明确校验信号的任务可达 90% 以上自动化率
循环迭代效率：相比人工逐条处理，Loop 可将复杂任务的端到端时间缩短 50-80%

与替代方案对比：

方案 A（纯 Prompt Engineering）：人工控制每一步，优点是灵活可控，缺点是人力瓶颈明显。适合一次性、探索性任务。
方案 B（Loop Engineering）：AI 自主循环，优点是自动化程度高、释放人力，缺点是需要前期投入搭建系统。适合重复性、迭代性任务。
临界点：任务需要超过 3-5 轮迭代时，Loop 开始展现优势；任务复杂度越高，Loop 的投入产出比越明显。

与相关概念的区别

vs Prompt Engineering（提示词工程）

维度 1（执行主体）：Prompt Engineering 中人是循环主体，Loop Engineering 中 AI 是循环主体
维度 2（自动化程度）：Prompt Engineering 每步都需要人工输入，Loop Engineering 全流程自动化
维度 3（适用场景）：Prompt Engineering 适合单次对话、探索性任务；Loop Engineering 适合多轮迭代、重复性任务
怎么选：一次性的简单任务用 Prompt Engineering，需要持续运行、反复迭代的任务用 Loop Engineering

vs Workflow（工作流）

维度 1（灵活性）：Workflow 通常是预定义的固定流程，Loop 支持根据执行结果动态调整
维度 2（自主性）：Workflow 按既定路径执行，Loop 中的 AI 可以自主判断下一步操作
维度 3（适用边界）：Workflow 适合流程固定的场景，Loop 适合需要 AI 自主决策的场景
怎么选：流程清晰、步骤固定的任务用 Workflow；流程复杂、需要 AI 自主探索的任务用 Loop

vs 传统 AI Agent

维度 1（角色定位）：传统 AI Agent 是被动工具，Loop 是自动化系统
维度 2（运行方式）：传统 Agent 依赖人工触发，Loop 支持定时自动启动
维度 3（长期运行）：传统 Agent 每次对话独立，Loop 通过记忆模块保持状态连续性
怎么选：短期任务用传统 Agent，长期、持续运行的任务用 Loop

进阶 / 面试加分项

最新进展：2025-2026 年，Loop Engineering 正在从「单 Loop」向「多 Loop 协同」演进。多 Loop 系统可以通过消息队列进行任务分发和结果汇总，实现更大规模的自动化协作。这一趋势将 Loop 的应用边界从单点任务扩展到企业级工作流。

业界争议：Loop 与人工的边界划定尚无定论。激进派认为应该追求「完全无人值守」，保守派认为「关键节点必须人工介入」。实际上，这个边界取决于任务的容错成本——容错成本高的任务（如金融、医疗）需要保留更多人工关卡。

一句话送给候选人：Loop Engineering 代表了 AI 从「工具」到「同事」的角色升级，理解六大模块的协同原理，是掌握 AI Agent 工程化的必经之路。

面试如何回答

🟢 一个完整的 Loop 包含哪些核心组成部分？

回答要点：

一个完整的 Loop 必须包含六大核心模块：

任务自动化：整个循环的核心，系统按设定时间自动启动、自主检索待执行任务，全程无需人工手动触发。没有自动化能力就只是单次运行的脚本。
并行隔离：多 Agent 并行运行时，必须使用 Git worktree 为每个 Agent 分配独立分支目录，避免多个 Agent 同时修改同一文件引发并发冲突。
Skills/技能：适配各类任务的流程规范和执行标准，提前配置在专属文件中，让大模型在执行任务时有清晰的决策依据和执行准则。
MCP 和插件：打通 Loop 与各类工具的连接通道，通过 MCP 协议让 Agent 具备读取工单、查询数据库、向通讯软件推送消息等能力。
子 Agent：核心逻辑是任务拆分、各司其职。例如编码 Agent 只负责编码，检查 Agent 专职审查，避免同一模型的思维惯性。
记忆：将任务记忆整理为 markdown 文件持久化存储在本地，保障跨对话、跨任务重启时的状态连续性。

这六大模块缺一不可，共同构成能够稳定落地、自主运行的完整 Loop。

🟡 为什么需要并行隔离？Git worktree 是如何解决这个问题的？

回答要点：

并行隔离是 Loop 工程化的关键技术环节。

如果同时启动多个 Agent 执行任务，很容易出现多个 Agent 修改同一个文件的情况。比如 Agent A 和 Agent B 同时修改了 config.json，就会引发并发冲突，导致任务失败或数据损坏。这在多人协作的软件开发中是常见问题，在多 Agent 场景下问题更严重。

目前最优的解决方案是利用 Git 的 worktree 功能。worktree 允许在同一个 Git 仓库的不同目录中同时处理不同分支。为每个 Agent 单独分配一个独立的 worktree 环境，实际上就是给它分配了一个独立的分支目录。这样每个 Agent 都在自己的目录中工作，彻底规避了互相干扰、互相修改文件的问题。

一个形象的比喻：worktree 就像给每个 Agent 分配了独立的「工作台」，大家各自在自己的工位上干活，谁也不会碰到别人的东西。这才实现了真正意义上的并行隔离。

🟡 为什么 Loop Engineering 会取代部分 Prompt Engineering？两者核心区别是什么？

回答要点：

Loop Engineering 的出现是 AI 能力发展到一定阶段的必然结果。

过去两年大家使用 AI Agent 的方式基本是：精心打磨一段提示词，把前因后果交代清楚，发送给 AI，等回复后再输入新的指令。在这个模式中，人才是那个一直在循环的主体，每一步都需要人工推进。这带来一个根本问题：一旦任务变得复杂繁琐，人的打字速度、耐心和专注力都会成为整个任务推进的最大瓶颈。

而现在大模型能力越来越强，单次对话运行时长可达几十分钟甚至数小时，完全具备自主持续运行的能力。此时再靠人工反复编写、调整提示词，性价比极低。很多时候我们手动写的提示词，本质也是参考大模型输出整理而来的。

两者的核心区别在于三点：

执行主体：Prompt Engineering 中人是循环主体，Loop Engineering 中 AI 是循环主体
自动化程度：Prompt Engineering 每步都需要人工输入，Loop Engineering 全流程自动化
适用场景：Prompt Engineering 适合单次对话、探索性任务；Loop Engineering 适合多轮迭代、重复性任务

Claude Code 负责人 Boris Cherny 说过，他现在基本不会专门给 Claude 写提示词了，日常工作就是搭建各类循环，核心工作变成了「写循环」。这标志着行业范式的重要转变。

🟡 Loop 中的记忆模块是如何设计的？为什么它对 Loop 的长期运行至关重要？

回答要点：

记忆模块是保障 Loop 稳定运行的关键基础设施。

设计思路是这样的：为了留存任务状态、留存关键信息，我们将任务记忆整理为 markdown 文件，持久化存储在本地硬盘。这些记忆文件记录的内容包括：任务背景和目标、过往执行进度和结果、待处理问题的清单、人工介入记录等。

这样做为什么重要？因为 AI Agent 的对话是有上下文长度限制的，超过限制就会丢失早期对话的记忆。而 Loop 通常需要持续运行数小时甚至数天，中途可能需要重启或者开启新的对话。如果没有记忆模块，每次重启都是从零开始，之前的工作全部白费。

有了记忆模块后，哪怕后续开启新的对话、重启任务，系统也能调取历史记录，清晰掌握任务背景和过往进度。这才实现了真正的状态连续性。

一个典型的应用场景是：Loop 每天定时检查 CI 失败用例。昨天检查到一半，系统因为某种原因重启了。重启后，系统读取记忆文件，发现昨天已经处理了 5 个用例，还有 3 个待处理，今天只需要继续处理剩下的 3 个。这就是记忆模块的价值。

🔴 什么样的任务最适合用 Loop？什么样的任务不适合？设计 Loop 的核心关键是什么？

回答要点：

设计 Loop 的核心关键，是看当前任务是否具备「大模型可自动识别、可精准判断的明确校验信号」。

最适合 Loop 的任务有两类：

测试驱动类任务：非常适配 Loop，所有测试用例全部通过就代表任务完成，未通过就是未完成，校验信号清晰明确。AI 可以根据测试结果反复迭代修改，自主完成闭环。
编译器驱动类任务：以类型错误清单清零为核心目标，判断标准一目了然。这类信号明确、标准统一的任务最容易搭建自动化循环。

不太适合完全自动化 Loop 的场景：
产品迭代类任务，比如「页面和设计稿精准对齐」这类需求，没有统一的量化标准，大多只能依靠截图比对，误差和主观性较强。这类循环无法完全脱离人工，关键节点依然需要人工把关审核。

从实际数据来看，具备明确校验信号的任务，Loop 可实现 90% 以上的自动化率；而缺乏量化标准的任务，自动化率可能不到 30%。

所以在设计 Loop 之前，首先要问自己：任务的完成标准是什么？AI 如何判断任务是否完成？如果答案不清晰，就不要强行上 Loop。

🟡 子 Agent 的设计有什么最佳实践？为什么不让同一个 Agent 既编码又检查？

回答要点：

子 Agent 设计遵循「任务拆分、各司其职」的核心原则。

最佳实践是将复杂任务拆解开来，交给不同的子 Agent 分别执行。每个子 Agent 有明确的职责边界和指令模板，彼此协作完成整体任务。

关键问题是：为什么不让同一个 Agent 既编码又检查？原因在于「思维惯性」。同一模型在执行编码任务时，会形成固定的思维模式和关注点，很难跳出这个框架去发现问题。就像我们自己写的代码，自己往往很难发现 bug，因为我们已经默认了代码的逻辑是对的。

更好的做法是拆分给指令不同、模型不同的专属 Agent。例如：

编码 Agent：专注于功能实现，按照需求完成代码编写
检查 Agent：专注于质量审查，对照项目规则和测试用例全面核查

由于检查 Agent 的指令和视角与编码 Agent 不同，能有效突破思维惯性，排查出更多隐藏问题。这在软件工程领域也是最佳实践——代码审查应该由非作者来完成。

一个 Loop 中子 Agent 的数量不固定，取决于任务复杂度。简单的 Bug 修复可能只需要 2 个子 Agent，复杂的流水线可能需要 5 个甚至更多。

🟡 MCP 协议在 Loop 中扮演什么角色？为什么说没有 MCP 就不是真正的 Loop？

回答要点：

MCP（Model Context Protocol）在 Loop 中扮演「连接器」的角色，是 Loop 打通真实工作场景的关键通道。

MCP 的核心作用是打通 Loop 和各类工具的连接通道。底层依托 MCP 协议，让 Agent 具备以下能力：读取工单 issue、查询数据库、向各类通讯软件推送消息、操作 CI/CD 系统、调用代码托管平台 API 等。这些能力让 Loop 不再局限于文本对话，能够真正落地对接实际工作场景。

为什么说没有 MCP 就不是真正的 Loop？因为没有 MCP 的 Loop 本质上只是一个「能聊天的脚本」，输入输出都局限在对话窗口内。它无法：

读取真实的工单系统获取任务
操作代码仓库创建 PR
触发真实的 CI/CD 流水线
将结果同步到项目管理工具

这样的 Loop 只能在实验室里跑，无法产生真实的业务价值。

一个典型的例子：Loop 通过 MCP 读取未关闭的工单 → 分析问题并修复 → 通过 MCP 创建 PR → 通过 MCP 更新工单状态 → 通过 MCP 通知相关人员。整个流程形成了从工单系统到代码仓库到通知系统的闭环，这才是有价值的自动化循环。

🔴 能否给我描述一个完整的 Loop 示例，展示六大模块是如何协同工作的？

回答要点：

让我用一个 Bug 修复自动化循环来完整展示六大模块的协同工作流程。

场景设定：在代码仓库中设置一个每日定时运行的修复循环。

第一阶段：任务发现（任务自动化 + Skills）
系统每天固定时间自动启动（无需人工触发），通过预设的 Skill 规则自动核查：前一天失败的 CI 任务、未关闭的工单 issue、最新代码提交记录。所有核查结果整理归档，生成待处理问题清单。

第二阶段：任务执行（并行隔离 + 子 Agent）
针对每一个待处理问题，Loop 单独创建独立的 worktree 环境，启动第一个子 Agent 起草修复方案、完成初步整改。再启动第二个专属子 Agent（检查 Agent），对照项目规则和现有测试用例全面核查修复结果。

第三阶段：状态同步（记忆 + MCP）
完成核查后，系统通过 MCP 协议自动创建 PR、更新工单状态。同时将任务状态和关键信息写入 markdown 文件持久化存储。如果遇到 AI 无法独立解决的复杂问题，自动整理成待处理清单留给人工。

整个流程只需要提前搭建一次循环体系，后续日常运行全程不需要手写一句提示词，这就是一套成熟、完整的 Loop 循环工程。六大模块缺一不可，协同工作才能实现真正的自动化。