怎么在 OpenAgenet（OAN）上发布和发现智能体等资源

如果你现在在做 Agent、Skill、MCP Server、Tool/API 之类的资源，应该很容易遇到一个现实问题：

资源越多，越难靠人肉方式管理、描述、查找和接入。

OpenAgenet（OAN）想解决的，就是这件事。它不是简单做一个资源列表，而是把智能体资源做成一类可注册、可发现、可验证的对象，让资源发布和资源发现有一条更清晰的路径。

官网：

• OpenAgenet / OAN
• GitHub 组织

先说结论

在 OAN 里，资源发布大致走这条路：

1. 准备资源信息
2. 选定资源类型和授权域
3. 生成或整理 DID 和元数据
4. 提交到 Registrar
5. 等待 Root 相关治理与发布链路完成
6. 让 Discovery 索引并可发现

资源发现则相反：

1. 用户或 Agent 输入任务需求
2. Discovery 根据查询、标签、资源类型和授权域筛选候选资源
3. 返回带证据的结果
4. 用户再决定是否进入原生协议调用或安装使用

这套流程的关键不在“有没有目录”，而在“目录里的资源是否可信、是否有效、是否适合当前任务”。

1. OAN 里的资源是什么

OAN 目前把这些东西都看成资源：

• agent_service
• skill
• mcp_server
• tool_api

它们的共同点是：都可以被注册、被发现、被验证。

在 OAN 的模型里，资源不只是一个 URL，而是一个带身份、带元数据、带授权边界的对象。

这也是为什么 OAN 引入了 did:oan、authorizedDomains、capabilityTags、resourceType 这些字段。

2. 发布资源前，要先准备什么

从官网和社区 skill 的思路看，发布资源前，建议至少准备这些信息：

• 资源名称
• 简短描述
• 资源类型
• 入口地址或包地址
• authorizedDomains
• capabilityTags
• 版本信息
• DID 相关材料
• 可能的 manifest、schema、hash、签名或包引用

这里有两个概念最容易混：

authorizedDomains

这是授权边界。它决定资源在哪些域里能被注册、分发或索引。

capabilityTags

这是能力描述。它决定资源更适合被怎么搜到、怎么匹配。

这两个不是一回事。

capabilityTags 不能拿来替代授权域，授权域也不能拿来充当标签。

3. 发布流程怎么走

如果你是开发者，最实用的理解方式是把 OAN 的发布流程看成一个“有证据链的注册流程”。

第一步：整理资源描述

把资源说清楚，尤其是：

• 它是什么
• 它能做什么
• 谁控制它
• 它适合什么场景
• 它对应什么协议或入口

第二步：补齐授权域

OAN 要求资源注册时，授权域不能含糊。

如果你知道资源属于哪个节点授权范围，就直接填清楚。

不要把授权域和能力标签混着写。

第三步：提交到 Registrar

注册节点负责接收资源注册请求，并对资源信息做结构化校验。

如果资源信息不完整，或者授权域不合法，Registrar 应该直接拒绝。

第四步：进入 Root / 发布链路

资源不是一提交就“全网可见”。

OAN 更强调治理和验证链路。

资源经过 Root 相关处理后，才更适合进入后续发布和发现流程。

第五步：被 Discovery 索引

Discovery 索引通过后的资源，才会变成真正可发现的候选项。

4. OAN 里的 Discovery 怎么用

Discovery 的目标不是简单搜索，而是让 Agent 或用户能按任务意图找资源。

比如你可以输入：

• 我需要一个能总结文档的 Skill
• 我需要一个支持知识检索的 MCP Server
• 我需要一个能处理合同审核的工具服务

Discovery 会基于这些信息去匹配：

• 资源描述
• capability tags
• resource type
• protocol
• authorization scope
• 生命周期状态

这意味着 OAN 的发现更像“语义发现”，而不是普通关键词查找。

5. 什么样的资源更容易被发现

从 OAN 的设计看，资源要更容易被发现，通常要做到：

• 描述清楚
• 类型明确
• 标签合理
• 授权域正确
• 版本可识别
• 元数据完整

尤其是 resourceDescription 和 capabilityTags，它们会直接影响资源能否被理解和匹配。

一个很实用的经验是：

• 描述不要只写“这是一个工具”
• 要写它能解决什么问题
• 标签不要太泛
• 最好围绕任务、领域、协议、输入输出方式来写

6. 官方默认入口和第三方节点

OAN 的一个重要特点，是它并不只考虑官方单节点模式。

社区 skill 的思路里，默认会连接官方 baseUrl，但也允许用户配置第三方 baseUrl 或显式的 Registrar / Discovery 节点。

这意味着：

• 普通用户可以先用官方默认路径
• 更高级的用户可以切到第三方节点
• 未来迁移域名或服务地址时，也更容易统一调整

这对生态很重要，因为智能体互联网最终不太可能只有一个节点运营方。

7. 社区 skill 在这里扮演什么角色

OAN 的社区 skill，本质上是给普通开发者一个更好上手的入口。

它主要帮你做这些事：

• 准备注册材料
• 检查字段是否完整
• 推荐 capability tags
• 辅助选择 authorized domains
• 组织 Discovery 查询
• 解释发现结果
• 帮你理解资源生命周期

它的边界也很清楚：

• 不负责启动整套 OAN 本地网络
• 不负责官方治理操作
• 不负责私钥和私有运维动作
• 不负责压力测试和正式运营流程

这点我觉得很对。

因为社区用户最需要的，往往不是“会运维整套基础设施”，而是“能把资源发上去、找得到、看得懂”。

8. 一个典型的发布例子

假设你有一个合同审查 Skill，要发布到 OAN，你通常需要：

• 资源类型：skill
• 资源名称：合同审查助手
• 简介：提取合同条款并提示风险
• authorizedDomains：比如法律、合规、文档处理等
• capabilityTags：比如 contract-review、risk-analysis、document-parsing
• 资源入口：manifest 或下载地址
• DID：对应的 did:oan

提交后，Registrar 会做校验，Discovery 再决定是否索引和返回。

之后，用户在 Discovery 里输入需求，才有可能找到你这个资源。

9. 一个典型的发现例子

如果用户输入：

我需要一个能从 Word 合同中提取条款并识别风险的工具

Discovery 可以根据以下信息帮你找：

• resourceType = skill
• capabilityTags 相关项
• 语义描述相似度
• 授权域匹配
• 生命周期状态是否有效

然后返回候选资源，再让用户决定是否进一步验证和接入。

这比“直接给一堆链接”更适合 Agent 场景。

10. OAN 这个思路的价值

我觉得 OAN 真正有价值的地方，不是把资源再做一遍目录，而是把资源接入这件事标准化了。

它回答的是一组很底层的问题：

• 资源怎么表示
• 资源怎么注册
• 资源怎么发现
• 资源怎么验证
• 节点怎么治理
• 第三方怎么接入

如果这些问题没有统一答案，Agent 生态就很难长成网络。

如果这些问题有了一套可复用的基础设施，资源发布和发现就会顺很多。

结语

如果你正在做 Agent、Skill、MCP Server、Tool/API，或者你本身就在搭一个智能体平台，OAN 值得认真看看。

它的思路很清楚：

• 用 did:oan 给资源身份
• 用 authorizedDomains 约束边界
• 用 capabilityTags 表达能力
• 用 Registrar 做注册
• 用 Discovery 做发现
• 用治理和验证保证资源不是“看起来像”，而是“可以被信”

对开发者来说，这样的一套资源基础设施，比单纯一个资源列表更接近智能体互联网真正需要的东西。