Trust Topology — 从不可靠的 Agent 中工程化信任
> 一句话版本：一位 35 年经验的软件工程领导者用 97 天、5109 次 gate check 的实战数据证明：AI Agent 系统的可靠性取决于验证门的排列方式，而不是模型本身的能力。核心洞察和分布式系统一样——"让协议可靠，而不是让节点可靠"。
| 项目 | 信息 |
|---|---|
| 来源 | https://michael.roth.rocks/research/trust-topology/ |
| 作者 | Michael Rothrock（35 年软件工程经验） |
| 类型 | 研究演示（slides 形式） |
| 数据规模 | 5,109 gate checks / 1,450 rejections / 97 天 / 8 项目 |
| 前置研究 | [543 Hours of Autonomous AI](https://michael.roth.rocks/research/543-hours/) / [Gate Analysis](https://michael.roth.rocks/research/gate-analysis/) |
核心内容
一句话论点
> "Alignment is undecidable. Trust is measurable."（对齐是不可判定的，信任是可度量的。）
核心问题
LLM 输出"看起来对但实际错"，这是 CI/CD 从未遇到过的问题：
- 不完整：遗漏需求、未实现组件、忽略边界情况
- 捏造：能编译能过 lint 但做错事
- 自相矛盾：表面看起来合理，内部逻辑矛盾
实践者的问题：既然不能信任模型输出，如何工程化出可靠的系统？
答案：和分布式系统一样——让可靠性成为协议的属性，而不是节点的属性。AI Agent 只是又一个不可靠的组件。
四阶段论证
1. 问题：LLM 输出不可预测，但失败有结构可利用
2. 重新定向：分布式系统研究者几十年前就解决了类似问题
3. 框架：四个属性构成 gate 拓扑的设计演算
4. 动态：拓扑会演化，系统在不换模型的情况下学习
实证数据：87% 的错误是可预测的
| 错误类型 | 占比 | 说明 |
|---|---|---|
| **遗漏（Omission）** | 49% | 忘了做某事（最容易被 gate 抓到） |
| **系统性错误（Systematic）** | 38% | 一致地做错某事 |
| **不一致（Incoherent）** | 12.7% | 内部自相矛盾 |
关键发现：
- 文件级 code review 完全抓不到不一致错误（0%），因为视野太窄
- 11 小时的 release arc 有 10% 不一致，更长的 feature arc 有 19.8%
- 分解（Decomposition）把不一致转化为遗漏——Agent 不是自相矛盾，而是忘了。遗漏是最容易在 gate 抓到的错误类型（checklist 就行）
四个诊断属性
1. Overlap Ratio（重叠率）
如果两个 gate 有 80% 的拒绝重合，你只有一个 gate 跑了两次。重叠率越低，每个后续 gate 贡献越大。
> "You need a different kind of gate, not more passes through the same one."
这解释了为什么 majority voting 和 reward model 在几百个 sample 后就 plateau——验证信号重叠度太高。
2. Verification Amplification（验证放大）
上游 gate 约束下游 gate 的输入。Plan gate（61% 拒绝率）在最前面过滤了最多的错误，让后续 gate 的负担更轻。
关键洞察：上游 gate 弱是最昂贵的问题——它会放过有缺陷的产物，浪费所有下游的算力。
3. Deterministic Ceiling（确定性天花板）
随机验证器（LLM 当 judge）能捕获不一致和系统性错误，但对遗漏无能为力——checklist、lint、test 这些确定性检查才能抓遗漏。每种 gate 类型都有它注定抓不到的错误。
4. Liveness Constraint（活性约束）
Gate 越多越安全，但越多越慢。系统必须在"安全"和"推进"之间找平衡。过多的 gate 会导致 Agent 永远无法交付。
三个设计杠杆
| 杠杆 | 控制什么 | 效果 |
|---|---|---|
| **分解（Decomposition）** | 推理链长度 | 有界任务 + 新上下文 → 不一致变遗漏 |
| **验证多样性（Verification Diversity）** | 重叠率 | 不同 artifact 类型的 gate 减少盲区 |
| **Oracle 路由（Oracle Routing）** | 升级路径 | 随机验证器在 auto-fix 和人工判断之间分流 |
四层 Gate 实际配置
| Gate | 检查数 | 拒绝率 | 最擅长抓 | 不一致检测 |
|---|---|---|---|---|
| Plan Review | 1,193 | 61% | 遗漏（54%） | 10.5% |
| Design Review | 1,491 | 37% | 系统性（48%） | 15.6% |
| Code Review（文件级） | 340 | 40% | 系统性（56%） | **0%** |
| Code Review（全上下文） | 2,085 | 28% | 遗漏（55%） | 16% |
人类意图的本质
意图是不可观察的。用户的目标在脑子里，每个产出物（spec、plan、design、code）都是意图的一个低保真投影。Gate 验证的是投影之间的一致性，而不是对意图本身的对应。这就是为什么系统需要升级路径（escalation）——有些不一致只有人类才能判断。
和 inference-scaling 文献的关联
- Brown et al. (2024): 弱模型多次采样 + 验证 > 强模型单次采样 → 但多数投票会 plateau
- Snell et al. (2024): 优化生成/验证的算力分配 = 14x 模型提升
- Lu et al. (2025): 不同模型家族做验证器 > 自验证（模型偏向接受自己风格的错误答案）
Trust Topology 解释了为什么这些结果成立：它们在组件层面操作，但问题本质是系统层面的。
Q&A：用 OpenClaw 写报告的具体例子
场景：用户发链接 → Agent 抓取 → 搜索 → 写报告 → 发布
没有 gate 的情况（现在的流程）：
- Agent 抓了网页，写了报告，直接发布
- 可能遗漏：忘了搜索补充资料、忘了保存 raw 文件
- 可能系统性：每次报告格式不一样、评分标准漂移
- 可能不一致：报告里说的和搜索结果矛盾
加了 gate 后：
Gate 1: Plan Review（生成前）
- Agent 先输出计划："我要抓这个链接 → 搜索这 3 个关键词 → 重点分析架构和与 Jay 的关联"
- Gate 检查：计划是否覆盖了用户意图？有没有遗漏关键维度？
- 抓遗漏 54%：比如"你忘了查 GitHub stars 和创建时间"
Gate 2: Content Review（写完后）
- 对照 plan 检查报告：plan 里说的每个点都覆盖了吗？
- 抓系统性 48%：比如"你 plan 说要分析与 Jay 的关联，但报告里这段只有一句话"
Gate 3: File-scope Check（确定性）
- 脚本检查：raw 文件存在？log.md 追加了？deploy 成功？
- 抓遗漏：
ls docs/deep-research/raw/slug-raw.md不存在 → 拒绝发布
Gate 4: Cross-reference Check（全上下文）
- 用不同模型（比如用 Qwen 检查 GLM 写的报告）对照原文和报告
- 抓不一致："原文说 AGPL-3.0，报告里写成了 MIT"
重叠率的体现：
- Gate 1 和 Gate 2 都检查"是否覆盖了用户意图" → 重叠高 → Gate 2 在这方面贡献小
- Gate 3（确定性脚本）和 Gate 4（LLM 全文检查）检查的东西完全不同 → 重叠低 → 互补性强
验证放大的体现：
- 如果 Gate 1 漏过了（没发现 plan 缺了"评分"），Gate 2 的负担就变重了——它要在完整报告里发现缺了评分，比在简短 plan 里发现难得多
- 上游弱 = 下游贵
分解把不一致变遗漏的体现：
- 如果不分解（一个 Agent 从头写到尾），它可能在报告前半说"这个项目很安全"，后半说"这个项目有严重安全风险" → 不一致，很难抓
- 如果分解（Agent A 抓数据，Agent B 写报告），Agent B 根本看不到 A 的完整推理过程，所以不会"自相矛盾"，但它可能"忘了"提到安全性 → 遗漏，checklist 一扫就出来
Gate 的两种类型
确定性 gate（脚本/规则）：
- 跑测试、lint 检查、checklist 逐项勾选
- 例：
ls raw-文件存在? && grep '评分' report.md?→ 通过/不通过 - 优点：100% 可靠，永远能抓到它能看到的错误
- 缺点：只能抓预设的错误类型（遗漏、格式问题）
随机性 gate（LLM 当 judge）：
- 让另一个 LLM 审查产出物是否满足要求
- 例：把报告丢给 Qwen，问"这个报告有没有事实错误或逻辑矛盾？"
- 优点：能理解语义，抓不一致和系统性错误
- 缺点：不可靠，同一个报告两次审查可能结论不同
Rothrock 的实际配置（4 个 gate 串联）：
用户需求 → [Plan Review] → [Design Review] → [文件级Code Review] → [全上下文Code Review] → 发布
LLM judge LLM judge LLM judge + lint LLM judge + test
拒绝率 61% 拒绝率 37% 拒绝率 40% 拒绝率 28%
不通过就打回去让 Agent 修改，通过才进入下一个 gate。
分析
这篇文章的价值：
- 实证驱动：5109 次 gate check，不是纸上谈兵
- 连接三个领域：分布式系统 + inference-scaling + 可计算性理论
- 可操作：给出了具体的 gate 配置和数据
- 反直觉发现：分解把"难抓的不一致"转化为"好抓的遗漏"——这是一个极好的工程设计洞察
- "验证不是检查正确性，而是检查投影之间的一致性"——精准且有深度
和上一篇（分布式 LLMs 博客）的关系：
- 上一篇：多 Agent 协调的理论不可能性（FLP、拜占庭、CAP）
- 这一篇：多 Agent 验证的实践工程框架（gate topology）
- 互补：一个说"问题是本质性的"，一个说"但可以这样工程化应对"
局限：
- 单人研究，8 个项目都是作者自己的，可能有偏差
- 没有公开代码/数据集供复现
- 框架偏概念性，缺乏形式化的数学定义
- "35 年经验"的个人背书 vs 同行评审
与 Jay 的关联：
- OpenClaw 的报告工作流本质上就是一个简单的 trust topology：web_fetch → 搜索 → 写报告 → 发布。没有显式的 gate，但 AGENTS.md 中的检查清单起了 gate 的作用
- Hermes Agent 的危险命令审批就是一个 gate：~40 正则 + 150 关键词 = 确定性检查
- 可借鉴：给 OpenClaw 的报告流程加上显式的 gate（plan review + content review），减少低质量报告
评分
| 维度 | 评分 (1-10) | 说明 |
|---|---|---|
| 实证严谨度 | 8 | 5109 次 gate check，分类详尽，单人但有数据 |
| 理论深度 | 8 | 分布式系统 + inference-scaling + 可计算性理论三连 |
| 实用价值 | 9 | 直接可操作的 gate 设计指南 |
| 创新性 | 8 | "协议可靠性"视角应用于 AI Agent，gate topology 概念新颖 |
| 可复现性 | 5 | 单人研究，无公开数据集 |
| 与 Jay 的关联 | 8 | 直接适用于 OpenClaw/coding agent 的验证流程设计 |
| **总分** | **7.7** | 当前 AI Agent 工程化信任的最佳实践框架 |
延伸阅读
这两篇文章是同一主题的理论 + 实践两面：
1. Multi-agentic Software Development is a Distributed Systems Problem — 理论（FLP、拜占庭、CAP）
2. Trust Topology（本文）— 实践（gate 设计、实证数据、工程框架）
建议按顺序阅读：先理解为什么问题本质上是分布式的，再看如何工程化应对。