Loop Engineering：设计一个能自己停下来的 AI 系统

学习来源：zostaff《Loop Engineering: The Anatomy of an Autonomous Loop》

提示词工程正在让位给系统设计

AI 辅助编程的讨论过去一直绕着 prompt 转：怎么写得更清楚，怎么加 few-shot，怎么让模型一次给出好答案。现在风气变了。越来越多人发现，真正卡住效率天花板的不是单次提示词的质量，而是你能不能设计一个让 agent 持续工作、自我修正、达成目标后自动停止的系统。

prompt 的杠杆在”怎么问”。loop 的杠杆在”怎么设计一个能自己跑完的过程”。

当你面对一个需要多轮迭代、持续反馈、逐步收敛的任务时，真正的问题不是”这轮 prompt 怎么写”，而是：

• 谁决定下一步做什么？
• 怎么判定”做完了”？
• 失败后怎么继续，而不是从头开始？
• 什么时候该停下来，而不是一直烧钱？

这些问题超出了 prompt 工程的范畴，进入了 Loop Engineering 的领域。

Loop 不是”更长的 prompt”

很多人把 loop 理解为”把很多 prompt 串起来”。其实结构完全不同。

Prompt 解决的是”这一轮怎么问”。Loop 解决的是”这个过程怎么自己跑完”。

一旦人从回路中退出，系统就必须自己回答三个问题：做什么、怎么算过、什么时候停。这三个问题没设计好，loop 就不是自动化工具，而是一个昂贵且不可控的随机游动。

五个组成部分，两个决定生死

一个工作循环通常由五部分组成：

1. Finding work：发现任务来源，例如失败的测试、未关闭的 issue、需要更新的文档。
2. Plan：把目标拆成可执行的步骤。
3. Action：执行具体动作，例如改代码、调 API、生成文件。
4. Verification：检查结果是否满足目标。
5. Memory：记录状态，让下一轮从当前位置继续。

Finding work、Plan、Action 在现代模型手里已经相对成熟。模型会读上下文、会拆任务、会写代码。但 Verification 和 Memory 才是 loop 的生死线，因为它们直接回答”做什么”和”什么时候停”。

Verification 必须是外部、客观的

让写代码的模型自己评判自己的代码，等于制造一个自我确认的循环。模型不会故意作弊，但它对自己的产物过于宽容，总能找到理由让自己通过。

有效的 verification 不能是另一个 agent 的”看起来不错”。它必须是能明确说”不”的东西：测试、构建、类型检查、linter、可量化的指标阈值。

代码领域之所以最早长出 loop，不是因为它更高级，而是因为它是世界上最容易被客观验证的东西之一。测试要么通过，要么失败，没有中间状态。

Memory 必须落在磁盘上

模型在单次运行结束时会忘记对话。如果 loop 的记忆只存在于聊天上下文里，下一轮就是失忆状态。状态必须外化到文件系统：一个 STATUS.md、一个 state JSON、一组 git 提交。

这也顺便解决了长上下文退化的问题。上下文越长，模型注意力越稀薄，质量越容易下降。每一轮从干净的上下文开始，从文件中读取状态，loop 就不会淹没在自己的历史里。

Maker 和 Checker 应该分开

让做工作的 agent 和检查工作的 agent 分开，是 loop 里一个结构性很强的做法。

做工作的 agent 可以快、可以便宜、可以积极尝试。检查工作的 agent 应该慢、严格、带着对抗性视角审查结果。例如，用 Claude Sonnet 写代码，用一个配置成 adversarial reviewer 的 Opus 专门挑毛病。

这个分离的成本是真实的。checker 会跑自己的模型和工具，账单可能翻倍。所以它不应该被滥用。只有在出错代价高的地方才值得启用独立 checker：安全、数据一致性、核心架构。小的、可逆的改动不需要双重审查。

制动器比引擎更重要

Loop 最危险的一面不是”做不好”，而是”停不下来”。

一个典型事故：两个 agent 互相礼貌地给对方找活干，没有 step limit、没有 budget ceiling、没有 stop condition，结果 loop 无人看管地跑了 11 天，烧掉数万美元。这不需要 AI 恶意失控，只需要缺少一个上限。

所以 loop 设计的第一原则应该是：先限制它能破坏什么，再决定它要做什么。

最小可用的制动器集合：

1. Step cap：硬性迭代次数上限。没有任何理由让 loop 无限跑下去。
2. Budget ceiling：单次或单阶段的钱上限。超过就停止。
3. Blast radius：隔离工作区。用 git worktree、容器或独立分支，让 loop 只接触你愿意被修改的东西。
4. Circuit breaker：同样的错误连续出现，说明 agent 已经卡住，不是在修复。此时应该停止并叫人。
5. Liveness check：每次运行写入 heartbeat，停止更新意味着 loop 已经死了，而不是在默默工作。

这些不是可选的增强功能。它们是 loop 的基础设施。没有它们，loop 不是资产，而是负债。

Loop 的四种死法

理解 loop 怎么死，比理解 loop 怎么跑更重要。失败的 loop 通常死于以下四种情况之一：

构建顺序：先手动，再固化，最后自动化

如果你想把某件事做成 loop，按这个顺序来：

1. 先手动跑一次完整流程，确认它在人的控制下能稳定工作。
2. 把流程固化成一个 skill 文件，避免每次都粘贴大段 prompt。
3. 用循环包装这个 skill，加入验收条件和停止条件。
4. 最后才把它放上 schedule。

跳过前面的步骤，直接自动化一个还没跑通的东西，是 loop 在夜里失控的典型路径。

关于成本也要诚实。那些”一百个 agent 的舰队”确实存在，但成本通常是每月数十万美元，且由大型机构资助。普通人的计划里，值得做的 loop 应该是小的、有上限的、指向一个具体且重复的任务的循环，而不是一个宏大 agent swarm 的复制品。

工程师的角色变了，但责任没变

Loop 把工程师从执行者变成设计者。你不再直接写每一行代码，而是建造一台能写代码的机器。但这台机器开向哪里、会不会失控、它做的事情你是否还理解，都变成了你的责任。

两个人可以构建完全相同的 loop，得到完全不同的结果。一个人用 loop 加速自己深刻理解的工作。另一个人用 loop 停止理解工作。Loop 无法区分他们。人可以。

最实用的起点是：找一个你最无聊、但仍在手动做的任务，用一个带制动器的小循环包住它。小到你还愿意阅读它提交的每一个 diff。没有人一开始就用两百个 agent 发两百个 PR。他们都是从自己信任的一个 loop 开始的。

总结

Loop Engineering 不是关于如何让 agent 更自动地做事，而是关于如何设计一个能自我验证、自我修正、自我停止的系统。

核心问题不是 prompt 怎么写，而是：

• 有没有外部、客观的 verification 机制？
• 状态是不是落在文件系统而不是模型记忆里？
• 做工作和检查工作的角色是否分离？
• 有没有 step cap、budget ceiling、blast radius 和 circuit breaker？
• 自动化之前，有没有先手动跑通并固化成 skill？

先装刹车，再踩油门。先限制爆炸半径，再设计任务。