原来我一直在做的，是 Loop Engineering

随着 Claude Fable 5 发布 “Loop Engineering” 也火了，听说 Fable 5 是专门为 Loop Engineering 训练的模型。

为什么又出现一个 “Loop Engineering”。

一个是：现在很少只跑一个 Agent，通常是几十个、几百个，甚至更多。
另一个是：我不再和 Agent 对话，而是和 Loop 或 routine 对话，由它替我提示 Claude。

我发现，这件事我已经在做了，只是没给它起名字，或者统称为 “Harness Engineering”。

我一直在把重复提示 Agent 的动作往外抽：写 skill、写 state、写 proof gate、让子 Agent 互相检查、让任务自己推进、让失败结果留在文件里，下一轮别从头犯傻。以前我把这叫 harness、workflow、mission、automation，或者更土一点，叫“睡眠编程”。

Addy Osmani 发了一篇 X Article，标题就是 Loop Engineering。

Boris Cherny 也讲：

I don’t prompt Claude anymore. I have loops running that prompt Claude.

原来不是我一个人在烦“亲自提示 Agent”这件事。大家都烦。只是现在有人把它命名了。

我不想再当 Agent 的人肉调度器

用 Agent 写代码，刚开始爽点很明显。你把任务说清楚，它能读文件、改代码、跑测试、解释失败。有些活确实快很多。

但用多了以后，另一个问题冒出来：你开始变成人肉调度器。

它要跑命令，你批准。
它测试失败，你贴日志。
它改错方向，你纠正。
它说完成了，你看 diff。
它卡住了，你补一句“继续”。
它忘了上轮失败原因，你再解释一遍。

一天结束，你好像没写多少代码，但一直在照看一个很勤快的实习生。

我最烦的是那种 5 分钟一次的小打断。不是大决策，也不是架构判断，就是一些机械动作：看 CI、复制报错、确认命令、提醒它不要动某个目录、让它把结果写清楚。

这些动作单次看都不重。
加起来很烦。

我后来开始把这些东西写进系统里。比如任务开始前先读项目规则；失败要写 state；改完必须跑验证；写代码的 Agent 不能自己给自己盖章；涉及敏感文件就停下来交给人。

当时没觉得这是一个新范式。只是觉得，不这么做，我会被 Agent 拖死。

现在看，这就是 Loop Engineering 的入口：不是让 Agent 更会聊天，而是把你反复说的话变成循环的一部分。

多开 Agent 不是 Loop

我也经历过那个阶段：开几个 Agent 并行跑，觉得自己像突然有了一个小团队。

一个修 bug。
一个写测试。
一个看文档。
一个查 CI。

看着很忙。输出很多。心理上很有生产力。

十分钟后开始翻车：两个 Agent 改了同一个文件；一个在旧上下文里跑；一个把失败归因到不存在的配置；还有一个自信地说完成了，但测试根本没跑到目标分支。

那不是 Loop。
那是设计缺陷。

Loop 至少要有闭环：

触发
执行
验证
记录状态
决定继续、停止，还是交给人

我现在对这个边界比以前更敏感。因为很多所谓 autonomous agent demo，其实只有前两步：触发和执行。看起来会动，但不会验证，不会记住，不会停。

这东西上生产很危险。

一个手动 Agent 跑偏，通常改坏一小块。一个跑偏的 Loop，如果每 10 分钟醒一次，还拿着比较大的权限，它可以很稳定地把错误扩大。更糟的是，它会一边扩大，一边给你写很礼貌的进度报告。

所以我现在看 Loop，第一眼不看它“能做什么”，先看它“怎么停”。

有没有 proof gate？
有没有 state？
有没有边界？
有没有升级给人的条件？
有没有禁止触碰的目录和操作？

没有这些，就别急着叫 Loop。叫自动烧 Token 更准确。

Gate 比 prompt 重要

这也是我最近越来越强的感觉：Agent 系统里，prompt 没以前那么稀缺了，Gate 更稀缺。

很多人还在纠结怎么写一个更好的提示词。我不是说 prompt 不重要，它当然重要。但如果你的系统没有硬验证，prompt 写得再漂亮，也只是让 Agent 更自信地输出。

Gate 可以很土。

npm test 过不过。
typecheck 有没有红。
旧版本失败、新版本通过的 regression test 有没有补。
desktop app 能不能真的打开，点到那个按钮。
PR diff 有没有碰 auth、payment、delete data。
连续两轮失败，是不是自动停下来找人。

这些东西不性感，但能救命。

Agent 的验证不应该只停在 unit test。尤其是 UI、桌面应用、自动化流程这些东西，真正的问题不是某个函数返回值，而是用户路径能不能走通。

那就让 Agent 自己走。

打开 app。
点击入口。
输入内容。
看截图。
发现 staging 挂了，就去查状态。
修完再跑一遍。

这听起来慢，也不酷。可是工程里很多靠谱的东西本来就不酷。CI 不酷，日志不酷，回滚不酷，权限边界也不酷。真出事时，救你的就是这些。

Loop Engineering 如果只讲“让 Agent 自己跑”，我没兴趣。
它真正有价值的地方，是把“跑完怎么证明”也放进循环里。

上下文也要从“喂”变成“取”

我过去非常喜欢给 Agent 塞上下文。项目背景、目录结构、历史坑、编码规范、测试命令，能塞就塞。尤其是不熟的 repo，我会把 prompt 写得像离职交接文档。

心理上很安全。
我都说清楚了，它写错就不是我的问题。

但后来发现，上下文太多也会出问题。它会把 Agent 锁进你的假设里。你说“可能是 A 文件的问题”，它就盯着 A 文件挖半天，哪怕真正的问题在 B。你把路线画得太细，它就不探索了。

现在我更倾向另一种方式：少预塞，多给入口。

别每次把项目规则贴进 prompt。放进 AGENTS.md。
别每次解释领域语言。放进 CONTEXT.md。
别每次讲失败历史。写进 state file。
别每次手动复制 CI 日志。给 connector。
别每次教它怎么做某类任务。写成 skill。

Agent 会忘，文件不会。

这句话我最近越想越觉得重要。很多团队说自己在做 context engineering，其实只是写了更长的 prompt。那还不够。真正适合 Loop 的上下文，应该能被 Agent 自己拉取，自己更新，下一轮继续用。

否则人还是没退出。
只是从“写代码的人”，变成了“喂上下文的人”。

这个词会不会留下来

技术圈每天都有新词。大部分词过几周就散了。

但 Loop Engineering 我觉得会留下来，不是因为它多漂亮，而是因为它命中了一个真实迁移：工程师的工作对象正在变。

以前我们写代码。
后来我们写 prompt。
现在我们开始写会重复运行的工作制度。

这个制度可能长这样：

每 30 分钟检查 CI。

只处理：
测试失败
lint 失败
typecheck 失败
依赖安装失败

不处理：
认证
支付
权限
数据删除
数据库迁移
生产部署

必须：
复现失败
修最小范围
跑对应验证
写回 state
失败两次后交给人

这不是一个“聊天提示词”。
这更像一条工程规则。

我现在很多工作也在往这个方向走。把一次性经验沉淀成 skill，把任务进度写进 state，把验证从“模型说完成”改成“工具跑过”，把写代码和审查拆给不同 Agent，把高风险操作挡在人类面前。

这些东西看着不如“AI 自动写代码”爽。甚至有点笨。

但我越来越相信，笨一点是好事。Loop 如果太聪明、太自由、太会自我解释，反而可怕。它最好有点死板：该停就停，该拒绝就拒绝，没证据就不要说完成。

别一上来就梭哈

我现在不会建议团队一上来就做“自动修所有 bug”的 Loop。

太大了。

我会从小地方开始：CI failure triage、依赖升级、lint fix、flaky test 复现、stale PR babysitter。它们有几个共同点：重复、麻烦、有验证、失败成本低。

不要一开始就碰：

认证。
支付。
数据删除。
生产部署。
数据库迁移。
架构重写。

这些地方不是 Agent 永远不能碰，而是不适合作为第一个 Loop。你还不知道自己的 Gate 够不够硬，state 有没有用，权限边界会不会漏，review 带宽能不能接住。上来就让它碰核心链路，本质上是在拿生产系统测信仰。

AlphaSignal 那个四条件测试我觉得挺实用：

任务是不是真的重复？
有没有自动验证？
Token 预算能不能承受空跑和重试？
Agent 有没有日志、复现环境、运行代码这些工程师该有的工具？

少一个，就先别上 Loop。

尤其是 Token 预算。Loop 会重读、探索、失败、重试。对公司是杠杆，对个人开发者可能就是账单刺客。一个每 10 分钟醒一次的 routine，如果没有明确边界，烧钱速度比想象中快。

工程判断里应该有账单。
没有账单的自动化讨论，容易烧光钱包。

最后人还是要负责

不要把 Loop Engineering 讲成“人类退出”。

人不会退出。
至少不该退出。

人应该退出的是重复提示、机械审批、低价值搬运。不是退出判断、责任和理解。

如果你只看 Loop 产物，不看它怎么做，几个月后会有一个新债务冒出来：理解债。PR 都能合，测试都能绿，但团队没人说得清为什么这么改。直到某天事故来了，大家才发现系统手感已经没了。

技术债通常臭在代码里。
理解债藏在人脑子空掉的地方。

所以我更愿意把 Loop Engineering 看成一种工程纪律，而不是一个炫技概念。

它问的问题很朴素：

你每天重复提示 Agent 的话，能不能写成 routine？
你每次手动复制的上下文，能不能放到 Agent 自己能取的地方？
你每次靠肉眼确认的完成，能不能变成 proof gate？
你每次让 Agent 从头撞墙的失败，能不能写进 state？
你能不能离开 20 分钟，回来不用先深呼吸？

如果不能，那还不是 Loop。

只是你养了一个很勤快、很会说话、还需要你一直盯着的实习生。

所以 Loop Engineering 只是 Harness Engineering 的其中一环。