"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 是两条独立发展趋势的产物。
第一条线索：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 生成系统"。
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 的本质是一个递归目标：你定义一个目的，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 文件回答：当前在做什么？上次尝试了什么、结果如何？什么在等人工处理？
flowchart LR A["Schedule / Automation"] --> B[Triage Skill] B --> C["Read + Write STATE / Memory"] C --> D[Isolated Worktree] D --> E[Implementer Sub-agent] E --> F["Verifier Sub-agent<br/>tests + gates"] F --> G["MCP / Git / Tickets"] G --> H{Need Human?} H -->|safe| I["Action (Commit/PR)"] H -->|risky| J[Escalate with context] I --> A J --> A
Addy Osmani 明确区分了两个概念：
Agent Harness Engineering — 一个 agent 单次运行的环境：工具集、上下文、权限、规则。harness 是沙箱。
Loop Engineering — harness + 调度 + 持久状态 + 验证链的完整编排系统。
用汽车来类比：
他同时提出了 Factory Model —— 构建软件的工厂系统：流水线、agents、检查、交接。Loop Engineering 是这个工厂车间的运营方式。
Loop Engineering 的深度远不止技术架构。它提出了几个值得整个行业思考的概念：
每次会话，agent 从零启动。任何你没说清楚的意图，agent 会用"自信的猜测"来填补。Skills 就是还债的方式——约定、构建步骤、"我们不这么做因为某次事故"写成一次，每次运行自动加载。
没有 skills 的 loop 是从零推导整个项目的每个周期。有 skills 的 loop 会产生积累效应。
Loop 越快地产生代码，你就越快落后于你的代码库。更快的 loop 产生更多你没写过的代码。除非你读 loop 生产的输出，否则理解债务只会增长。
这是一个反直觉的事实：loop 不是免费的杠杆，它把认知负担从"写"转移到了"读"。
最危险的陷阱。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 来逃避思考是催化剂。同样的动作，相反的结果。
并行 agent 协调的人力成本：review 带宽、merge 冲突、上下文切换。Worktrees 消除的是机械碰撞，但你仍然是天花板——你的 review 带宽决定了你能同时跑多少 loop，而不是工具。
cobusgreyling/loop-engineering 仓库定义了 7 个经过生产验证的 loop 模式，每个都有完整文档、starter 模板和成本估算。
daily-triage-report-only.md 记录了 L1 先跑一周、校准 triage 准确率后再进入 L2 的完整过程。pr-babysitter-week-one.md 记录了实际部署后的两个失败：
why-we-killed-ci-sweeper.md 记录了第 4 天就关停的教训：
Loop Engineering 的仓库包含了精心整理的故障目录。这不是理论推演，而是真实生产中踩过的坑。
| # | 反模式 | 替代方案 |
|---|---|---|
| 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 |
系统按严重性分 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 只报信号不做发明。
如果你在用 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 工具：
npx @cobusgreyling/loop-cost --pattern daily-triage --cadence 1d --level L1
# → ~50k tokens/run, 建议每日上限 100k tokens
Loop Engineering 的安全体系强调：
Loop Engineering 不是关于让 AI 完全取代你。恰恰相反——它要求你投入更多的人工程度。
你需要：
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 最反直觉的核心洞见：自动化程度越高，需要的工程判断力越强。
⚠️ 免责声明： 本文所有内容仅用于技术研究和学术交流目的，不构成任何形式的建议或指导。文中涉及的 URL、仓库信息、引用和案例均基于 2026 年 6 月 15 日的公开可查来源。具体实现可能因版本更新而变化，使用前请查阅各工具的最新官方文档。token 成本估算为近似值，实际消耗因项目复杂度而异。
关注公众号「coft」，获取更多 AI 时代的深度思考。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。