什么是 Loop Engineering？AI Coding 正在从 Prompt 走向 Loop

最近在 AI Coding 圈里，Loop Engineering 这个词突然火了。

有两句话很能概括这个变化。

Peter Steinberger 在 X 上说：

不要再一轮一轮手动提示编码智能体，而要设计循环来提示它们。

据 Rohan Paul 转述，Claude Code 负责人 Boris Cherny 也说过类似的话：

我不再只是 prompt Claude，我运行的是 loop，loop 会提示 Claude 并决定下一步做什么。

第一次看到这类说法，可能会觉得：是不是又来了一个新名词？

但如果你已经在工作里用过 ChatGPT、Claude、Codex、Cursor、MCP、Agent、自动化脚本，甚至已经开始写 AGENTS.md、CLAUDE.md，就会发现它其实没那么玄。

它更像是 AI 使用方式走到某个阶段后，自然长出来的一层总结：

AI 正在从“问答工具”，变成“可以被放进真实流程里持续运行的工程系统”。

这也是我理解 Loop Engineering 的核心。

---

从 Prompt 到 Loop：AI 使用方式的四次工程化升级

最开始，我们只是把 AI 当成问答工具。

帮我解释这个概念。
帮我写一段代码。
帮我优化这篇文章。

后来发现，prompt 写得越清楚，模型效果越好。于是我们开始给模型设角色、写格式、补约束：

你是一名资深后端工程师……
请按以下格式输出……
请先分析再给结论……

这时候关注的是 Prompt Engineering：

这一轮怎么问得更好？

再后来，任务变复杂了。模型不知道项目上下文，不知道代码结构，不知道团队规范，也不知道测试命令。于是我们开始沉淀：

AGENTS.md
CLAUDE.md
README.md
开发规范
测试说明
模块说明

这其实已经进入了 Context Engineering：

让模型看到正确的材料。

继续往后，我们不满足于让 AI 只是回答问题，而是希望它真正干活。于是开始接入：

MCP / Tool / CLI / Shell / Git
代码平台 / 需求平台 / 日志平台 / 监控平台

这时 AI 有了外部能力，可以读取真实系统、调用工具、执行命令。

但只接入工具还不够。真实工作不是一步完成的，研发任务里会有需求评审、方案设计、任务拆解、编码、测试、CR、发布、监控等多个阶段。所以我们开始把模型、上下文、工具、数据和流程编排到一起，让 AI 不只是“会调用工具”，而是能在一套受控流程里执行任务。

这就是 Harness Engineering 关心的事：

让 AI 在一个有权限、有约束、可观察、可接管的系统里执行。

再往后，新的问题出现了：

它可能改了不该改的文件；
它可能没跑测试就说完成了；
它可能自己判断自己没问题；
它可能在错误方向上反复重试；
它可能忘了前面已经做过什么。

于是我们会继续补两类东西。

一类是验收机制：Review、Checker、Eval、lint、类型检查、安全扫描。它们解决的是：Agent 做完之后，凭什么说结果可靠？

另一类是运行约束：文件权限、工作区隔离、外部访问、超时、重试次数、人工批准。它们解决的是：Agent 执行过程中，能做什么、不能做什么、出问题时怎么停下来？

再加上状态记录，Agent 才不只是跑一段命令，而是能带着证据、边界和历史继续推进。

这时候，一个更本质的问题就出现了：

为什么还需要我一轮一轮介入？
能不能把触发、执行、验证、修正、记录、升级人工这些动作，
设计成一个持续运行的系统？

这就是 Loop Engineering 要解决的问题。

Prompt、Context、Harness、Loop 不是替代关系，而是逐层叠加：Prompt 解决表达，Context 解决信息，Harness 解决执行，Loop 解决持续推进。

---

Loop Engineering 到底是什么？

我的定义是：

Loop Engineering 不是某个 /loop 或 /goal 命令，而是设计一个让 AI 能围绕目标持续运行、持续验证、持续修正，并在必要时让人介入的工作系统。

普通 prompt 更像是：

人问 → AI 答

Agent Workflow 更像是：

人给任务 → AI 按步骤执行 → 人检查结果

而 Loop Engineering 更像是：

事件触发
→ AI 接单
→ 加载上下文
→ 调用工具执行
→ 验证结果
→ 写入状态
→ 根据反馈继续、修正、停止或升级人工
→ 新反馈再次进入循环

所以它关注的不是某一次回答是否漂亮，而是这个系统能不能持续做正确的事：

能不能发现任务？
能不能看到真实上下文？
能不能调用合适工具？
能不能检查结果？
失败后能不能修正？
关键节点能不能让人接管？
所有过程能不能被追踪和审计？

这也是为什么我不建议把 Loop Engineering 理解成“让 AI 全自动替代人”。

更准确地说，它的目标是：

让 AI 在一个可控、可验证、可追踪、可接管的系统里推进工作。

---

Loop 跑起来，需要 5+1 个基础件

Addy Osmani 在《Loop Engineering》里提到，一个有效的 loop 通常需要五类 primitive，以及一个记录状态的地方。

放到研发场景里，可以先按这个 5+1 框架理解：

Automations：自动触发、定时扫描、监听变化
Worktrees：隔离工作区，避免多个 Agent 互相污染
Skills：沉淀项目知识、开发规范、测试命令、发布流程
Plugins / Connectors：连接需求、代码、CI/CD、日志、监控等平台
Sub-agents：分析、开发、Review、测试、安全等角色分工
State：记录任务状态、执行日志、失败原因、风险和下一步

这里要注意：5+1 是 Loop 的基础骨架，不是一张完整的平台架构图。

比如 Eval / Checker 可以看成专门负责验收的 Sub-agent 及其配套检查；Human Gate 是高风险动作前的人类确认机制；Agent 看板 / Control Plane 则是研发场景里为了观察、授权、暂停、接管和审计而补出来的干预层。

所以更清楚的说法是：

5+1 是 Loop 的基础骨架；
Eval、Human Gate、Control Plane 是研发落地时长出来的工程增强；
Harness 则贯穿整个 Loop，为运行提供权限、隔离、超时、重试和人工批准。

这几个概念不要混成一堆。

否则 Loop Engineering 很容易被讲成一个“万能 Agent 平台”，听起来很大，但落地时不知道从哪里开始。

---

研发流程，本来就是一个 Human Loop

其实研发同学并不陌生 Loop。

我们日常工作中的研发流程大概是：

需求 / Bug 进入需求平台
→ 需求评审、系统分析、任务拆解
→ 拉分支开发
→ 提交 PR
→ 代码 CR
→ 测试验证和回归
→ 预发、灰度、生产发布
→ 观察日志、指标、告警、用户反馈
→ 异常排查、回滚或创建新问题
→ 新问题再次进入需求池

这套流程天然就是一个 Loop。

只不过今天推动这个循环的主要还是人：

有人看需求；
有人拆任务；
有人开发；
有人 CR；
有人测试；
有人发布；
有人看监控；
有人把问题重新录入需求平台。

传统团队靠流程、文档、老同学经验和管理制度保证这个循环能持续运转。

Loop Engineering 要做的事情，不是推翻这套流程，而是把其中可自动化、可验证、可回滚的部分逐步 Agent 化。

所以它不是“AI 替代研发流程”，而是“AI 进入研发流程”。

也不是“一键完成从需求到上线”，而是先把流程里那些稳定、重复、有明确验收标准的环节变成 Agent 可以持续推进的小闭环。

---

一个需求进入后，Agent Loop 如何跑起来？

如果只讲组件，Loop Engineering 很容易变成一堆名词。

更容易理解的方式，是把它放回一条真实研发链路里看。

假设需求平台里出现了一个新的研发需求，一个比较完整的 Agent Loop 可能是这样运行的：

1. 定时调度发现新需求
2. 加载需求背景、历史讨论、相关代码和团队规范
3. 分析需求，拆解开发子任务、风险点和验收标准
4. 多个 Code Agent 在隔离工作区中并行开发
5. Checker Agent 检查代码、测试、构建、覆盖率和安全风险
6. 满足条件后推进到预发、灰度或发布准备，并观察结果
7. 将执行日志、验证证据、失败原因和下一步写回状态系统
8. 新反馈再次进入需求池，触发下一轮循环

这条链路里，5+1 primitive 分别在不同位置发挥作用：

Automations：发现新需求，或监听 PR、CI、告警变化
Skills：沉淀需求分析方法、代码规范、测试命令和验收标准
Sub-agents：分析 Agent、拆解 Agent、Code Agent、Review Agent、Checker Agent
Worktrees：让多个 Code Agent 在隔离工作区里并行开发
Connectors：连接需求平台、代码平台、CI、通讯工具、日志和监控平台
State：记录阶段、证据、失败原因、风险和下一步

而 Harness、Eval、Human Gate 负责把这个过程“管住”：

Harness：控制权限、隔离、超时、重试、外部访问和人工批准
Eval / Checker：验证 Agent 的结果是否真的可靠
Human Gate：高风险决策、发布动作、不可逆操作必须交还给人

这时人和 Agent 的分工会变得更清楚：

Agent 负责推进流程；
Skill 负责沉淀经验；
Connector 负责连接真实系统；
Checker 负责验证证据；
State 负责记录上下文；
人负责高风险决策和最终责任。

一句话：

Agent 负责推进状态，人负责定义边界。

---

设计 Loop 时，我们真正要做什么？

Loop Engineering 不只适用于编码，也适用于需求分析、文档生成、测试回归、代码 Review、告警处理、数据分析等场景。

而且 Loop 通常是嵌套的。

比如在一个大的研发交付 Loop 里，可以再拆出：

需求分析 Loop
PRD 设计 Loop
代码开发 Loop
代码 Review Loop
测试回归 Loop
告警处理 Loop

大 Loop 管端到端流程，小 Loop 管单个环节内部的迭代。内层 Loop 的输出，是外层 Loop 的输入；内层 Loop 的异常，也可能需要升级到外层处理。

所以设计 Loop 时，不是先问“能不能全自动”，而是先问这几个问题。

1. 从哪个最小闭环开始？

不要一上来就做“从需求到上线全自动”。

更好的起点通常是：

自动扫 CI 失败并生成排查报告；
自动扫 PR 并做第一轮 Review；
自动根据需求生成任务拆解和验收标准；
自动跑测试并把失败原因写回任务；
自动整理线上告警、日志和影响范围。

这些场景有清晰输入、清晰输出、清晰验收标准，也更容易做人工接管。

2. 状态机怎么设计？

Loop 不是“while true 调模型”。

真正重要的是状态推进：

待发现
→ 待分析
→ 待执行
→ 待验证
→ 待人工确认
→ 已完成
→ 已失败 / 待重试 / 已升级人工

没有状态机，Agent 就只是在连续对话；有了状态机，Agent 才是在推进工作。

3. 哪些动作必须 Human Gate？

不是所有动作都应该交给 AI 自动执行。

比如：

生产发布；
删除数据；
大规模重构；
影响权限或安全策略；
跨团队接口变更；
高成本或不可逆操作。

这些节点应该默认需要人确认。

4. 边界和成本怎么控制？

Loop 一旦持续运行，就必须有边界。

至少要定义：

最长执行时间；
最大重试次数；
最大 token / 成本预算；
允许访问的目录和工具；
允许修改的文件范围；
失败后是否回滚；
什么时候必须停止并升级人工。

没有这些约束，Loop 很容易从“自动化”变成“自动失控”。

5. 工程资产怎么沉淀？

长期看，真正有价值的不是某一次 prompt，而是沉淀下来的工程资产：

Skills：项目规范、常见任务打法、测试命令、发布流程
Connectors：需求平台、代码平台、CI/CD、日志、监控、通讯工具
Evals：质量门禁、安全检查、覆盖率要求、回归标准
State：任务进展、历史决策、失败原因、验证证据

这也是为什么 Loop Engineering 比 Prompt Engineering 更接近真实工程。

Prompt 更像输入技巧，而 Loop 更像系统设计。

---

两个容易踩的误区

误区一：把 Loop 理解成“更长的 prompt”

Loop 不是把提示词写得更长。

更长的 prompt 仍然只是在解决“这一轮怎么问”。

Loop 解决的是：

谁来触发？
怎么执行？
如何验证？
失败后怎么办？
状态记录在哪里？
什么时候交还给人？

这是系统问题，不是文案问题。

误区二：把 Loop 理解成“全自动替代人”

Loop Engineering 的目标不是让 AI 自己决定一切。

恰恰相反，它要把 AI 放进一个更清晰的边界里：

低风险、可验证、可回滚的动作，可以交给 Agent 推进；
高风险、不可逆、责任重大的动作，必须交还给人。

真正成熟的 Agent Loop，不是“没有人”，而是“人可以在关键位置看见、理解、授权、暂停、接管和审计”。

---

总结

我理解的 Loop Engineering，不是一个新命令，也不是一个更长的 prompt。

它是把 AI 放进真实工作系统里，让它围绕目标持续执行、观察结果、验证质量、记录状态、修正下一步，并在需要时让人接管。

按 Addy 的 5+1 来说：

Loop Engineering
= Automations
+ Worktrees
+ Skills
+ Plugins / Connectors
+ Sub-agents
+ State

放到真实研发场景里，还会自然补出几类工程增强：

Checker / Eval：让结果有独立证据；
Human Gate：让高风险动作回到人手里；
Control Plane / 看板：让人能观察、授权、暂停、接管和审计；
Harness：为整个 Loop 提供权限、隔离、超时、重试和人工批准。

它最终要实现的是：

从需求到上线的闭环；
从上线到反馈的闭环；
从反馈到下一轮需求的闭环；
从错误到规范沉淀的闭环。

一句话总结：

Prompt 是指令，Harness 是运行系统，Eval 是验收机制，Loop 是把执行和验证持续连起来。

而人和 AI 的关系，也会从“人一轮一轮提示 AI”，变成：

AI 负责推进状态，人负责定义边界。

---

参考资料

1. Addy Osmani, Loop Engineering: https://addyosmani.com/blog/loop-engineering/
2. Addy Osmani, Agent Harness Engineering: https://addyosmani.com/blog/agent-harness-engineering/
3. Anthropic, Building Effective Agents: https://www.anthropic.com/research/building-effective-agents
4. Anthropic, Demystifying Evals for AI Agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
5. OpenAI Codex Best Practices: https://developers.openai.com/codex/learn/best-practices
6. OpenAI Codex Automations: https://developers.openai.com/codex/app/automations
7. Peter Steinberger 关于 designing loops 的 X 原文: https://x.com/steipete/status/2063697162748260627
8. Rohan Paul 转述 Boris Cherny 关于 loops 的 X 内容: https://x.com/rohanpaul_ai/status/2063289804708835412