可信资源不是一次性发布
智能体资源不是一次发布后永远不变的静态条目。Agent Service 会升级模型和工具链,MCP Server 会增加或移除工具,Skill 会迭代描述和参数,Tool/API 会调整 endpoint、schema 和认证方式。一个可信基础设施必须支持资源生命周期,而不是只支持首次注册。
OAN 将资源生命周期拆成几个阶段:准备、注册、Root 验证、资源包发布、Discovery 同步、用户发现、版本更新,以及必要时的暂停、撤销或重新发布。每个阶段都有不同角色参与,并通过 DID 文档、ResourcePackage、Root Proof、授权域和签名请求形成可验证链路。
准备和注册阶段
准备阶段由资源提供者完成。提供者需要明确资源类型,是 Agent Service、Skill、MCP Server 还是 Tool/API;准备资源 DID、服务入口、协议绑定、能力描述、能力标签、授权域、版本信息和包哈希。Registrar 可以提供注册辅助,例如草稿校验、能力标签建议、授权域候选和主体控制证明流程。这里的建议是辅助性的,不能替代最终验证。
注册阶段由 Registrar 承担入口职责。Registrar 会保存注册证据,验证草稿完整性,并在需要时向 Root 提交 ResourceRegistrationSubmission。OAN 强调 Registrar 自身也是基础设施节点,必须有 Root-issued Registrar authorization VC,并结合最新治理状态判断自己是否有效授权。也就是说,注册入口本身不能脱离治理。
Root 验证和 CDN 分发
Root 验证阶段是可信发布的核心。Root 不负责业务调用,也不对资源质量做万能背书。它负责验证协议对象是否一致、DID 文档和元数据哈希是否匹配、主体控制证明是否成立、上游请求是否由授权 Registrar 签名,以及资源包是否符合当前 OAN 规则。验证通过后,Root 归档资源包并生成 Root Proof。
分发阶段通常由 CDN 承担。CDN 可以高效分发 DID 文档、资源包、元数据和索引材料,但它不是信任权威。客户端和 Discovery 仍要验证 Root Proof 和相关哈希。这样,即便分发层未来更换供应商、迁移域名或扩展节点,也不会改变资源可信性的判断基础。
Discovery 同步和版本更新
Discovery 同步阶段则决定资源是否对查询可见。Discovery 节点同步 Root 和 CDN 数据后,需要验证包级证据,并按授权域过滤。Root 可以向 Discovery 发送资源发现批量通知,其中包含授权域、sequence 范围、CDN manifest URL、CDN updates URL 和证明材料。Discovery 可以维护本地排序、评价或企业偏好,但不能把本地信号凌驾于 Root trust facts 之上。对用户来说,Discovery 返回的是可信候选,而不是任意抓取结果。
| 生命周期阶段 | 主体 | 关键产物 | 用户可见结果 |
|---|---|---|---|
| 准备 | 资源提供者 | DID、描述、入口、哈希 | 可提交草稿 |
| 注册 | Registrar | ResourceRegistrationSubmission | 待验证提交 |
| Root 验证 | Root | ResourcePackage、Root Proof | 已验证资源包 |
| 分发 | CDN | DID 文档、资源包、索引材料 | 可下载工件 |
| 同步 | Discovery | 本地索引、签名响应 | 可查询候选 |
| 更新 / 撤销 | Root / 节点治理 | 新版本或状态变更 | 最新 active 或不可见 |
版本更新是生命周期中非常重要的一环。资源 DID 应保持稳定,版本信息和包哈希则随发布变化。这样,用户能识别“同一个资源的新版本”,Discovery 也能默认返回最新 active 版本。对升级频繁的 Skill 或 MCP Server 来说,这比每次发布都换一个标识更符合实际使用方式。Root 侧也可以提供资源版本查询或生命周期观察接口,让 SDK 和运维工具跟踪一个资源从发布到更新、暂停或撤销的变化。
节点授权也是生命周期的一部分
开放治理还体现在基础设施节点生命周期中。Registrar、Discovery 和未来 VC issuer 等节点,需要通过治理流程获得有效授权。OAN 的有效授权不是单一文件或单一链上状态,而是“最新链上治理状态 active + 有效 Root-issued authorization VC”的组合。节点被暂停或撤销后,即使旧凭证还存在,也不应继续被视为有效授权节点。
这种组合式授权解决的是开放生态中的一个现实问题:节点既要能独立运行,又不能脱离公共治理。链上治理记录适合表达节点授权状态、角色变更和撤销事实;Root-issued authorization VC 适合给节点提供可被其它服务离线或半离线验证的凭证。二者结合后,系统既不需要把每次资源查询都压到链上,也能避免“拿着旧凭证永久有效”的风险。
链上治理不承载高频业务流量
这也是 OAN 对“DID 一定依赖链上高频访问”这一常见误解的回答。OAN 使用链上治理来处理基础设施节点身份、授权和状态变更,不把每次资源发现、每次用户查询或每次服务调用都放到链上执行。资源注册、包分发、Discovery 索引和 SDK 查询主要发生在链下服务中,再通过 Root Proof、签名响应和哈希绑定保留可验证性。这样既保留了治理可追溯性,也避免把高频业务流量压到区块链性能瓶颈上。
第三方节点接入需要技术准入
第三方节点接入也应纳入这个生命周期。未来第三方 Registrar 或 Discovery 节点在加入前,需要通过接口一致性、授权域处理、签名响应、资源包验证、错误报告和安全边界等测试。测试通过可以作为获得官方授权的必要条件,但不是充分条件;最终仍要结合治理流程、运营主体、授权范围和持续运行情况判断。这样,技术准入和治理准入各司其职。
这种生命周期模型让 OAN 不只是一个资源目录。它把资源从创建、发布、分发、发现、更新到治理状态变化都纳入协议和工程边界。对于智能体互联网而言,可信不是一次性动作,而是贯穿资源和节点全生命周期的连续状态。
生命周期与治理动作
| 生命周期阶段 | 主体 | 关键产物 | 用户可见结果 |
|---|---|---|---|
| 准备 | 资源提供者 | DID、描述、入口、哈希 | 可提交草稿 |
| 注册 | Registrar | 注册提交 | 进入验证队列 |
| 验证 | Root | ResourcePackage、Root Proof | 获得可信版本 |
| 分发 | CDN | 资源包和索引材料 | 可以被节点拉取 |
| 发现 | Discovery | 本地索引和签名响应 | 可查询候选资源 |
| 更新 / 撤销 | Root / 节点治理 | 新版本或状态变更 | 最新 active 或不可见 |
所以,OAN 不只是一个资源目录。它把资源从创建、发布、分发、发现、更新到治理状态变化都纳入协议和工程边界。对于智能体互联网而言,可信不是一次性动作,而是贯穿资源和节点全生命周期的连续状态。
生命周期视角
资源不是发布完就结束,而是会经历准备、注册、验证、分发、发现、更新和撤销等阶段。OAN 的价值就在于把这些阶段都放进同一套治理和发现链路里。
| 生命周期阶段 | 主体 | 用户可见结果 |
|---|---|---|
| 准备 | 资源提供者 | 可提交草稿 |
| 注册 | Registrar | 待验证提交 |
| Root 验证 | Root | 已验证资源包 |
| 分发 | CDN | 可下载工件 |
| 同步 | Discovery | 可查询候选 |
| 更新 / 撤销 | Root / 节点治理 | 最新 active 或不可见 |
开放治理的重点不是“谁都能改”,而是“改动可追踪”
资源可以更新,节点可以调整授权,发现结果也会随版本变化而变化。但这些变化都要有来源、有证据、有状态,不然就不叫治理。