Loop Engineering 学习笔记
Loop Engineering 学习笔记
Loop Engineering（循环工程）是 2026 年 AI 工程化的最新范式，由 Google Cloud AI 工程总监 Addy Osmani 系统性定义。它坐在 Harness 的上一层楼——Harness 负责武装单次 Agent 运行，Loop 则设计一套系统让 Agent 自动化、循环地执行任务。工程师的角色从"驾驶员"转变为"交通系统设计师"。
概念起源
2026 年年中，Claude Code 创始人 Boris Cherny 公开表示已不再手动输入提示词——"我的工作变成了写循环"。同期，Addy Osmani 发表长文系统性定义了 Loop Engineering，给出最精准的本质定义：
Loop Engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
Loop Engineering 不是取代 Prompt Engineering，而是终结"人肉喂指令"——将一次次的 Prompt → 等待 → 阅读 → 再 Prompt 的线性流程，升级为可自动发现任务、分配执行、验证结果、决定下一步的循环系统。
四阶演进
从 Prompt 到 Loop，AI 工程化经历了四个阶段的认知递进：
| 阶段 | 管什么 | 比喻 | 人类角色 |
|---|---|---|---|
| Prompt Engineering | 管"一句话" | 教练 | 告诉模型做什么 |
| Context Engineering | 管"一扇窗" | 图书管理员 | 窗口里放什么信息 |
| Harness Engineering | 管"一次跑" | 工具制造者 | 单次运行的约束和边界 |
| Loop Engineering | 管"一直跑" | 交通系统设计师 | 调度系统让 Agent 自主循环 |
关键洞察：Prompt 没有死，只是从"人的核心工作"变成了 Loop 系统里的一个基础零件。未来 AI 工程的竞争，不再是谁的 Prompt 写得巧，而是谁的 Loop 闭环更完整、谁的自动化更彻底。
Loop 的特征
一个真正的 Loop 系统具备三个标志性特征：
- 在定时器上跑：由 Cron、CI/CD 事件、工单触发等机制自动激活，而非人工手动启动。
- 孵化小帮手（Sub-agents）：主 Loop 可动态生成子 Agent 处理专项任务，实现角色分离。
- 自我喂食：一轮的输出作为下一轮的输入，形成持续的学习和改进循环。
五大工作流
Addy Osmani 定义了 Loop 的五个核心工作流阶段：
发现（Discovery）
Agent 自动找活，而非人喂活。触发源包括：
- 定时任务：Cron 定时扫描 CI 失败、未关闭的 Issue、过期的 TODO。
- 事件驱动：Git Push、PR 创建、工单新增、客服反馈等事件自动触发。
- 消息监听：Slack / 飞书消息中的关键词触发。
交付（Handoff）
隔离环境，避免并行冲突。核心机制：
- Git Worktree：每个任务在独立的 Git Worktree 中执行，不影响主干分支。
- 沙箱隔离：Agent 在受限环境中运行，限制文件系统和网络访问。
- 并行支持：多个 Loop 实例可同时处理不同任务，互不干扰。
验证（Verification）
最关键环节。必须有一个能说"不"的检查机制：
- 独立审查者（Evaluator）：由另一个 Agent（甚至不同模型）独立审查输出，避免"自我催眠"。
- Maker-Checker 原则：生成者与评判者必须是不同的 Agent。
- 态度分离：评判者应被设定为"怀疑论者"，默认代码是坏的，除非被证明能跑。
- 自动化验证：编译通过 + 测试通过 + Lint 通过 = 基本合格。
持久化（Persistence）
状态写入磁盘，而非仅存在上下文窗口中：
- 状态文件：任务进度、执行结果写入本地文件。
- 看板集成：自动更新 Jira / GitHub Projects 的任务状态。
- Git 提交：所有变更以 Git Commit 形式持久化，支持回滚和审计。
调度（Scheduling）
自动触发，让循环真正转起来：
- 本地调度：
/loop命令，需要开发机保持在线。 - 云端调度：CI/CD 平台（GitHub Actions、GitLab CI）或云函数，关机也能持续运行。
- 混合调度：本地处理快速迭代任务，云端处理长时间运行任务。
六大组件
Addy Osmani 披露了 Loop 体系的"5+1"核心架构：
1. Automations（自动触发）
发动机，挂在时间表或触发器上。支持定时任务、消息监听、CI/CD 事件、工单新增等多场景自动触发，让 Agent 从"被动待命"变成"主动开工"。
2. Worktrees（工作隔离）
隔离层，Git Worktree 防止并行写入冲突。每个 Loop 实例在独立的 Worktree 中工作，完成后通过 PR 合并回主干。
3. Skills（技能库）
知识库（SKILL.md），固化项目知识，偿还"意图债"。将团队的编码规范、架构约定、最佳实践编码化，Agent 按需加载而非全部塞入上下文。
4. Plugins & Connectors（连接器）
连接器，通过 MCP 协议连接外部世界：
- Issue Tracker（Jira、GitHub Issues）
- 数据库（MySQL、PostgreSQL）
- 消息平台（Slack、飞书）
- CI/CD 平台（GitHub Actions）
5. Sub-agents（子 Agent）
角色分离，最核心的分离是生成者（Generator）与评判者（Evaluator）：
- 生成者：负责代码生成、文档编写等创造性任务。
- 评判者：负责代码审查、测试验证等质量把控任务。
- 协调者：负责任务分配和进度管理。
6. Memory（持久记忆）
持久化状态，写在磁盘上。Agent 会忘，仓库不会。关键记忆包括：
- 已完成任务的历史记录和决策理由。
- 反复出现的错误模式和解决方案。
- 项目的架构决策记录（ADR）。
Maker-Checker 原则
Loop 最大的风险在于**"自我催眠"**——写代码的 Agent 无法客观评价自己的代码。必须引入独立的评判者：
| 维度 | 要求 |
|---|---|
| 结构分离 | 生成者与评判者必须是不同的 Agent（甚至不同的模型） |
| 态度分离 | 评判者应被设定为"怀疑论者"，默认代码是坏的，除非被证明能跑 |
| 工具支持 | 利用 /goal 等机制，让 Fresh Model 判定任务是否完成 |
| 验证层级 | 编译通过 → 测试通过 → 独立 Agent 审查 → 人工抽检 |
实战案例
Addy Osmani 的个人 Triage Loop
个人级 Loop 的典型工作流：
- 每天早晨自动读取 CI 失败报告和未关闭的 Issue。
- 为每个任务开启独立的 Git Worktree。
- Agent 修复问题并提交 PR。
- 独立 Evaluator Agent 审查 PR。
- 通过的 PR 自动合并，结果推送到收件箱供人工快速审阅。
Stripe 的 Minions（企业级）
Stripe 的 Minions 系统是企业级 Loop 的标杆：
- 规模：每周合并 1,300+ PR。
- 核心设计：确定性 Orchestrator 备齐上下文，LLM 只负责写代码；硬编码 Pipeline 跑 Linter 和测试。
- 关键洞察：不让 LLM 做编排决策，只让它在明确的上下文中执行——确定性流程 + 非确定性推理的组合。
调度层级对比
| 层级 | 机制 | 适用场景 | 限制 |
|---|---|---|---|
| 本地 | /loop 命令 | 快速迭代、开发调试 | 需开发机在线 |
| CI/CD | GitHub Actions / GitLab CI | 事件触发、定时任务 | 受 CI 平台限制 |
| 云端 | 云函数 / Routines | 长时间运行、无人值守 | 成本需监控 |
代价与风险
Loop Engineering 并非银弹，过度自动化带来四类核心风险：
| 风险 | 表现 | 缓解策略 |
|---|---|---|
| 验证债 | 自动化产出堆积，无人验证，错误安静积累 | 定期人工抽检、设置覆盖率门槛、独立 Evaluator |
| 理解腐烂 | 代码在长，但工程师脑子里的地图停了，不再理解项目细节 | 定期代码走读、Agent 生成变更摘要供人阅读 |
| 认知投降 | 循环太可靠，人懒得有意见，外包了判断力 | 保留关键决策的人工审批节点 |
| Token 失控 | 循环空转或重试导致账单爆炸 | 设置 Token 预算上限、监控每轮消耗 |
核心警示：正如 Addy Osmani 所强调的——验证责任仍然在于人，AI 的输出仅是声明（claim），而非证明（proof）。
第一个 Loop 搭建步骤
从零构建一个最小可用的 Loop 系统：
- 跑一个
/loop定时任务：设定触发频率（如每 30 分钟）。 - 让它读取 CI/Issue 做 Triage（发现阶段）：自动扫描未处理的任务。
- 加状态文件（记忆持久化）：记录已处理任务和处理结果。
- 加 Evaluator（如
/goal）：让独立的审查者能说"不"。 - 加 Worktree（隔离执行）：支持并行处理多个任务。
常见误区与踩坑
| 误区 | 问题 | 正确做法 |
|---|---|---|
| 没有 Evaluator | Agent 自我审查流于形式，"自我催眠" | 生成者和评判者必须分离 |
| Loop 无终止条件 | 循环空转，Token 账单爆炸 | 设置最大迭代次数、Token 预算和超时机制 |
| 所有任务都自动化 | 高风险操作无人审批 | 关键操作（删除、部署、权限变更）保留人工确认 |
| 不监控 Token 消耗 | 月底账单"惊喜" | 实时监控每轮 Token 消耗，设置预算上限和告警 |
| 忽视理解腐烂 | 工程师逐渐失去对项目细节的掌控 | 定期代码走读，Agent 输出变更摘要供人阅读 |
总结
Loop Engineering 的本质是将 AI 工程化的杠杆从"优化单次输出"升级为"设计可持续运行的系统"。它不是让 Prompt 过时，而是让 Prompt 成为系统的一部分；不是让工程师失业，而是让工程师从"驾驶员"进化为"交通系统设计师"。一个成熟的 Loop 系统需要同时解决自动化（让 Agent 跑起来）、验证（确保跑得对）、记忆（记住跑过什么）和成本控制（别让账单爆炸）四个维度的工程挑战。
参考资料
- 《Loop Engineering 橙皮书》
- Addy Osmani《Loop Engineering》长文（Google Cloud AI，2026）
- Boris Cherny & Peter Steinberger 关于 Claude Code 和 Loop 的访谈
- Stripe Minions 系统技术分享