智能体资源不是一次发布后永远不变的静态条目。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 验证阶段是可信发布的核心。Root 不负责业务调用,也不对资源质量做万能背书。它负责验证协议对象是否一致、DID 文档和元数据哈希是否匹配、主体控制证明是否成立、上游请求是否由授权 Registrar 签名,以及资源包是否符合当前 OAN 规则。验证通过后,Root 归档资源包并生成 Root Proof。
分发阶段通常由 CDN 承担。CDN 可以高效分发 DID 文档、资源包、元数据和索引材料,但它不是信任权威。客户端和 Discovery 仍要验证 Root Proof 和相关哈希。这样,即便分发层未来更换供应商、迁移域名或扩展节点,也不会改变资源可信性的判断基础。
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 或不可见 |
资源可以更新,节点可以调整授权,发现结果也会随版本变化而变化。但这些变化都要有来源、有证据、有状态,不然就不叫治理。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。