Loop Engineering：从 Prompt 到自动化流水线

背景：第四个 Engineering 诞生

2026 年 6 月 7 日，OpenClaw 创始人 Peter 发推："你不再需要为编码智能体编写提示词了，你应该设计循环来提示你的 Agent。"

几天前，Claude Code 创始人 Boris 在开发者大会上说了类似的话："我不再手动给 Claude 写提示词了，我运行着能让 Claude 自动编排任务的循环，我的工作就是编写这些循环机制。"

随后 Google 的 Addy Osmani 发了一篇长文，把 Loop Engineering 这个概念正式梳理了出来。

继 Prompt Engineering → Context Engineering → Harness Engineering 之后，AI 行业的第四个共识性 Engineering 诞生了。

四次跃迁

Engineering 核心能力 底层学科 关键转变
Prompt Engineering 语言表达 语言学 好好说话，AI 会更懂你
Context Engineering 信息筛选和组织 信息科学 光说话不够，得给 AI 足够的信息
Harness Engineering 系统设计和规则制定 控制论 光给信息也不够，得给 AI 设规则和约束
Loop Engineering 目标定义和管理 管理学 光设规则也不够，得让整个系统能自己跑起来

Loop 的五个组件

Addy Osmani 把一个完整的 loop 拆成了五个组件：

1. 定时任务——Loop 的心跳

整个 loop 的自动启动机制。Claude Code 里有几种方式：
- /loop 命令按间隔自动执行
- cron 定时调度
- Hook 在 Agent 生命周期的特定节点自动触发（比如每次改完文件自动跑一遍 lint）
- GitHub Actions 里运行，关上电脑它也在跑

没有定时任务的 Agent，每次都得手动踢一脚才会动，那不是 loop，还是你在操控。

2. 工作树隔离——Worktree

同时跑好几个 Agent 的时候，给每个 Agent 一个独立的工作空间，各干各的互不干扰，干完了再合并。

3. 项目知识体系——不止 Skill

Addy Osmani 原文写的是 skill，但单 skill 不够，必须得是知识管理体系：
- CLAUDE.md = 全局的规则和约束
- 跨会话记忆 = 之前悬而未决的记录和文档路由
- docs 体系 = 完整的所有的知识和经验沉淀

为什么知识管理在 loop 里特别重要？ 因为 loop 是自动跑的，你不在场。如果 Agent 的记忆里有过期信息，它就会基于错误的前提做决策；如果 CLAUDE.md 膨胀到几百行全是历史叙事，真正的规则反而被挤出去了。

没有干净知识体系的 loop，就像一个每天早上都在看过期文档的员工，干得越快错得越多。

4. 连接器——MCP

一个只能看文件系统的 Agent 能力很有限。但接上 GitHub、飞书、数据库之类的，它就能在你的真实工作环境里干活了。这才叫真正的闭环——从发现问题到解决问题到通知人类，一条龙。

5. 子 Agent

做事的和检查的分开。写代码的 Agent 不能自己给自己打分——跟学生自己批自己的考卷一个道理，它一定会对自己太宽容。所以得有另一个 Agent（甚至用不同的模型）专门检查前一个 Agent 的输出。

/goal 命令：Loop 的微观产品化

Claude Code 和 Codex 都有一个命令，叫 /goal。

给 Claude 一个完成条件，比如"所有测试通过并且 lint 检查没有报错"，然后它就会一轮一轮的自己干，干完每一轮之后就会检查这个条件是不是满足了。

这就是 Loop Engineering 这套骨架最直接的微观产品化体现。

灵魂：定义目标的能力

大多数讲 Loop Engineering 的文章，都停在了五个组件和 /goal 命令这一层。这些是术。

更核心的，是道：定义目标的能力。

目标定义对比

目标 A："把这个应用优化一下"
→ Claude 会陷入尴尬状态，因为它不知道什么叫"优化好了"。可能改了一点代码就自己觉得还行就停了，也可能一直改一直改，把代码库改得面目全非。

目标 B："test/auth 目录下所有测试通过，tsc --noEmit 零报错，npm run lint 零违规"
→ Claude 每改一轮代码，都会去跑测试、跑类型检查、跑 lint。三个命令，三个明确的通过标准。全过了就停，没过就继续。

同一个工具，同一个模型。区别只在于你的目标定义得好不好。

这就是管人的逻辑

定义目标的能力，其实就是管人的逻辑——管理者要做的，是确保目标足够清晰、资源足够充足、反馈足够及时。

这三条跟一个好的 loop 的三个要素一模一样：
- 目标清晰 = 你的条件写得精准
- 资源充足 = 你给 Agent 配好了 Skill、连接器、工作权限
- 反馈及时 = 你设计了验证机制，每一轮都有独立的检查器告诉 Agent 做得对不对

管人的逻辑和管 Agent 的逻辑完全一样。只不过管 Agent 比管人还要极端——人可以理解你的模糊意图，会主动来找你确认；Agent 很多时候不会，它会非常自信地按照它自己的理解去执行，然后非常自信地告诉你它做完了。

古德哈特定律：最阴险的陷阱

当一个衡量指标变成了目标本身的时候，它就不再是一个好的衡量指标了。

翻译成人话：你考核什么，员工就只做什么，然后其他东西可能全都退化。

这个事在 Agent 身上被放大了一百倍——Agent 比人类更擅长钻规则的空子。

经典案例：你的 loop 条件是让测试全部通过，那 Agent 可能最后不去修 Bug，直接把失败的测试给你删了。从验证条件来看它确实完成了目标，但从你真正想要的结果来看……它啥也没干。

所以，一个好的目标定义，不能只有"做完了"的标准，还必须有"不能怎么做"的边界。 这正是 Harness Engineering 在 Loop Engineering 里面发挥作用的地方——Harness 是约束，是护栏；Loop 是驱动力。两个加在一起，才是一个完整的系统。

目标定义框架（实战经验）

  1. 完成标准要可以被机器验证——不能是"把它做好"，而是"tsc 零报错 + 测试全过"
  2. 边界条件要跟完成标准一起定义——告诉 Agent 不能删测试、不能改公共接口、不能引入新依赖
  3. 要有失败的降级方案——不是所有目标都能一次达成，定义超时、重试上限、人工介入条件
  4. 目标要分层——大目标拆成可验证的子目标，每个子目标独立可检查

总结

从 Prompt → Context → Harness → Loop，四次跃迁讲的是同一个故事：

  • Prompt = 好好说话
  • Context = 给够信息
  • Harness = 设好规则
  • Loop = 让它自己跑

Loop Engineering 说是 Engineering，但它的核心竞争力根本不在工程，在管理。

语言学、信息科学、控制论、管理学。四个 Engineering，四门古老的学科。

Boris 说，2026 年他就再也没有手写过一行代码了——他的工作是编写 loop。晚上睡觉的时候，甚至有时候会有几千个 Agent 在同时工作。

技术的尽头是管理。