只会写Prompt？你 OUT 了，未来属于 Loop Engineering

AI 圈又开始造新词了。

这次叫：Loop Engineering。

听起来像又一个概念包装，但我认真看完以后，反而觉得这个词有必要。

因为它关心的重点，已经从“怎么把一句 Prompt 写得更漂亮”，挪到了一个更现实的问题：

未来真正值钱的，可能是设计一个能自动跑起来的 AI 循环。

这件事，对写代码的人重要。

对做运营、产品、管理、自动化的人，也一样重要。

新词从哪来

最近几天，Loop Engineering 这个词在推特、社媒和各种 AI 群里都刷屏了。

起点大概是 6 月 7 日，OpenClaw 的创始人 Peter 发了一条很短的推文。

大意是：

你不再需要为编码智能体编写提示词了，你应该设计循环来提示你的 Agent。

这里的循环，就是 Loop。

差不多同一时间，Claude Code 的 Boris 也在开发者大会上说了类似的话。

他现在已经不太手动给 Claude 写提示词了，而是运行一些能让 Claude 自动编排任务的循环。人的工作变成了写这些循环机制。

也就是，写 Loop。

再后来，Google 的 Addy Osmani 写了一篇长文，把这个概念完整整理了一遍。

于是，在 Prompt Engineering、Context Engineering、Harness Engineering 之后，AI 行业又冒出了第四个 Engineering：

Loop Engineering。

我以前挺反感这种新词。

很多词确实只是为了显得高级，类似“某某 4.0”，一看就像会议室里憋出来的。

但 Loop Engineering 不太一样。

它更像是行业发展太快以后，大家终于找到了一个比较准确的表达。

以前我们说“让 Agent 自动干活”，太泛。

现在说 Loop Engineering，重点就清楚了：

你要设计的是一套能持续启动、执行、检查、修复、再执行的系统。

从聊天，到流水线

以前你用 Claude Code 或 Codex 写代码，大多数时候是这样：

你给它一个任务。

它写完。

你看一眼，觉得不对，再补一句。

它改完。

你再看，再提意见。

整个过程看起来像 AI 在干活，其实发动机还是你。

你坐在电脑前，一轮一轮推动它。

你不说下一句，它就停了。

这就是过去很多 Agent 工作流的真实状态：名字叫 Agent，本质还是高级聊天框。

但 Loop 的思路不一样。

比如 Boris 提到过一种工作方式：写一个类似 /loop babysit all my PRs 的循环，让 Claude Code 自动照看所有 PR。

CI 挂了，它去修。

有新 review 评论，它派子 Agent 去处理。

需要独立修改，就开独立工作树。

甚至有些 Loop 可以挂到定时任务上，晚上自动启动。人睡觉的时候，Agent 还在处理问题。

这就不是“我给 AI 一段 Prompt，让它帮我完成一个任务”了。

这是你定义一个目标，让系统自己一轮一轮往前推进。

你要做的事变成了：

定义目标。

定义验证条件。

定义失败以后怎么处理。

然后把重复执行交给系统。

说白了，Prompt 像一句命令。

Loop 像一条自动化产线。

前者适合临时帮忙，后者才适合持续生产。

一个 Loop 需要什么

Addy Osmani 把一个完整的 Loop 拆成了几个组件。我用更接地气的方式说一下。

第一个，是触发机制。

也就是整个 Loop 的心跳。

它可以是定时任务，可以是事件触发，也可以是某个 Hook。

比如每 30 分钟检查一次 PR。

比如每次文件修改后自动跑 lint。

比如 GitHub Actions 在 CI 失败时启动 Agent。

如果每次都要你手动点一下，严格来说，那还不是 Loop。

那只是你在遥控一个工具。

第二个，是工作区隔离。

开发者对 Worktree 应该很熟。

当你同时跑多个 Agent 时，必须给它们独立工作空间。

一个 Agent 修登录问题。

一个 Agent 改支付逻辑。

一个 Agent 处理文档。

各干各的，最后再合并。

如果几个 Agent 同时改同一个文件，还没有隔离机制，那场面大概率不会好看。

第三个，是项目知识体系。

Addy 原文里提到了 Skill，但我觉得只讲 Skill 还不够。

Loop 真正需要的，是一套干净、可维护、会更新的知识管理体系。

因为 Agent 每次启动时，都要知道项目规则、代码结构、历史坑点、命名约定、测试方式。

如果这些东西散在聊天记录里，Loop 一自动运行就容易失控。

更麻烦的是，过期知识会误导 Agent。

一个每天读旧文档的员工，动作越快，错得越快。

Agent 也是一样。

所以 CLAUDE.md、AGENTS.md、Skills、项目文档、长期记忆，这些东西不是装饰。

它们是 Loop 的地基。

第四个，是连接器。

也就是 MCP 这类东西。

一个只能读本地文件的 Agent，能做的事有限。

但如果它能连 GitHub、飞书、数据库、浏览器、工单系统，它就能进入真实工作流。

发现问题。

修复问题。

提交结果。

通知相关人。

这才叫闭环。

第五个，是子 Agent。

做事的和检查的最好分开。

让写代码的 Agent 自己给自己打分，就像学生自己批自己卷子。

它不一定故意放水，但它天然容易宽容。

更稳的方式，是一个 Agent 负责执行，另一个 Agent 负责审查，必要时再换一个模型来验收。

这五个东西加起来，一个 Loop 的骨架就出来了：

能自动启动。

有隔离空间。

有项目知识。

能连接真实系统。

有独立检查。

这已经不是“会不会写提示词”的问题了。

这是系统设计问题。

/goal 只是入口

Claude Code 和 Codex 里有一个命令，其实就是 Loop Engineering 的微型版本。

Claude 里叫 /goal，Codex 里叫"追求目标"。

它的逻辑很简单：

你给一个完成条件，Agent 自己一轮一轮执行，直到条件满足。

比如：

test/auth 目录下所有测试通过。

tsc --noEmit 零报错。

npm run lint 零违规。

满足了就停。

没满足就继续修。

很多讲 Loop Engineering 的文章，会停在这里。

讲一下 /goal，讲一下 /loop，再讲一下定时任务，差不多就结束了。

这些当然有用。

但它们都还是“术”。

Loop Engineering 最核心的能力，不是会不会配 Hook，也不是会不会写脚本。

而是四个字：

定义目标。

真正难的是目标

定义目标听起来很简单。

真做起来，很折磨。

举个对比。

目标 A：

把这个应用优化一下。

目标 B：

让 test/auth 目录下所有测试通过，tsc --noEmit 零报错，npm run lint 零违规。

这两个目标的差别，足够决定 Agent 是帮你干活，还是帮你制造新问题。

目标 A 最大的问题是，它没法验证。

什么叫优化好了？

页面更快一点算不算？

代码少一点算不算？

体验顺一点算不算？

Agent 不知道。

于是它可能改两处代码，然后自信地告诉你“完成了”。

也可能一路改下去，把项目改得面目全非。

因为它不知道什么时候该停。

目标 B 就清楚很多。

每一轮做完，跑测试。

跑类型检查。

跑 lint。

全过就停。

没过就继续。

同一个模型，同一个工具，结果完全不同。

区别不在 AI 多聪明。

区别在你有没有把目标翻译成可验证的完成条件。

我自己做自动化时踩过很多坑。

后来发现，最麻烦的通常不是技术。

是目标不清楚。

比如“自动监控 AI 行业热点”这句话，听起来没毛病。

但细问就全是坑：

什么算热点？

浏览量过万算，还是转发过千算？

抓取频率是每小时，还是每天？

抓到以后怎么打分？

怎么去重？

怎么排序？

怎么推送？

推送失败怎么办？

每个环节没有标准，最后就会变成一条很勤奋但很混乱的自动化链路。

这就是 Loop Engineering 最现实的地方。

它逼你先把“我想要什么”讲清楚。

管 Agent，本质是管理

这件事我越用越觉得，它不像纯工程问题，更像管理问题。

管理一个 Agent，和管理一个员工，有很多地方是一样的。

你跟员工说：

“把这个功能做好。”

他大概率会做出一个你不满意的版本。

因为你脑子里的“好”，和他理解的“好”，可能完全不是一回事。

但你换一种说法：

这个接口响应时间降到 200 毫秒以内。

错误率控制在 0.1% 以下。

下周三之前上线。

上线前必须通过压测和回归测试。

这时候偏差就会小很多。

因为目标有了可验证标准。

AI 也是一样。

甚至更极端。

人如果没听懂，可能会问你一句：老板，你这个需求是不是这个意思？

Agent 很多时候不会。

它会按照自己的理解往前冲，然后很有礼貌地告诉你：我已经完成了。

这才是最吓人的地方。

所以我一直不太认同“AI 时代文科没用了”这种说法。

管理学、心理学、组织行为学，不但没有过时，反而更重要。

因为你面对的对象变多了。

以前你管人。

现在你还要管 Agent。

而管 Agent 的核心，也是目标、资源和反馈。

目标清晰：完成条件要精准。

资源充足：Skill、连接器、权限、文档要配好。

反馈及时：每一轮都要有检查器告诉它做得对不对。

这三件事，放在人类团队里是管理。

放在 Agent 系统里，就是 Loop Engineering。

别忘了古德哈特定律

目标定义还有一个很阴险的陷阱。

管理学和经济学里有个名字，叫古德哈特定律。

简单说就是：

当一个指标变成目标，它就不再是一个好指标。

翻成人话：

你考核什么，人就只做什么。

其他东西可能全退化。

在人类管理里，这个问题已经存在很多年了。

到了 Agent 身上，它会被放大。

因为 Agent 更擅长钻验证器的空子。

比如你给它的 Loop 条件是：

让所有测试通过。

听起来很合理。

但如果没有边界，它可能不去修 Bug，而是直接删掉失败测试。

结果呢？

测试确实全过了。

从验证条件看，它完成任务了。

从真实目标看，它什么都没解决，还顺手把防线拆了。

这就是为什么 Loop 不能单独存在。

它必须和 Harness 一起用。

Harness 是约束。

Loop 是驱动力。

Harness 告诉 Agent 哪些线不能越。

Loop 告诉 Agent 往哪个方向持续推进。

只有驱动力，没有约束，系统会跑偏。

只有约束，没有循环，系统又动不起来。

两个合在一起，才像一个真正能用的 Agent 系统。

我的目标定义框架

如果把前面的东西收一下，我自己现在更常用的是这四条。

第一，完成标准要能被机器验证。

不要写“优化一下”“体验更好”“内容更完整”。

尽量写成测试通过、接口耗时、错误率、覆盖率、交付文件、检查命令、验收清单。

机器能判断，Loop 才知道什么时候停。

第二，边界条件要和完成标准一起写。

比如不能删除测试。

不能改公开 API。

不能绕过鉴权。

不能引入新依赖。

不能改用户没授权的文件。

这些话看起来啰嗦，但非常必要。

因为 Agent 很擅长完成字面目标，也很容易忽略真实意图。

第三，要有失败后的降级方案。

Loop 不可能每次都顺利。

测试一直不过怎么办？

权限不够怎么办？

依赖下载失败怎么办？

冲突合并不了怎么办？

好的 Loop 不应该无限死磕。

它应该知道什么时候重试，什么时候切换方案，什么时候停下来交给人。

第四，目标要分层。

不要一上来就让 Agent “重构整个系统”。

更好的方式是拆成小目标：

先让测试恢复。

再让类型检查通过。

再处理 lint。

再补文档。

再发 PR。

每一层都有自己的完成条件。

这样 Agent 不容易迷路，人也更容易验收。

四次跃迁

回头看，从 Prompt 到 Context，到 Harness，再到 Loop，讲的是同一条线。

Prompt Engineering 解决的是：你怎么把话说清楚。

核心能力是表达。

Context Engineering 解决的是：你怎么给 AI 足够的信息。

核心能力是筛选和组织。

Harness Engineering 解决的是：你怎么给 AI 加规则和护栏。

核心能力是系统约束。

Loop Engineering 解决的是：你怎么让 AI 在目标牵引下持续运转。

核心能力是目标管理。

语言学。

信息科学。

控制论。

管理学。

这些听起来很古老的东西，绕了一大圈，又回到了 AI 时代的核心位置。

这事挺有意思。

人类社会很多底层逻辑，其实一直没怎么变。

只是以前我们把这些逻辑用在组织和人身上。

现在，它们开始用在 Agent 身上。

所以别只盯着 Prompt 了。

Prompt 当然还重要。

但如果你想真正把 AI 用进工作流，下一步要练的，是设计循环、定义目标、设置边界、建立反馈。

未来的差距，可能就藏在这里。

如果你也在把 AI Agent 放进自己的工作流，建议先收藏这篇。下次写 /goal、写自动化脚本、设计 Agent 流程时，把“目标、边界、反馈”这三个词放在最前面。

关注我，后面我会继续拆 Agent 工作流、Skills、MCP 和自动化实战，把这些新概念翻译成普通人真的能用上的方法。