本章规定资源在 OpenAgenet (OAN) 网络中的时间、状态和证据关系。智能体服务、技能包、MCP 服务和工具 API 等资源以 DID 标识主体，以 DID 文档描述控制关系、能力和服务入口，以资源包承载可发布内容；注册 VC 证明注册服务节点受理过登记，根平台可信发布证明证明特定资源包通过根平台验证并进入发布链路。资源“已登记”“已发布”“已索引”和“当前可调用”是不同事实，必须分别证明。

本章中的状态关系可以用一个资源版本作为关联键来理解：

资源 DID
  -> DID 文档版本
  -> 资源包版本 + 文档/元数据/包哈希
  -> 注册 VC
  -> 根平台可信发布证明
  -> 分发游标与发现索引版本

上面的链条表示证据之间的关联，不表示所有步骤同步完成，也不表示注册服务节点返回结果就等于发现服务节点已经可见。

18.1 资源生命周期状态机

状态必须由事件、证明或持久化记录触发，不能由页面按钮或单次 HTTP 成功推断。注册成功最多说明注册服务节点完成受理；根平台验证、授权检查、资源包摘要校验和发布任务完成后才能进入已发布；发现服务节点完成验证和索引后才能进入可发现。失败应保留原因、关联标识和重试边界。

18.2 初始注册

发布者在浏览器中创建或导入本地身份，使用本地私钥签署 DID 文档和注册请求；私钥不应上传到注册服务节点。注册服务节点验证格式、控制关系、资源类型、必填元数据和节点授权，成功后记录登记并按接口约定返回注册 VC。根平台随后独立验证资源包、注册节点授权和发布条件，内容分发平台及发现服务节点再异步接收和索引。缺少本地身份、签名无效、字段缺失、网络失败、VC 为空和传播延迟必须分别反馈，不得统称为全网注册完成。

18.3 同 DID 资源更新

同 DID 更新的依据是控制关系连续，而不是 DID 字符串相同。更新请求应带有前序版本、资源 DID、版本和内容摘要，并由既有控制公钥或明确授权的更新密钥签名。注册服务节点验证控制权和版本关系，根平台重新验证资源包与发布授权，发现服务节点只接受通过根平台发布流程的版本。相同内容和前序版本的重复提交应幂等处理；内容变化必须推进版本和摘要，无授权、倒退或分叉应拒绝。新版本未传播完成前，旧的有效版本可以继续返回。

18.4 DID Document 版本管理

DID 文档版本表达身份文档、控制公钥、服务端点或能力元数据的变化，不等同于 did:oan 方法版本或资源包版本。当前版本应由稳定 DID、前序关系、序列或等价版本规则和控制者签名共同确定，时间戳只能用于审计。解析器不得仅按到达时间解决同一前序版本的分叉；发现服务节点默认返回已发布、状态有效且序列最高的版本，并支持按版本或内容摘要查询历史版本。

版本判定顺序应保持确定性：

生命周期状态过滤 -> 证明校验 -> 发布序列比较 -> 版本比较 -> 查询排序

资源包版本与接口兼容性不是同一个维度。技能包可以只更新文档或示例，工具 API 可能同时改变输入输出模式和端点，MCP 服务还可能改变协议绑定或暴露能力；因此版本号本身不能替代变更说明。资源包中的 packageVersion、packageHash、metadataHash 和 lifecycleState 应与 DID 文档元数据及根平台发布证明中的对应值一致。

一个用于审计的最小绑定记录可以表示为：

{
  "resourceDid": "did:oan:SKDM:example-resource-did",
  "packageVersion": "1.2.0",
  "didDocumentHash": "sha256:example-did-document-hash",
  "metadataHash": "sha256:example-metadata-hash",
  "packageHash": "sha256:example-package-hash",
  "lifecycleState": "active",
  "previousVersion": "1.1.0"
}

以上 DID、版本和摘要均为示例占位值；它表达的是字段之间的绑定关系，不是官方固定资源或固定版本。

18.5 资源包版本管理

资源包是根平台验证、内容分发平台保存和发现服务节点索引的发布单元。版本必须能指向一组规范化元数据、入口、协议绑定、依赖和内容摘要；根平台可信发布证明应绑定资源 DID、资源类型、资源包版本及包摘要。资源 DID 可以在正常升级中保持不变，旧资源包可标记为被替代并保留审计证据；发现服务节点默认返回最新有效包，调用方请求指定版本时仍须验证其发布证明和凭证状态。

可按变更影响范围选择更新对象：只改变发布包内容时，至少更新资源包版本和包哈希；改变 DID 文档中的服务入口、公钥或资源元数据时，应同步更新 DID 文档及其摘要；改变能力标签、授权域或生命周期时，还要重新检查语义治理和可见性。任何一种影响根平台可信发布证明绑定字段的变化，都不能只在发现节点本地修改索引。

18.6 元数据与端点变更

能力标签、描述、用例、协议绑定、端点、认证要求和依赖等会影响发现或调用判断的变化，应产生新的 DID 文档版本、资源包版本或二者组合，并重新签名、验证和索引。端点变化还应检查 TLS、认证、协议和实际能力；旧端点下线不等于资源 DID 撤销，调用方应根据新版本和状态决定是否调用。

18.7 注册 VC 生命周期

注册 VC 证明注册服务节点受理某项登记，不是资源质量保证，也不替代根平台发布证明。验证方应检查签发者授权、主体 DID、资源类型、版本或内容摘要、签发时间、有效期及吊销状态。VC 缺失、无效、签发者未授权或状态未知时，不得标记为可信注册。凭证吊销只影响其证明事实，不会自动改写 DID 文档；DID 停用也不等于历史凭证消失。

查询方处理凭证时，应将“凭证存在”和“凭证当前有效”分开记录。对于资源版本 v1 的注册 VC，即使其签名有效，也不能直接证明 v2 已登记；对于 v2 的根平台可信发布证明，也不能反向替代注册服务节点对登记事实的证明。资源更新、凭证吊销和主体停用发生后，发现服务节点应按最新可验证状态过滤结果，历史凭证仍可作为审计材料保留。

18.8 资源暂停与恢复

暂停是可逆状态，原因应区分控制者操作、治理限制、证明暂不可验证、端点维护和节点同步异常。网络超时或指标无数据不能直接改变资源生命周期。暂停应有控制签名、治理事件或其它可核验证据；恢复前重新检查控制证明、VC、根平台发布证据、端点和治理条件，并让发现节点按发布序列重新同步，而不是只修改本地状态。

18.9 资源撤销与停用

资源撤销针对发布资格或版本，DID 停用针对资源主体，凭证吊销针对某项证明，端点下线针对服务入口。撤销和停用应记录发起者、依据、目标 DID 或版本、原因、生效时间和传播范围；历史材料可以保留审计，但不能作为当前可调用资源返回。传播未收敛前，节点必须标注状态和新鲜度，而不是宣称全网立即完成撤销。

节点授权变化与资源状态的处理可以按以下关系核对：

18.10 节点暂停与资源可见性

节点授权属于治理对象，资源控制权属于资源 DID。注册服务节点失去授权后，根平台应停止接受其新的可信发布输入，并按治理规则重新评估已有发布；发现服务节点失去授权后，不应继续以正常授权节点身份发布结果，但其数据可为恢复和审计保留。节点恢复须先恢复身份和授权，再依游标补齐数据。客户端应区分节点故障、同步中和资源撤销。

版本选择不是简单的“最后写入优先”。例如，发现服务节点同时收到同一资源的 1.1.0 和 1.2.0，应先确认两者都具有可验证的发布来源和状态，再依据发布序列、前序关系和版本规则选择当前结果；如果 1.2.0 的摘要或证明校验失败，不能因为版本号更大就覆盖 1.1.0。选择结果还应保留被采用版本和被排除版本的原因，便于定位传播延迟与版本冲突。

18.11 发现节点的版本选择

发现节点先过滤状态、签名、注册 VC、根平台可信发布证明、版本有效性和索引新鲜度，再执行语义和结构化排序。默认对同一 DID 返回已发布、状态有效且发布序列最高的版本；版本冲突、序列缺口或证明未知时应报告异常而非随机选择。精确 DID 查询和语义查询均应返回版本、摘要、来源、证据状态和索引时间。

18.12 历史版本与可审计性

审计记录应关联 DID、文档版本、资源包版本、摘要、控制签名、注册 VC、根平台可信发布证明、发布序列、节点接收时间和索引时间。历史查询应区分当前有效、已替代、已撤销、已归档和节点尚未同步；历史证据用于还原发布事实，不得绕过当前状态。节点重建或数据库迁移不得无记录地丢失规范要求保留的证据。

历史记录至少应能回答三个问题：某个版本由谁控制并签署，根平台是否接受并发布过该版本，以及指定发现服务节点在什么时间以何种状态看到该版本。若只能找到资源包文件而没有控制签名、发布证明或索引观察记录，只能证明材料曾被保存，不能证明它曾经是网络中的有效版本。

18.13 资源 VC 与发布证据生命周期

注册 VC 和根平台可信发布证明具有不同签发主体和事实范围。前者证明登记受理，后者证明特定资源包通过根平台验证并进入发布链路；二者均须绑定明确的 DID、版本和摘要。更新产生新摘要时应重新产生相应证据，撤销、停用、过期和授权失效须分别检查。下载到发布者本地的证明文件不改变服务端的有效性判断。

证据关联可按版本逐项核对：

同一资源 DID
  -> 同一资源包版本
  -> 对应 DID 文档/元数据/包摘要
  -> 注册 VC 的登记事实
  -> 根平台可信发布证明
  -> 发现服务节点的接收和索引观察

其中任何一环指向不同 DID、版本或摘要，都应按绑定不一致处理，而不是用文件名或下载时间推断它们属于同一发布。

18.14 更新传播与过期索引收敛

注册服务节点 -> 根平台验证与发布 -> 内容分发平台 -> 发现服务节点接收 -> 校验、索引与可见

各段使用 DID、版本、摘要、发布序列或事件游标关联；重复投递必须幂等，断点重试从确认游标继续。序列缺口、摘要不一致、证明无效或治理状态未知时，发现节点不得更新有效投影。旧索引的收敛以新版本完成验证和投影为准，而非以请求发出为准。

传播检查还应记录每个节点看到的状态，而不是只比较资源数量。数量相同可能是旧版本仍在索引，也可能是新版本替换了旧版本；必须比较资源 DID、版本、摘要、生命周期状态、发布序列和观察时间。发生异常时，保留最后成功游标和原始响应，避免通过重置索引掩盖缺失或乱序事件。

18.15 资源所有权转移策略

所有权转移必须由原控制者授权、新控制者确认，并由根平台或治理流程验证后生效；重新提交同 DID 或出示新的注册 VC 都不足以证明转移。运营维护权和发布代理权可以单独授权，但范围、期限和撤销方式应与控制权分开记录。原私钥遗失时不得绕过签名强行接管，应进入可审计的治理恢复流程；当前实现未提供完整转移接口时，本节属于协议设计要求。

在控制权转移完成前，旧控制者仍是资源更新和撤销判断的关键证据来源；新控制者的声明、运营授权或资源包签名不能单独覆盖旧控制关系。转移完成后，维护记录应同时保存旧控制者授权、新控制者确认、根平台或治理流程的生效事实，以及发现服务节点完成更新后的观察结果。这样才能将“提出转移”“转移获批”和“节点已收敛”区分开来。

参考来源