文章目录
- 0.前言
- [1.什么是 Loop Engineering？](#1.什么是 Loop Engineering？)
- 2.核心理念转变
- [3.Loop Engineering 的六大核心模块](#3.Loop Engineering 的六大核心模块)
- 4.关键设计模式：分离"生成者"与"验证者"
- 5.一个典型的Loop工作流示例
- [6.Loop Engineering 的三个层次](#6.Loop Engineering 的三个层次)
- [7.Harness + Loop：完整的工作流体系](#7.Harness + Loop：完整的工作流体系)
- [8.Loop Engineering 的三个必须警惕的问题](#8.Loop Engineering 的三个必须警惕的问题)
- 9.小结
- 参考文献
0.前言
最近，AI 圈的新概念越来越多：Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering。
它们看起来像是在不断造词，但背后其实对应着一个很明显的变化：AI 的任务单位变了。
过去，我们更关心"怎么让模型回答好一个问题"，所以重点是提示词。后来发现，光把 Prompt 写得更长、更细，并不能解决可靠性问题。模型还需要正确的历史记录、外部数据、工具权限、记忆状态和任务目标，于是有了 Context Engineering。
再往后，AI 开始真正调用工具、执行代码、访问文件、操作系统，工程重点又从"给模型什么信息"，转向"如何让模型在真实环境里安全、稳定地行动"。这就是 Harness Engineering 所关注的运行环境、沙箱、权限、评测和可观测性。
而 Loop Engineering 又往前走了一步。
它关注的已经不是一次 Agent Run 能不能成功，而是系统能否在更长时间里持续推进：发现任务、制定计划、执行、验证、修复失败、记录状态，然后进入下一轮，直到满足停止条件。
所以，这些概念并不是简单的替代关系，而是 AI 工程控制范围不断外扩：
Prompt 是一句话，
Context 是一组信息，
Harness 是一套运行环境，
Loop 是一个持续工作的系统。当然，这里面确实存在命名竞争和行业炒作，但工程范式的变化也是真实的。
未来真正稀缺的，可能不只是会写 Prompt 的人，而是能把模型、工具、状态、评测、安全和反馈回路连接起来，搭建可靠 AI 工作系统的人。
1.什么是 Loop Engineering？
Loop Engineering（循环工程） 是指设计一套让AI Agent能够自主迭代、自我修正、持续运行直至目标完成的系统。
Claude Code负责人Boris Cherny说："我不再给Claude写提示词了。我写好一个个运行着的循环，让循环去提示Claude并让它自己搞清楚该做什么。我的工作就是写循环。"
2.核心理念转变
| 传统模式 | Loop Engineering |
|---|---|
| 人写提示词 → Agent执行一次 → 人读结果 → 人写下一轮 | 人设计循环 → 循环自动触发Agent → Agent自主多轮迭代 → 循环管理状态 |
| 全程握住Agent | 系统自己跑，人是"设计师" |
3.Loop Engineering 的六大核心模块
根据 Addy Osmani 的系统梳理，一个完整的Loop需要六样东西：
| 模块 | 作用 | 在Claude Code/Codex中的体现 |
|---|---|---|
| Automations | 按计划自动触发，独立完成发现和分类 | /loop定时任务、cron调度、/goal持续运行直到条件成立 |
| Worktrees | 让并行运行的多个Agent互不干扰 | git worktree、isolation: worktree配置 |
| Skills | 把项目知识写下来，避免Agent每次都靠猜 | SKILL.md定义技能 |
| Plugins & Connectors | 把Agent接入真实工具（Issue Tracker、数据库、Slack） | 基于MCP协议构建 |
| Sub-agents | 拆分工种：一个负责生成，另一个负责检查 | 双重Agent架构：写代码的和检查代码的分开 |
| Memory | 记录"已完成什么"和"下一步是什么" | Markdown文件或Linear看板，存在磁盘上（不是上下文里） |
4.关键设计模式：分离"生成者"与"验证者"
Loop 中最有用的结构设计是：把写代码的和检查代码的拆成两个Agent。
- 让写代码的Agent评审自己的代码，它会对自己"太好说话"
- 一个拿着不同指令、有时甚至是不同模型的第二个Agent，能抓住第一个Agent自己没意识到的问题
- 这个你真正信任的验证者，是你敢走开的唯一原因
这也是/goal命令的核心逻辑：每一轮结束后，一个独立的小模型检查是否完成，而不是让写代码的Agent自己打分。
5.一个典型的Loop工作流示例
作者展示了自己最常使用的一个Loop：
每天早上，一个定时任务在代码仓库上自动启动。它调用一个"分诊技能"，翻查昨天的CI失败记录、Open Issue、最近谁提交了什么代码。发现值得修改的问题后，这个Loop会自动：
- 开一个独立工作区（worktree）
- 派一个Sub-agent去起草修复方案
- 派第二个Sub-agent拿着项目技能文档和现有测试去审查方案
- 如果审查通过，连接器会自动开PR、更新工单
- Loop搞不定的东西，放到Triage收件箱里等人处理
结果：从发现、分配、修复、审查到开PR，全程无需手动输入一个字。
6.Loop Engineering 的三个层次
| 层次 | 描述 | 当前状态 |
|---|---|---|
| 第一层 | 单Agent内部的迭代循环 | 社区讨论焦点，Boris Cherny描述的场景 |
| 第二层 | 多Agent之间的协作循环 | 部分技术团队在探索 |
| 第三层 | 人与Agent网络共同构成的组织级循环 | 明略科技Octo宣称已在生产环境运行 |
7.Harness + Loop：完整的工作流体系
两者的关系可以这样理解：
| 概念 | 角色 | 比喻 |
|---|---|---|
| Harness Engineering | 约束与护栏 | 告诉Agent"你不能越线"，确保安全可控 |
| Loop Engineering | 驱动力与自动执行 | 告诉Agent"往那个方向一直跑"，持续迭代直到目标完成 |
Harness让AI"套上缰绳"，Loop让AI"自己跑起来"------两者结合，才是一个完整的生产级AI系统。
从技术演进路径来看：
Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering
好好说话 提供信息 设规则和约束 让系统自己跑8.Loop Engineering 的三个必须警惕的问题
Addy Osmani 明确指出，Loop 虽好，但要注意三个问题：
| 问题 | 说明 | 应对 |
|---|---|---|
| 验证还是你的活 | Loop说"完成了"，不证明真完成了 | 你依然是代码质量的最终负责人 |
| 理解债务会滚雪球 | Loop产出越快，代码和人能理解的差距越大 | 主动去读、去思考Loop产出的东西 |
| 认知投降 | Loop跑得太顺，你就不再自己判断了 | 同一种行为，可能得到相反结果------看你是用Loop辅助思考，还是用Loop逃避思考 |
Boris Cherny说"我的工作是写Loop"------这句话没说工作减少，说的是工作难点的变化。
9.小结
| 维度 | Harness Engineering | Loop Engineering |
|---|---|---|
| 核心问题 | 如何让Agent安全、可控地运行？ | 如何让Agent自动、高效地工作？ |
| 核心手段 | 约束、护栏、反馈回路、检查点 | 自动触发、任务分配、验证机制、状态记忆 |
| 关键组件 | 上下文工程、架构约束、熵抗机制 | Automations、Worktrees、Skills、Sub-agents、Memory |
| 角色比喻 | "马具" | "自动驾驶系统" |
| 企业价值 | 让AI Agent可落地、可审计、可回滚 | 让AI Agent可扩缩、可并行、可长期运行 |
展望未来，正如Google Cloud AI总监 Addy Osmani 所言："Loop越强，你得越清醒。" 设计Loop是大势所趋，但要保持思考，像一个还要继续做工程师的人一样搭建系统，而不是去做只会点"开始键"的人。