1. 引言
当我们谈论 AI 辅助开发时，最常见的画面是：开发者打开对话框，输入一段提示词，等待模型生成代码，复制粘贴，再继续下一个问题。这种“提示-响应”模式虽然高效，却把人类牢牢钉在循环的中心——每一步都需要人来发起、判断、纠错。
Loop Engineering（循环工程）试图打破这个范式。它的目标不是写出更好的提示词，而是设计一套能够自我维持、自我迭代的开发循环：让 AI 不只是回答问题，而是成为循环中的一个常驻节点，持续观察、执行、反馈、改进。
本文将从 Loop Engineering 的核心概念与诞生背景讲起，拆解其六大核心模块，对比它与传统编程循环的本质差异，最后给出一个可持续运行开发循环的实践设计。
2. Loop Engineering 的核心概念与诞生背景
2.1 什么是 Loop Engineering
Loop Engineering 是一种以“循环”为基本单元来设计 AI 系统的工程方法论。它不再把 AI 视为一个被动的“问答工具”，而是把它嵌入到一个持续运行的闭环中：感知 → 决策 → 执行 → 反馈 → 再感知。
在这个循环里，AI 的每一次输出都会成为下一次输入的上下文，系统因此具备了自我演进的能力。开发者从“逐条发指令”变成“设计循环的规则与边界”。
2.2 诞生背景：从对话到系统
Loop Engineering 的兴起有三个直接推力：
- 大模型能力的跃迁：模型不再只能“回答”，还能调用工具、读写文件、执行代码、自主规划。能力边界的扩展让“让 AI 自己跑起来”成为可能。
- Agent 框架的成熟：以 Claude Code、LangChain、AutoGPT 为代表的 Agent 框架，提供了让模型多步决策、调用外部工具的运行时环境。
- 开发者疲劳：提示词工程把大量认知负担压在开发者身上。人们开始意识到，与其每次手动喂上下文，不如设计一个能自动积累上下文、自动执行例行任务的循环。
一句话概括：当 AI 从“被调用”走向“自主运行”，工程设计的单元就从“提示词”变成了“循环”。
下面是 Loop Engineering 的核心循环示意：
3. 六大核心模块
一个完整的 Loop Engineering 系统通常由六个模块构成。它们各自承担循环中的一个环节，组合起来才能形成自运转的闭环。
3.1 Automations（自动化触发器）
Automations 是循环的“心跳”——它们决定循环何时启动。常见的触发器包括：
- 定时触发（如每天凌晨同步依赖版本）；
- 事件触发（如代码合并、Issue 创建、CI 失败）；
- 状态触发（如测试覆盖率低于阈值时自动介入）。
Automations 让循环不必依赖人工“踢一脚”才能运转。
3.2 Worktrees（工作树）
Worktrees 是循环的“工作台”。它把一次循环的执行隔离到一个独立的工作区中，避免污染主分支或主环境。
在开发循环中，Worktree 通常对应一个独立的 Git 分支或沙箱目录。AI 在其中自由实验、修改、运行测试，只有验证通过的结果才会被合并回主干。这保证了循环可以大胆试错，而不必担心破坏稳定状态。
3.3 Skills（技能）
Skills 是循环的“能力库”。它们把 AI 可执行的操作封装成可复用的单元——比如“运行测试并汇总失败用例”“生成变更日志”“执行代码审查”。
Skill 的价值在于标准化：同一个技能可以在不同循环中被反复调用，且行为一致。它让 AI 的能力从“临场发挥”变成“按需装配”。
3.4 Connectors（连接器）
Connectors 是循环的“触角”。它们负责打通外部系统：GitHub、Jira、Slack、数据库、云服务等。
通过 Connector，循环中的 AI 可以读取 Issue、推送 PR、发送通知、查询数据。没有 Connectors，循环就只能在一个封闭的沙盒里自娱自乐，无法真正介入真实的工作流。
3.5 Sub-Agents（子代理）
Sub-Agents 是循环的“分工”。当主循环面对复杂任务时，可以拆解出多个子代理并行处理——一个负责调研、一个负责编码、一个负责测试。
子代理之间通过共享的上下文或消息队列协作，最终把结果汇总回主循环。这种结构让循环具备了横向扩展的能力，而不是单线程地一步步走。
3.6 Memory（记忆）
Memory 是循环的“长期记忆”。它让循环跨越多轮运行仍能积累经验：
- 哪些方案失败了，为什么失败；
- 项目的代码风格与约定；
- 用户的历史偏好与纠错记录。
Memory 是循环“越用越聪明”的关键。没有记忆的循环每次都是从头开始，有了记忆，循环才能持续进化。
六大模块在循环中的协作关系如下图所示：
4. Agent Loop 与传统编程循环的本质差异
传统编程循环（开发-测试-部署）与 Agent Loop 看似相似，但存在本质差异：
| 维度 | 传统编程循环 | Agent Loop |
|---|---|---|
| 驱动者 | 人类开发者 | AI Agent + 规则 |
| 反馈来源 | 测试结果、人工 review | 测试、日志、用户反馈、自我评估 |
| 上下文 | 每次手动加载 | 自动积累于 Memory |
| 迭代粒度 | 以“版本”为单位 | 以“循环”为单位，可高频运行 |
| 错误处理 | 人工介入修复 | AI 自主诊断并尝试修复 |
| 扩展方式 | 增加人力 | 增加 Sub-Agent / Skill |
最核心的差异在于反馈回路是否闭合。传统循环中，反馈最终要回到“人”这里才能推动下一步；而 Agent Loop 中，反馈可以直接驱动 AI 的下一步行动，人类只在关键节点（如合并、发布）介入。
换句话说：传统编程是“人驱动、AI 辅助”，Agent Loop 是“规则驱动、AI 执行、人监督”。
两种循环的反馈回路差异可以用下图直观呈现：
5. 实践场景：如何设计一个可持续运行的开发循环
下面以一个“自动维护开源项目”的循环为例，展示如何把六大模块组合成一个可持续运行的开发循环。
5.1 循环的目标
设计一个循环，让它能够：自动处理新提交的 Issue、修复简单 Bug、提交 PR、并在人工确认后合并。
5.2 循环的模块装配
5.3 各环节的落地要点
- Automations：监听仓库的
issues事件，新 Issue 创建即触发循环。 - Connectors：通过 GitHub API 拉取 Issue 正文、标签、关联代码。
- Sub-Agents：一个子代理负责复现问题，另一个负责检索相关代码位置。
- Worktrees：每次修复都在独立分支上进行，避免污染主分支。
- Skills：封装“运行测试并汇总结果”“生成 PR 描述”等标准操作。
- Memory：记录“此类 Bug 的常见根因”“项目偏好的提交信息格式”，让后续循环更快。
5.4 让循环“可持续”的三个原则
- 设置安全边界：AI 只能修改 Worktree 内的内容，合并必须人工确认——防止失控。
- 反馈要闭环：每次循环结束都要把结果写回 Memory，让下一次循环站在前一次的肩膀上。
- 保留人工监督点：不是所有环节都自动化。发布、重大重构、对外沟通等高风险动作，保留人工决策。
6. 总结
Loop Engineering 把 AI 从“被提示的工具”提升为“自运转系统中的执行者”。它的核心不是某一种技术，而是一种视角转换：从设计提示词，转向设计循环。
六大模块各司其职——Automations 提供心跳，Worktrees 提供沙盒，Skills 提供能力，Connectors 提供触角，Sub-Agents 提供分工，Memory 提供记忆。它们组合在一起，才能构成一个真正可持续、可进化的开发循环。
当你下一次面对重复性的开发任务时，不妨问自己：我是在写一条提示词，还是在设计一个循环？
