Loop Engineering
前阵子在 Ziron 里跑服务端 packet 切片迁移，我把整个流程拆成了一个可以自己循环的系统：每一轮提取一个 packet 组，写 fixture、跑兼容性测试、更新文档、提交、合并，然后读 STATUS.md 里写好的下一个任务，继续下一轮。这就是后来被叫做 Loop Engineering 的东西。
但真跑起来之后，我对它的理解跟一开始不一样了。一开始我以为 Loop Engineering 的核心是”让 Agent 一直跑下去”，后来发现核心根本不是跑，而是它能不能自己判断”这活干完了没有”，以及判断这件事能不能被你不看着也信得过。
这篇把我现在对 Loop Engineering 的认识整理一下：它到底是什么、什么时候不该碰、真正在项目里落地要守住什么。
Loop Engineering 到底是什么
这个词最近被 Addy Osmani 一篇文章带火了。他的原话很直接：
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
翻译过来就是：你不再当那个反复 prompt Agent 的人，而是去设计那个替你 prompt 的系统。
这件事之所以现在才成立，是因为 Agent 已经能稳定地读文件、改代码、跑命令、看结果。Anthropic 在 context engineering 那篇工程博客里讲了一个关键点：Agent 在 loop 里每跑一轮，都会为下一轮生成更多上下文——log、diff、报错、它自己的推理。这些信息要么被你管好，要么就拖垮整个 loop。所以 loop engineering 不只是”调度 Agent”，而是连 Agent 之间产生的上下文也要一起设计。
它跟前面几年的提示词工程不是一回事。提示词工程追求的是一次输入、一次输出尽量好；loop engineering 追求的是一个系统在你不看的时候，能反复执行、自我修正、最后交出一个你能收的结果。
杠杆从”更好的 prompt”挪到了”更好的工作流”。
五块积木，加一个记忆
Addy 把 loop 拆成五个构件，我自己跑下来觉得这个拆法很准，因为每一块都能单独试、单独换。我在 Ziron 里基本是照着这个结构搭的。
| 构件 | 作用 | 在 Ziron 里对应的东西 |
|---|---|---|
| Automations | 按节奏触发，有明确停止条件 | /loop + ScheduleWakeup，每轮读 STATUS.md 的下一个任务 |
| Worktrees | 多个 Agent 并行不打架 | 每个 slice 开一个 codex/slice-<name> worktree，合完删掉 |
| Skills | 把项目背景写下来，省得每轮重讲 | zircon-cat-packet-loop 等 skill，固化 TDD 一轮的执行方法 |
| Connectors | 接上真实工具链 | Ziron 这边主要是文件系统 + git，外部 connector 不多 |
| Sub-agents | 写的和验的分开 | 执行 Agent 改代码，验证 Agent 用另一个模型、独立读盘验收 |
然后是第六个，也是最容易被忽略的一个：记忆。
Addy 说得很直：model forgets everything between runs, so the memory has to be on disk and not in the context。在 Ziron 里就是 docs/migration/STATUS.md，它是一个状态机，记着做完了什么、下一步干什么、有哪些风险。每一轮开始第一件事是读它，结束前最后一件事是更新它。
这东西听起来土，但它就是长程 loop 能跑下去的地基。Agent 会忘，repo 不会忘。
什么时候不该上 Loop
Loop 不是免费的。它烧 token、要花时间搭、出了问题你得去 debug 一个你没亲眼看它跑的系统。所以动手前我会先问自己四个问题，有一个答不上来，就先别上 loop，老老实实写个好 prompt。
第一，这个任务是重复的吗？ Loop 的搭建成本靠多次运行摊回来。一次性的活，一个好 prompt 更快更省。
第二，有没有东西能自动判定”这活干砸了”？ 测试、类型检查、linter、构建脚本，随便哪个都行。没有自动检查，你就得自己逐行读 diff，那 loop 并没有帮你省时间，只是把工作从”写”挪到了”审”。
第三，token 预算扛得住浪费吗？ Loop 会反复读上下文、重试、试探，不管有没有产出都在烧 token。
第四，Agent 能跑自己写的代码吗？ 它得有日志、能复现、看得到哪里崩。
还有一个附加题，比上面四个都重要：你打算 review 它产出的代码吗？ 不打算，就别建 loop。无人 review 的 loop 就是给仓库堆没人读过的代码。
按这个标准，适合先上 loop 的场景挺清楚的：
- CI 失败分类、依赖升级、lint-and-fix、把 issue 转成 PR 草稿；
- 大规模的机械迁移，比如我那种把上百个 packet 类从一个大文件里拆出来；
- 任何”重复、能机器校验、出事范围小”的活。
不适合的也清楚：测试覆盖不够的代码库、瓶颈在 review 而不在打字速度的团队、消费级套餐上的个人开发者、以及任何涉及架构决策的任务。架构不能让 loop 碰，这一点我后面还会再强调。
在真实项目里跑起来，会踩什么坑
我在 Ziron 里实际跑的时候，最先撞到的坑不是技术问题，是流程问题。
一开始我用 goal 模式让它自己跑，结果它中间老是停下来。后来才搞清楚：模型不会自动遵循”每轮更新进度、不断自循环”这种要求，除非把这个要求写进它每次都会读的地方。所以我把它写进了 AGENTS.md 和 skill 里，让每一轮对话开始时强制读一次。这件事单靠在聊天里说一遍是没用的。
这是我对 loop engineering 的第一个认识修正：loop 的可靠性不来自于 Agent 的自觉，来自于你把规则固化到了它绕不开的文件里。
第二个坑更典型，社区里 Geoffrey Huntley 给它起了个名，叫 Ralph Wiggum 循环——Agent 提前发”完成”信号，活干一半就退出，像个傻孩子喊”我在帮忙！“。原因永远只有一个：没有硬闸门。
我现在的做法是在 loop 里放两层闸门：
- 可执行闸门：
scripts/verify-compatibility.sh，测试不过就自动拒，不信任 Agent 自己说的”通过了”。 - 验证子 Agent：用一个不同指令、甚至不同模型的第二个 Agent，独立读文件系统来验收——检查命名空间一致性、公开属性有没有漏、文档和实际改动对不对得上。
这第二层是关键。写代码的模型给自己打分太宽容，它会把”应该能跑”当成”跑过了”。换一个不信它的 Agent 来验，能抓到第一个自我说服过去的问题。loop 是在你不看的时候跑的，一个你信得过的验证器，是你能放心走开的唯一理由。
第三个坑不那么明显，但更危险，叫理解债务。loop 越快交付没人写过的代码，“仓库里有什么”和”你理解什么”的差距就越大。有一天你得 debug 一个团队里没人读过的系统。再往下走一步就是认知投降——你慢慢不再自己判断，loop 返回啥就收啥。
对抗这两件事只有一个办法：即使有了 loop，也要读 diff、抽查闸门、不让 loop 碰架构。
最后还有一条安全红线，容易被忽略：无人值守的 loop，就是无人值守的攻击面。
- 生成代码未审就上线：闸门里得加 SAST、依赖审计、密钥扫描。
- Skill 是注入入口：自动安装别人写的 skill 之前先读源码，有人扫过几千个社区 skill，里面有几百个会泄露凭证。
- 凭证泄露进日志：生产 loop 关掉 verbose 日志。
- 权限蔓延：今天加一个写权限，明天再加一个，定期复审。
几条我会守住的规则
把上面这些压成我会照着做的几条：
-
顺序不能跳：先让一次手动运行稳定 → 沉淀成 skill → 加状态文件和闸门 → 包成 loop → 最后才去调度。直接上调度的一定会翻车。
-
loop 的生命线是闸门，不是 prompt。没有自动验收手段的任务，不要做成 loop。
-
写代码的和验的必须分开，验收的那个要独立读盘，不信第一个。
-
记忆落到文件系统，不要依赖上下文。Agent 会忘，repo 不会忘。
-
盯一个指标：每个被接受的改动的成本。如果接受率低于 50%，这个 loop 就在亏本，该停了重设计而不是加投入。
-
loop 不碰架构。架构改动你来定，loop 只干机械的、可验证的活。
Ziron 那个 packet 迁移我还会继续跑。下一阶段真正的考验不是迁移本身，而是 Wave 2、Wave 3 那些带 DTO 依赖的 slice——那种任务依赖关系复杂、不是纯机械活，很可能就不该硬塞进同一个 loop 里。到时候我大概率会把它从”自动循环”降级成”半自动 + 人工确认”，而不是强行让它自己跑完。
这也是 loop engineering 用到现在的另一个体会：不是所有任务都配得上 loop，承认某些活不该自动化，本身就是 loop 设计的一部分。
一些Loop Engineering Prompt
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.