从官网到 SDK 和 Skill：OAN 如何降低资源发布和发现门槛

基础设施项目需要多层入口

一个基础设施项目如果只有协议文档，很难形成生态。开发者需要能看懂项目定位，也需要能快速尝试注册和发现流程；普通用户需要知道自己能做什么；节点运营者需要理解接入路径；工具开发者则希望有 SDK、Skill 或示例可以直接复用。OAN 在这方面的思路，是把官网、SDK、社区 Skill 和参考节点实现结合起来，形成从认知到上手的路径。

官网承担第一层入口。Home 页面适合解释 OAN 为什么存在：智能体资源需要统一身份、可信注册、可验证分发和可信发现。Docs 页面进一步展开 DID、资源模型、授权域、能力标签、Root Proof、第三方节点、SDK 和生态参与方式。Register 和 Discovery 页面让用户直接体验资源注册和发现，而不是只阅读抽象概念。

SDK 封装常用注册发现能力

SDK 承担第二层入口。对于开发者来说，真正接入 OAN 不应从手写 HTTP 请求开始。TypeScript SDK 中的 OanClient 封装了注册、发现、状态查询、标签建议、授权域目录、注册元数据建议、发现查询建议和生命周期观察等能力。开发者可以调用 registerResource 提交资源，调用 discoverResources 查询候选资源，也可以通过 suggestCapabilityTags、suggestRegistrationMetadata、suggestDiscoveryQuery 等方法降低表单填写和查询构造成本。

OAN SDK 的入口配置采用 baseUrl 和显式 endpoint 两层模型。默认 baseUrl 指向官方 API 入口，SDK 可由它推导 Registrar、Discovery、Root 和 CDN 相关路径；如果用户显式配置某个节点 endpoint，则该 endpoint 优先生效。这一设计很适合开放网络：官方服务迁移到正式域名时，默认值可以统一更新；第三方部署节点时，也可以提供自己的 baseUrl 或独立节点地址，而用户侧调用方式保持一致。

baseUrl 只是路由便利

baseUrl 需要被理解为路由便利，而不是信任权威。真正的可信性仍然来自 DID 文档、Root Proof、资源包哈希、节点授权凭证和治理状态。也就是说，用户可以通过一个统一入口访问官方网络，也可以连接第三方节点，但无论入口在哪里，都应按同一套协议对象做验证。这样可以同时满足易用性和开放性。

社区 Skill 承担第三层入口。OAN Community Skill 可以让使用智能体开发工具的用户，通过 Skill 工作流理解并调用 OAN 的注册、发现或文档能力。对于不想直接写代码的人，Skill 是更自然的入口。它也体现了 OAN 自己对“智能体资源”的理解：Skill 不只是文档，而是可以被智能体环境识别、调用和组合的能力描述。

参考实现覆盖不同使用者

参考节点实现承担第四层入口。OAN 的 Root、Registrar、Discovery、CDN 等服务以 Rust 实现，强调性能、可靠性和清晰的边界。Python demo Agent 展示业务智能体如何进行可信调用。TypeScript 更适合官网、SDK 和开发者工具。这种多语言分工不是炫技，而是让不同模块使用合适的工程栈：基础设施服务重视并发和稳定性，前端与工具链重视开发体验，Agent demo 重视易读和快速实验。

对资源发布者来说，理想路径应该是：先在官网理解资源类型，再通过 Register 页面或 SDK 准备资源 DID 文档和元数据，获得 Registrar 辅助建议，提交到 Root 验证，最终在 Discovery 中被找到。注册前需要准备的信息并不神秘：资源名称、资源类型、描述、服务入口、协议绑定、能力标签、授权域、版本、包或 manifest 链接、哈希、发布者 DID 和必要凭证。页面和 SDK 的作用，是把这些字段组织成可验证提交，而不是让用户猜测接口格式。

发布者、消费者和节点运营者的路径

对资源消费者来说，路径则是：在 Discovery 页面或 SDK 中查询资源，拿到候选结果，验证 DID 文档、Root Proof、资源包哈希和 Discovery 签名，再进入具体协议调用。普通用户可以先通过页面体验查询；开发者可以在代码里使用 SDK；智能体环境可以通过 Skill 或工具链自动化执行相同流程。

对节点运营者来说，OAN 还需要提供第三方节点接入机制。Registrar 和 Discovery 节点不能只是“谁都可以随便开”。节点应经过治理或授权流程，获得 Root-issued authorization VC，并结合链上治理状态共同形成有效授权。第三方节点接入测试套件可以作为技术准入检查的一部分，帮助节点在接入前验证接口、报告、授权域、注册发现流程和安全边界是否符合要求。

OAN 降低门槛的关键，不是把信任流程隐藏掉，而是把复杂流程分层呈现。普通用户看到的是清晰的页面和可操作入口；开发者看到的是 SDK 和示例；节点运营者看到的是接入规范和测试套件；研究者看到的是 DID、VC、治理和可信发现的理论基础。只有这些入口同时存在，智能体互联网基础设施才可能从项目走向生态。

不同角色的上手路径

OAN 降低门槛的关键，不是把信任流程隐藏掉，而是把复杂流程分层呈现。普通用户看到的是清晰的页面和可操作入口；开发者看到的是 SDK 和示例；节点运营者看到的是接入规范和测试套件；研究者看到的是 DID、VC、治理和可信发现的理论基础。只有这些入口同时存在，智能体互联网基础设施才可能从项目走向生态。

入口设计

OAN 的用户路径可以拆得很清楚：Home 用来建立第一印象，Docs 用来解释概念，SDK 用来降低接入成本，Skill 用来降低智能体环境里的使用成本，Reference nodes 用来展示真实运行面。

入口之间要能互相导流

这些入口不是并列孤岛，而是从“看懂”到“会用”再到“能运营”的连续路径。用户从官网进来，应该能自然走向文档、代码、示例和节点实现，而不是卡在一个页面上。