Loop Engineering（循环工程）深度解析：从提示词工程到系统工程的范式转移

概念来源：Addy Osmani、Peter Steinberger、Anthropic Boris Cherny 等，2026 年 6 月推广
核心社区讨论：Lushbinary、Kilo.ai、MindStudio、SonarSource
关键工具载体：Claude Code（/loop, /goal, /subagent）、OpenAI Codex（Automations, /goal, worktrees）

一、核心问题：提示词工程的天花板

AI Coding Agent 已经进化了两代：

第一代：Autocomplete（代码补全）

• Copilot、TabNine
• 帮助写单行/函数，但人类负责理解项目、找文件、跑测试、解读失败、决定下一步

第二代：Agent（对话式 Agent）

• Claude Code、Cursor Agent、OpenAI Codex
• 模型自己规划、调用工具、编辑文件、运行测试
• 但每次都需要人类在座位上等它干完，然后给下一个指令

天花板：当你有 20 个文件要改、5 个测试要修、3 个 PR 要开时，你不可能坐在电脑前等 agent 做完一个再指挥下一个。提示词工程（Prompt Engineering）优化的是单次交互的质量，但无法解决规模化交互的效率问题。

Loop Engineering 的答案：不再优化单次提示，而是设计一个系统去自动生成和验证提示。

二、Loop Engineering 的定义：递归目标系统

Loop Engineering is building a system that prompts your agent on a schedule and against a goal, instead of typing each prompt yourself.
—— Lushbinary

一句话定义：循环工程是构建一个按计划和目标自动提示 agent 的系统，而不是自己手动输入每个提示。

核心逻辑：

定义递归目标（一次）
    ↓
系统发现工作（自动化/定时触发）
    ↓
分配子 agent 执行（工作区隔离/并行）
    ↓
验证结果（子 agent 审查/确定性测试）
    ↓
记录状态（持久化记忆）
    ↓
决定下一步（递归循环，直到目标达成）

leverage 从单条提示的质量转移到系统设计的质量。

三、五个关键构建块 + 记忆

Loop Engineering 需要五个核心构建块，加上一个持久化记忆层：

3.1 Automations（自动化触发）——心跳

功能：按时间表自动触发 agent 执行指定任务，无需人类在场。

Claude Code 实现：/loop 命令

/loop "Read yesterday's CI failures and open issues, write findings
       to TODO.md, and draft fixes for anything labeled quick-win"
       --schedule "0 9 * * 1-5"

OpenAI Codex 实现：Automations 标签页

• 选择项目、提示词、运行频率、本地或后台工作区
• 发现问题的运行进入 Triage 收件箱
• 未发现问题的运行自动归档

关键设计：automation 可以调用 skill（$skill-name），避免把一大段指令硬编码在定时任务里。

3.2 Worktrees（工作区隔离）——并行安全

功能：让多个子 agent 同时工作而不互相踩脚。

实现：Git worktrees（Claude Code 和 Codex 都原生支持）

• 每个子 agent 获得独立的代码副本
• 修改在独立分支上，不会污染主分支
• 并行执行多个任务（修 bug + 写功能 + 重构）

关键设计：worktree 隔离是并行的前提。没有隔离，两个 agent 改同一个文件必然冲突。

3.3 Skills（项目技能库）——知识沉淀

功能：把项目知识（编码规范、构建步骤、架构约定）写成可复用的 markdown 文件，agent 每次运行时自动加载。

Claude Code 实现：.claude/skills/ 目录

# .claude/skills/triage.md
---
name: ci-triage
description: Reads CI failures and classifies them.
---
When reading CI logs, look for these patterns:
- "flaky test" → label as "flaky"
- "type mismatch" → label as "type-error"
- "timeout" → label as "infra"

OpenAI Codex 实现：skills 目录（TOML 定义）

关键设计：skill 是复用的上下文，不是一次性提示。写好一次，所有 automation 和子 agent 都能用。没有 skill，agent 每次都要重新猜项目约定。

3.4 Connectors（工具连接器）——接入现有工具链

功能：让 agent 能操作你已有的工具（GitHub、Linear、Slack、Jira、邮件等）。

实现：MCP（Model Context Protocol）

• Claude Code：hooks 触发 shell 命令
• OpenAI Codex：built-in connectors（GitHub、Linear 等）
• 自定义：通过 MCP 服务器接入任何工具

典型用法：

agent 完成修改 → connector 自动开 PR → Linear 更新 ticket → Slack 通知团队

3.5 Sub-agents（子智能体）——分工协作

功能：把一个任务拆给多个 agent，有的负责「做」，有的负责「检查」。

Claude Code 实现：/subagent 命令
OpenAI Codex 实现：TOML 定义的子 agent 配置

关键分工模式：Maker-Checker（制造者-审查者）

子 agent A（maker）:  draft the fix  →  子 agent B（checker）: review against skills & tests
     ↓                                                    ↓
  写代码/改文件                                     跑测试/检查规范
     ↓                                                    ↓
  提交草案                                          通过/拒绝 + 反馈

为什么必须分离？ 自己写代码自己检查，等于「两个乐观者达成一致」（Two optimists agreeing）。审查者必须是一个独立的 agent，用不同模型（通常更强，如 Claude Opus）和不同上下文（只读技能，不写代码）。

3.6 Memory（持久化记忆）——状态脊椎

功能：在运行之间记住「做了什么、通过了什么、还有什么没做」。

关键洞察：模型每次运行都会忘记一切。记忆必须活在磁盘上，而不是上下文窗口里。

实现方式：

• TODO.md 文件（最简单有效）
• GitHub Issues / Linear 看板
• SQLite 数据库
• 专门的 state 文件

# TODO.md
## Open
- [ ] flaky test in test/auth/login.spec.ts (CI run #4821)
- [ ] migrate billing module to new pricing API (blocked: need API key)

## Done
- [x] bump axios to patched version (PR #312, merged)
- [x] fix CSS regression in header (PR #315, merged)

为什么这个简单的东西最关键？ 因为它是整个循环的脊椎。明天早上的运行会读取今天的 TODO.md，从昨天停下的地方继续。没有它，每个 automation 都是孤立的，没有累积效应。

四、核心原语：/goal（递归目标直到验证通过）

2026 年最被讨论的 agent 原语，Claude Code 和 Codex 都实现了：

# Claude Code
/goal "All tests in test/auth pass and lint is clean"

# OpenAI Codex (CLI 0.128.0+, April 30, 2026)
codex /goal "Migrate the billing module to the new pricing API,
             keep all existing tests green"

工作机制：

1. Agent 持续执行（plan → act → observe → adjust）
2. 每次 turn 后，一个独立的 verifier 子 agent 检查目标条件是否达成
3. 条件达成 → 停止，报告完成
4. 条件未达成 → 继续，带反馈进入下一轮

关键设计：verifier 是一个更小的模型（通常用轻量模型做检查，省成本），且与 maker 分离（避免自我验证的偏差）。

五、一个完整循环的端到端示例

[每天早上 9:00]
    ↓
Automation 触发："triage CI failures and open issues"
    ↓
Skill 加载：ci-triage.md（定义分类规则）
    ↓
读取昨晚 CI 日志 + open issues + recent commits
    ↓
写入 TODO.md：
  - [ ] flaky test in test/auth/login.spec.ts
  - [ ] type mismatch in billing/api.ts
    ↓
对每个优先级高的 item：
    ↓
  打开独立 worktree（git worktree）
    ↓
  子 agent A（maker，Claude Sonnet）：draft the fix
    ↓
  子 agent B（checker，Claude Opus）：review + run tests
    ↓
  如果通过：
    - Connector 开 PR（GitHub MCP）
    - 更新 TODO.md：标记为 [x]
    - 更新 Linear ticket（Linear MCP）
  如果没通过：
    - 写反馈到 TODO.md
    - 下次 automation 重试
    ↓
[明天早上 9:00，从 TODO.md 继续]

你实际做了什么？ 设计了这个系统一次。之后没有手动提示任何步骤。这就是 Loop Engineering 的全部意义。

六、三个必须警惕的风险

Loop Engineering 不是「让 AI 全自动然后你去喝咖啡」。三个风险会随着循环变强而更严重：

6.1 Verification Debt（验证债务）

A loop running unattended is also a loop making mistakes unattended.

• 弱验证：agent 声称「完成了」但没有证据（测试没跑、lint 没过）
• 自我验证偏差：maker 和 checker 是同一个模型，容易「两个乐观者达成一致」
• 缓解：独立的 verifier 子 agent + 确定性测试门（deterministic gate）

SonarSource 的验证分层模型：

正确顺序：LLM verifier 先过滤草案 → Deterministic gate 决定能否发版。只有第一层 = Ralph Wiggum 循环（《辛普森一家》里的傻孩子，什么都信）。

6.2 Comprehension Debt（理解债务）

The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually get.

循环跑得越快，代码库增长越快，你真正理解的比例越低。一个月后，你可能不知道系统里有哪些代码是循环写的、哪些逻辑是循环加的。

缓解：

• 强制要求人类 review 合并的代码（不要 auto-merge）
• 定期「代码漫游」：让循环生成文档，但你得读
• 保持小步快跑，每个 PR 都小 enough 能人工 review

6.3 Cognitive Surrender（认知投降）

When the loop runs itself it's very tempting to stop having an opinion and just take whatever it gives back.

这是最隐蔽也最危险的风险。循环运行得如此顺畅，你逐渐放弃了自己的判断，变成「循环说什么就是什么」。

Addy Osmani 的警告：

Designing the loop is the cure when you do it with judgement and the accelerant when you do it to avoid thinking. Same action, opposite result.

设计循环本身是治愈（你深入思考了系统），但如果是为了避免思考而设计循环，那就是加速剂（你更快地放弃理解）。

七、Loop Engineering vs Prompt Engineering：范式对比

关键洞察：Prompt Engineering 和 Loop Engineering 不是替代关系，是分层关系。Loop Engineering 在 Prompt Engineering 之上，解决规模化问题。你仍然需要写好 skill（提示词工程），但 skill 被复用而不是每次重写。

八、工具现状：Claude Code vs OpenAI Codex

2026 年中，两个领先工具的 loop 原生支持：

Addy Osmani 的观察：

Once you notice the shape is identical across tools, you stop arguing about which agent is best and start designing a loop that works no matter which one you happen to be sitting in.

工具的具体命令不同，但循环的形状相同。这是 Loop Engineering 作为元技能的价值——不依赖特定工具。

九、工程启示：从「写代码」到「设计系统」

Loop Engineering 的根本转变：

工作的重心从单一的指令编写转向了系统架构的设计。

这意味着工程师的核心能力需要扩展：

9.1 新增能力要求

9.2 组织级影响

单人开发者：

• 维护一个 TODO.md + 一个每天早上运行的 triage automation
• 可以管理 2-3 倍于以往的代码量
• 但必须保持对代码的理解（避免认知投降）

团队：

• 共享 skill 库（编码规范、架构决策、安全规则）
• 循环开的 PR 需要人类 review（不可 auto-merge）
• 定期审计循环的 token 消耗（避免账单惊喜）

企业：

• 需要专门的「Loop 工程师」角色（设计、监控、优化循环）
• 安全/合规要求：所有循环操作必须有审计日志（connector 的副作用）
• 成本治理：自动化调度可以烧掉大量 token（尤其是带 verifier 的循环）

9.3 何时用 Loop，何时不用

适合 Loop：

• 重复性维护（CI 失败 triage、依赖更新、文档同步）
• 大规模重构（已知模式、可验证完成条件）
• 测试补全（覆盖率目标、可运行验证）
• 监控/告警响应（自动诊断、自动修复、人工确认）

不适合 Loop（仍需人工）：

• 架构设计（需要创造性判断）
• 安全关键代码（必须人类审查）
• 需求模糊的任务（目标无法精确定义）
• 一次性探索性工作（设置循环的成本高于手动做）

十、总结：Loop Engineering 是 Agent 时代的 DevOps

Loop Engineering 不是新概念，它是AI Agent 时代的 DevOps：

• DevOps 把「手动部署」变成「自动化部署流水线」
• Loop Engineering 把「手动提示 agent」变成「自动化 agent 编排系统」

核心公式：

Loop Engineering = 自动化触发 + 工作区隔离 + 项目技能 + 工具连接器 + 子 agent 协作 + 持久化记忆

三个铁律：

1. 验证不能丢：没有确定性 gate 的循环只是自动化（automation），不是工程（engineering）
2. 记忆必须在磁盘上：上下文窗口会忘，state 文件不会
3. 工程师不能投降：设计循环需要判断，运行循环也需要判断

最终，Loop Engineering 把人类从「操作员」升级为「系统设计师」——你设计的是让 agent 能持续、可靠、可验证地工作的机制，而不是写一条条提示去指挥它。

参考来源：

• Addy Osmani: https://addyosmani.com/blog/loop-engineering/
• Lushbinary: https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/
• SonarSource: https://www.sonarsource.com/blog/loop-engineering-without-verification-is-just-automation/
• Kilo.ai: https://kilo.ai/articles/what-is-loop-engineering
• MindStudio: https://www.mindstudio.ai/blog/what-is-loop-engineering-ai-coding-agents

#LoopEngineering #AIAgent #ClaudeCode #OpenAICodex #自动化 #提示词工程 #软件开发 #DevOps #小凯