用打车讲清楚:什么是 Loop Engineering?
周末下午，我想去深圳湾公园走走。
掏出手机，打开打车 App，输入目的地，叫车。
很简单对吧？一条直线：叫车 → 上车 → 到。
但你仔细想想，从「我想去深圳湾公园」到「我真的站在深圳湾公园」，中间其实藏着一整套设计——你只是做得太熟了，没意识到而已。
这套设计，就叫 Loop Engineering。
先说结论
Prompt Engineering 是告诉 AI 说什么。Loop Engineering 是设计 AI 怎么做事——包括怎么开始、怎么应对意外、怎么判断做没做完、以及什么时候该放弃。
下面我用「去深圳湾公园」这一件事，把 Loop Engineering 的核心概念全部拆一遍。
一、目标定义：你到底要去哪？
你不会说「我要出门」。你会说「我要到深圳湾公园」。
这两者的区别是：一个可以验证，一个不行。
「出门」——你走出家门那一刻就算完成了，但这显然不是你想要的。「到达深圳湾公园」——GPS 能确认，你自己也知道到没到。
对应到 AI Agent：不是「帮我处理一下数据」，而是「把这个 CSV 按日期分组求和，输出到 result.json」。
目标不清晰，后面所有环节都是空转。 这是 Loop Engineering 的第一步，也是最容易被忽略的一步。
二、执行策略：你打算怎么去？
目标定了，接下来是选方案。
这里有两种模式：
手动指定——我就要打网约车去。方案确定，不用纠结。
自由发挥——不限方式，骑车、地铁、朋友来接、打车，怎么到都行。
对应到 AI Agent：你可以在指令里写死执行路径（「用 Python pandas 读取这个 CSV」），也可以只给目标让 Agent 自己选工具和方法。
两种模式没有对错，取决于你对过程的掌控需求。但不管哪种，你得意识到这是一个设计决策，而不是随便来。
三、异常处理：事情不会总按计划走
好，假设你选了打网约车。
但现实会出各种幺蛾子：
| 异常类型 | 具体情况 | 处理方式 |
|---|---|---|
| 执行前异常 | 没人接单、排队 28 人 | 等一会儿 → 超时就切方案 |
| 执行中异常 | 司机半路车抛锚了 | 下车，重新叫一辆 / 换地铁 |
| 方向性异常 | 司机走错路，越开越远 | 提醒司机 / 取消订单重来 |
| 外部异常 | 突然暴雨，路面积水 | 等雨停 / 换地铁 |
注意，不同的异常需要不同的处理策略。全部用同一种方式兜底（比如无脑重试），是最差的设计。
对应到 AI Agent：
- API 调用超时 → 重试
- 代码写出来但运行报错 → 读错误信息，改代码
- 方向搞错了（理解错需求）→ 回到目标重新规划
- 外部依赖挂了 → 换一个工具
好的 Loop Engineering，不是假装不会出错，而是提前想好「出错了怎么办」。
四、边界条件：什么情况下不该继续？
你打车去公园，不会无限等下去。你心里有一些隐含的限制：
- 时间：最多等 15 分钟，超了就换方案
- 预算：打车费超过 100 块，我宁可坐地铁
- 时效：晚上 10 点公园关门了，8 点还没出发就别去了
- 体力：骑了 20 分钟还没到一半，放弃
这些就是边界条件——你不会明确说出来，但它们一直在你脑子里运行。
对应到 AI Agent：max_iterations（最多重试几次）、timeout（超时多久放弃）、budget（最多花多少 token/钱）、质量阈值（输出达不到最低标准就重来）。
没有边界条件的循环，就是死循环。 Agent 会一直跑下去，烧你的 token，还觉得自己在努力。
五、验收条件：怎么判断「到了」？
你觉得「到了」是一件很简单的事对吧？
但仔细想想：
- 司机把你放在深圳湾公园对面的马路上，算到了吗？
- 到了公园停车场入口，但你还要走 10 分钟才能到海边，算到了吗？
- 你到了，但发现公园在维护，不让进，算完成了吗？
验收条件定义得越清晰，结果的质量越高。
对应到 AI Agent：
- 「帮我写一篇文章」→ 写了一篇，但质量很差，算完成吗？
- 「帮我修这个 bug」→ 这个 bug 修了，但引入了两个新 bug，算完成吗？
- 「帮我部署到线上」→ 部署了，但没跑起来，算完成吗？
验收不只是「做没做」，而是「做到什么程度才算过关」。 这是 Loop Engineering 里最考验设计功力的地方。
六、退出机制：什么时候该放弃？
不是所有目标都能达成。
晚上 11 点了，公园关门了——不去了。这不是失败，这是合理退出。
暴雨预警，所有交通方式都不安全——不去了。这也是合理退出。
连续换了 3 种方案都不行，你累了烦了——不去了。也行。
退出不丢人。没有退出机制才丢人——那叫死循环。
对应到 AI Agent：达到最大重试次数、超出预算、检测到无法完成（比如依赖的服务彻底挂了）→ 停下来，返回当前状态和失败原因，而不是永远跑下去。
七、回退策略：Plan B、C、D
你打车失败了，不会傻站着。你会有一条降级链：
网约车 → 地铁 → 朋友来接 → 骑共享单车 → 算了改天再去
这条链有优先级：先试成本最低的，再试麻烦一点的，最后是兜底方案。
而且每次回退不是从零开始——你打车的时候已经走到了一个新位置，旁边可能正好有个地铁站。上一轮的输出，是下一轮的输入。
对应到 AI Agent：主策略失败后，按什么顺序尝试备选方案？每次切换是否保留之前的上下文？兜底方案是什么？
好的 Loop Engineering，会把回退链设计成一条平滑的降级路径，而不是断崖式失败。
拉到一起看
用一张表把「去深圳湾公园」和 AI Agent 的 Loop Engineering 全部对上：
| Loop Engineering 概念 | 去深圳湾公园 | AI Agent |
|---|---|---|
| 目标定义 | 到达深圳湾公园 | 明确、可验证的任务描述 |
| 执行策略 | 打网约车 / 自由选择 | 指定工具 / 让 Agent 自选 |
| 异常处理 | 没人接单、车抛锚、走错路 | API 超时、代码报错、理解错需求 |
| 边界条件 | 最多等 15 分钟、预算 100 以内 | max_iterations、timeout、budget |
| 验收条件 | GPS 确认到达 + 能进公园 | 输出符合预期 + 通过质量检查 |
| 退出机制 | 太晚了 / 公园关门 → 不去了 | 超限 / 不可能完成 → 返回失败 |
| 回退策略 | 网约车→地铁→朋友接→骑车 | 主工具→备选→降级→兜底 |
其实我一直在用，只是不知道它叫这个名字
我遇到大任务的时候，经常用 Codex 的 Goal 模式。
直到 Loop Engineering 这个词在我眼前出现的次数多了，我才去认真了解，然后发现——Codex 的 Goal，其实就是 Loop Engineering 的产品化。
写好一份目标清单，交给 Codex Goal，然后解放双手啥也不用管，等着验收结果就行。
它帮你做的事，本质上就是前面说的那些：定目标、选策略、跑循环、处理异常、检查验收、该退出就退出。你没有手动设计这个 loop，但产品已经帮你设计好了。
觉得设计 Loop 太麻烦？
看到这里你是不是觉得——Loop Engineering 道理是挺好，但真要我自己去设计一个目标，想清楚异常处理、边界条件、验收标准、回退策略……太多东西了，真的很头疼。
别说你了，我也头疼。
所以有人做了一个 Skill 来帮你减轻这份痛苦：qiaomu-goal-meta-skill。
它做的事很简单——帮你把脑中模糊的想法，变成一份清晰的 Goal。你说出你大概想做什么，它引导你把目标、异常、边界、验收这些东西一步步理清楚，然后交给 Agent 去跑循环。
连设计 Loop 这件事本身，也可以用一个 Loop 来完成。
写在最后
AI 时代的新词，不用追。
这两年新概念太多了——RAG、CoT、MoE、Loop Engineering……每隔几周就有一个新词刷屏。大多数时候远远看着就好，然后继续做自己手头的事。这些概念不会让你噌的一下效率提高 10 倍。当你真的需要的时候，它自然会出现在你面前——就像今天这篇文章出现在你面前一样。
说到这个就想到 Agent 这个词。说实话，我到现在也没办法用一句简单通俗的话去定义它。我对「不知道」的定义是：我没法用让外行人也能听懂的语言去解释它。我对 Agent 只有一个模糊的感受，知道它大概是个什么样子。你要让我精确定义，我说不出来。
但这并不影响我用 AI 去 build 东西。
你不需要知道发动机的工作原理，也能开车去深圳湾公园。能用起来，比能定义它更重要。
比起「怎么用」，我更关注「怎么设计的」。
从 Loop Engineering 的出现，到社区里那些优秀的 Skill、Prompt 模板，其实能窥探到一些更底层的东西——系统思维。
这也是我最近在关注的方向。比起知道某个工具怎么用，我更想知道：这个东西是怎么被设计出来的？为什么要这么设计？为什么它好用？
Loop Engineering 的本质不是什么新发明，它就是把我们日常生活中「遇到问题→调整→再试」的思维模式，系统化地应用到了 AI Agent 的设计上。
很多所谓的「新概念」，其实都是旧智慧的新包装。
看透设计背后的思维模型，比记住每一个新名词，有用得多。