摘要

  • 2026 年 9 月 29 日提交的 AER-1 修订 04 是一份个人 Informational Internet-Draft。它要求工作流叶子使用每一步的 receipt_id；当前公开页面实际使用 seq:receipt_hash。
  • 五个步骤验证端点全部返回 HTTP 200，五张收据全部标记为已验证，五个输出哈希也都与页面清单一致。页面算法精确复现公开根，但草案算法得到另一根。
  • 固定提交中的 Python、Rust、TypeScript 辅助函数跟随草案；宣称 43/43 的向量集仍标注修订 -03，没有工作流或 Merkle 根测试。

“步骤有效”不等于“工作流只有一个身份”

公开工作流 42a3c2cf-2cdd-5b8a-aced-016e5a2fb634 共有五步。逐一请求它们的验证端点，结果没有出现失败：五次 HTTP 200，五次 verified: true，五个返回的输出哈希与工作流页面上的清单逐项相同。

页面随后将每一步的序号、冒号和小写输出哈希拼成 seq:receipt_hash，对其 UTF-8 字节做 SHA-256。父节点由左右两个 32 字节摘要直接拼接后再哈希；每层节点数为奇数时，复制最后一个节点。这样得到的结果是 a4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4，与页面公布的根完全相同。

如果保持步骤、顺序、父节点规则和奇数复制规则都不变，只把每个叶子的输入换成步骤收据的 receipt_id，结果就变成 7c4817ca249edfeae259b98abf63ed38a31d9dbeebf5ee23139410a7a7f63b37。

后一个算法来自 AER-1: A Portable Execution Receipt for AI Agent Tool Calls 修订 04。它尚不是 RFC，也没有被 IETF 工作组采纳。它的地位必须说清楚，但这并不会消除眼前的运行事实：当前文档与当前页面对同一个五步工作流给出了不同的身份。

这不是 SHA-256 碰撞，也不是第五张收据坏了。两边都忠实执行了各自的规则。真正缺少的是一个共同认可、随根一起携带的“叶子定义”。

分叉发生在树长出来之前

许多系统把“使用 SHA-256”当成完整协议。实际上，哈希函数只回答如何压缩字节；它不回答要压缩什么字节。

修订 04 规定：对每个 receipt_id 字符串的 UTF-8 字节做 SHA-256，再按顺序构造二叉树。文本先把这一方式称为推荐构造，紧接着用 MUST 要求实现必须采用，并明确删除旧修订允许替代构造的空间。给出的理由恰好就是本次观察：同一工作流出现不同根，会破坏跨实现验证。

公开页面则把位置和输出承诺直接装进叶子。这个设计并非毫无道理。序号固定顺序，输出哈希把步骤结果绑定进来。草案设计也有自己的逻辑：稳定的收据标识组成工作流，验证者再逐张解析并检查收据。

两种设计都可以被讨论，不能被混称。一个 64 位十六进制根不会自我说明：它没有告诉后来者叶子来自 ID、输出哈希还是二者的组合。只保存根，就等于把解释权留给当时的服务实现。

这正是决策边界。根可以成为审批、结算、审计或放行的对象；但如果根没有构造标识，决策者其实没有完整地知道自己批准了什么。

运行代码已经形成两个兼容集合

固定在提交 f3aacbb5cf7d00977fd107afc34fc24b08c4f569 的公开仓库提供了另一层证据。Python 的 merkle_root 接收收据 ID；Rust 对 ID 的字节做哈希；TypeScript 对 ID 的 UTF-8 做哈希。三者都复制奇数层末节点，并以原始摘要拼接父节点。它们与修订 04 一致。

网页中的浏览器代码却从验证端点取回输出哈希，再生成 seq:hash 叶子。这里的差异不是说明文字落后，而是实际参与运算的字节不同。

“运行代码优先”不能被简化成“网页永远对”。它要求先看真实部署在哪个兼容集合里。当前草案和三份已检查的辅助实现属于一个集合，当前网页属于另一个集合。同样，发布一份新草案也不会自动改写既有公开收据。文档、向量、库和部署必须通过实际采用而收敛。

按照 Lu Heng 的最小初始规范思想，共同层可以薄，却不能把互操作所需的不变量省掉。叶子字节就是不变量。如果独立验证者还得向原服务询问“你当时是什么意思”，那么权威并没有被哈希消除，只是被藏进了本地约定。

43/43 只回答了 43 个既定问题

仓库列出七种语言运行器全部 43/43：Rust、Go、TypeScript、Python、Java、C# 和 Swift。这是对所列向量的有价值证明，不是对后来所有功能的通行证。

实现说明列出的测试范围包括收据字段、UUID、时间戳、严格 Base64 与 UTF-8、输出承诺、来源类别、生产者配置、可选锚定和发射器往返。没有工作流。

向量索引仍写着规范修订 -03。43 个案例中没有以 workflow、Merkle、step sequence、step hash 或 odd-node duplication 为对象的向量。换言之，七种语言完全可能满分，同时从未构造过一棵工作流树。

分数没有撒谎；越界解释才会撒谎。

一个真正覆盖修订 04 的向量应固定五个 ID、五个叶子输入、五个叶子摘要、每一层中间节点、末节点复制和最终根。网页、API 以及每种语言必须消费同一份向量。只有这样，43/43 才能延伸到新边界。

一个“已验证”至少包含六层事实

第一层是步骤完整性：收据保存的字节与输出承诺相符。第二层是清单绑定：端点返回的哈希与工作流页面宣称的哈希一致。第三层是叶子语义：验证者使用了某个具名构造规定的字段。第四层是根兼容：另一个实现按同一构造得到同一根。第五层是外部见证：第三方在某个时间记录了选定承诺。第六层才是外部效果：工具操作真的产生了业务所关心的结果。

本次公开页面为前两层提供了强证据，也证明了它自己的第三、第四层。页面还展示状态为 partial 的 Nostr 工作流锚。锚可以见证收到的根，却不能裁定原本应该采用哪一种叶子。

聚合也不会抬高来源等级。外部代理上报的步骤仍是上报；网关观察仍只证明网关所见。查询价格不等于成交，执行调用不等于产生外部效果。

所以产品界面不能只显示“已验证”。它应回答：字节已验证、步骤已验证、根与哪个构造兼容、锚记录了什么、外部结果是否被独立确认。

根需要一张构造护照

可移植的工作流根至少应携带：收据与工作流模式版本、叶子构造标识、精确编码、哈希函数、父节点规则、奇数节点规则、输出编码、按序步骤 ID 与承诺、逐步来源、最终输出字节定义、锚定范围以及覆盖该构造的向量版本。

接受这棵树的系统还应记录自己的政策版本和决策主体。这不是增加形式，而是保留责任：谁在什么规则下接受了哪个对象。

若部署从 seq:receipt_hash 迁移到 receipt_id，不能悄悄重算历史。应保留旧根，发布带版本的新承诺，并在过渡期并列计算两根。使用者可以明确选择兼容集合，而不是被告知旧历史从来就意味着新规则。

来源与限制

本次观察冻结于北京时间 2026 年 9 月 30 日。它证明修订 04、固定公开提交和当时在线页面之间存在可复算差异；不证明恶意、SHA-256 弱点、系统入侵、外部操作失败、广泛采用或 IETF 背书。代码结论仅覆盖实际检查的 Python、Rust 和 TypeScript 工作流辅助函数。草案与服务都可能更新。