当我们谈论如何用好 AI 编程时，大多数人还停留在"如何写出更好的 Prompt"这个层面。但真正的范式转移正在发生：与其继续手写 Prompt 指挥 Agent，不如设计一个能自动驱动 Agent 的"小系统"。这就是循环工程（Loop Engineering）。
1. 核心概念：从"提示"到"设计循环"
循环工程的核心，是让一个系统自动完成一整套闭环动作：
- 发现任务
- 分配任务
- 调用智能体
- 检查结果
- 记录进度
- 决定下一步
一句话概括这种转变：从"我提示 Agent"变成"我设计一个会提示 Agent 的循环"。
两种工作模式的对比非常直观：
- 以前：人 → Prompt → Agent → 人检查 → 再 Prompt
- 现在：人设计循环 → 循环驱动 Agent → Agent 执行 / 检查 / 记录 → 人只处理关键判断
2. 循环工程的 5 个核心模块
2.1 自动化（Automations）
作用：让任务按计划自动运行。
典型场景包括：每天扫描 Issue、总结 CI 失败、发现上周引入的 Bug、自动生成提交简报、定时检查代码库状态。
自动化是循环的"心跳"。没有自动化，就只是一次性任务，不是循环。
2.2 工作树（Worktrees）
作用：让多个智能体并行工作时互不污染。
多个 Agent 同时改同一个仓库，容易冲突；一个 Agent 的实验性修改可能破坏另一个任务。解决方法是：每个 Agent 在独立的 Git worktree / branch 中工作，最后再合并、审查、取舍。
并行 Agent 编程必须隔离工作区，否则很快变成代码车祸现场。
2.3 技能（Skills）
作用：沉淀项目知识，避免每次都重新解释。
技能通常包含：项目背景、代码规范、常用命令、测试方式、部署流程、业务约束、已知坑点。没有技能时，要么反复把项目约定塞进 Prompt（每轮重复），要么不塞——让 Agent 从代码库重新推断，能推出来的会重复花成本，推不出来的隐性知识（业务背景、历史遗留问题）只能靠猜。有技能后，这些项目知识沉淀下来，可被反复复用。
Skill 是长期上下文，不该反复塞进 Prompt，而应该沉淀成可调用资产。
2.4 插件与连接器（Plugins / Connectors）
作用：让 Agent 接入真实工具，而不是只在本地文件里自嗨。
可连接的对象包括：GitHub / GitLab / Jira / Linear、数据库、API、Slack / 飞书 / Telegram、CI/CD、内部系统。
区别在于：没有连接器，Agent 只能说"你可以这样修"；有连接器，Agent 可以开 PR、关联 Ticket、通知团队、查询 CI。
连接器决定循环能不能进入真实工作流。
2.5 子智能体（Sub-agents）
作用：拆分角色，避免同一个 Agent 既写代码又做 Review——写的人审自己，往往不会严格批评自己的产出。
常见结构是：一个智能体负责实现、一个负责 Review、一个负责测试、一个负责总结 / 归档。重点是生产者和检查者分离。
让写代码的 Agent 自己审自己，等于让学生自己批卷子。可以，但别太信。
3. 还有一个容易被忽略的关键：记忆（Memory）
长期循环必须有外部记忆，形式可以很简单：Markdown 文件、Linear / Jira 看板、GitHub Issue、数据库记录、项目日志。
为什么需要它？模型会忘，仓库不会。长期运行的智能体不能依赖单次对话上下文。
记忆需要记录的内容：
- 已完成什么
- 当前卡在哪
- 下次继续做什么
- 哪些任务被搁置
- 哪些结论已经验证过
4. 组合起来看：一个循环的完整运转过程
一个完整循环的示例流程如下：
- 每天早上自动运行
- 读取昨天的 CI 失败、Issue、最新提交
- 调用分类 Skill 进行任务筛选
- 把结果写入 Markdown 或看板
- 对值得处理的任务创建独立 worktree
- 派一个智能体提出修复方案
- 派另一个智能体审查方案和测试结果
- 通过连接器开 PR / 更新 Ticket / 通知团队
- 无法自动处理的任务进入人工收件箱
其核心思想是：人不再亲自提示每一步，而是设计流程，让流程推动智能体工作。
5. 循环工程的价值
- 提高杠杆：你不再处理单个任务，而是设计一个能持续处理任务的系统。
- 降低重复劳动：重复性的分类、检查、摘要、初步修复可以自动化。
- 支持并行：多个智能体可以在不同 worktree 中同时跑任务。
- 项目知识复利：Skills 和 Memory 会让系统越跑越懂项目。
6. 风险和限制
6.1 Token 是真实成本
长期循环会持续消耗 Token。需要控制：运行频率、上下文大小、是否复用 Skill、是否先做轻量筛选、是否只把高价值任务交给大模型。
6.2 无监督的循环会批量产出垃圾
无人值守的循环可能大量制造低质量代码。防范方式：强制测试、独立 Review Agent、小步提交、清晰验收标准、人工抽查关键改动、不允许自动合并高风险 PR。
6.3 “完成了"不等于完成了
Agent 说任务完成，不代表真的完成。必须验证：测试是否通过、行为是否正确、是否引入新问题、是否符合业务目标。
6.4 理解债（Understanding Debt）
Agent 生成代码越快，你可能越不理解这份代码。 系统越来越复杂，代码你没写过也没真正理解，出问题时没人知道为什么。
6.5 惰性依赖
循环自动跑久了，人容易停止思考，直接接受结果。这里有一个关键分界点：
如果你设计循环是为了加速理解，它是工具；如果你设计循环是为了逃避理解，它是灾难加速器。
7. 实践原则
原则 1：先设计小循环。 不要一开始就搞"全自动软件工厂”。可以从这些开始：每日 Issue 分类、CI 失败摘要、PR Review 初筛、每周技术债扫描、自动生成变更日志。
原则 2：每个循环都要有验收标准。 不要只写"修复登录问题"，而要写清楚：“修复登录失败问题，并满足：auth 测试全部通过、lint 通过、不修改 public API、输出变更摘要”。
原则 3：生产和审查分离。 最小可用结构是：Agent A 实现、Agent B 检查、人最终确认。
原则 4：把知识沉淀成 Skill。 凡是你反复告诉 Agent 的东西，都应该变成 Skill：项目如何启动、测试怎么跑、哪些目录不能改、代码风格要求、常见错误处理方式。
原则 5：把状态沉淀到 Memory / 文件 / 看板。 不要依赖聊天记录。循环每次结束都应该留下：做了什么、结果是什么、还有什么没做、下次应该从哪里继续。
8. 总结
循环工程的本质：不是写更好的 Prompt，而是设计一个能持续发现任务、调用智能体、验证结果、记录状态的自动化工作系统。
但别误会：循环可以替你跑流程，不能替你承担工程责任。真正的价值不是"让 Agent 自动干活"，而是"让工程师用系统化方式放大判断力"。