Loop Engineering：你可能并不需要一个 Agent Loop

原帖：Codez on X: Loop engineering: the 14-step roadmap from prompter to loop designer

前言：这篇文章真正有价值的地方，不是教你怎么搭 loop

最近我在读一篇讲 loop engineering 的长帖。

它很容易让人兴奋。读前几段时，我脑子里冒出来的都是这种问题：

• 以后是不是不用自己盯着 agent 了？
• prompt 这件事是不是快退休了？
• 是不是只要把系统搭起来，剩下的就能自动跑？

但我读完以后，记住的不是“14 步怎么做”，而是一句更扫兴的话：

你可能并不需要一个 loop。

我反而觉得，这才是整篇文章最成熟的地方。

现在聊 agent，特别容易滑向一种乐观主义：

• 模型越来越强
• 工具越来越多
• 那下一步当然就是把所有事情都自动化

听起来很顺。问题是，现实一般不会这么配合。

这篇文章真正想说的是：不是所有能让 agent 帮忙的任务，都值得做成一个无人值守的 loop。

它先泼冷水，再谈方法。这个顺序我挺喜欢。因为很多文章都在教人怎么搭系统，只有少数文章会先问一句：你真的需要这个系统吗？

我这次没有让 AI 直接给我总结，而是用问答的方式一点点拆。拆到后面我才意识到，我一开始理解偏了。我以为它讲的是“怎么更高级地写 prompt”，其实它讲的是另一件事：杠杆点已经换地方了。

一、从写 prompt 到设计系统，杠杆点到底变在哪

我最初的理解很简单：

• prompt 是人手动写的
• loop 是让 agent 自动做事的
• 所以 loop 只是“更自动一点的 prompt 工程”

后来发现，这个理解不够。

这篇文章真正的意思不是：

• prompt 不够强，所以我们把 prompt 写得更完整

而是：

• 真实工作本来就不是一个回合，而是一个过程。

以前你和 coding agent 协作，大概是这样：

1. 你发现任务
2. 你写 prompt
3. 你补上下文
4. 你看结果
5. 你决定下一步

这套流程里，agent 更像一个你拿在手里的工具。它会干活，但节奏、方向、停不停，基本都由你来控。

loop engineering 想做的，是把这条链路接过去：

1. 系统自己发现任务
2. 系统自己把任务交给 agent
3. 系统自己跑 verifier 检查结果
4. 系统自己记录状态
5. 系统自己决定下一步要不要继续

这时候分工就变了：

• agent 负责局部执行
• loop 负责流程编排
• human 负责设目标、设边界、设验收标准

所以这篇文章最核心的一句话是：

leverage moved from typing prompts to designing the system that prompts

以前杠杆在 prompt quality。现在杠杆在 system design。

也就是说，你的工作不再只是“会提问”，而是开始变成：

• 谁来提问？
• 什么时候提问？
• 问完怎么算过？
• 失败了怎么办？
• 下一轮从哪接着跑？

这个变化其实挺像带实习生。

prompt 像是你给实习生下一条临时口头指令。

loop 则像是你开始设计一套值班流程：

• 任务从哪来
• 做到哪算过
• 过不了怎么办
• 记录放哪
• 明天接着从哪里继续

这已经不是”问得更好”，而是”把工作链路设计好”。

二、这篇文章其实是在反对一种很流行的冲动

如果只看标题，很容易把它读成：

• prompt 时代结束了
• everyone should build loops
• 不会做 loop 的人很快就落后了

但作者其实没这么激进。

他真正纠正的是一个现在很常见的误解：

agent 变强 不等于 所有工作都该自动 loop 化。

很多事情当然可以让 agent 帮忙。

但：

• agent can help
• 不等于
• this should become an unattended loop

这个区分非常关键。

因为有不少任务看起来很适合自动化，实际上只是：

• 做一次很爽
• demo 很漂亮
• 真跑起来并不划算

还有一种更糟：

• 表面上自动化了
• 实际上你还是得在后面不停兜底

这种系统最烦。它既没省掉你的心智负担，还多养了一套要维护的东西。

所以作者真正关心的问题不是：

• 这个任务 agent 能不能做？

而是：

• 这个任务能不能在 没人一直盯着 的情况下，稳定、反复、还算经济地跑下去？

如果答案是否定的，那它就不该变成 loop。

三、4-condition test：值不值得 loop，先过这四关

这篇文章最值得带走的，不是后面的 14 步，而是前面的 4-condition test。

作者给了一个很实用的判断框架：一个任务只有同时满足四个条件，才值得认真考虑 loop 化。

1. 任务会重复发生

这一点听起来最朴素，但特别容易被忽略。

因为很多自动化冲动都长这样：

• 这个任务挺烦
• 我不想再手动做
• 干脆做个 loop

但如果它只是一次性的，或者几个月才来一次，那 loop 的搭建成本根本没地方摊。

说白了就是：

• setup cost 不会自己消失
• 只有反复运行，才谈得上 amortization

如果工作本身不重复，往往一个好 prompt 比一个 loop 更合适。

2. 结果能自动验证

这是全文最重要的一条。

我一开始也差点把“验证”想浅了，以为：

• 再拉一个 agent 来 review 不就好了？

后来才发现，这正是作者最反对的那类伪验证。

他强调，真正好的 verifier 应该是：

• test
• build
• type check
• linter
• 其他能客观给出 pass / fail 的外部约束

为什么“另一个 agent 来 review”通常不够？

因为另一个 agent 给你的，还是 主观判断。

它的问题至少有三层。

第一，它看到的不是现实，而通常只是第一个 agent 交上来的产物。也就是说，它审的是“作业”，不是“做作业时真正处在什么环境里”。

第二，它没有客观标准。没有 test、没有 build、没有 type check 的时候，它能说的通常只有：

• 看起来不错
• 逻辑似乎成立
• 我同意这个实现

这不是验证，这是意见。

第三，两个 agent 很容易共享同一种偏差。于是就会出现作者那句很毒的总结：

two optimists agreeing

我读到这句的时候一下就清醒了。

没有 objective gate 的自动化，经常只是两个模型在互相点头。

所以我给自己记住的版本是：

• agent reviewer 给的是意见
• test/build/linter 给的是约束

这个区别特别重要。

3. token 预算扛得住

这条很现实，也很少有人愿意认真谈。

很多人聊 agent loop，只聊能力，不聊成本。可 loop 天生就是更烧 token 的，因为它会：

• 反复读取上下文
• 重试
• 失败后再探索
• 跑验证
• 多轮做决策

一次性 prompt 关注的是“这一枪打得准不准”。

loop 关注的是“这条链路能不能一直跑”。

只要进入续跑，成本曲线就完全不一样了。

所以 loop 是否可行，不只是技术问题，也是经济问题。

这也解释了为什么同一套方法：

• 对预算很充足的团队，看起来像常识
• 对消费级套餐用户，看起来像不计后果的烧钱实验

4. agent 有足够工具

没有工具的 loop，本质上是在盲飞。

至少它要能：

• 读到足够的上下文
• 运行代码
• 看日志
• 拿到错误信息
• 执行 verifier

如果这些都没有，loop 并不是在自动完成任务，而是在黑箱里猜。

所以作者这里其实是在强调：

• loop 不是“让 agent 一直说话”
• loop 是“让 agent 在可观测、可执行、可验证的环境里工作”

差别很大。

四、我后来才想明白：这四个条件到底在过滤什么

刚读到这里时，我其实只是把四条背下来了。

后来再想，才意识到这四条不是 checklist，而是在过滤一种很常见的假自动化。

它们筛掉的，大概就是两类任务：

• 做一次很爽，但长期不划算
• 表面自动化了，实际上人还是得一直兜底

也就是说，作者真正想阻止你犯的错是：

• “哇，这个也能自动化”
• “那个也能自动化”
• 最后做出一堆看起来很聪明、实际上不稳的 loop

这些 loop 往往有共同特征：

• 不重复
• 不好验收
• 成本高
• 出错时人还是得亲自上场

所以作者真正问的，不是：

• 这个任务能不能交给 agent？

而是：

• 这个任务能不能在 没人一直盯着 的情况下，稳定、反复、经济地跑下去？

这才是 4-condition test 真正厉害的地方。

五、state file：没有外部状态，loop 每一轮都像失忆

后半段里我最喜欢的一个点，是作者强调 state file。

我一开始没太重视这个词，心想不就是个记录文件吗？

后来才发现，不是。

在 loop 里，state file 根本不是普通笔记，而是一种外部记忆。

它解决的是跨轮连续性问题：

• 上一轮做到哪了？
• 为什么停在这里？
• 下一步是什么？
• 当前卡点是什么？
• 什么算 stop condition？

如果没有 state file，最直接的问题当然是：

• 忘记当前进展
• 每次都要从头回忆
• 浪费 token

但更麻烦的是另一层：

• 没有可审计的执行轨迹
• 你不知道它为什么做了某个决定
• 也不知道它是不是在同一个坑里来回打转

所以后来我把 state file 理解成三样东西：

• resume mechanism
• cost control mechanism
• debugging mechanism

它不是 diary，不是让 agent 把所有 thoughts 都抄进去。

它更像一个 coordination artifact，只记录对下一轮决策真正有用的最小状态。

这一点挺适合提醒自己：

• prompt 解决的是单回合上下文
• state file 解决的是跨回合连续性

六、minimum viable loop：先把闭环跑通，再谈漂亮架构

这一部分我也很喜欢。

因为很多人一聊到 agent loop，就会天然往“更复杂”走：

• 多 agent swarm
• 很 fancy 的 orchestration
• 很复杂的 verifier 链
• 各种自动 memory、自动 skill、自动 scheduler

看起来都很酷。

但作者其实在反对这种冲动。

他提倡的最小可用 loop 只有四个部件：

• one automation
• one skill
• one state file
• one gate

为什么他这么强调 minimum viable loop？

因为复杂 loop 最大的问题不是“难写”，而是：

• 难验证
• 难定位
• 难收敛

系统一复杂，出错时你根本不知道问题在：

• automation
• skill
• state
• verifier
• orchestration
• 还是 agent 之间的交接

更糟的是：

• 你还没证明这件事值不值得 loop 化
• 就先把维护成本做大了

所以正确顺序其实很朴素：

1. 先把一次人工 run 做可靠

2. 把它固化成 skill
3. 再用 loop 包起来
4. 最后才 schedule

我挺喜欢这个顺序。它不是在追求“能演示”，而是在追求“能闭环”。

MVP 和能闭环之间，有时候真差得挺远。

七、Ralph Wiggum loop：最危险的不是失败，而是假成功

后半段最让我警觉的一个词，是 Ralph Wiggum loop。

作者用它来描述一种很阴险的失败模式：

• loop 看起来在正常工作
• 实际上它已经过早宣布“完成”
• 然后安静地退出，或者继续沿着错误方向花钱

这种失败为什么比直接报错更危险？

因为：

• 报错至少会暴露问题
• 你会介入
• 损失虽然有，但它是可见的

而“安静地错了”最麻烦的地方，是它会制造一种成功幻觉。

系统看起来都正常：

• 有结果
• 有日志
• 有流程
• 甚至还在继续推进

但现实世界并没有同意它真的完成了。

这时候最危险的就不是 failure，而是 false success。

我觉得这特别像人自己做事时的一种坑：

• 真正坑人的不是“我不会”
• 而是“我以为我会，而且还没意识到自己错了”

所以作者特别反对：

• soft completion condition
• “done when it looks good”
• “另一个 agent 说看起来没问题”

因为这些条件都太容易让 loop 在真正完成之前提前停下。

八、comprehension debt：loop 越强，理解债务反而越容易涨

这是整篇文章里最反直觉、也最让我在意的一部分。

我一开始会本能地觉得：

• loop 越强，出错越少
• 事情推进越快
• 那不就是越轻松吗？

后来才意识到，问题恰恰出在这里。

如果 loop 很弱：

• 它会经常失败
• 你会频繁介入
• 你被迫和系统保持接触

但如果 loop 很强：

• 它不断产出可接受结果
• 你越来越少亲自读 diff
• 越来越少亲自 debug
• 越来越少亲自判断

于是，仓库里的真实状态，就会开始比你脑子里的理解模型增长得更快。 这就是 comprehension debt。

它的可怕之处在于：

• 平时不痛
• 出事时最痛

真正要付账的那天通常是：

• 某个线上 bug 需要你亲自修
• 某段关键逻辑没人真正读过
• 某个架构问题开始反噬

你会发现，之前省下来的不只是工作量，你其实是把理解成本延期支付了。

理解债务的本质，不是“代码变多了”。

而是：

• 系统真实复杂度 增长得比 人的理解能力 更快

这才是债。

九、cognitive surrender：系统没坏，人先退了

另一个我很喜欢的词是 cognitive surrender。

如果说 comprehension debt 是“你没跟上系统”， 那 cognitive surrender 更像是：

• 你干脆不想跟了

loop 太顺的时候，人很容易慢慢滑向一种状态：

• 不再主动形成自己的判断
• 不再认真读 diff
• 不再追问“为什么是这样”
• loop 给出结果，就默认收下

这不是系统坏了。

这是系统太好用，导致人先退化了。

所以作者提醒得非常对：

• loop 不是让人彻底退出
• 而是把人的角色从“手动 dispatch”转移到更高层的判断

真正该由人做的事情会变成：

• 目标设定
• 边界定义
• 验收标准
• 风险判断
• 差异阅读

如果这些都不做，那 loop 越强，你越容易认知投降。

十、security tax：无人值守 loop，也是无人值守攻击面

文章最后一部分的语气明显更硬了。

作者说：

An unattended loop is an unattended attack surface.

这句话不是在说“loop 可能不安全”，而是在说：

• 只要 loop 是长期运行的
• 只要它持有权限
• 只要它会自动采取行动
• 只要它会读取文本上下文

那它天然就是一个攻击面。

为什么？

因为这已经不是普通脚本了。

一个 unattended loop 往往同时具备：

• 长期在线
• 能读上下文
• 能写文件
• 能开 PR
• 能装 skill
• 能看日志
• 还会被文本输入影响

这意味着它不仅会有普通自动化的风险，还有 LLM 特有的问题：

• prompt injection
• 被 issue / PR / skill / 文档污染
• 日志泄露凭据
• 权限慢慢变大却没人复查

所以作者把它称为 security tax，我觉得特别准。

自动化不是白拿收益。你拿到效率红利的同时，也顺手继承了一笔安全账单。

十一、我最后真正带走的，不是 14 步

读完以后，我觉得这篇文章最重要的收获，不是“我学会怎么搭 loop 了”。

而是我以后在动手之前，我会先问三个问题：

1. 这件事真的值得 loop 化吗？

不是因为 agent 能做，就说明它值得自动化。

2. 如果 loop 了，谁来客观验收？

没有 objective gate，自动化只是乐观主义者互相同意。

3. 如果这个系统持续跑下去，我是否还理解它在做什么？

如果不能，那效率提升很可能只是理解债务延期爆炸。

这三个问题，比“怎么调 prompt”重要得多。

结尾：先定义 gate，再决定是否自动化

如果让我把这篇文章压成一句真正能指导行动的话，我会写成：

先定义 gate，再决定是否自动化；先做最小闭环，再考虑做大 loop。

我现在对 agent loop 的态度，比以前谨慎多了，但也更清晰了。

不是不用 loop。

而是：

• 只在重复、可验证、成本可控、工具足够的任务上用它
• 先做最小闭环
• 保留人的判断
• 小心理解债务
• 把安全当成成本，而不是事后补丁

这篇文章最成熟的地方，不在于它让人兴奋，而在于它提醒你：

真正的问题不是“我能不能搭一个 loop”，而是“我配不配拥有这个 loop”。