本章说明 OpenAgenet (OAN) 将可被注册、发布、分发和发现的能力单元统一建模为资源。当前核心资源类型包括智能体服务、技能包、MCP 服务和工具 API；基础设施节点、组织和开发者也可以作为身份或主体类型出现在关联关系中，但本章重点讨论四类可发现资源。每个资源至少具有独立的资源 DID、资源类型、描述、能力标签、用例、协议绑定、服务端点、版本和生命周期状态，并可通过资源包承载某一版本的可验证表示。

资源模型只统一跨类型互操作所需的共性，不把四类资源强行变成同一种业务对象。资源类型决定字段解释、端点形态、协议绑定和调用方式；资源 DID 确定控制和注册边界；资源元数据用于注册和发现；资源包将 DID文档、元数据、哈希和根平台可信发布证明绑定为可分发对象。后续章节分别规定身份、注册、发现、发布和调用，避免在本章重复定义其全部协议行为。

4.1 资源模型概览

资源模型的公共身份字段包括资源 DID、资源类型、主体类型，以及可选的控制方 DID、发布方 DID 和签发方 DID；公共描述字段包括名称、描述、能力描述、能力标签和用例；公共连接字段包括协议绑定、服务端点和认证或凭证要求；公共状态字段包括版本、生命周期状态、授权域、网络范围和更新时间。oanMetadata 是 DID文档中承载 OAN 资源语义和生命周期信息的主要元数据对象，资源包中的资源元数据则为发布和发现提供版本化表示。

资源类型枚举至少包括 agent_service、skill、mcp_server 和 tool_api。资源 DID 的方法特定编码应与资源类型保持一致，资源类型、主体类型、DID文档中的 oanMetadata 和资源包元数据必须能够相互校验。字段未出现、为空或仅存在于网页展示层时，不得据此推断资源具备对应能力；实际调用许可也不由资源模型中的端点或描述字段自动授予。

四类资源共享资源 DID、资源元数据、版本和生命周期等公共模型，同时根据自身的能力形态使用不同的协议绑定、端点和包内容：

flowchart TB
    RESOURCE[可注册、发布、分发和发现的资源]
    RESOURCE --> AGENT["智能体服务<br/>agent_service"]
    RESOURCE --> SKILL["技能包<br/>skill"]
    RESOURCE --> MCP["MCP 服务<br/>mcp_server"]
    RESOURCE --> TOOL["工具 API<br/>tool_api"]

下面的示例只展示公共字段如何组合，具体资源仍需根据类型补充协议、端点、包信息和凭证要求。resourceType、subjectType 和 resourceDid 是机器判断资源边界的字段，名称、描述和能力标签则服务于人类理解与发现检索：

{
  "resourceDid": "did:oan:SKLG:example-skill",
  "resourceType": "skill",
  "subjectType": "skill",
  "publisherDid": "did:oan:ORLG:example-publisher",
  "name": "Repository Structure Summary",
  "description": "Summarizes the structure of a code repository.",
  "capabilityTags": ["code-repository", "project-structure-summary"],
  "authorizedDomains": ["public"],
  "lifecycleState": "active",
  "packageVersion": "1.0.0",
  "hashAlgorithm": "sha256",
  "updatedAt": "2026-09-09T08:30:00Z"
}

该对象可以作为资源元数据的最小阅读样例，但不能单独替代 DID文档、控制证明、资源包哈希或根平台可信发布证明。发现服务节点可以使用其中的结构化字段建立索引，调用方仍需取得对应证据并根据资源类型执行后续验证。

4.2 智能体服务

智能体服务是提供可被调用的智能体能力的资源类型，对应资源类型值 agent_service。它通过资源 DID 表达独立的控制和发布边界，通过资源描述表达能力、能力标签、用例、输入输出和适用场景，通过服务端点和协议绑定表达如何建立连接。智能体服务可以声明 A2A、MCP 或其它业务协议，但声明协议只说明资源的接口语境，不代表调用方已经获得业务授权。

与 A2A Agent Card 的关系属于互操作映射关系。OAN 的能力描述、能力标签、用例、服务端点、协议绑定、版本和认证声明可以为 A2A Agent Card 的相应信息提供可信身份和发布来源；A2A Agent Card 的字段也可以通过适配器映射为 OAN 资源元数据。OAN 额外提供资源 DID、控制证明、注册凭证、根平台发布证明、治理状态和授权域，使“能力描述”能够与来源、版本和网络治理事实关联起来，但不改变 A2A 本身的交互协议语义。

4.3 技能包

技能包是可独立发布、安装、加载或复用的能力单元，对应资源类型值 skill。它应通过资源描述说明能力、输入输出、用例、依赖和使用条件，通过服务端点、包信息或实现链接说明获取和使用入口。技能包可以被智能体服务或其它编排系统组合使用，但技能包的可发现状态、版本和来源仍然应以自身资源 DID、资源包和根平台发布事实为依据。

技能包的“可复用”表示调用方能够在满足其依赖、版本和授权条件时重复使用，不表示它可以绕过资源控制、安装安全或业务权限。技能包描述中的安装命令、下载地址、脚本或依赖只能作为公开声明，调用方仍应验证资源包哈希、发布证明、版本状态和本地执行策略。

例如，技能包的公开元数据可以把能力、适用任务、依赖和版本放在同一资源边界内：

{
  "resourceDid": "did:oan:SKLG:example-skill",
  "resourceType": "skill",
  "subjectType": "skill",
  "name": "Repository Structure Summary",
  "description": "Summarizes a code repository and its project structure.",
  "capabilityTags": ["code-repository", "project-structure-summary"],
  "implementationLinks": [
    {
      "relation": "depends_on",
      "targetDid": "did:oan:TLFI:example-tool-api",
      "targetType": "tool_api",
      "versionConstraint": ">=1.0.0"
    }
  ],
  "lifecycleState": "active",
  "packageVersion": "1.0.0",
  "hashAlgorithm": "sha256",
  "updatedAt": "2026-09-09T08:30:00Z"
}

这里的 implementationLinks 表达可验证的资源关系，版本约束表达组合条件；它不表示目标工具 API 已经被安装，也不表示调用方已经获得访问权限。实际资源包发布时，还需把该元数据与 DID文档哈希、元数据哈希和资源包哈希绑定。

4.4 MCP 服务

MCP 服务是以 Model Context Protocol 提供工具或资源访问能力的服务资源，对应资源类型值 mcp_server。它的资源 DID 标识服务发布和控制边界，资源元数据说明能力标签、用例、协议版本、传输方式、服务端点和认证要求，MCP 能力描述可以通过协议绑定或专用能力对象表达。工具清单或资源清单属于服务能力声明，不能单独替代服务端点认证、调用授权和运行状态检查。

OAN 与 MCP 元数据的映射应保留两层边界：MCP 负责描述和执行协议层的工具、资源及交互语义，OAN 负责为 MCP 服务提供资源身份、控制证明、可信发布、治理状态和发现入口。MCP 服务的端点可访问，不代表该端点已经被根平台发布或对所有调用方开放；发现结果也不应把 MCP 能力声明直接解释为调用许可。

一个 MCP 服务的资源描述可以同时给出协议绑定和服务端点，例如：

{
  "resourceType": "mcp_server",
  "subjectType": "mcp_server",
  "protocolBindings": [
    {
      "id": "mcp-http",
      "protocol": "MCP",
      "version": "2025-06-18",
      "transport": "streamable-http",
      "serviceRef": "#mcp-service"
    }
  ],
  "services": [
    {
      "id": "#mcp-service",
      "type": "MCPServer",
      "serviceEndpoint": "https://example.invalid/mcp",
      "protocol": "MCP"
    }
  ]
}

该示例中的地址、版本和标识符均为示例值。protocolBindings 说明资源按何种协议接入，services 说明网络入口，两者仍需与资源 DID、发布版本、哈希和认证要求关联；发现服务节点不应仅因存在 MCP 工具清单就把资源标记为可直接调用。

4.5 工具 API

工具 API 是通过网络接口提供具体操作能力的资源，对应资源类型值 tool_api。它应描述接口地址、操作或能力名称、输入参数、输出结果、协议、版本、认证方式和调用约束；复杂参数可以通过输入和输出 schema、协议 schema 引用或外部文档表达。一个工具 API 可以被智能体服务、技能包或 MCP 服务引用，但引用关系不等于调用方已经通过目标端点的认证和授权。

工具 API 的资源描述与实际服务实现应保持可验证关联。资源控制方负责声明接口和版本，发布链路负责绑定 DID文档、元数据、哈希和根平台证明，调用方负责在连接前检查端点、版本、证据和自身策略。接口存在、HTTP 响应正常或在发现索引中出现，都不能单独证明工具业务结果正确或调用一定被允许。

工具 API 的能力描述可以用输入、输出 schema 和认证要求把“能做什么”与“如何调用”分开表达：

{
  "resourceType": "tool_api",
  "resourceDescription": {
    "name": "Repository Structure Summary API",
    "capabilityDescription": "Accepts a repository reference and returns a project structure summary.",
    "inputSchema": {
      "type": "object",
      "required": ["repository"],
      "properties": {
        "repository": { "type": "string" }
      }
    },
    "outputSchema": {
      "type": "object",
      "required": ["summary"],
      "properties": {
        "summary": { "type": "string" }
      }
    }
  },
  "credentialRequirements": [
    {
      "credentialType": "Bearer",
      "presentationMode": "header",
      "required": true
    }
  ]
}

schema 约束输入输出形状，凭证要求说明调用前需要准备的认证材料；真正的权限判断、限流、业务校验和结果质量仍由目标 API 及调用方策略负责。资源模型只为这些声明提供可登记、可发布和可发现的身份边界。

4.6 资源关系与组合

资源关系用于表达资源之间可验证的依赖、提供、调用、包含或组合。当前实现以 implementationLinks 等结构化链接承载关系，链接至少应包含关系类型、目标资源 DID，并可包含目标资源类型、目标服务和版本约束。关系的可信性来自双方资源身份、发布证据和当前状态，而不是来自一段无法校验的自然语言说明。资源包可以承载某一版本关系的发布表示，但不应把一个版本的关系自动延伸到所有未来版本。

组合系统在运行前应验证每个被引用资源的 DID、资源类型、版本或包哈希、根平台发布证明、生命周期状态和授权域。被引用资源不可发现、版本不满足约束、证明缺失、被撤销或暂停时，调用方或编排系统应根据风险选择拒绝组合、等待同步或仅作不具备调用资格的展示，不得把索引中存在摘要当作组合完整性证明。

资源关系在数据上可以表示为一个明确的链接对象，而不是把依赖写进自由文本：

{
  "relation": "provides",
  "targetDid": "did:oan:TLFI:example-tool-api",
  "targetType": "tool_api",
  "targetService": "#repository-summary",
  "versionConstraint": "^1.0.0"
}

关系验证至少需要检查目标 DID、关系类型、目标类型、版本约束和目标资源的当前发布状态。targetService 只是定位目标服务的引用，不能替代端点可达性和认证；当目标资源的版本或包哈希变化时，原关系需要重新匹配和验证。

4.6.1 资源之间的依赖关系

依赖关系表示一个资源的正常使用需要另一个资源或外部能力。依赖声明应指向目标资源 DID，并在必要时给出目标类型、服务引用和版本约束；依赖的业务含义、安装方式和运行时授权可以通过资源描述或协议绑定补充，但身份和版本边界必须结构化表达。依赖目标更新时，调用方应重新检查版本约束和发布状态。

4.6.2 智能体服务与技能包组合

智能体服务可以依赖或组合多个技能包，将技能包作为任务执行、信息处理或工具编排的可复用能力。组合记录应区分智能体服务 DID、技能包 DID、技能包版本或包哈希以及关系类型；智能体服务的发布不自动覆盖技能包的控制和发布事实。调用方需要同时验证智能体服务和技能包的证据及兼容条件。

4.6.3 MCP 服务、工具 API 与调用关系

MCP 服务可以提供工具集合，也可以通过协议绑定引用一个或多个工具 API；工具 API 也可以被智能体服务或技能包直接调用。关系声明应说明目标 DID、目标服务或操作、协议及版本，避免只写“支持某工具”。MCP 协议层可发现的工具能力仍需叠加 OAN 的资源身份、发布状态、端点认证和调用方授权判断。

4.6.4 组合完整性与版本约束

组合完整性至少要求关系双方的 DID、资源类型、版本或包哈希、关系声明、根平台可信发布证明和当前生命周期状态一致，并检查目标资源是否处于调用方可见的授权域。版本约束不满足、包哈希变化、证明过期或资源暂停时，不得继续使用旧组合声明作无条件调用依据；必要时应重新发现、重新验证或回退到明确兼容的版本。

4.7 作为独立可标识对象的资源

四类资源均可拥有独立资源 DID，并以该 DID 作为创建、登记、发布、发现和更新的身份边界。主体 DID 可以表达资源控制关系，发布方 DID 可以表达登记或运营来源，但不能用主体或发布方 DID 替代资源自身 DID。资源 DID 的方法特定编码应与资源类型一致，DID文档中的公钥、服务端点和 oanMetadata 应共同支持资源身份和能力声明的校验。

独立 DID 使技能包、MCP 服务或工具 API 可以脱离某个智能体服务单独被发现和复用，也使它们能够独立更新、暂停、撤销和形成版本记录。资源之间存在组合关系时，仍应分别验证各自 DID 和发布证据；一个资源的可信状态不能自动传递给其依赖资源。

资源类型与 did:oan 方法特定编码之间存在代码级校验关系。当前公共库用 AG、SK、MC 和 TL 分别对应智能体服务、技能包、MCP 服务和工具 API；下面的 DID 仅用于说明形态：

编码前缀是当前实现用于资源类型一致性检查的标识，不应被理解为脱离 did:oan 方法规则的独立 DID 方法。资源类型与 DID 文档 oanMetadata.resourceType 不一致时，节点应拒绝将其当作该类型资源继续处理。

4.8 资源元数据与能力描述

资源元数据是资源身份之外用于注册、发布和发现的结构化说明。公共字段包括资源 DID、资源类型、主体类型、控制方或发布方 DID、名称、描述、能力描述、能力标签、授权域、协议绑定、服务端点、凭证要求、包信息、网络范围、生命周期状态、版本和更新时间。DID文档中的 oanMetadata 与资源包中的资源元数据应在资源 DID、资源类型、版本、哈希、授权域和状态等关键字段上保持一致。

能力描述回答资源能够完成什么，能力标签回答资源属于哪些受治理的能力类别，用例回答这些能力在什么任务中使用。名称和自由文本有助于人和语义引擎理解资源，但不能替代结构化标签、协议绑定、端点或控制证明。元数据是资源提供方作出的声明，根平台和发现服务节点可以验证其结构、哈希和发布来源，但不因字段齐全就替代对业务质量的独立评估。

能力字段在 oanMetadata.resourceDescription 中可以组织为一个面向检索的最小对象：

{
  "name": "Repository Structure Summary",
  "description": "A reusable capability for examining code repositories.",
  "capabilityDescription": "Finds repository files and summarizes the project structure.",
  "capabilityTags": ["code-repository", "project-structure-summary"],
  "useCaseExamples": [
    "I need a tool that can search code repositories and summarize the project structure."
  ],
  "version": "1.0.0"
}

其中自然语言字段适合语义发现和用户理解，标签适合结构化筛选，版本用于与资源包和发布证据关联。它们共同描述资源的能力，但不等于节点已经验证了运行效果，也不替代调用前的身份、发布和授权检查。

4.8.1 基本身份与描述字段

基本字段至少应能够确定资源 DID、资源类型、主体类型、名称、描述、控制方或发布方关系，并与 DID文档的 id、oanMetadata.resourceType、oanMetadata.subjectType 及相关 DID 字段一致。资源类型值应使用协议定义的枚举，展示层的中文名称或别名不能作为唯一机器判断依据。

4.8.2 能力标签、能力描述与用例

能力标签应优先使用根平台维护的能力标签树中的规范标识，也可以在明确标识来源的前提下保留扩展标签；能力描述和用例应说明可执行能力、输入输出和适用任务。注册服务节点可以根据描述提供标签推荐，发现服务节点可以结合标签、别名、描述和用例进行结构化或语义检索，但相关性结果仍需经过身份、发布和授权域校验。

4.8.3 协议、端点与认证信息

协议绑定应说明协议名称、版本、传输方式、服务引用或 schema 引用，并与一个或多个服务端点关联；服务端点应说明地址、类型、版本、协议及必要的端口或服务器信息；认证信息应表达公开的认证方式、凭证要求或调用前提。端点和认证声明是资源能力说明的一部分，不等同于调用方已经获得访问权限。

4.8.4 状态、版本与治理信息

资源元数据应区分资源生命周期状态、资源包版本、更新时间、过期时间、上一版本或版本约束，以及授权域和网络范围。生命周期状态表达资源是否 active、暂停、撤销或被替换等事实，传播进度则由根平台发布、内容分发和发现同步记录表达；二者不能用一个 available 字段混为一谈。

4.9 用例、协议绑定、端点与认证声明

用例、协议绑定、服务端点和认证声明共同组成“如何理解和使用该资源”的公开说明。一个资源可以有多个用例、多个协议绑定和多个端点；每个绑定应尽可能说明适用能力、协议版本、传输方式、服务引用和 schema，认证声明应尽可能关联到目标端点、操作或版本。若端点不可用、协议版本不匹配或认证信息不完整，发现服务节点可以返回带有相应状态的结果，但不应将其表述为可直接调用。

4.9.1 用例描述

用例描述应说明任务目标、输入条件、期望输出和适用资源能力，优先与能力描述和能力标签建立对应关系。自然语言用例可以用于语义检索和用户理解，但不能单独证明资源具备该能力；需要精确约束时，应结合输入输出 schema、协议绑定和版本信息。

4.9.2 协议绑定

协议绑定应记录协议名称、协议版本、传输或交互方式，以及与端点或 schema 的引用关系。A2A 和 MCP 可以作为外部协议语境进入资源描述，OAN 的绑定字段只表达该资源如何接入这些协议，不应把 OAN 资源注册状态写成外部协议的强制条款。

4.9.3 服务端点

服务端点是资源对外提供能力或获取材料的网络入口，可以包含端点标识、端点类型、地址、版本、协议、服务器类型和端口等信息。一个资源存在多个端点时，应说明端点之间的协议或版本差异；端点不可达、证书错误或服务停用时，发现结果应保留该事实或新鲜度信息，不能只看静态地址。

4.9.4 认证与调用要求

认证与调用要求用于说明调用方需要提供何种身份、凭证、签名、权限或协议上下文。资源可以公开声明凭证类型、签发方、范围和呈现方式，但最终业务授权由资源端点和调用方策略共同决定；OAN 的 VC、根平台可信发布证明和节点治理状态是调用前验证材料，不是对所有业务操作的自动授权。

资源模型中的认证声明主要回答“调用方需要准备什么”，例如凭证类型、签发方、作用域和呈现方式；端点收到请求后仍需检查凭证有效期、请求主体、业务权限和运行策略。可以把同一资源的公开声明理解为两层：

4.10 资源包与发布产物

资源包是绑定某一资源版本的可分发对象，通常包含资源 DID、资源类型、资源版本、DID文档、DID文档哈希、元数据哈希、资源包哈希、哈希算法、资源元数据、根平台可信发布证明和创建时间。DID文档表达身份、公钥、服务端点和 OAN 元数据；资源元数据表达能力、用例、协议、端点、授权域和生命周期；控制证明表达资源控制方对操作的授权；注册 VC 表达注册服务节点处理过的登记事实；根平台可信发布证明表达根平台已验证并接受该资源版本的事实。

在节点接口中，资源模型分别对应不同的载荷类型：客户端提交的是 ResourceRegistrationSubmission，其中的 metadata 仍是动态 JSON，因为注册服务节点需要按当前资源元数据规则校验其结构；根平台验证通过后，把这些字段组织为 ResourcePackage，再由 ResourceCdnPublishRequest 或批量请求承载并分发。因此，“资源对象”“登记请求”和“可分发资源包”不是同一个 JSON 对象，客户端不应把注册请求直接当作已经完成根平台证明的资源包。

这些对象形成分层验证链路而不是平行附件。调用方或发现服务节点应先解析 DID文档并验证控制关系，再校验元数据与 DID文档的资源类型、DID、授权域和版本一致性，重算 DID文档哈希、元数据哈希和资源包哈希，验证注册凭证、根平台可信发布证明及当前治理状态。注册受理、根平台发布和发现索引分别由不同组件产生，任一阶段成功都不能替代其它阶段。

一个资源包可以按以下结构理解。示例中的哈希、DID、时间和证明内容均为占位示例，用于展示对象之间的引用关系，不代表官方固定值：

{
  "packageVersion": "1.0.0",
  "resourceDid": "did:oan:SKLG:example-skill",
  "resourceType": "skill",
  "didDocument": {
    "@context": ["https://www.w3.org/ns/did/v1"],
    "id": "did:oan:SKLG:example-skill",
    "verificationMethod": [],
    "authentication": [],
    "assertionMethod": [],
    "service": [],
    "oanMetadata": {
      "subjectType": "skill",
      "resourceType": "skill",
      "capabilityTags": ["code-repository", "project-structure-summary"],
      "authorizedDomains": ["public"],
      "lifecycleState": "active"
    }
  },
  "didDocumentHash": "sha256:example-did-document",
  "metadataHash": "sha256:example-metadata",
  "packageHash": "sha256:example-package",
  "hashAlgorithm": "sha256",
  "metadata": {
    "resourceDid": "did:oan:SKLG:example-skill",
    "resourceType": "skill",
    "subjectType": "skill",
    "name": "Repository Structure Summary",
    "description": "Summarizes a code repository.",
    "capabilityTags": ["code-repository", "project-structure-summary"],
    "authorizedDomains": ["public"],
    "services": [],
    "lifecycleState": "active",
    "packageVersion": "1.0.0",
    "packageHash": "sha256:example-package",
    "metadataHash": "sha256:example-metadata",
    "hashAlgorithm": "sha256",
    "updatedAt": "2026-09-09T08:30:00Z"
  },
  "rootProof": {
    "rootDid": "did:oan:INLG:example-root",
    "packageClaims": {
      "resourceDid": "did:oan:SKLG:example-skill",
      "resourceType": "skill",
      "version": "1.0.0",
      "didDocumentHash": "sha256:example-did-document",
      "metadataHash": "sha256:example-metadata",
      "packageHash": "sha256:example-package",
      "hashAlgorithm": "sha256",
      "lifecycleState": "active",
      "authorizedDomains": ["public"]
    }
  },
  "createdAt": "2026-09-09T08:30:00Z"
}

验证方可以先用 resourceDid 和 resourceType 判断对象归属，再重算三类哈希，检查 metadata 与 DID文档的关键字段一致性，最后验证 rootProof.packageClaims 与当前包声明是否一致。该顺序有助于把“内容完整”“资源可控”“注册受理”和“根平台发布”分别定位，不把一个下载文件误解为全部网络事实。

4.10.1 ResourcePackage 内容

资源包内容应以一个资源版本为中心组织，至少绑定 resourceDid、resourceType、packageVersion、DID文档、DID文档哈希、元数据哈希、资源包哈希、哈希算法、资源元数据和根平台可信发布证明。资源包中的 rootProof 应能够通过其声明关联资源 DID、类型、版本、哈希、生命周期状态、授权域和必要的治理或发布引用。

4.10.2 元数据与资源内容

元数据是对资源内容、能力和运行入口的结构化说明，资源内容可以是技能包文件、服务描述、工具接口或 MCP 能力声明。元数据中的包信息、下载地址、清单地址、实现链接和版本字段应指向或描述当前资源版本，不得让历史元数据覆盖当前资源包的身份和哈希。

4.10.3 哈希与完整性证明

资源包应分别表达 DID文档哈希、元数据哈希和资源包哈希，并声明使用的哈希算法。验证方应按规范化表示重算相应哈希，检查资源包内部字段和根平台证明中的声明是否一致；哈希匹配只能证明内容完整性，不能单独证明控制权、节点授权或业务端点可信。

4.10.4 发布、下载与验证产物

注册服务节点可以返回登记结果、注册凭证或下载材料，根平台产生接受记录和根平台可信发布证明，内容分发平台提供可下载的资源包和相关材料，发现服务节点保存已验证的索引对象。下载到资源包不等于资源已经完成调用授权；调用方应根据来源、版本、新鲜度、治理状态和本地策略重新验证。

4.11 资源生命周期与可见状态

资源生命周期描述资源版本本身的状态，网络传播进度描述该版本是否经过注册受理、根平台接受、内容分发和发现索引。一个资源可以已登记但尚未根平台发布，可以已发布但尚未被某个发现服务节点同步，也可以在发现索引中存在但因授权域或治理状态变化而不再向特定调用方可见。状态判断应同时引用产生状态的组件和相应证据。

资源更新应区分同一版本的幂等重试与新的版本发布。相同资源 DID、版本和哈希的重复提交可以复用既有结果；内容变化、版本变化、控制密钥变化或生命周期变化必须进入新的验证和发布判断。旧快照可以用于有限展示，但不能覆盖当前撤销、暂停、替换或授权域限制。

资源版本和传播状态可以用两个维度观察：

4.11.1 注册状态

本地草稿表示资源材料尚未被注册服务节点受理；已提交表示注册服务节点已收到并处理请求；已登记表示注册服务节点形成了登记记录或注册凭证。上述状态不能直接说明根平台已发布或发现服务节点已索引。资源控制方应保存本地 DID文档、密钥和提交材料，以便在失败或更新时重新验证。

4.11.2 发布与索引状态

根平台已发布表示根平台接受了特定资源版本并形成发布证明；内容已分发表示资源包已进入内容分发平台的承载范围；发现服务节点已索引表示某个发现服务节点完成资源包验证并写入本地读模型。三个状态按异步流程推进，可能短暂不一致，应通过游标、状态和新鲜度表达。

4.11.3 暂停、撤销与恢复状态

暂停表示资源或其版本在规定范围内暂时不得继续按 active 状态传播或调用；撤销表示相应资源、凭证、发布事实或节点授权不再有效；恢复表示经过新的治理或发布判断后重新允许相应动作。状态变化应关联版本、资源 DID、治理事实或发布记录，不能只改网页显示文字；发现服务节点应在状态传播后更新索引和查询结果。

4.11.4 公开可见与可信可发现状态

公开可见表示某个门户或节点能够向特定查询方返回资源信息，可信可发现表示该发现服务节点已验证资源身份、发布证明、哈希、生命周期和授权域，并允许在其授权范围内返回。资源可能公开显示但尚未具备可信可发现资格，也可能已被根平台发布但对某个授权域不可见；调用方仍需在连接前执行自己的验证。

4.12 资源所有权、控制权与委托关系

资源所有权是业务或组织层面的权利关系，DID 控制权是通过密钥和签名证明能够代表资源 DID 执行规定操作的密码学关系，运营管理权是对端点、内容或运行环境的管理责任，发布代理权是注册服务节点或其它授权参与者代为提交或处理材料的资格，调用授权是资源端点和调用方策略共同决定的业务许可。它们可以属于同一主体，也可以由不同主体承担。

资源元数据可以通过 controllerDid、publisherDid、subjectDid、implementationLinks 或凭证要求表达部分关系，但字段本身不是关系真实性的充分证明。验证方应分别检查资源 DID 控制证明、发布方或注册服务节点的凭证、根平台发布证明、治理状态和业务端点认证，不能因某一方能够上传文件、提供地址或签发登记结果，就推定其拥有其它权限。

4.13 资源依赖与组合完整性

依赖完整性要求组合中的每个资源都能被独立识别、定位、验证并按版本使用。最低检查集合包括目标资源 DID、资源类型、关系类型、目标版本或包哈希、DID文档和元数据一致性、根平台可信发布证明、生命周期状态、授权域和必要的协议兼容条件。发现服务节点只返回索引摘要时，调用方还应取得完整资源包或可验证证明后再建立高风险组合。

当发现节点落后、目标资源暂不可获取或证明暂缺时，可以将组合标记为待同步或不可验证；当目标资源版本漂移、被暂停、撤销、超出授权域或哈希不一致时，应拒绝继续使用该组合，除非存在明确满足约束的替代版本。组合完整性是调用前的验证条件，不是资源登记或搜索排名的附带结果。

四类资源共享资源 DID、资源类型、能力描述、版本、端点、协议绑定和生命周期等共性信息，但其内容形态和调用方式不同。资源模型的目标是提供共同的登记、发布和发现骨架，而不是把四类资源强行转换成同一种运行时对象。

flowchart LR
    AG[智能体服务] -->|组合/调用| SK[技能包]
    AG -->|使用协议能力| MCP[MCP 服务]
    MCP -->|暴露工具| API[工具 API]
    SK -.依赖.-> API
    AG -.引用资源 DID、版本或包哈希.-> MCP

资源关系必须显式表达目标 DID、关系类型以及版本或包哈希。仅有名称、搜索相关性或端点可达性，不能证明依赖完整；被引用资源暂停、撤销、版本漂移或超出授权域时，组合方应拒绝继续使用或转入待验证状态。

资源模型的边界： OAN 负责资源的身份、描述、发布、发现和验证关联；资源内部的模型推理、业务流程、工具执行和最终业务授权仍由相应资源及调用方策略负责。

参考来源