Proof-or-Stop：证据门控的 agent 生命周期控制
Proof-or-Stop：证据门控的 agent 生命周期控制
为什么重要
Loop-Engineering 的核心风险是“循环会相信自己已经完成”。Proof-or-Stop 把 reviewed、tested、DONE、ready-to-merge 这类生命周期状态从自然语言声明改成证据门控状态：agent 可以提出 claim，但只有 fresh、绑定当前 source state、可机械复查的 receipt bundle 才能推动状态前进。
对 Hermes 来说，这直接对应“任务完成前必须有真实工具输出”的执行纪律：日报入库、代码修改、部署发布、wiki reindex 都不应只报告“已完成”，而应能指向文件、hash、测试、HTTP 状态或重新执行结果。
机制 / 一阶原理
Proof-or-Stop 的一阶原理是 claim admissibility：系统不判断 agent 是否“诚实”，而判断某条 claim 是否具备当前门禁可接受的证据。证据必须满足三个条件：
- 新鲜性：证据对应当前 source/tree/material hash，而不是旧 commit 或旧测试结果。
- 可复查性：receipt bundle 能被下游 gate 独立验证，而不依赖 agent 叙述。
- 状态绑定：证据必须绑定到将要推进的生命周期状态，例如 done-required full-test receipt、review-assurance floor、merge-readiness certificate。
这使得 PR、review comment、green pipeline 都不再天然可信；它们只是候选输入。真正的信任边界是消费方在推进状态前重新检查证据是否仍绑定当前源状态。
与既有 wiki 的关系
| - 延续 [[agentops-coding-agent-verification | AgentOps verification membrane]]：最终声明必须有独立 verdict / receipt。 |
- 强化 Harness-Engineering：harness 不只是工具编排，还要拥有生命周期状态机和 admissibility rule。
- 细化 Loop-Engineering：无人 loop 的停止条件应是证据门控状态，而不是模型自述“完成”。
对 Hermes / llm-wiki 的可执行启发
- 每次 radar deep ingest 的“实际入库”应能列出 raw、source、concept、index、log 和 reindex 的真实路径/输出。
- 对代码/发布任务，最终报告可逐步采用
claim -> receipt结构：每个完成声明后跟测试、diff、curl、hash 或文件存在检查。 - wiki 页面更新前后的 log 可视为轻量 receipt，但对高风险发布还应增加 source hash / HTTP header / public URL 验证。
失败模式与边界
Proof-or-Stop 并不证明程序语义正确；它证明的是在某个 trust model 下证据足以推进生命周期状态。过度门控会增加摩擦、成本和 false stop；证据若被错误绑定或验证器本身被污染，也会形成新的单点风险。
写入记录
- 2026-07-18 09:00 CST：新增来源页，归纳机制、与既有概念的关系、Hermes/llm-wiki 启发和边界条件。