Loop Engineering：让自治系统停在可判断的地方

我想做的 Loop Engineering，其实不是让一群 AI 永不停歇地开会，而是把目标、执行、判断和人类授权分开。系统可以持续工作，但必须在关键位置停下来，给出足够清楚的证据，让下一步仍然是一项可以被选择的行动。

整个结构从一个在最开始确定的 Goal 出发。Orchestration 负责把它拆成关键里程碑；Labor 负责完成具体工作；Judge 负责判断里程碑是否真的达成；Scrum 则在需要的时候做一次检查和调整。每隔 24 小时，系统还要强制暂停并输出报告，由人类决定继续、重规划还是终止。

这里最重要的不是“循环”两个字，而是循环里每一种权力都被放在不同位置。制定任务的人不直接宣布自己完成了任务，执行任务的人也不能只靠自述获得通过。

Goal 先确定，Orchestration 只负责分解

Goal 在一开始由人类设定。它不是一句不断被系统重新解释的口号，而是一份有版本号的契约。Orchestration 可以改变路径、拆分任务、调整先后顺序，却不能静默地把最终目标换成另一个更容易完成的目标。

每个里程碑最好同时写明成功条件、所需证据、资源预算和升级规则。这样 Orchestration 的工作才是调度，而不是一边出题、一边判卷。

Labor 交付产物，不交付“我已经完成”

Labor 层只做工作。它可以写代码、运行测试、整理数据或生成报告，但它提交给下一层的必须是能够检查的产物。执行者的总结可以帮助阅读，却不能替代证据本身。

这条边界很重要。否则系统很容易把流畅的语言误当成真实进展，把一个说得很完整的答案误当成已经发生的工程结果。

双 AI Judge 先独立，再耦合

Judge 不应只有一个。两个 AI 可以采用不同的审查方向：一个关注证据是否充分、结果能否复验；另一个专门寻找反例、风险、回滚缺口和目标漂移。

它们先独立形成结论，避免互相锚定；然后交换各自最强的反对意见，再决定是否修订。所谓“耦合”不是让两个 AI 从一开始就一起讨论，而是让独立判断在之后发生碰撞。共识可以放行，有限分歧可以附条件进入 Scrum，过大的分歧则直接升级给人类。

Scrum 是审核时刻，不是永动机

Scrum 没有必要持续不停地进行。它更像一个按条件触发的控制点：里程碑完成时检查一次，任务连续失败时检查一次，外部信息改变时检查一次，人类要求介入时再检查一次。

如果当前工作正在稳定推进，也没有新的判断需要消费，Scrum 就应该保持安静。循环的目的不是制造活动，而是让必要的调整在正确的时刻发生。

24 小时后，继续运行的权力回到人类

无论系统多么自治，每 24 小时都要强制停下来，输出 Goal 当前版本、里程碑完成情况、Judge 判定及原始证据、资源消耗、开放风险和下一步计划。

这份报告不是例行汇报，而是一次重新授权。人类可以继续、修改、回滚或终止。24 小时也不是必须等满的时间：高风险操作、预算越界、目标矛盾、反复失败和 Judge 的重大分歧，都应该提前触发同样的暂停。

Loop Engineering 真正要工程化的，不是 AI 的忙碌程度，而是自治系统什么时候必须停下来，承认自己需要一次外部判断。