核心发现
97天，5,109次门禁检查，1,450个真实拒绝。
结论反直觉：可靠性不是模型属性，是拓扑属性。
87%的错误有结构，可预测，可系统化处理。
| 错误类型 | 占比 | 特征 |
|---|---|---|
| 遗漏 | 49% | 需求没实现，组件没构建，边角案例被忽略 |
| 系统性 | 38% | 一贯性地用错误方式做某事 |
| 不一致 | 12.7% | 逻辑自相矛盾，表面看起来连贯但内含冲突 |
不一致只占12.7%。大多数失败是 mundane 的，不是 AI 的「幻觉」或「胡说八道」。
为什么 CI/CD 失效了
CI/CD 的前提是：被自动化的东西必须可预测地成功或失败。
LLM 输出违反了这个假设。它看起来正确，但可能失败于完全不同的方式。代码可能编译通过、lint通过、做的是错误的事。
处理看起来对但实际失败的输出，比 CI/CD 解决过的任何问题都根本性地更难。
分布式系统早就回答过这个问题
如何在无法信任组件可靠性的情况下，构建可靠的系统？
答案：让可靠性成为协议属性，而不是节点属性。
AI Agent 只是另一种不可靠的组件。
四个设计杠杆
1. 分解（Decomposition）：控制推理链长度。有边界的任务 + 新鲜上下文，把不一致转化为遗漏。
2. 验证多样性（Verification Diversity）：控制重叠率。在不同工件类型和范围上操作的 gate 重叠更少，暴露盲点。
3. Oracle 路由（Oracle Routing）：控制升级路径。随机验证器在三端之间调配——自动修复 / 人类判断——保持人类权威而不强迫人类审查所有内容。
四个诊断属性
重叠率（Overlap Ratio）
如果两个 gate 80%的情况下拒绝相同的产物，你没有两个 gate，你只有一个 gate 跑了两次。重叠率越低，每个后续 gate 贡献越多。
推理扩展文献遇到了这个问题：Brown et al. 发现超过几百个样本后，多数投票和 reward model Plateau 了。框架预测了这个现象：当验证信号高度重叠时，更多样本无法提供帮助。你需要不同类型的 gate，不是对同一个 gate 的更多次通过。
验证放大（Verification Amplification）
上游 gate 约束下游 gate 的输入。Plan gate 拒绝率最高（61%），因为它操作范围最广：从表达的人类意图创建的第一个产物。到达 code review gate 时，输入已经过了意图、结构、设计的验证。
弱的上游 gate 是最昂贵的缺口位置，因为它让有缺陷的产物通过，浪费下游周期的资源。这个不对称性只向前流动。
确定性上限（Deterministic Ceiling）
确定性检查（valid JSON, compilable code, schema conformance）提供硬保证。但结构性正确 ≠ 语义性正确。代码可以编译、通过所有 linting、符合 schema，但做的是错误的事。结构性验证和语义性验证之间的 gap 是最难残留错误所在，任何确定性 gate 都无法关闭它。
这形成了两个可靠性层：
- 确定性底层：可证明的——测试要么通过要么失败
- 随机性提升：估计的——LLM 审查者的判断
活性约束（Liveness Constraint）
每个 gate 缩小了可接受产物的空间。如果 gate 集体消灭了99%的 LLM 输出，系统将困在重试中。无法通过添加 gate 来达到完美可靠性。有一个实际极限。
55%的首次通过率表明系统已经以中等严格的接受集运作。再加一个 gate 会增加正确性保证但降低吞吐量。设计问题始终是：这个 gate 是否能捕获足够多的新错误来证明活性成本合理？
动态：边界迁移
边界不是固定的。
当语义 gate 反复拒绝同一类错误，这类模式可以被编入确定性检查。当人类反复通过 oracle 层做出相同的架构决策，这个决策可以被编码为语义规则由 LLM 验证器自动应用。
这就是系统的中心动态：系统学习而不改变任何模型。可靠性提高了，即使模型保持不变，因为验证拓扑从操作经验中学习。
上周需要 LLM 判断的东西 → 这周变成一个 regex
需要 oracle 判断的东西 → 下周变成语义规则
三层架构
- 确定性检查：schema validation, type checking, linting。接近零成本的硬保证。
- 语义检查：LLM 评估产物是否满足意图。中等成本的概率判断。
- Oracle 检查：人类做出决定。高成本、低吞吐量的ground truth。
核心架构：构建更大验证器，而非更大生成器
框架的一个推论：模型大小主要是活性参数。一旦你的 gate 对它们检查的属性是 sound 的，更大的生成器主要为你购买吞吐量——更高的概率在第一次尝试时就清除 gate。
这颠覆了行业当前的主流扩展策略。每个人在建更大的生成器。框架说：建更大的验证器。
小模型 → 生成候选产物
确定性 gates → 即时消灭明显失败（接近零成本）
只有通过结构验证的候选 → 才到达昂贵的随机验证器（大模型判断）
用几百 token 的评估价格，而不是几千 token 的生成价格。
数据：按 Gate 分类
| Gate | 检查数 | 拒绝率 | 主要错误类型 | 不一致 |
|---|---|---|---|---|
| Plan | 1,193 | 61% | 遗漏 (54%) | 10.5% |
| Design | 1,491 | 37% | 系统性 (48%) | 15.6% |
| Code (file) | 340 | 40% | 系统性 (56%) | 0% |
| Code (system) | 2,085 | 28% | 遗漏 (55%) | 16% |
关键发现：File-scoped code review 检测到0%的不一致错误，因为它的窗口太窄。这验证了分解的作用：边界上下文把不一致转化成了遗漏，后者更容易被 gate 捕获。
应用建议
从你已经有的 gate 开始：
- 识别 gate：Plan review、design review、tests、linters，你可能已经有了。给它们命名。
- 区分确定性和随机性：每个 gate，区分什么可以机械检查（结构、语法、schema）vs 什么需要判断（意图、质量、一致性）。先自动化确定性检查。
- 测量重叠：调整直到每个 gate 捕获其他 gate 遗漏的错误。如果两个 gate 拒绝相同的东西，你有冗余，没有深度。
开放前沿
修订周期：Agent 工作未通过 gate 时，下一次尝试只有31%的通过率。Agent 生成能力强但修订能力弱。这是管道中最弱的环节，也是最有希望的改进领域。
训练：在推理时过滤输出的相同验证拓扑可以塑造训练时的权重更新。RLHF 中的 reward model 是 gate。Constitutional AI 在训练期间使用随机子验证器。过程奖励模型在推理步骤级别 gate 中间推理。相同的形式词汇（重叠率、验证放大、确定性上限）适用于两种机制。