Loop Engineering --- 从"写 prompt"到"设计循环"，AI Agent 的下一次进化
"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
--- Boris Cherny, Head of Claude Code at Anthropic
一句话判断
Loop Engineering 的核心主张直接到近乎粗暴：别再手动写 prompt 了，设计一个系统来替你写。 你的角色从"每次问一句"变成"设计一个能一直问下去的循环"。这可能是 2026 年 AI 工程领域最被低估的一次范式转移。
一、背景：为什么会出现 Loop Engineering？
两条线索的汇集
Loop Engineering 是两条独立发展趋势的产物。
第一条线索：Agent 框架的内卷。 2024 年我们还在争论 LangChain vs. 裸调用 API，2025 年 Claude Code、Codex、Grok 把 tool-use 推进到了生产级水平。到 2026 年，"一个 Agent 能做什么"已经不是问题了，问题是"一个 Agent 能持续做什么"。单次会话的能力见顶后，大家开始关注跨会话的持续性。
第二条线索：人类瓶颈。 Peter Steinberger（知名 iOS 开发者，PSPDFKit 作者）2026 年 6 月的一句话在社群炸开：
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
Boris Cherny 随后在访谈中呼应：
"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
核心洞察是：人的注意力是有限资源。 一个人一天能写的 prompt 数量有上限------但一个定时循环可以无限运行。杠杆点从"写更好的 prompt"转移到了"设计更好的 prompt 生成系统"。
Addy Osmani 的正式命名
2026 年 6 月 7 日，Google 工程总监 Addy Osmani 在他的博客上发表了该领域最具影响力的文章 Loop Engineering（addyosmani.com/blog/loop-engineering/），正式为这个概念命名并系统化。他将其明确定义为：
"Replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop is a recursive goal: you define a purpose and the AI iterates until complete."
社区响应
就在 Addy Osmani 发布的同一天前后，Cobus Greyling 发起了 GitHub 仓库 cobusgreyling/loop-engineering（截至本文写作时已获 210+ star），把这个概念变成了一个包含 7 个生产级别模式、3 个 CLI 工具、安全指南和真实失败案例的完整工程体系。
这个仓库的核心主张是：
"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. For developers using Grok, Claude Code, Codex, Cursor, and other AI coding agents."
此后再也没有人把 Loop Engineering 当成一个"概念"来讨论了------它已经是一个具备工具链、模式库和生产验证的工程领域。
二、什么是 Loop Engineering？五原语 + 内存
核心定义
Loop 的本质是一个递归目标：你定义一个目的，AI 不断迭代（调用子 agent、验证、读写外部状态），直到目标完成或循环主动上交给你。
一个 loop 和一次普通会话的区别：
| 维度 | 普通会话 | Loop |
|---|---|---|
| 触发方式 | 手动输入 prompt | 定时器 / 事件自动触发 |
| 状态 | 上下文窗口（易丢失） | 持久化文件/数据库（跨轮次） |
| 范围 | 单次 task | 持续执行 + 自我调度 |
| 验证 | 人眼检查 | 子 Agent 分角色验证 |
| 自我迭代 | 无 | 基于状态文件和过去运行记录 |
五原语
Cobus Greyling 的框架将 Loop Engineering 抽象为五个构建块 + 内存：
Automations / Scheduling → 定时调度，心跳
Worktrees → 隔离执行环境
Skills → 持久化项目知识
Plugins & Connectors → 接入外部工具（MCP）
Sub-agents → 制造者/检查者分离
+ Memory / State → 跨循环持久状态1. 自动化/调度 --- loop 的心脏。没有调度，就只是一次性运行。形式包括：Grok 的 /loop 命令、Claude Code 的 scheduled tasks、GitHub Actions cron、Hermes 的 cronjob 工具。
2. Worktrees --- 当两个 loop 同时编辑同一份代码时，会出现 merge 地狱。Git worktrees（或其他隔离检出机制）让每个 agent 拥有独立的工作目录。loop 执行完后应清理 worktree。
3. Skills --- 项目意图的持久化。一个 SKILL.md 文件编码了项目约定、构建命令、代码规范、领域知识。没有 skills，loop 每次从零推导------这就是"意图债务"。
4. Plugins & Connectors（MCP） --- 只读文件系统是不够的。Connectors 让 loop 读写 Jira/Linear tickets、Slack/Discord 通知、GitHub PRs、数据库查询。MCP 已经成为这套生态的通用协议层。
5. Sub-agents（Maker / Checker 分离） --- 这是最重要的结构性模式。写代码的 agent 不能评判自己的工作。第二个 agent（不同 prompt，有时用更强模型）负责验证。这种分离是 unattended loop 能让你安心走开的唯一保障。
+ Memory/State --- 模型没有跨会话长期记忆。Loop 必须读写持久化的东西：一个 STATE.md、一个 database row、一个 GitHub Project view。好的 state 文件回答：当前在做什么？上次尝试了什么、结果如何？什么在等人工处理？
Loop 的解剖（Mermaid）
#mermaid-svg-sfqtrfxN3fmDyhJp{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-sfqtrfxN3fmDyhJp .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-sfqtrfxN3fmDyhJp .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-sfqtrfxN3fmDyhJp .error-icon{fill:#552222;}#mermaid-svg-sfqtrfxN3fmDyhJp .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-sfqtrfxN3fmDyhJp .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-sfqtrfxN3fmDyhJp .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-sfqtrfxN3fmDyhJp .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-sfqtrfxN3fmDyhJp .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-sfqtrfxN3fmDyhJp .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-sfqtrfxN3fmDyhJp .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-sfqtrfxN3fmDyhJp .marker{fill:#333333;stroke:#333333;}#mermaid-svg-sfqtrfxN3fmDyhJp .marker.cross{stroke:#333333;}#mermaid-svg-sfqtrfxN3fmDyhJp svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-sfqtrfxN3fmDyhJp p{margin:0;}#mermaid-svg-sfqtrfxN3fmDyhJp .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-sfqtrfxN3fmDyhJp .cluster-label text{fill:#333;}#mermaid-svg-sfqtrfxN3fmDyhJp .cluster-label span{color:#333;}#mermaid-svg-sfqtrfxN3fmDyhJp .cluster-label span p{background-color:transparent;}#mermaid-svg-sfqtrfxN3fmDyhJp .label text,#mermaid-svg-sfqtrfxN3fmDyhJp span{fill:#333;color:#333;}#mermaid-svg-sfqtrfxN3fmDyhJp .node rect,#mermaid-svg-sfqtrfxN3fmDyhJp .node circle,#mermaid-svg-sfqtrfxN3fmDyhJp .node ellipse,#mermaid-svg-sfqtrfxN3fmDyhJp .node polygon,#mermaid-svg-sfqtrfxN3fmDyhJp .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-sfqtrfxN3fmDyhJp .rough-node .label text,#mermaid-svg-sfqtrfxN3fmDyhJp .node .label text,#mermaid-svg-sfqtrfxN3fmDyhJp .image-shape .label,#mermaid-svg-sfqtrfxN3fmDyhJp .icon-shape .label{text-anchor:middle;}#mermaid-svg-sfqtrfxN3fmDyhJp .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-sfqtrfxN3fmDyhJp .rough-node .label,#mermaid-svg-sfqtrfxN3fmDyhJp .node .label,#mermaid-svg-sfqtrfxN3fmDyhJp .image-shape .label,#mermaid-svg-sfqtrfxN3fmDyhJp .icon-shape .label{text-align:center;}#mermaid-svg-sfqtrfxN3fmDyhJp .node.clickable{cursor:pointer;}#mermaid-svg-sfqtrfxN3fmDyhJp .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-sfqtrfxN3fmDyhJp .arrowheadPath{fill:#333333;}#mermaid-svg-sfqtrfxN3fmDyhJp .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-sfqtrfxN3fmDyhJp .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-sfqtrfxN3fmDyhJp .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-sfqtrfxN3fmDyhJp .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-sfqtrfxN3fmDyhJp .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-sfqtrfxN3fmDyhJp .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-sfqtrfxN3fmDyhJp .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-sfqtrfxN3fmDyhJp .cluster text{fill:#333;}#mermaid-svg-sfqtrfxN3fmDyhJp .cluster span{color:#333;}#mermaid-svg-sfqtrfxN3fmDyhJp div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-sfqtrfxN3fmDyhJp .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-sfqtrfxN3fmDyhJp rect.text{fill:none;stroke-width:0;}#mermaid-svg-sfqtrfxN3fmDyhJp .icon-shape,#mermaid-svg-sfqtrfxN3fmDyhJp .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-sfqtrfxN3fmDyhJp .icon-shape p,#mermaid-svg-sfqtrfxN3fmDyhJp .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-sfqtrfxN3fmDyhJp .icon-shape .label rect,#mermaid-svg-sfqtrfxN3fmDyhJp .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-sfqtrfxN3fmDyhJp .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-sfqtrfxN3fmDyhJp .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-sfqtrfxN3fmDyhJp :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} safe
risky
Schedule / Automation
Triage Skill
Read + Write STATE / Memory
Isolated Worktree
Implementer Sub-agent
Verifier Sub-agent
tests + gates
MCP / Git / Tickets
Need Human?
Action (Commit/PR)
Escalate with context
三、Harness vs. Loop：两种思维层次
Addy Osmani 明确区分了两个概念：
Agent Harness Engineering --- 一个 agent 单次运行的环境：工具集、上下文、权限、规则。harness 是沙箱。
Loop Engineering --- harness + 调度 + 持久状态 + 验证链的完整编排系统。
用汽车来类比：
- Harness = 引擎 + 变速箱 + 方向盘（一辆能开的车）
- Loop = 自动驾驶系统 + 导航 + 加油计划 + 定期保养（一个能自己跑的舰队）
他同时提出了 Factory Model ------ 构建软件的工厂系统：流水线、agents、检查、交接。Loop Engineering 是这个工厂车间的运营方式。
四、核心概念体系
Loop Engineering 的深度远不止技术架构。它提出了几个值得整个行业思考的概念：
意图债务（Intent Debt）
每次会话，agent 从零启动。任何你没说清楚的意图，agent 会用"自信的猜测"来填补。Skills 就是还债的方式------约定、构建步骤、"我们不这么做因为某次事故"写成一次，每次运行自动加载。
没有 skills 的 loop 是从零推导整个项目的每个周期。有 skills 的 loop 会产生积累效应。
理解债务（Comprehension Debt）
Loop 越快地产生代码，你就越快落后于你的代码库。更快的 loop 产生更多你没写过的代码。除非你读 loop 生产的输出，否则理解债务只会增长。
这是一个反直觉的事实：loop 不是免费的杠杆，它把认知负担从"写"转移到了"读"。
认知投降（Cognitive Surrender）
最危险的陷阱。loop 自己运行，你就停止发表意见了。Addy Osmani 的警示：
"Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking, same action, opposite result."
设计 loop 时的判断力是解药，用 loop 来逃避思考是催化剂。同样的动作，相反的结果。
编排税（Orchestration Tax）
并行 agent 协调的人力成本：review 带宽、merge 冲突、上下文切换。Worktrees 消除的是机械碰撞，但你仍然是天花板------你的 review 带宽决定了你能同时跑多少 loop，而不是工具。
五、7 个生产模式（Real Patterns）
cobusgreyling/loop-engineering 仓库定义了 7 个经过生产验证的 loop 模式，每个都有完整文档、starter 模板和成本估算。
1. Daily Triage（日常分诊）
- 节奏: 1d--2h
- 成本: 低（L1 报告 ~50k tokens/run）
- 核心: 每天起床时自动生成一份"当前哪些东西需要你注意"的报告------CI 是否红、issue 是否堆积、PR 是否搁置。L1 阶段纯报告，不做任何修改。
- 🔴 真实案例 : 仓库中的
daily-triage-report-only.md记录了 L1 先跑一周、校准 triage 准确率后再进入 L2 的完整过程。
2. PR Babysitter（PR 保姆）
- 节奏: 5--15 分钟
- 成本: 高（单次修复 ~250k tokens）
- 核心: PR 的自动看护------监测新 review comment 并自动回应最小 diff，CI 红了自动定位修复，ready to merge 时打标签提醒人。
- 🔴 真实案例 :
pr-babysitter-week-one.md记录了实际部署后的两个失败：- Day 3: 对 flaky e2e 测试产生了"无限修复循环"------loop 连续 4 次试图通过修改代码"修复"环境问题。修复方案：在 triage 中加入 flake 分类 + 硬限制最多 3 次尝试。
- Day 5: 通知疲劳------每 5 分钟在 PR 上留言"没变化"。修复方案：只在"需人工介入"时才留言。
- 最终结果：SLACK CI/REBASE 消息从每天 ~12 条降到 ~4 条，首次修复提案时间从数小时缩短到 ~25 分钟。
3. CI Sweeper（CI 清扫）
- 节奏: 5--15 分钟
- 成本: 极高（L2 ~500k tokens/run）
- 核心: 发现 CI 变红 → 定位 root cause → 生成修复。风险最高、ROI 也最高的模式之一。
- 🔴 真实案例 :
why-we-killed-ci-sweeper.md记录了第 4 天就关停 的教训：- 跳过 L1（报告期）直接上 auto-fix
- 一半运行中 verifier 和 implementer 同 session
- 没有分支 allowlist------扫到了已知红色的 feature 分支
- 没有预算限制------48 小时内烧了 ~800 万 tokens
- 挽救措施：删掉所有 CI 任务 → 切换为 event-driven（仅 main 失败触发）→ 重新启用时加了 1 周报告期 + 2M token/天预算 + 分支 allowlist
4. Dependency Sweeper（依赖清扫）
- 节奏: 6h--1d
- 成本: 中
- 核心: 自动检测过时依赖，生成安全补丁 PR。L2 只做 patch-only 更新。
5. Changelog Drafter（更新日志起草）
- 节奏: 1d 或 tag 时
- 成本: 低（L1 草稿）
- 核心: 汇总最近 commit 和 PR 标题，自动生成 changelog 草稿。被标记为"low-risk, high-ROI L1 win"。
6. Post-Merge Cleanup（合后清理）
- 节奏: 1d--6h
- 成本: 低
- 核心: Merge 后的清理------删除 feature 分支、检查遗留 TODO、更新状态文件。推荐在非高峰时段运行。
7. Issue Triage（Issue 分诊）
- 节奏: 2h--1d
- 成本: 低
- 核心: 新 issue 自动分类、打标签、分配 reviewer。L1 仅提案，不自动操作。
六、反模式与失败模式（来自真实生产环境）
Loop Engineering 的仓库包含了精心整理的故障目录。这不是理论推演，而是真实生产中踩过的坑。
十大反模式（Anti-Patterns）
| # | 反模式 | 替代方案 |
|---|---|---|
| 1 | 同一个 agent 实现和验证 | 独立的 verifier sub-agent，默认立场：REJECT |
| 2 | 没有尝试上限（无限循环修复） | 硬上限 3 次 → 带着完整上下文上报人工 |
| 3 | Triage 输出长篇叙事 | 结构化 markdown + 单行项目 + 明确建议动作 |
| 4 | L3 级别权限从第一天就开启 | L1 报告期 1 周，校准后才进 L2 |
| 5 | 多个 loop 共享无 schema 的状态文件 | 每个模式一个文件，或明确分区 + 清理规则 |
| 6 | MCP 连接器一上来就是完整写入权限 | L1 只读，信任建立后逐步开放 |
| 7 | 没有 kill switch | 每个 loop 必须在 LOOP.md 中记录暂停/停止条件 |
| 8 | 用代码修复 flake 测试 | 分诊 → 隔离 → 上报基础设施，不要修改应用代码 |
| 9 | verifier 通过就自动 merge | 显式路径 allowlist + 危险路径人工 merge |
| 10 | 没有运行日志 | 每个 loop 必须追加到 loop-run-log.md |
关键失败模式（Failure Modes）
系统按严重性分 S1（烦人）→ S2（有害）→ S3（危险）。
S1 Token Burn --- 子分钟级节奏 + 重型 sub-agent，或者空 triage 时启动了完整的 sub-agent 链。缓解：先做便宜的 triage-only，有 actionable item 再 spawn sub-agent。
S2 Infinite Fix Loop --- 同一个 PR 或 CI 任务被反复自动修复 5+ 次。原因：verifier 太弱、root cause 误判、flaky 测试被当作 regression。缓解：硬上限 3 次、verifier 用更强模型、flake 隔离。
S2 State Rot --- STATE.md 引用已合并的 PR 或关闭的 issue，loop 对"ghost item"采取行动。缓解：每轮运行先清理已关闭项目、写时间戳。
S2 Verifier Theater --- Verifier 说"过了"，CI 却红。原因：verifier prompt 太模糊（"looks good"）、没有实际跑测试、和 implementer 同模型同上下文。缓解：verifier 必须跑测试并报告输出、prompt 写"找理由拒绝"。
S2→S3 Over-Reach --- Loop 重构了不相关的模块、"修复"了设计问题、改动了禁止路径。缓解：路径 allowlist/denylist、verifier 检查改动文件范围、triage 只报信号不做发明。
七、Loop Engineering 在 Hermes Agent 中的实践
如果你在用 Hermes Agent，你其实已经在用 Loop Engineering 的某些原语了------只不过没有用这个名字。
| 原语 | Hermes 对应 |
|---|---|
| 调度 | cronjob 工具 + hermes cron CLI |
| Worktrees | hermes chat -w (worktree mode) |
| Skills | skill_manage 工具 + 自动加载 |
| Sub-agents | delegate_task 工具 |
| Memory/State | memory 工具 + session DB |
| MCP Connectors | hermes mcp 系列命令 |
Hermes 的 cronjob 系统是最直接的 loop 实现：
hermes cron create "every 1d" --prompt "Run loop-triage skill. Update STATE.md." --skills loop-triage这个命令创建了一个 Daily Triage loop：每天定时启动 → 加载 loop-triage skill → 读取 STATE.md → 分析项目状态 → 写入新状态 → 等待下个周期。
而 delegate_task 是实现 Maker/Checker 分离的关键工具：
delegate_task(
goal="Review if implementation matches spec",
toolsets=['file']
)这些不是抽象概念------它们是 Hermes 中可运行的工具。Loop Engineering 的框架帮我们理解这些原语之间的关系，以及如何安全地组合它们。
八、安全、成本与控制
分阶段上线
所有 loop 模式都推荐分阶段部署：
L1（报告期）→ 仅观察、仅报告、不动手
L2（辅助期）→ 可以提议修复、但不自动操作
L3（自助期）→ 经过 allowlist 验证后，处理低风险操作预算控制
cobusgreyling/loop-engineering 提供了三个 CLI 工具：
- loop-init --- 脚手架 starter + budget/run-log
- loop-audit --- 评估项目的"Loop Readiness Score"，检测未记录的 loop
- loop-cost --- 根据 pattern + cadence + level 估算 token 成本
bash
npx @cobusgreyling/loop-cost --pattern daily-triage --cadence 1d --level L1
# → ~50k tokens/run, 建议每日上限 100k tokens安全边界
Loop Engineering 的安全体系强调：
- Denylist --- loop 不能碰的路径（生产配置、认证凭证等）
- Allowlist --- 只有这些路径上的改动可以 auto-merge
- Human gate --- 任何中等以上风险的操作必须等待人批准
- Kill switch --- 每个 loop 必须有明确的停止条件文档
九、总结：Build the loop. Stay the engineer.
Loop Engineering 不是关于让 AI 完全取代你。恰恰相反------它要求你投入更多的人工程度。
你需要：
- 读取 loop 的输出，而不是只看成功/失败标记
- 对 loop 提议的修改保持判断，而不是"AI 改了那就这样吧"
- 定期校准 triage 质量，而不是 loop 跑起来了就不管了
- 写入技能来还债，而不是让意图债务越滚越大
Addy Osmani 在文章结尾的那句话值得反复读：
"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."
这大概也是 loop engineering 最反直觉的核心洞见：自动化程度越高，需要的工程判断力越强。
关键参考来源
- Addy Osmani --- Loop Engineering (2026-06-07)
- cobusgreyling/loop-engineering --- GitHub Repo (210+ stars)
- cobusgreyling/loop-engineering --- Concepts & Vocabulary
- cobusgreyling/loop-engineering --- Failure Modes Catalog
- cobusgreyling/loop-engineering --- Anti-Patterns
- anthropics/anthropic-cookbook --- Tool Use / Agentic Loop Pattern
- Peter Steinberger 引用 --- 见于 Addy Osmani 的 Loop Engineering 文章
- Boris Cherny 引用 --- 见于 Addy Osmani 的 Loop Engineering 文章
⚠️ 免责声明： 本文所有内容仅用于技术研究和学术交流目的，不构成任何形式的建议或指导。文中涉及的 URL、仓库信息、引用和案例均基于 2026 年 6 月 15 日的公开可查来源。具体实现可能因版本更新而变化，使用前请查阅各工具的最新官方文档。token 成本估算为近似值，实际消耗因项目复杂度而异。
关注「coft」 ，获取更多 AI 时代的最新深度思考。
