真实生态里的资源形态更多
很多人谈智能体互联网时，会自然把注意力放在“Agent”本身。但在真实工程系统里，智能体并不是唯一需要被发现和调用的对象。一个复杂任务可能需要一个天气 API、一个企业知识库 MCP Server、一个代码生成 Skill、一个数据清洗工具、一个审批流程入口，以及若干具备自主规划能力的 Agent Service。它们共同构成了智能体可用的能力网络。
因此，OAN 没有把资源模型限制为 Agent Service，而是把 Agent Service、Skill、MCP Server、Tool/API 作为初始的一等资源类型。这个选择很关键。它意味着 OAN 关注的不是“某一种智能体产品”，而是智能体生态中的可发现能力单元。
四类资源各有侧重
Agent Service 是可调用的业务智能体，通常有网络服务入口，可以对话、执行任务或与其它智能体协作。MCP Server 是面向模型上下文协议的能力服务，可能暴露工具、资源或提示。Tool/API 是更通用的可调用接口，可能是 HTTP API、RPC 服务、企业连接器、数据库查询入口、地图、支付、检索或流程 API。Skill 则更像能力描述和组合说明，它不一定直接运行服务，但可以指向一个或多个实现资源。
| 资源类型 | 典型内容 | 发现时关注点 | 更适合表达什么 |
|---|---|---|---|
| Agent Service | 对话、任务执行、协作入口 | 身份、入口、生命周期 | 可直接调用的智能体服务 |
| Skill | 能力说明、实现链接、参数 | 能力标签、适用场景 | 可复用能力包 |
| MCP Server | 工具、资源、提示接口 | protocolBindings、endpoint | 模型可访问能力 |
| Tool/API | HTTP API、RPC、企业接口 | schema、认证、入口 | 通用系统能力 |
OAN 对这些资源采用统一的 did:oan 标识框架。资源 DID 中的主体代码与资源类型应保持一致，例如 AG、SK、MC、TL 分别对应 Agent Service、Skill、MCP Server 和 Tool/API。DID 字符串本身应标识稳定资源主体，而不应把版本号、endpoint、算法或可变描述硬编码进去。资源的服务入口、协议绑定、能力标签、授权域、包版本、哈希和外部工件引用，则放在 DID 文档和资源包中表达。
统一流程不抹平资源差异
这种设计带来一个直接好处：不同资源形态可以进入同一套注册、分发和发现流程。Registrar 可以帮助不同资源准备注册信息；Root 可以验证 DID 文档、元数据和包之间的绑定；Discovery 可以按资源类型、能力标签、协议和授权域返回候选资源。用户或智能体不必为每种资源形态学习完全不同的信任流程。
OAN 的 ResourceMetadata 也体现了这种统一但不抹平差异的思路。它包含 resourceDid、resourceType、publisherDid、subjectDid、name、description、capabilityTags、authorizedDomains、protocolBindings、services、lifecycleState、packageVersion、packageHash、metadataHash 等字段。对不同资源类型来说，字段含义会有侧重：Skill 更依赖实现链接和包描述；MCP Server 更强调协议绑定和工具入口；Tool/API 更强调接口 schema、认证要求和 endpoint；Agent Service 更强调服务入口、协作协议和可验证控制关系。
资源关系可以形成能力图谱
统一身份也有助于资源之间建立关系。例如，一个 Skill 可以声明自己由某个 Agent Service 实现，或者通过某个 MCP Server 暴露，或者调用一组 Tool/API。调用方可以从 Skill 出发，进一步解析到实际服务入口；也可以从服务资源出发，查看它支持哪些 Skill 或协议。这种资源图谱比单纯的“服务列表”更适合智能体自动规划。
需要强调的是，OAN 并不托管所有资源文件。Skill 文件、OpenAPI 规范、MCP manifest、可执行包或外部工件可以由提供方、代码仓库、对象存储或机构网站托管。OAN 关注的是身份面、发现面和验证面：资源引用是否可信，包哈希是否匹配，发布者是否可验证，生命周期状态是否仍然有效。外部工件通过 URL、hash、version 和 package reference 表达，避免把 DID 文档变成大型文件仓库。
版本更新需要稳定身份
这也解释了为什么 OAN 同时支持版本与生命周期。一个 Skill 升级频繁时，资源 DID 可以保持不变，新的 ResourcePackage 记录新的版本、元数据和包哈希；Discovery 可以默认返回最新 active 版本，也可以支持追溯历史版本。对调用方而言，它看到的是“同一个资源的新版本”，而不是一堆难以关联的重复条目。
当智能体生态继续扩大，用户真正需要的往往不是“找一个 Agent”，而是“找一个能完成某类任务的可信资源”。这个资源可能是 Agent，也可能是 Skill、MCP Server 或 API。OAN 将这些形态纳入同一资源模型，是为了让智能体互联网更接近一个可组合、可治理、可验证的能力网络。
资源类型与 DID 表达
| 资源类型 | DID 需要承载 | Discovery 需要理解 |
|---|---|---|
| Agent Service | 服务身份和入口 | 可调用的智能体服务 |
| Skill | 能力说明和依赖 | 可复用能力包 |
| MCP Server | 协议绑定和端点 | 模型可访问工具集合 |
| Tool/API | 接口描述和约束 | 通用业务能力 |
当智能体生态继续扩大，用户真正需要的往往不是“找一个 Agent”，而是“找一个能完成某类任务的可信资源”。这个资源可能是 Agent，也可能是 Skill、MCP Server 或 API。OAN 将这些形态纳入同一资源模型，是为了让智能体互联网更接近一个可组合、可治理、可验证的能力网络。
资源边界
这里讲得并不只是一种资源，而是几种常见资源都需要被放进统一的身份和发现框架里。这样，OAN 才能同时覆盖 Agent、Skill、MCP Server 和普通 Tool/API。
| 资源类型 | 最关键的发现信息 | 适合放进 OAN 的内容 |
|---|---|---|
| Agent Service | 身份、入口、生命周期 | DID、描述、入口、授权域 |
| Skill | 能力说明、使用条件 | 能力标签、版本、依赖 |
| MCP Server | 协议能力、端点 | protocolBindings、endpoint |
| Tool/API | 接口地址、认证方式 | OpenAPI、调用约束、示例 |
统一管理不等于抹平差异
统一的是注册、验证、发现的流程；不统一的是资源本身的结构。OAN 允许不同资源保持自己的表达方式，只要它们能被可信描述、可信验证、可信发现。
