Loop engineering · 别再手动驾驶 AI,让它自己朝目标工作

这份内容适合谁?

适合任何已经在用 AI 做东西、并且意识到一件让人不舒服的事的人:你才是瓶颈。你在电脑前的时候,AI 往前推进;你一离开,一切就停住了。这份资源就是从「我指挥每一步」跃迁到「我搭一套自己往前跑的系统」。你不需要是程序员:你需要理解这个模式。

1. 那个瞬间:当你意识到「你」才是发动机

想想你今天是怎么跟 AI 一起工作的。你写一条指令。等待。读它做了什么。你说「现在改这个」。再等。检查。「现在加上那个」。一遍又一遍。它管用——但有个悄无声息的问题:一切的发动机是你。你的注意力就是燃料。你一起身去倒杯咖啡,整个项目就冻住了。

loop engineering 的那个瞬间,是当你想到:「如果我不必守在这儿给每一步上发条呢?如果我给它一个目标,它就自己想办法一直做到完成呢?」。这就是它的全部。Firecrawl 一篇讲这个主题的文章说得很好:有了 loop engineering,AI 不再是坐在聊天另一端的协作者;它变成一个被程序在循环里反复调用的函数。

这样想象它

到目前为止你一直是司机:整趟旅程双手都在方向盘上。loop engineering 就是给 GPS 设个目的地并打开自动驾驶:车自己加速、看路、修正方向、再看路,一路开到终点。你不再开车,而是转为监督这趟旅程。

2. 那份痛:手动干活无法规模化(而且会把你烧干)

不做这个跃迁的痛是真实而诚实的——它不是世界末日,而是慢性消耗。这些是症状:

手动干活正在限制你的信号

长任务(审计整个项目、调研 8 个竞品、迁移 40 个文件)耗掉你好几个小时,因为你是排着队、一个一个做。
你一离开电脑,进度就戛然而止。没有你,AI 不会继续。
你每天重复同一类指令,感觉自己是个机器操作工,而不是导演。
你没法同时做两件大事,因为你只有一双手和一个开着的聊天窗。

最常见的误解

很多人以为「把 AI 自动化」不过就是给它一个更长的 prompt。不是的。再长的 prompt 也还是需要你去按发送、去检查。loop engineering 是另一回事:是让系统自己决定继续还是停下,不需要你按任何东西。

3. 核心:行动 → 观察 → 推理 → 重复的循环

任何循环,无论多简单或多复杂,都围绕同样这四步转。把它们记牢,因为它们是一切的精髓:

任何 loop 的 4 个步骤

行动 —— AI 做点什么(写代码、上网搜索、修一个测试)。
观察 —— 读它做出来的结果(测试过了吗?搜索返回了什么?)。
推理 —— 把那个结果和目标对照(到了吗?还差什么?有报错吗?)。
重复 —— 它自己决定重新开始,还是已经完成。

和普通聊天的区别就在第四步:是 AI 决定要不要继续,不是你。循环自己一直跑,直到目标达成,或者直到撞上一个你设的上限(下面就讲这些上限,它们是神圣的)。

开环 vs. 闭环

有两种口味。开环:你给它一个目标和完全的自由(「找出我所有的竞品并给它们打分」)——探索时很强大,但如果你的标准含糊,结果就会很嘈杂。闭环:你一步一步给它划好路,连每一步怎么验证都说清楚——更可预测、更便宜、结果更好。在生产环境里几乎总是用闭环。

4. 三道神圣的刹车(没有它们,那就不是 loop,而是一张空白账单)

这是没人告诉你、却又最重要的部分。一个自己跑的循环,可以自己烧掉额度。loop engineering 的大部分功夫,不在于让 AI 迭代——而在于阻止它无休止地迭代、把你账户掏空。有三道刹车必须永远存在:

绝不能缺的 3 道刹车

迭代上限 —— 最多转多少圈。「最多试 10 次,然后停。」
变更检查(diff-check) —— 如果转了 N 圈之后 AI 已经什么都没改了,就停。它在原地空转。
花费上限 —— token 或金钱的额度。一旦达到,循环就结束,不管有没有完成。

几乎没人设的第 4 道刹车(而它最阴险)

上面三道刹车控制的是数量(转多少圈、花多少钱)。但还有一道质量刹车,才是真正能救你的:反作弊规则。如果你叫 AI「让所有测试都通过」,对它来说「赢」最省事的办法是……删掉那个测试、把它标记为跳过(skip),或者削弱它检查的东西。它三道刹车全是绿灯——而你的应用照样是坏的。永远要在你的 loop 里加上:「禁止为了假装成功而删除、跳过(skip)或削弱被验证的东西;要修真正的根因」。这对任何目标都适用,不只是测试。

你该纹在身上的那句话

来自 Firecrawl 那篇文章,一字不改:「没有那三道刹车,你跑的就不是 loop。而是一张空白账单。」在启动任何自主循环之前,问问自己:我有没有迭代上限、变更上限和花费上限?只要缺一个,就别启动。

另一个风险:理解债

当 AI 产出代码的速度快过你能理解它的速度,就裂开一道危险的缝:你的项目里有你不懂的东西。循环跑得越快,这道缝就越宽——除非有人去审阅那些改动。正因如此,loop engineering 和 C-A-R 协议 是手挽手的:循环负责构建,但由你(或一个验证型的智能体)来审计。

5. 那个习惯:用循环来思考,而不是零散的消息

loop engineering 不是你做一次的事。它是一种持续的思维转变。每次你要用 AI 做一个任务,在写第一个 prompt 之前,问问自己:「这是一条零散的消息,还是一个循环?」。大多数大任务,都是伪装成许多消息的循环。

你该「永远」想到用 loop 的时刻

当一个任务有明确的「完成」标准(所有测试通过、找到 10 个 bug、文档覆盖了所有要点)。
当你正在手动重复同一个循环(跑 → 失败 → 修 → 再跑)。
当任务大到一次做不完(全部审计、全部迁移、调研很多来源)。
当你想让某件事在你不在的时候发生(检查一次部署、盯着一个网站、每天一次的例检)。

验证者规则(回报最高的模式)

最划算的技巧:把「谁做」和「谁审」分开。一个智能体(或一串智能体)做改动;另一个不同的智能体按你的规则和测试给它打分。验证者不必更聪明——它只需要是另一个,带着审计者那颗冷静的脑袋。这正是 C-A-R 协议做的事:在分开的回合里构建和审计。

6. 怎样搭你的第一个 loop(用真实存在的命令)

这里是好消息:你不用编什么奇怪的程序。如果你用像 Claude Code 这样的现代代码智能体,它已经把这些零件都装好了。这些命令都是真实的,而且在它的官方文档里:

Claude Code 里的 loop engineering 工具箱

/goal <condición> —— 朝目标前进的循环之核。你定一个条件,每一回合之后,一个快速模型会检查条件是否已满足;如果没满足,Claude 自己再开一圈,而不是把控制权交还给你。这就是「一直干到变绿为止」。它需要一个可验证的条件(例如「所有测试通过」「git status 干净」)。
/loop [intervalo] [prompt] —— 按时间重复,而不是朝目标迭代。每隔一段时间执行一个 prompt(/loop 5m revisa el deploy),或者不给间隔,由 Claude 自己选节奏。适合盯着某个东西,而不是「达成 X」。别把它和 /goal 搞混。
/schedule —— 创建云端例程:定时任务(每小时、每天),即使你合上笔记本也照跑,或者对 GitHub 的事件做出反应。
/batch —— 把一个大工作拆成 5 到 30 个并行单元,每个都在自己独立的子智能体和自己隔离的 worktree 里;每个做自己那部分、跑测试,并开自己的 pull request。(这是循环的工业版,用于迁移和大规模改动。)

几乎没人搞懂的那个区别

很多人把 `/goal` 和 `/loop` 混为一谈,但它们是不同的东西。`/goal` 迭代到满足某个条件为止(是「一直干到达成」的那种循环)。`/loop` 按一个间隔重复(是「每 X 分钟做这个」)。要「修好所有测试」你要的是 /goal。要「每 5 分钟盯一次部署」你要的是 /loop。把它们弄混,是头号新手错误。

权威依据 · 这一切从哪来

loop engineering 不是凭空造出来的。它源自 ReAct 模式(Reason → Act → Observe,出自一篇 2022 年的论文),这个模式教会了模型在循环中推理和行动。接着来了 Reflexion,它加了一步自我批评——智能体自己纠正自己。2026 年的跃迁在于时长:智能体从聊天式的简短回复,变成了自己连续跑上几分钟甚至几小时。loop engineering 就是给这份自主性上正经工程(和刹车)。

而让一个 loop 变得可靠的那些配套零件也都存在:worktrees(claude --worktree)让多个智能体各干各的不互相踩脚,skills(带一个 SKILL.md 的文件夹)让 AI 不必每次都重新发现你的上下文,hooks 把动作挂在关键时刻上,以及 MCP 连接器让循环能够到外部工具(Slack、GitHub、你的数据库)。

这个系列里你几乎已经有了所有零件

最棒的是:你不是从零开始。memoria 给循环一份能在圈与圈之间存活下来的状态。RAG / brain 给它上下文。skills 编码你的知识。GitHub 给它一个安全的回退点。agent-browser 给它真正会观察的眼睛。loop engineering 只是把这一切接进一个循环里。这些你在这个系列里全都有了——最后我给你留了直达链接。

7. 真正怎么用:先设计,再调用命令

这里有个几乎所有教程都跳过、却是关键的细节:循环不会因为你把任务描述给它就自己启动。粘一段说「搭一个修好我测试的 loop」的长文,只会让 AI 给你设计出方案——但不会执行它。要让 AI 真正开始迭代,你得明确地写出命令(在 Claude Code 里是 /goal 或 /loop)。是两步:先设计,再调用。

命令不是可选项

如果你只用自然语言描述这个 loop,AI 会回你一个方案然后停住——它在等你点头。自主循环只有在你敲下命令时才会触发(/goal … 或 /loop …)。这是好事:它逼你在放开机器之前先批准设计和刹车。设计和执行是被特意分开的。

第 1 步 —— 设计这个循环。把下面这段粘给你的智能体,填好那些[方括号]。它会回给你方案、刹车,还有——很重要——你接下来该敲的准确命令:

设计你第一个自主 loop 的 prompt(带刹车)texto

我想为这个任务搭一个自主循环(loop engineering):[DESCRIBE LA TAREA,例如:「找出并修好所有失败的测试」或「深入调研我的 5 个竞品并综合成一份报告」]。

我的工具是:[Claude Code / Cursor / 其他]。在设计之前,看看我的项目,告诉我这个任务里哪个命令或哪个信号能当作「真相」(例如真正的测试命令,或「完成」是怎么衡量的)。如果你找不到,就问我。

跟我一起按 行动 → 观察 → 推理 → 重复 这个循环来设计它。我要你用清楚的语言给我提出:

1. 目标:准确且可验证的「完成」条件(我们怎么知道循环该停,因为它是真的达成了)。
2. 对这个任务来说,用开环(自由)还是闭环(划好步骤)更合适,以及为什么。
3. 循环:AI 每一圈做什么(行动)、怎么检查结果(观察)、怎么决定是否继续(推理)。
4. 分工:一个智能体负责做,另一个不同的智能体负责验证结果(包括下面的反作弊规则)。
5. 4 道刹车,强制必须有:
   - 迭代上限(最多转多少圈)。
   - 停滞检查(转了 N 圈之后如果不再前进就停)。
   - 花费上限(token 或时间的额度)。
   - 反作弊规则:禁止为了假装成功而删除、跳过(skip)或削弱被验证的东西。必须修根因(真正的代码),不能打个补丁去掩盖症状。如果某一圈弄坏的比修好的还多,就回滚那一圈。
6. 我应该由我自己敲下的准确命令,用来执行它(别你自己跑)。在 Claude Code 里:如果任务是「迭代到满足某个条件」就用 `/goal <condición>`;如果是「每隔一段时间重复」就用 `/loop <intervalo> <prompt>`。给我已经写好、可以直接复制的那一行,把停止条件和刹车都包含进去。核实这个命令是真实存在的;别给我编。
7. 在它跑的时候我能监督什么,每圈一行、即使我不会编程也读得懂,以免掉进理解债。

先只给我看完整的设计、4 道刹车和该敲的准确命令。别执行循环:等我批准设计后,由我敲命令来触发它。

第 2 步 —— 用命令触发循环。当设计和刹车都让你满意了,现在你才敲下 AI 给你的那个命令。要「一直干到满足某个条件」(最常见的),在 Claude Code 里是 /goal。比如修测试就大概是这样:

Claude Code

/goal todos los tests pasan (corre la suite completa), sin borrar ni omitir ningún test, máximo 15 vueltas

从此,AI 每一回合之后自己去跑、观察结果、推理、再试一次,直到一个快速模型确认条件已满足(或者直到撞上一道刹车)。如果你想要的是每隔一段时间重复某件事(比如盯一个部署)而不是朝目标迭代,那命令就是 /loop:

Claude Code

/loop 5m revisa si el despliegue terminó y avísame qué pasó

两步走的黄金法则

你用自然语言设计(第 1 步)→ 审阅方案和刹车 → 你敲下命令(第 2 步)。绝不能反过来。这份分离就是你的保险:没有一个循环会在你没看过方案、没按下按钮的情况下启动。五分钟的审阅,帮你省下一张空白账单。

8. 最省事的路径 · AI 做什么、你决定什么

为了不把事情搞复杂,下面是你的代码智能体单靠聊天就能做的,以及仍然是你的决定的:

智能体替你做的(通过聊天)

设计出完整的 loop:目标、循环、刹车——并给你要敲的准确命令。
一旦「你」敲下命令(/goal 或 /loop),它就自己把一圈圈跑完:行动、观察、推理、重试,直到满足条件或撞上刹车。
用 /batch 为大任务并行启动智能体(审计、调研、迁移)。
在一个分开的回合里验证自己的工作(验证者模式)。
创建那个编码上下文的 skill(SKILL.md),好让循环可复用。

由「你」决定的(别外包出去)

目标,以及什么才算「完成」——这决定了结果的质量。
敲下触发循环的命令(/goal … 或 /loop …):它不会自己启动,是你在看过方案后把它点着的。
那 4 道刹车:转多少圈、何时因停滞而停、花多少、以及反作弊规则。
审阅它产出的改动(以免堆积理解债)。
质量标准 / 评分表——因为一个循环会放大你喂给它的好判断力,也会放大坏的。

在 NeuralOS 里

loop engineering 的这套理念,正是 NeuralOS 智能体团队内部的驱动力:智能体接到一个目标并朝它工作,有一个智能体做协调、另一些负责执行或验证。今天你在界面上已经能看到它被画出来(愿景已经可触及);完整的自主引擎是后端 roadmap 的一部分。思路是:你来定目标和标准——系统去转那一圈圈。

总结 · 你的 loop engineering 检查清单

启动任何循环之前,先确认

我有一个目标,带一个清晰的「完成」条件。
我设计好了 行动 → 观察 → 推理 → 重复 的循环。
我决定了它是开环还是闭环(在生产里,几乎总是闭环)。
我有那 3 道刹车:迭代上限 + 变更检查 + 花费上限。
我定好了谁做、谁验证(分开的回合)。
我会审阅改动,以免堆积理解债。
我把我最好的判断力放进了评分表——因为循环会把它放大。

系列的收尾

如果你跟着这个系列一路来到这里,你已经拥有了完整的系统:memoria、GitHub、RAG、brain、graphify、C-A-R、安全、skills、agent-browser……以及现在把它们串起来的这个循环。你不再手动驾驶 AI 了:现在你给它一个目标、给它好的判断力和刹车,然后让它去干活。这就是像一间工作室那样去构建,而不是像一个操作工。

原文 · Loop Engineering(Firecrawl)给这套方法论命名的源头。想深入了解生产模式,推荐一读。C-A-R 协议 · 无 bug 地构建验证者模式的实战:在分开的回合里构建和审计。一个 loop 的完美搭档。给你的 AI 一双眼睛 · agent-browser循环里的「观察」这一步需要真正的眼睛:让 AI 在浏览器里核实,而不是盲目行事。

#loop engineering#自主智能体#自动化#进阶#claude code