Loop Engineering：让AI Agent自动循环执行任务的系统化方法

从「敲Prompt」到「设计系统」

过去两年，大多数人使用AI编程Agent的方式都是线性的：写一句Prompt，等它返回，读一遍，再写下一句。这种模式确实提升了效率，但问题也很明显——人始终是流程里最忙的那个调度员。

更讽刺的是，当模型能力越来越强时，手动Prompt的瓶颈反而愈发突出。瓶颈不再是模型，而是你自己。你越用越发现，真正拖慢速度的，是那个不停在键盘前敲「下一步」的人。

Loop Engineering（循环工程）正是为解决这个问题而生。它的核心思路，是把一次次的手动提示，升级成一个能自动运作的系统。你一次性设计好流程，让AI Agent在明确边界内反复地发现任务、分配任务、检查结果、决定下一步，而你退到后面做监督。

这就像从一个始终握着方向盘的司机，变成设计了一套自动驾驶规则、然后在副驾看仪表盘的人。角色从「使用AI」切换到了「运营AI」。

五个核心原语：让循环持续运转

一条能持续跑的Loop回路，需要五个核心原语，再加一个外部记忆，缺一样，循环就会「泄露」。

五个原语构成循环的基础

心跳与并行：Automations 与 Worktree

Automations 是循环的心跳，它决定Loop何时被触发。可以是定时的——比如每小时查一次部署状态；也可以是事件驱动的——比如GitHub的PR一旦创建，就自动拉起一轮处理。

Worktree 解决的是并行污染问题。Git Worktree 让多个Agent在同一仓库的不同目录里干活，每条修复线有独立的分支和文件状态。这样即便晚上同时跑三条修复线，它们也不会互相覆盖、互相污染。

Git Worktree 是 Git 的一项内置功能，允许同一个本地仓库同时检出多个工作目录，每个目录对应独立的分支和文件状态，但共享同一份 .git 对象数据库。传统的多分支并行开发需要反复 git stash 或切换分支，而 Worktree 让不同任务在物理上彼此隔离——一个目录在修复 Bug，另一个目录在开发新功能，两者互不干扰。在 Agent 并行场景下，这一特性尤为关键：如果多个 Agent 共享同一工作目录，并发写文件会产生竞态条件，代码修改会相互覆盖，导致构建失败甚至逻辑混乱。Worktree 从文件系统层面切断了这种污染路径，是实现稳定并行 Loop 的基础设施前提。

知识与工具：Skills 与 Connectors

Skills 解决的是「Agent知不知道该怎么做」的问题。把前端框架、接口规范、测试如何运行这些稳定规则，沉淀到 Skills.md 或 Agents.md 中，Agent按需读取，不用每次都往System Prompt里塞。

Skills 把项目规范变成可执行约束

Connectors 解决的是「Agent碰不碰得到真实系统」的问题。通过MCP或Connector，把Agent接入GitHub、Linear、Slack、Sentry等真实工具链。没有连接器，Agent只能给建议；接上了，它才能真正推进工作流。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的开放协议，旨在标准化 AI 模型与外部工具、数据源之间的连接方式。其设计思路类似 USB-C 的「通用接口」：工具提供方实现一次 MCP Server，任何支持该协议的 AI 客户端都可以直接调用，而无需为每个模型单独开发适配层。对于 Loop Engineering 而言，Connectors 的意义在于把 Agent 的能力边界从「生成文本建议」扩展到「在真实系统中执行操作」——例如直接在 GitHub 上创建 PR、在 Linear 里更新任务状态、在 Sentry 里标记 Issue。没有这层连接，Agent 产出的只是「参考意见」；接入真实工具链后，它才能成为工作流中真正推进事项的执行节点。

分工制衡：Subagents

第五个原语 Subagents，核心思想是把执行和检查分开。一个Agent既提方案、又写代码、又做检查，效率是高，但风险明显——它太容易相信自己了。

更稳妥的做法是拆成三个角色：

Proposer：负责提方案和拆任务
Implementer：在隔离的Worktree里实现代码
Reviewer：按Skills、测试和验收标准做严格门禁

让制造者与检查者分离，在复杂度上升时，比单个Agent包揽一切稳得多。

此外，还需要一个外部记忆（如 Progress.md），让Agent即使上下文窗口耗尽「失忆」，仓库也记得当前进度。

Proposer-Implementer-Reviewer 的三角分工本质上借鉴了软件工程中「关注点分离」的原则，同时也对应着人类团队中产品、研发、QA 的职责划分。单一 Agent 自产自销时，存在一种被称为「自我确认偏差」的系统性风险——模型倾向于认可自己刚生成的输出，在自我审查时很难发现逻辑缺陷或遗漏的边界条件。将角色拆开后，Reviewer Agent 以独立上下文重新审视代码，缺少前序生成过程的「惯性」，更容易发现问题。此外，三角结构天然产生了检查点：每个交接环节都可以记录中间状态，一旦某步骤失败，系统能够精确定位是提案阶段、实现阶段还是验收阶段出了问题，极大降低了调试复杂度。

落地路径：六步搭建第一条Loop

落地一条Loop有清晰的六步路径，建议从最薄的一端开始往上搭：

写清楚Spec——这是唯一不能交给Agent的活，它定义了「完成」长什么样。
拆成原子任务——每条任务都有明确的Pass或Fail判定。
用Skills沉淀规范——把稳定规则固化到文档中。
跑起最小骨架——用Loop先把闭环验证起来。
引入Subagent分工——让执行与检查分离，提高可靠性。
接入Connectors嵌进真实工作流——这一步是从「个人玩具」升级成「团队基础设施」的临界点。

Spec 是唯一不能交给 Agent 的活

边界比能力更重要

Loop越强，安全边界反而越重要。有三件事AI Agent永远替代不了人：

第一，验证责任仍在人。 Agent说「完成」不等于真完成，没有测试就没有信任。

第二，审查入口不能丢。 人会越来越看不懂Agent改了什么，所以好的Loop必须保留审查入口和变更摘要。

第三，认知投降比执行失败更可怕。 带着判断去设计Loop，它是效率放大器；为逃避判断去启动Loop，它就成了风险源。

上线前的安全检查清单

权限是安全边界，不是开关

上线之前，有一张清单要逐条过：

明确输入输出格式和停止条件
给单次运行设置Token和时间预算
按任务复杂度选模型，而不是无脑上最高档
只开必要的工具权限
写操作全部隔离在分支或草稿PR中

最危险的反模式，是用「全局YES」全自动跳过权限确认——那不是Loop Engineering，是拆掉了刹车。权限是安全边界，不是开关。

常见问题与最适合起步的场景

Loop Engineering 与 Prompt Engineering 的核心区别在于：Prompt Engineering优化的是「一次对话」的质量，而Loop Engineering优化的是「一整套能持续运作的自动化系统」。

最适合先尝试的任务，是那些重复、边界清楚、结果可验证的工作——比如定期跑测试、自动整理仓库变更日志、PR初步评审。需要强调的是，Loop Engineering并不会让Agent完全替代人工：目标定义、权限边界、结果验收和最终责任，始终在人手里。

从「使用AI」到「运营AI」

Loop Engineering 的本质，是把「和AI合作」从一个动作升级成一个系统。当你不再每次去敲下一句Prompt，而是设计那个能持续自动运转的系统时，你就完成了从「使用AI」到「运营AI」的转变。

今天就能做三件事来开始实践：把最重复的一个任务写成Spec，用Loop或一个最小脚本跑起来验证闭环，再把状态写进 Progress.md 或 Linear。三件事做完，你的第一个Loop就上线了。