Loop Engineering 最稳的上线方式不是一步到位无人值守。 而是分 3 层放权： L1：只报告 每天扫 CI、issue、PR，输出摘要，不改任何东西。 L2：小修复 只处理 lint、文档、测试快照这类低风险任务，必须开 PR。 L3：有限自动化 只在明确白名单里自动处理，遇到权限、支付、数据库、生产配置立刻停。 先让它看，再让它动，最后才考虑自动合并。

Loop Engineering 最容易被误解成： 让 Agent 一直自动跑。 它真正重要的地方，是目标定义。 以前你写 Prompt，是告诉 AI 这一次怎么做。 现在你设计 Loop，是告诉 AI： 什么算完成。 怎么验证完成。 失败了怎么办。 哪些动作禁止做。 什么时候必须停下来。 这要求的是管理能力。

graph engineer vs loop engineer : 不是替代，是嵌套。Loop 是最小的 Graph（单节点自环）；Graph 里每个干活的节点内部仍在跑自己的 Loop。"Loop Engineering is dead" 是 Hame‍l Husain 的反讽炒作。完整递进链：Prompt → Context → Harness → Loop → Graph，每层向外包一层。 多 Agent 不是必然更好。《Nature Machine Intelligence》2026 年研究（260 种配置）：可拆分的金融任务多 Agent 最高 +80.8%；强顺序依赖任务最高 −70%；SWE-bench Verified 上四类多 Agent 架构全部 −1.3%~−12.8%。决定变量是任务可拆分性，不是复杂度。 选型规则（社区共识版）：一个 Agent + 工具 = Loop；多个 Agent + 交接 = Graph。当你在 Loop 里硬塞并行、独立评审、人工审批门时，就是该升级到 Graph 的信号。

很多人以为会用 /loop，就算懂 Loop Engineering。 其实差很远。 /loop 只是让 Agent 定期醒来继续干活。 Loop Engineering 要回答的是： 它醒来后读什么状态？ 怎么判断哪些任务该做？ 谁来验证它做对了？ 出错后什么时候停？ token 成本有没有上限？ 高风险动作谁批准？ 裸 loop 是自动化。 生产 loop 是一套小型操作系统。

个人开发者想试 Loop Engineering，不要一上来就做无人值守开发。 先做一个最小 loop： 1. 找一个重复任务 2. 写清输入来源 3. 写清完成标准 4. 写清禁止动作 5. 加一个检查命令 6. 连续失败 2 次就停 7. 输出一份状态报告 适合练手的任务： 整理 issue。 同步文档。 修 lint。 生成日报。 检查 CI。 先让它只处理低风险、可回滚、可验证的事情。

为什么硅谷大佬，都纷纷看好Loop？ 传统 prompting 的本质是：人类就是loop本身。 你写prompt → Agent输出 → 你review → 你再写下一个prompt → 循环往复。 每一步都依赖人类注意力、上下文记忆和决策带宽。一个人一天能有效驱动的token量和任务复杂度是有限的。 Loop Engineering的本质是：系统自己成为loop。 因此，循环工程比提示词工程更重要。 他们是基于这个判断：一旦loop成熟，手动提示词的性价比会直接崩盘！