Loop Engineering — 循环工程技能
元数据
- 技能名称: Loop Engineering
- 触发词: loop engineering, 循环工程, 写循环, 设计循环, agent loop, 自动化循环, 智能体循环, /loop, /goal, self-running agent
- 适用场景: 需要让 AI 智能体自主、持续、多轮迭代完成任务的任何场景
- 核心价值: 把你从"亲手一轮轮写提示词"替换掉，设计一套自己会找活、派活、检查、记进度、决定下一步的系统
什么是循环工程
循环工程是把提示词从"每次手敲"变成"写进循环、反复复用"。你不再是一个回合一个回合地跟智能体对话，而是搭一套小系统：它会自己找活、把活派出去、检查做完没有、记下进度、再决定下一步干什么。
核心类比：从操作机床 → 设计整条产线。
循环的六大组件
设计任何一个循环，必须考虑以下六块积木。缺了哪块，循环就会从那里"漏"。
1. 自动化（Automations）—— 心跳
定时触发，自动发现和分诊任务。
两种关键原语：
| 原语 | 行为 | 使用时机 |
|---|---|---|
/loop |
按固定间隔反复运行同一段提示词 | 周期性检查/监控类任务（盯 PR、分类 issue、检查 CI） |
/goal |
一直运行直到某个可验证的条件为真才停 | 有明确完成标准的任务（测试全过、lint 清零、构建成功） |
/goal 的关键设计：每轮结束后由独立的小模型判断"到底完成没有"，写代码的那个模型不许给自己打分。必须拆分制造者与检查者。
间隔选择指南：
- 实时性要求高的监控（PR 审查、CI 失败响应）：1-5 分钟
- 日常分诊/整理（issue 分类、僵尸 PR 清理）：30 分钟 - 1 小时
- 长周期任务（周报、知识蒸馏、依赖升级检查）：每天 / 每周
- 云端例程（关电脑后仍需运行）：用云端 Routine，最小 1 小时
2. 隔离工作区（Worktrees）—— 防打架
两个智能体同时改一个文件 = 必定冲突。每个并行任务必须分配独立 worktree。
实现方式：
- git worktree add ../worktree-feature-a feature-a
- 每个子智能体在自己的检出里工作
- 任务完成后 worktree 自动清理
原则：并行数 > 1 就必须用 worktree。
3. 技能（Skills）—— 治金鱼记忆
把项目知识写成 SKILL.md，智能体每轮自动读取。不要每轮重新解释。
SKILL.md 必须包含的硬信息：
- 构建/测试命令（精确的，不许有歧义）
- 代码规范红线（"绝对不许用 any 类型"）
- 历史踩坑记录（"那次因为时区导致事故，所有时间字段必须带时区"）
- 项目独有的约定（"日志统一用 logger，不用 console.log"）
描述原则：精准、枯燥 > 聪明、花哨。技能描述是给 AI 匹配用的，不是给人读的。
4. 连接器（Connectors / MCP）—— 接入真实世界
让智能体能读 issue、查数据库、往 Slack 发消息、开 PR。
这是"告诉你怎么改"和"直接替你开好 PR、更新好工单"的分水岭。
| 没有连接器 | 有连接器 |
|---|---|
| "这里是修复方案，你手动去开 PR 吧" | 循环自动开 PR → 链接 Linear 工单 → CI 绿了自动 ping 频道 |
| 循环只能"看"文件系统 | 循环能"行动"在你的真实工作流里 |
5. 子智能体（Sub-agents）—— 制造者与检查者分离（铁律）
这是循环工程中最重要的一条原则。
错误：一个智能体既写代码又审查自己 → 总是手软，自夸，放水
正确：智能体 A 写代码 + 智能体 B（不同指令、最好不同模型）独立审查
典型分工：
- 探索者（低 reasoning effort，快速扫）
- 实现者（中等 reasoning effort，专注写代码）
- 验证者（高 reasoning effort，严格对照 spec 和 skill 挑刺）
Token 成本说明：子智能体每个都要跑模型调用，token 消耗叠加。只在"第二意见值得花钱"的地方用。
6. 记忆（Memory）—— 明天的循环能接上今天
记忆必须在磁盘上，绝对不能只存上下文。模型每轮都会忘光。
推荐方案（按复杂度递增）：
1. 一个 Markdown 状态文件：记录做了什么、通过什么、还剩什么
2. Linear / Jira 面板：通过 MCP 连接器读写
3. 结构化进度文件 + 子任务清单
循环设计方法论
步骤一：判定任务是否适合循环
循环适合有明确、可验证完成标准的任务：
- ✅ 测试全部通过
- ✅ lint 零警告
- ✅ 构建成功
- ✅ 所有 issue 已分类
- ✅ PR 已 review 且 CI 绿
不适合开放式探索任务（"帮我研究一下这个新技术"），容易跑飞白烧算力。
步骤二：填写循环设计六问
拿到一个任务后，按顺序回答：
- 触发方式：定时（/loop）还是跑到完（/goal）？间隔/停止条件是什么？
- 隔离策略：需要并行吗？需要 worktree 吗？
- 知识注入：任务需要哪些项目背景？有没有对应的 SKILL.md？
- 外部连接：需要读写哪些外部系统（issue / Slack / 数据库）？
- 检查机制：谁写？谁验？要不要换模型？
- 状态记录：进度写在哪？下一轮怎么接上？
步骤三：先单步验证再循环
严禁一上来就写完整循环。先手动跑一轮核心逻辑，确认单个子任务能跑通后，再封装为循环。
步骤四：设定熔断
每个循环必须有熔断机制：
- 最大轮数（防止无限循环烧 token）
- 最大耗时（xx 分钟后强制退出并报警）
- 异常后的降级行为（记录失败 → 丢入人工收件箱）
三层架构参考（"蜂巢"模式）
| 层级 | 机制 | 最小间隔 | 关机后运行 | 适用场景 |
|---|---|---|---|---|
| 第一层 | /loop 本地循环 | 1 分钟 | ❌ 停 | 会话内实时监控 |
| 第二层 | 云端 Routine | 1 小时 | ✅ 继续 | 跨日长周期任务 |
| 第三层 | /batch + 动态工作流 | 一次性并行 | ❌ | 大规模批量操作 |
组合才是魔法：第二层发现写入文件 → 第一层接力干活 → 遇大活拉起第三层 → 结果回流 → 每周蒸馏更新技能文件 → 智能体每周比上周更聪明。
三大经典陷阱及对策
| 陷阱 | 表现 | 对策 |
|---|---|---|
| 偷懒 | 50 项安全问题做了 20 项就说"搞定" | 停止条件必须可量化验证；检查者和制造者拆分 |
| 自夸 | 给自己的活打高分 | 验证者换模型，用更强的 reasoning effort |
| 漂移 | 跑到第 47 轮时，"别做 X"的约束悄悄消失 | 每轮把关键约束重新注入；定期蒸馏更新 SKILL.md |
设计完成后的检查清单
- [ ] 停止条件是可自动验证的（不是"看起来不错"这种主观判断）
- [ ] 制造者和检查者是两个不同的智能体
- [ ] 状态文件在磁盘上，不在上下文里
- [ ] 有熔断机制（最大轮数或最大时间）
- [ ] 失败有降级路径（丢回收件箱等人工处理，而非静默忽略）
- [ ] 项目知识已沉淀为 SKILL.md，循环引用它而非每轮口头交代
- [ ] 如果涉及并行任务，已设置 worktree 隔离
核心哲学
> 你的产出不应该依赖于某一次对话，而应该依赖于系统。
>
> 写循环 = 给一支随叫随到的数字团队办入职。你是在设计一份工作，不是在操作工具。
>
> 循环越强，越要当那个看得懂它在干什么的工程师，而不是只会按"运行"的人。
（内容由AI生成，仅供参考）
