Bernstein的Janitor验证体系：为什么AI Agent的自我报告不能直接信任-开发者社区

【免费下载链接】bernstein

The open‑source AI Agents Governance & Orchestration framework: write the rules declaratively, Bernstein enforces them and produces the verifiable, replayable record. Free, Apache-2.0. https://bernstein.run

项目地址：https://gitcode.com/gh_mirrors/be/bernstein

点击查看免费下载

在 AI Agent 自动化开发流程中，最大的隐患之一不是"Agent 写不出代码"，而是"Agent 声称做完了"。Bernstein是一个开源的 AI Agent 治理与编排框架（Governance & Orchestration Framework），它的核心组件Janitor（清道夫验证器）专门解决"自我报告不可信"问题：不采信 Agent 的口头汇报，而是用可执行的完成信号、工作归属归因和带签名的验证凭证，对每个任务做独立裁决。本文带你完整走一遍这套验证体系的设计思路。

为什么"我做完了"这句话不能直接采信

LLM 驱动的 Agent 有一个被反复观察到的特性：自报的置信度与实际正确性并不相关。Bernstein 的文档对此有明确的结论（docs/quality/empirical-confidence.md）：模型自评的 confidence 无法作为决策依据，单次运行的结果也过于嘈杂。

所以 Bernstein 的原则很简单：Agent 只负责干活，"干没干完"由独立于 Agent 的验证层裁决。验证逻辑集中在 janitor.py，它是每个任务完成后的第一道关卡——官方架构文档将其称为质量管线的核心（docs/architecture/quality-pipeline.md）。

值得注意的是，Janitor 规则里记录的"历史教训"本身就来自真实事故，例如：

误归属（Misattribution）：一个没有改任何文件的"经理"任务，因为子任务的改动恰好满足了它的完成信号而"顺理成章"地通过了验证；
橡皮图章孤兒（Rubber-stamped orphans）：崩溃恢复产生的"自动完成"任务（0 提交、0 token、空 diff）被当作完成，因为"没有失败的信号"被误读成了"通过"。

这两类事故直接催生了下面这些防线。

第一道防线：完成信号（Completion Signals）

Bernstein 不信任自然语言汇报，而是要求每个任务在规划阶段就声明一组可执行的完成信号（completion signals），验证时对文件系统逐一检查：

信号类型	含义	验证方式
`path_exists`	文件/目录已交付	检查路径是否存在（精确匹配，临时 worktree 内的文件不算数）
`test_passes`	测试通过	实际运行命令，退出码必须为 0
`file_contains`	文件包含指定内容	内容匹配检查
`absence_verified`	"确实没有"类声明	必须对应到一次有完整覆盖记录的工具调用，缺失证据一律 fail-closed
`llm_judge`	模糊任务的主观评判	异步 LLM 裁判（见下文）
`schema_valid`/`hash_stable`等	产物字节级校验	只允许在"产物模式"下评估，文件系统路径直接 fail-closed

其中两个细节体现了"防作弊"思路：

路径不能指进临时工作区。Agent 在.sdd/worktrees/里写的文件不算交付——run 结束后 worktree 会被删除，Janitor 会把工作区内的路径翻译成仓库相对路径再对主检出做验证；
fail-closed 设计。任何无法评估的信号（比如产物模式信号出现在文件系统路径上）不会被当作"通过"，而是明确判负。"没被检查过的声明"永远不会读成"已验证"。

第二道防线：工作归属归因（Attribution）

信号全过还不够——Janitor 还要回答"这些改动确实是这个任务做的吗？"

janitor.py 中的归因逻辑按优先级解析：

查找 commit message 中引用了当前任务 id 的提交（最强证据）；
回退到最近一次提交、且限定在任务声明的owned_files范围内（弱证据，会明确记录"attribution 较弱"）。

判定结果分三档：

空 diff + 非 no-op 任务 → 直接拒绝（REJECT），这就是"空 diff 守卫"，专治橡皮图章式完成；
空 diff 但有不平凡信号通过（如test_passes真实跑通）→ 接受但标记警告，提示人工复核；
规划类任务的"产物"是任务图本身，只要分解出了子任务即可凭此通过，且会在日志中记录子任务列表——接受是"可审计的"，而不是按任务类型一刀切豁免。

第三道防线：LLM Judge 也有"置信度门槛"

对难以用确定性信号描述的任务（如"代码质量是否达标"），Bernstein 引入了llm_judge信号：把任务描述、评估标准和 git diff 交给一个独立的裁判模型（模板见 templates/prompts/judge.md），要求返回结构化 JSON 判定。

但裁判本身也可能"说谎"或"失误"，所以配套了多重保险：

置信度阈值 0.7：低于阈值的 accept 判定会被标记"需人工复核"，而不是直接采信；
判定重试上限 2 次：judge 判retry时自动创建修复任务，超限即停，防止无限循环烧钱；
降级 fail-closed：LLM 调用失败、返回空、JSON 解析失败等一切降级场景，都会被编码为"零置信度 + 标记复核"的 retry，绝不静默变成通过；
成本封顶：diff 截断在 10,000 字符、响应限 1024 token，单次判定成本约几分钱。

Verifier Ladder：验证过程本身也可以被验证

"验证者可信吗？"这个问题 Bernstein 用 **Verifier Ladder（验证阶梯）**回答（docs/sdd/verifier-ladder.md，实现见 verifier_ladder.py）：

把"是否可合并"的单个布尔值拆成三层有序凭证：

deterministic 层：完成信号 + 归因 + guardrails 等确定性检查；
judge 层：LLM 裁判的裁决；
human 层：人工共识/评审。

每一层只要运行过，就封一条冻结的TierRecord（配置哈希、输入哈希、证据哈希、裁决）进 lineage 签名链；复合LadderReceipt再把这些层绑定成一个merge_eligible声明。关键设计是**"验证即重算"**：bernstein verify ladder <receipt-hash>会重新哈希、重新推导裁决，并逐条核对每层的 spine 锚点——哪怕 receipt 内部哈希自洽，只要存储的merge_eligible不被层裁决所蕴含，也会被拒绝。连"裁判被咨询但从未实际裁决"这种情况都会诚实地记为skip，而不是悄悄消失。

未验证完成的"仪表盘告警"：Verification Nudge

就算有 Janitor，仍可能出现"任务完成了但没有任何验证痕迹"（没跑测试、没过质量门、没查完成信号）的情况。Bernstein 用 verification_nudge.py 对此建账：

每次完成写一条 append-only 记录到.sdd/metrics/verification_nudges.jsonl；
当窗口内未验证完成占比 > 30%（默认阈值）且完成数 ≥ 3时，在bernstein status、TUI 和/status/API 中触发告警；
配套运维手册给出了标准处置流程：先抽查一个被标记任务，区分"Agent 真的跳过了验证"还是"日志摘要解析漏了证据"（docs/operations/verification-tracking.md）。

这套机制和 Janitor 的关系是互补的：Nudge 是面向操作员的粗粒度健康信号，Janitor 是面向任务的细粒度合并门禁。

失败之后：不阻塞，而是回流

验证失败时，Bernstein 不只是"挡住"。失败结果会反馈给 cascade-router（docs/architecture/quality-pipeline.md）：先在同一模型链上换更强模型重试（sonnet → opus），同时记录成本与原因到.sdd/metrics/cascade_chains.jsonl。可选的跨模型验证器（cross_model_verifier.py）还会让另一个厂商的模型来审查 diff——"写代码的 != 审代码的"。