Loop engineering 不是让你把 prompt 写得更长，而是让你把 agent 放进一个可持续运行的控制系统里。
一句话定义
如果 prompt engineering 解决的是“这一轮怎么问”，那么 loop engineering 解决的是“这个任务如何持续跑、如何读写状态、何时停止、谁来验证”。
它和普通 prompt 的区别
- prompt 关注单次调用的指令质量
- loop 关注多轮运行的调度、状态、验证和人工接管
- prompt 更像战术口令，loop 更像一套长期运行的流程设计
一个健康 loop 的基本链路
调度 -> triage -> 读写状态 -> 隔离执行 -> implementer -> verifier -> 外部系统 -> human gate
这条链不一定每次都完整出现，但多数能长期运行的 agent 工作流都绕不开这些环节。
五个关键构件
- 调度：决定 loop 什么时候被唤醒
- worktree / 隔离环境：避免自动改动直接污染主工作区
- skills / 项目规则：让 agent 知道仓库边界与执行纪律
- connectors：把 GitHub、Linear、Slack 等外部系统接进来
- sub-agents：把 maker 和 checker 分开，不让同一个 agent 自证正确
真正让 loop 可持续的，不只是这五个构件，而是它们背后的状态中枢，例如 STATE.md、run log、budget 和记忆文件。
为什么应该先做 L1
很多团队失败，不是因为不会写 prompt，而是太早追求全自动。更稳的路径通常是：
- L1：先报告，不改代码
- L2：在 verifier 和隔离环境保护下做低风险修复
- L3：在预算、审计和 kill switch 充分到位后，再考虑更高自动化
哪些任务最适合 loop
- daily triage
- PR 跟进与提醒
- CI 清理与失败归因
- changelog / release note 草稿
- 依赖升级与低风险维护
这些任务的共同点是：重复、高频、边界相对清晰。
风险边界
loop 的问题从来不只是“偶尔错一次”，而是会把错误重复放大。所以预算上限、run log、denylist、人工 gate 和 kill switch 必须前置，而不是出事故后再补。
这也是 loop engineering 最重要的判断：能停下来的 loop，才值得继续自动化。