一个行为，三种登记：Fail-closed 的草案、类与进行中的问题
规范解读 · 第 13 篇 · 本文引证来源 · 草案原文逐字引证：draft-kroehl-agentic-trust-aae-02 · 其一致性向量仓：aae-conformance-vectors · 进行中的问题：issue #189 · W3C AI Agent Protocol CG 列表 2026 年 10 月线程：0015 号信 · 0027 号信 · 0031 号信 · 0032 号信 · 我方草案 draft-li-rttp-iqa-addressing-00 · 姊妹柱：RTTP（rttp://，CRI 27） · IQA（iqa://，CRI 28）
有些词安静地走了几十年，然后一口气同时抵达。Fail-closed——把无法验证的状态按「拒绝」处理、而不是按「放行」处理的纪律——就是其中之一。短短五个月里，它先被一份 IETF 草案写成 MUST，然后以数据类的形态住进一套一致性向量，继而在 W3C AI Agent Protocol CG 列表上作为实验行为被预登记，如今又被论证成一条报告语义规则。这篇文章按名字致意每一种登记，把三种登记分开——因为把它们分开正是全部要点——然后解读这个词在合规实验室 issue #189 里刚刚打开的活问题。
这个词，以及为什么它不属于任何人
Fail-closed 是古老的工程直觉：防火墙没有规则就默认拒绝，熔断器得不到应答就断开，气闸无法确认就保持关闭。检查无法完成时，默认动作是拒绝，而不是继续。没有任何标准组织拥有这个词，也没有组织需要拥有它——这恰恰说明，有趣的故事从来不是谁先说的，而是每一种登记最近把它说得多么精确：哪个检查、哪种失败、哪种拒绝，以及——问题最新的一层——这个拒绝在结果表上应该被叫做什么，第三方才能重算它。
登记一：那份草案，谨致谢意
CryptoKRI GmbH 的 Lars Kersten Kroehl 在 Agent Authorization Envelope 草案里给这个词写下了智能体时代的 MUST：“If revocation status cannot be determined — for example, on network failure or an HTTP 5xx response — the relying party MUST reject the AAE.”（撤销状态无法确定——例如网络故障或 HTTP 5xx 响应——依赖方必须拒绝该 AAE。）自七月起，他的 aae-conformance-vectors 仓已把 revocation_status_indeterminate 作为独立拒因携带——行为，用数据表达。独立收敛是一个设计问题真实存在的最强信号。我们点名致谢，心怀敬意。
登记二与登记三：墙上
我们自己的登记更窄，而且立在 CG 列表上。0015 号信为租约撤销实验预登记了行为：活体 standing-read 模式下，不可达变体的拒绝是 fail-closed——“an organ that cannot be reached is not read as silent consent”（一个无法触达的机关，不被读作沉默的同意）。0031 号信把这个点变成了报告语义：“A record that folds unreachability into a substantive reason manufactures an intent nobody had; keeping the two apart is what makes third-party recomputation meaningful.”（把不可达折叠进实质理由的记录，是在伪造一种从未有人表达过的意图；把两者分开，第三方重算才有意义。）而登记之间的桥，是 Lars 本人在墙上开篇信（0027 号信引用）里亲手搭的：“Lee’s fail-closed answer for the unreachable case already names the behaviour, and the result sheet should be able to show it.”（Lee 对不可达情形的 fail-closed 回答已经为该行为命名，结果表应当能把它显示出来。）三种登记，一个信念——而且引用链指向的是慷慨的方向。
顺带说清这些登记不是什么。草案陈述的是它自己信封模型里的行为规则；0015 号信预登记的是一个实验的预期行为；0031 号信论证的是结果表的区分。它们没有一个宣称拥有这条原则，也没有一个需要宣称。功夫全在区分里——规范规则、实验预期、报告要求是三件不同 scope 的工件，一个把它们搅在一起的合规文化，最后只会吵署名，而不是吵向量。
issue #189 里的活问题
实验室仓库里的 issue #189 现在把这个信念变成了两个具体问题。第一个是机械问题：“I can supply a fixture for that case with the evaluation instant pinned in the vector, so the expected decision no longer depends on when it runs.”（我可以为该情形提供夹具，把评估时刻钉死在向量里，使预期判定不再依赖运行时机。）欢迎——它补全了我们关心的一环。我们的独立 runner 已经拒绝为任何 SHA-256 未钉进清单的向量文件计分；钉死评估时刻，是把确定性从字节扩展到时间。我们自己的表述，在 0032 号信里：“A score that moves with the clock is not a score; it is a reading.”（随时钟移动的分数不是分数，是一次读数。）这个子问题我们在两个场地都问了，而它的收口比这篇文章还快：发布约一小时后，Lars 在 #189 里作答——absolute，逐字写道：“The verifier reads the instant from the fixture and never calls the clock, so the expected decision comes out the same on any machine and at any time.”（验证器从夹具读取时刻，从不调用时钟，预期判定在任何机器、任何时刻都相同。）偏移量被他拒绝，理由与我们会给的如出一辙：“An offset would need an anchor both sides agree on, which adds a dependency a fixture does not need.”（偏移量需要双方同意的锚——那是夹具不需要的依赖。）确定性从字节延伸到时间，无需共享锚点走后门；整条线程出发时的那个信任问题的最小实例，就这样以最小的方式收了口。
第二个是治理问题，而其克制与那个类同样值得记录：“Our set reports revocation_status_indeterminate as a rejection reason distinct from ancestor_revoked, and the existing taxonomy does not carry that class. Hence the question before a PR.”（我们的集合把 revocation_status_indeterminate 报告为独立于 ancestor_revoked 的拒因，而现有分类法没有这个类。所以先问再提 PR。）仓库自己的 CONTRIBUTING 要求候选留在现有 schema 与分类法之内，因此采纳与否属于套件维护者的裁决——这一点我们已在 issue 里和墙上记录在案。属于列表的，按我们 10 月 24 日的信（0028 号信），是验收之争：任何公共向量集的接受标准在列表上论证，而不是在任何别处敲定。机械归仓库，采纳归维护者，标准归列表。这个分工轮不到任何人重画。
发布当日的补记：那套向量已按 Lars 在墙上宣布的候选路线提交为 PR #190——字节逐字钉死在 6bb462f，CHECKSUMS.sha256 六十四条过摘要门，偏差如实申报而非含糊带过，而证据一栏写的是：“Author-produced only … No independent run exists.”（仅作者自跑……尚无独立运行存在。）独立运行的席位被明示空出、而非默认占有——这正是本文所主张的：把登记分开，让每一个签名落得清楚。
我们的态度
开源协议是不断发展更新的——这正是我们聚集到一起讨论和实验的原因。草案贡献了 MUST，向量贡献了类，墙上贡献了语义。本博客承载的两套方案——RTTP（rttp://）答在哪与何时，IQA（iqa://）答是否——将以 runner 遇见 revision 2 的同一种方式迎接 revision 3：冻结输入过摘要门、钉死评估时刻、按模式与轴分开计分，并为任何想重算这次运行的人留下一份存证工件。一场公平的实验可以给三种登记同时计分——并且每一种都按它自己的名字致意。
一句话：一个行为，三种登记——草案把它写成 MUST，向量把它携带成类，墙上把它论证成语义；把登记分开、各自署名致意，因为这份区分正是第三方重算得以成立的原因。