智能体资源不只是 Agent：Skill、MCP Server 和 Tool/API 为什么也需要统一身份

真实生态里的资源形态更多

很多人谈智能体互联网时，会自然把注意力放在“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 则更像能力描述和组合说明，它不一定直接运行服务，但可以指向一个或多个实现资源。

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 表达

当智能体生态继续扩大，用户真正需要的往往不是“找一个 Agent”，而是“找一个能完成某类任务的可信资源”。这个资源可能是 Agent，也可能是 Skill、MCP Server 或 API。OAN 将这些形态纳入同一资源模型，是为了让智能体互联网更接近一个可组合、可治理、可验证的能力网络。

资源边界

这里讲得并不只是一种资源，而是几种常见资源都需要被放进统一的身份和发现框架里。这样，OAN 才能同时覆盖 Agent、Skill、MCP Server 和普通 Tool/API。

统一管理不等于抹平差异

统一的是注册、验证、发现的流程；不统一的是资源本身的结构。OAN 允许不同资源保持自己的表达方式，只要它们能被可信描述、可信验证、可信发现。