Loop Engineering（循环工程）¶
CONFIDENCE — MEDIUM
从“用提示词驱动 Agent”到“设计替你写提示词的循环系统”，这是 2026 年由 Addy Osmani 收拢命名的 AI Agent 工程范式。
核心框架：Harness（基础设施）+ Loop（循环）¶
Loop Engineering 分为两个层次：
- Harness（基础设施）：固定配置文件，定义规则和权限，不随运行改变
- Loop（循环）：在基础设施之上运行的迭代流程，包含目标、行动、验证、记忆写入、继续/停止决策
关键洞察：厨房与食谱的比喻，两者缺一不可。多数失败源于混淆层次，在基础设施层问题中错误地重写提示词。
三阶段演进¶
| 阶段 | 模式 | 说明 |
|---|---|---|
| 第一阶段 | 逐行驾驶 | 模型自动补全，人 Tab Tab Tab |
| 第二阶段 | 并行手动 | 同时开多个 Agent 会话，人当调度员 |
| 第三阶段 | Loop 驱动 | 设计循环系统，让 Agent 自主决定该干什么 |
Loop Engineering = 第三阶段。 不再亲手写每条提示词，去设计那个替你写提示词的系统。
七层基础设施（Harness）¶
| 层 | 文件/目录 | 核心作用 |
|---|---|---|
| 1 | CLAUDE.md |
常驻上下文，越精简越好，需定期修剪。过大的常驻上下文会显著拉低任务完成率 |
| 2 | settings.json |
权限白名单 + hook 配置；机密单独隔离存放 |
| 3 | hooks/ |
PreToolUse / PostToolUse / Stop 三事件；成功静默、失败 loud（策略底线） |
| 4 | agents/ |
子代理，在全新上下文中调用，解决自我确认偏差 |
| 5 | skills/ |
渐进加载，同一任务出现第三次时才建，避免技能堆积消耗 token |
| 6 | .mcp.json |
MCP 工具声明；只用当前需要的，启用写权限前必须有 audit hook |
| 7 | MEMORY.md + vault/ |
分层持久化：跨会话变化 vs 跨会话不变；必须每会话修剪 |
单向依赖：基础设施定义规则 → 循环在规则内运行。
Loop 的 5 个组件 + 1 根脊柱¶
| 组件 | 作用 | 关联技术 |
|---|---|---|
| 心跳（Heartbeat） | 定时触发，自动发现任务 | cron, scheduler |
| 工作树（Work Tree） | 多智能体隔离的 Git 分支目录 | git worktree |
| 技能（Skill） | 项目规则写一次，每个 Agent 每次都读 | SKILL.md |
| 连接器（Connector） | 通过 MCP 接到真实工具 | MCP 协议 |
| 子智能体（Sub-agents） | 写代码和审代码拆开 | 职责隔离、独立上下文 |
| 记忆（Memory） | 持久化状态：做过什么、试过什么、还差什么 | Agent Runtime |
五步循环（Loop）¶
步骤 1：Goal spec（目标规格）¶
存于磁盘，循环每轮重新读取。明确定义“完成标准”和“停止条件”。没有它的后果：代码在写、测试在过，但解决的不是你的问题，失败看起来像进展。
步骤 2：Plan → Act → Verify¶
最小可行循环：计划 → 执行 → 独立验证。省略验证的后果：错误输出成为下一轮输入，自信垃圾（confident garbage）复利增长。
步骤 3：Sub-agent fan-out（子代理扇出）¶
单一目标分支为多个独立子任务（如分析多篇文章、修复多个文件）。一个臃肿上下文做不到，多个小型上下文可以。
步骤 4：Scheduler and persistence（调度与持久化）¶
调度器故意比代理更笨，只负责定时触发，不做状态判断。每次迭代必须序列化“做了什么、尝试了什么、下一步是什么”。
步骤 5：三大失败模式识别¶
| 失败模式 | 本质 | 根因 |
|---|---|---|
| Confident garbage | 错误输出通过验证并跨轮复利 | 验证步骤缺失或薄弱 |
| Context rot | 模型在累积历史超过阈值后退化 | 单长上下文持续膨胀 |
| Ralph Wiggum loops | 同一迭代重复执行 | 磁盘状态未捕获进度，代理重新计划已完成步骤 |
单轮迭代完整流程¶
- cron 触发运行脚本
- 调用 Agent
- 读取常驻上下文与权限配置（基础设施 1、2）
- 每次编辑应用 PostToolUse hook（基础设施 3）
- 读取目标规格与状态文件（循环步骤 1）
- 计划并执行（循环步骤 2）
- 调度 verifier 子代理到全新上下文验证（基础设施 4 + 循环验证）
- 写回状态文件（循环步骤 3/状态同步）
- 如有新偏好，更新记忆文件（基础设施 7）
- 退出，等待下一次触发（循环步骤 4）
缺失任一基础设施文件的后果：无常驻上下文文件 → 每轮重新推导项目结构；无 verifier 子代理 → 主上下文内验证，永远通过；无记忆文件 → 同一修正每周重复应用。
/goal vs /loop 区别¶
/goal |
/loop |
|
|---|---|---|
| 触发方式 | 立即执行 | 按时间表定时执行 |
| 结束条件 | 目标达成后自动停止 | 不判断完成与否，只负责准时执行 |
| 类比 | 跑一个任务 | 心跳（Heartbeat） |
| 适用场景 | 一次性但可自动判断的批量任务 | 每日重复的内容收集、监控等 |
适用条件（四条全中才值得搭）¶
- 每周以上都会重复 — 一次性活不值得
- 验证能自动化 — 测试、类型检查、Linter 能挡坏结果
- Token 预算扛得住 — Loop 反复读上下文、重试、试探
- Agent 手里有资深工程师那套工具 — 日志、能跑代码看崩哪里的环境
风险与提醒¶
- 理解鸿沟：Loop 越快交付，你没亲手写的代码和你真正搞懂的东西差距越大
- 最危险的姿态：舒舒服服接受 Loop 吐出来的一切
- Over-baking（发酵过头）：无人盯着的 Loop 也在无人盯着地犯错
- 验证永远在人手上，需要在适合的时间点具备自我验证能力