来源：GitHub (★106)
URL: https://github.com/moonrunnerkc/swarm-orchestrator
精读日期：2026-09-09
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • 本项目是一个"proof-carrying runner and verifier"（携带证明的运行器与验证器），用于有界代码变更，核心主张是：它无法让门禁通过、无法将声明标记为已验证、也无法事后篡改记录。
  • 运行结果返回九个答案而非单一布尔值，其中"无人检查"（nobody checked）与"检查且失败"（checked and failed）是不同发现，将它们混为一谈是导致未执行任何代码的变更显示为绿色的原因。
  • 验证器设计为无依赖（dependency-free），只需 Node 即可离线检查他人证据；验证过程在无法被产出方触及的全新 checkout 中执行，产出方唯一传递的是补丁本身。
  • 覆盖循环需要 Node 22 或更高版本（运行时下限而非偏好），旧版本会因 Node 22 拒绝的选项而失败。
  • 密钥来自环境变量或 OS keychain，绝不来自提交的文件；提交并克隆的密钥文件意味着已与所有持有仓库的人共享。
  • 18 个真实仓库补丁中，有 4 个通过了项目完整测试套件但未通过隐藏验收测试——"门禁通过"与"工作完成"是两回事，只有 oracle 能判断后者。
  • 项目自我评估：12 个门禁中，6 个有实测证据通过，3 个部分通过，2 个未证实，1 个在规模上失败。

二、方法/架构拆解

  • 核心架构：三个关键机制——(1) 追加式哈希链账本（append-only hash-chained ledger）记录所有运行；(2) 门禁在数值棘轮（numeric ratchet）下重试，拒绝牺牲测试、断言或覆盖率的修复；(3) 签名包（signed bundle）携带自身验证器，任何人可离线检查。
  • 运行流程：声明意图修改的文件 → 通过记录每次工具调用的咽喉点（chokepoint）进行编辑 → 运行门禁 → 在棘轮机制下重试失败。验证流程：克隆基础提交到产出树无法触及的位置 → 应用补丁 → 在该 checkout 中运行检查。
  • 门禁输出示例：测试门禁（如 "2 collected, 2 passed, 0 failed"）、占位符检查、密钥扫描（secret-scan）、类型检查（typecheck，若无脚本则标记 n/a）。
  • "Bond"机制：每次通过的门禁会被交给一个 bond（一个必须拒绝的文件）。拒绝 bond 的检查视为"守住"（held）；看到 bond 却放行的检查是空洞的（vacuous），空洞的阻塞门禁使整个运行不通过验证。
  • 九个答案而非布尔值：区分"通过"、"无人检查"、"失败"等状态。例如，一个变更唯一的通过门禁是 linter，不算"运行过"的变更；反之亦然。
  • 验证演示：同一 bundle 验证后篡改单个字节，exit 0 与 exit 1 并排展示，附带复现脚本；bundle 可在从未见过该仓库、无网络、无挂载的机器上验证。
  • 模型与 harness 的边界：绿色判定由 harness 计算，模型无法自行产出；当模型断言了语言无法解析的谓词时，harness 将其渲染出来。
  • 运行策略：命令在词法路径和程序策略下运行（非容器隔离）；密钥扫描是已知模式清洗而非密钥移除；模糊测试零崩溃是证据而非证明。
  • 模型支持：支持 OPENAI_API_KEY、GOOGLE_GENERATIVE_AI_API_KEY，或本地 Ollama / rapid-mlx（--model local:<id>）。
  • 版本注意：Node 版本低于 13 是不同程序（该包名曾承载过 12.x 的 PR 审查器），依赖时需锁定 major 版本。

三、值得注意的局限/争议

作者承认的局限：

  • 命令运行在词法路径和程序策略下，作者明确说明"这不是容器隔离"（not containment）。
  • 密钥检测器做的是已知模式清洗（known-pattern scrubbing），不是密钥移除。
  • 模糊测试零崩溃是证据，不是证明。
  • 12 个门禁中：2 个未证实（unproven），1 个在规模上失败（fails on scale）。
  • 没有配置可信任务 oracle 时，无法判断变更是否真正完成所请求的工作——"门禁通过"与"工作完成"是两回事。

AI 判断的局限/争议：

  • 数值棘轮机制虽拒绝牺牲测试/覆盖率的修复，但"牺牲"的判定标准可能被绕过（如通过降低断言质量而非数量）。
  • "Bond"机制依赖门禁能"看到"并拒绝 bond 文件，若门禁本身逻辑有缺陷或 bond 文件路径不在检查范围内，验证可能失效。
  • 九个答案体系增加了语义复杂度，但"无人检查"与"失败"的区分在自动化流水线中可能被下游工具错误扁平化。
  • 词法路径和程序策略非容器隔离，意味着恶意补丁仍可能通过路径穿越或程序行为逃逸。
  • 模型无法产出绿色判定是好事，但 harness 渲染模型断言的方式可能引入新的解析歧义。

四、与 RRLab 研究的关联

  • Harness 工程：本项目的"咽喉点记录每次工具调用 + 哈希链账本"模式可直接借鉴——RRLab 的 agent harness 可引入不可篡改的操作日志，确保每次 agent 行为可审计、可重放。
  • 模型评测："九个答案而非布尔值"的粒度思想对评测体系有启发——RRLab 评测不应只输出 pass/fail，应区分"未执行"、"执行但失败"、"执行且通过"等状态，避免假阳性。
  • Agent 落地："Bond 机制"（给每个通过的门禁一个必须拒绝的测试文件）是验证 agent 是否真正"理解"检查逻辑的巧妙方法，可用于 RRLab 的 agent 能力验证。
  • 多模型协同：作者明确区分"门禁通过"（harness 可验证）与"工作完成"（需 oracle 判断），RRLab 在多模型协同中可引入独立 oracle 模型交叉验证，而非仅依赖单一模型的自我报告。
  • AI 原生产品：签名 bundle 携带自身验证器、离线可验证的设计，对 RRLab 构建可信 AI 产出物（如自动生成的代码、报告）有直接参考价值——产出物应自带可验证性，而非依赖中心化信任。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/moonrunnerkc/swarm-orchestrator