ReAct 循环（Thought-Action-Observation）在论文里很优雅，但拿到生产环境有三个致命缺陷：没有确定退出条件（Agent 可以无限空转）、没有目标连续性判断（用户中途插嘴就跑偏）、没有成本保护（烧光 API 额度）。
本文从一个 7262 行 Rust 代码的真实循环引擎出发，拆解了六层确定性约束如何为 LLM 的不确定性兜底。
第一层是 Pre-AL Gate——每轮循环前用纯 Rust 代码注入执行契约，告诉 Agent 当前在第几轮、锁定在哪个阶段、哪些验收还没通过。这层不经过 LLM，完全确定。
第二层是 LLM-as-Judge 评估器——用 temperature=0.0 的独立 LLM 调用判断 Agent 是否真的完成。关键设计是评估器的 system prompt 有一条铁律："说完成了不算，必须有证据。"
第三层是确定性优先评估——在调用 LLM 评估器之前，先用纯代码扫一遍 Agent 输出，检测阻塞标记、用户决策请求和基础设施错误。80% 的异常情况不需要浪费 LLM 调用。
第四层是阶段验收门禁（Phase Gate）——即使 LLM 评估器说"做完了"，纯代码的验收门禁还要再做一轮检查。支持四种检查：script（验证脚本是否成功执行）、file_exists（文件是否在磁盘上）、file_glob_count（文件数量是否达标）、user_confirmation（用户是否确认）。代码可以否决 LLM 的判断。
第五层是目标连续性裁决——用户中途输入新消息时，先用纯代码做词汇重叠度评分（阈值 0.24 判同一任务，0.08 判新任务），只有不确定的才调用 LLM 做最终裁决。
第六层是迭代上限和解析失败保护——最多 20 轮循环，评估器连续返回垃圾就暂停，防止烧光预算。
这套机制的核心思想是把"任务完成"从 LLM 的自我宣称变成可验证的客观事实。循环引擎还在每轮产生反馈记录（失败模式、应该避免什么、建议策略），最多保留 20 条，作为记忆系统的输入。
Anthropic 在 Building Effective Agents 里建议保持简单、优先透明、精心设计 ACI。生产级循环引擎完全对应了这三条，但多了一层关键设计：确定性否决权——LLM 的判断可以被代码否决，且代码优先级最高。
这就是为什么一个看起来简单的"循环调用 LLM"需要 7000+ 行代码。不是循环本身复杂，而是叠加足够多的确定性约束需要大量边界处理。