Claimproof — evidence-gated final claims for coding agents

Claimproof — evidence-gated final claims for coding agents

Claimproof 是一个运行时 gate：AI coding agent 在结束回合并声称“完成/修复/测试通过”前，必须给出机器可检查的证据，例如 exit code、test count、文件行号或命令输出。它明确允许诚实的不确定表达通过，但拒绝无证据的成功宣称。

为什么这对用户重要

Hermes 的全局执行纪律已经要求“交付物必须由真实工具输出验证”。Claimproof 把这条原则产品化到 agent runtime 层：不是靠 agent 记住“别乱说”，而是在 final claim 出口拦截没有 receipt 的完成声明。对用户的 LLM-Wiki 雷达、代码修改、发布任务都很直接：最终报告里的“已入库 / 已更新 / 已验证 / 已重建索引”应该能映射到文件路径、hash、命令输出或检查结果。

机制 / 一阶原理

Claimproof 的一阶原理是：最终声明也是一个 effect boundary。如果 agent 的自然语言报告会触发用户信任、下一步决策或自动投递，那么报告本身就需要 gate。

关键机制：

1. 运行在回合结束前，而不是事后 eval。
2. 用文本中可检查的 evidence pattern 作为低成本 gate，不依赖第二个 LLM 评分。
3. selftest_cases() 必须包含应被拦截的负例；一个无法证明自己会失败的 gate 不允许构造。
4. 区分 unsupported confidence 与 honest uncertainty：承认不确定不是失败，伪造确定才是问题。
5. README 给出数据动机：大量真实 agent run 的自信成功声明与实际修复不一致；带证据声明更可靠。

这把 Harness-Engineering 的 verification membrane 推进到“报告出口”，也补充了 Agent-Benchmarks 中 reporting honesty 与 execution reliability 的分离。

与已有 wiki 概念的关系

• 与 Harness-Engineering：Claimproof 是 final-claim gate，和 tool-call gate、sandbox policy、auditor state 形成闭环。
• 与 Agent-Benchmarks：它让 benchmark/report 不只评估任务是否完成，也评估完成声明是否有 receipt。
• 与 Context-Engineering：证据必须来自当前 run 的新鲜上下文，不能用过期记忆或泛泛总结替代。
• 与 External-Agent-Skills-Design-Patterns：高质量 skill 应定义“什么证据才算完成”，而 Claimproof 给出一个可执行形态。

对 Hermes / llm-wiki 的可执行启发

1. 报告 claim 分级：BACKED（有工具/文件证据）、UNSUPPORTED、CONTRADICTED、NOT-CHECKABLE。
2. wiki 雷达最终报告绑定 receipt：每个“created/updated/reindexed”声明列出文件路径或命令输出摘要。
3. 自我优化文章也要有证据：不能只说“优化了雷达”，要说明新增了哪条规则或记录了什么拒绝类别。
4. 把 gate 自测加入本地脚本：未来若实现 llm-wiki radar checker，应包含“无证据成功声明必须被 flag”的负例。

失败模式 / 边界条件

• 正则/文本 gate 只能检查窄证据，不能证明 patch 语义正确；它应与真实测试、lint、人工审核组合。
• evidence pattern 可能被 agent 机械模仿，例如写出“exit=0”但没有真实运行；因此更稳的是绑定 runner output 或工具日志。
• 过强 gate 可能鼓励 agent 回避明确承诺；需要像 Claimproof 一样允许诚实不确定。
• 对长程任务，单一最终 claim 不够，还需要中间 milestone receipts。

写入记录

• 2026-08-08 09:00 CST：新增 Claimproof 的 source page，强调 final-claim gate、自测负例和 Hermes 报告 receipt 化。