在智能体互联网里，资源不再只来自单一平台。一个可调用的 Agent Service、一个 MCP Server、一个自动化 Skill、一个 Tool/API，都可能由不同开发者、企业、研究机构或社区维护。随着资源规模扩大，单一官方节点很难承担全部注册、审核、发现和领域治理工作。OpenAgenet（OAN）的设计目标之一，就是让第三方节点能够在统一信任框架下参与资源注册、分发和发现。
第三方节点接入 OAN，并不是简单地“部署一个服务，然后挂到列表里”。它涉及节点身份、授权域、治理状态、Root 授权、技术测试、运行监控和资源可信链路。本文围绕 OAN 当前的设计与实现，说明第三方节点有哪些类型，为什么需要接入，如何接入，以及背后的技术机制。
一、OAN 里的第三方节点有哪些
OAN 当前主要面向三类基础设施节点开放第三方参与。
第一类是 Registrar Node，即注册节点。Registrar 负责帮助资源提供方完成资源注册材料，包括 did:oan DID Document、资源类型、能力描述、授权域、协议绑定、包元数据、签名材料等。它是资源进入 OAN 可信发布路径的入口。
第二类是 Discovery Node，即发现节点。Discovery 负责从 Root 认可的分发路径同步资源包，验证 Root proof、包哈希、公告事实和生命周期状态，然后建立本地索引，对外提供资源查询能力。它不是普通搜索引擎，而是一个带验证边界的可信发现服务。
第三类是第三方 VC Issuer，即第三方可验证凭证签发方。它可以围绕特定行业、能力、组织资质或合规要求，为资源或节点签发额外凭证。VC Issuer 当前更偏后续扩展方向，但在 OAN 的治理模型中已经预留了角色。
其中，最核心、最先落地的是第三方 Registrar 和第三方 Discovery。因为它们直接决定资源如何进入网络，以及用户和智能体如何发现资源。
二、为什么需要第三方节点
第三方节点接入的价值，不只是“分担流量”，更重要的是让智能体互联网具备开放生态能力。
对资源提供方来说，第三方 Registrar 可以提供更贴近行业的注册服务。比如法律、金融、工业、医疗、教育等领域的资源，往往需要不同的元数据要求、审核标准和风险提示。一个行业型 Registrar 可以更懂这个领域的资源质量和合规边界。
对资源消费者来说，第三方 Discovery 可以提供更专业的发现体验。通用发现节点适合全局检索，但专业发现节点可以围绕特定领域优化索引、排序、解释和过滤策略。例如，面向企业内部工具、科研 Agent、工业控制接口或合规审查 Skill 的 Discovery，可以采用不同的检索策略和展示规则。
对 OAN 生态来说，第三方节点意味着治理不再是单点平台模式。不同组织可以运行自己的基础设施节点，但仍然遵循统一的 DID、资源包、Root proof、授权域和发现响应规范。这样既能保持开放，又不会牺牲可信验证。
三、接入不是自动授权
OAN 对第三方节点接入采用分层机制。一个节点提交了申请材料，并不等于已经被授权；一个节点通过技术测试，也不等于自动获得官方授权。
可以把接入流程理解为三层。
第一层是公开申请记录。节点运营方提交节点信息，包括运营主体、服务端点、节点 DID Document、申请的授权域、运行说明、安全联系人、服务可用性说明等。这一层解决“这个节点是谁，打算提供什么服务”。
第二层是技术测试。OAN 规划了第三方注册发现节点接入测试套件，用于检查节点实现是否满足基本协议要求，例如接口行为、输入输出结构、授权域处理、DID 文档一致性、资源注册校验、发现查询约束、报告可重复性等。测试通过说明“被测节点通过技术测试”，但这只是授权准入的必要条件。
第三层是治理与 Root 授权。治理流程确认节点是否被接受，Root 根据治理状态和节点身份材料签发基础设施授权 VC。只有治理状态有效，并且节点持有 Root-issued infrastructure authorization VC，节点才应被视为 OAN 可信基础设施的一部分。
这种设计避免了两个极端：既不是任何人随便部署节点都能成为可信节点，也不是所有能力都只能由官方单点提供。
四、第三方 Registrar 如何接入
第三方 Registrar 的职责，是在授权范围内接收资源注册。它应当完成几项准备工作。
首先，运营方需要部署 Registrar 服务，并提供稳定的公网 API base URL。这个 base URL 是用户、SDK 或 Skill 访问该 Registrar 的入口。OAN 的 SDK 和社区 Skill 支持官方默认入口，也支持用户配置第三方节点 endpoint 或 baseUrl。
其次，Registrar 需要生成并发布自己的 did:oan DID Document。该 DID Document 应描述节点角色、服务端点、验证方法、控制关系以及 authorizedDomains 等信息。对于基础设施节点来说，DID Document 不是宣传页，而是后续验证节点身份和授权状态的机器可读材料。
再次，Registrar 要明确自己申请服务的授权域。授权域不是能力标签。authorizedDomains 表示该 Registrar 被允许接收哪些领域的资源注册。比如一个法律领域 Registrar 可以申请法律相关授权域，但不应默认接收全部金融、医疗或工业资源。
最后，Registrar 需要通过技术测试和治理流程。激活后，它在接收资源时应检查资源 DID、资源类型、DID Document、元数据、授权域、包哈希和签名材料，并拒绝超出自身授权域范围的资源。
五、第三方 Discovery 如何接入
第三方 Discovery 的职责，是在授权范围内提供可信发现服务。
Discovery 节点同样需要稳定公网 API base URL、节点 DID Document、服务说明、监控能力和安全联系人。它还需要明确申请哪些授权域，因为 Discovery 不是全网无约束展示资源，而是在自身授权范围内暴露 Root 已验证资源。
Discovery 的核心工作链路是：从 Root/CDN 同步已发布资源包，验证 Root proof、包哈希、公告事实和生命周期状态，然后建立本地索引。用户或智能体发起查询时，Discovery 返回匹配资源，同时应保证结果没有超出节点授权域。
这意味着 Discovery 可以优化语义检索、排序、解释和过滤，但不能用语义相似度突破治理边界。一个资源即使与查询非常相关，如果不在该 Discovery 的授权域覆盖范围内，也不应作为可信发现结果返回。
Discovery 响应还应具备可验证性。理想情况下，用户或 SDK 不只是拿到“搜索结果”，还应能检查结果来自哪个 Discovery 节点、该节点是否被授权、结果是否绑定 Root 已验证资源包、相关证明是否新鲜有效。
六、第三方 VC Issuer 的位置
第三方 VC Issuer 可以理解为面向特定信任事实的凭证签发方。比如某个机构可以围绕资源安全评测、接口互操作性、行业资质、数据合规、模型能力评估等签发可验证凭证。
不过 VC Issuer 不应替代 Root、Registrar 或 Discovery。它提供的是额外证据，而不是基础设施授权本身。OAN 的治理模型中，VC Issuer 也需要自身 DID、签发策略、凭证类型说明、撤销或状态接口，并在参与试验网络信任流时接受治理和 Root 授权约束。
这使 OAN 可以逐步支持更丰富的信任生态：资源是否由授权 Registrar 接入，是一类证据；资源是否通过第三方安全评测，是另一类证据；资源是否仍处于有效生命周期，又是另一类证据。这些证据可以组合，但职责不混淆。
七、授权域是接入机制的关键
第三方节点接入 OAN 时，最容易被误解的概念是授权域。
OAN 中的 authorizedDomains 是治理属性，用来决定 Registrar 可以接收哪些资源、Discovery 可以展示哪些资源。它不是搜索标签，也不是营销分类。
capabilityTags 则用于描述资源能力，帮助发现节点做检索和排序。比如一个 Skill 可以有 contract-review、risk-analysis 等能力标签，但这些标签不能扩大它的授权范围。授权检查必须基于 authorizedDomains。
这种分离让 OAN 的治理更清晰。一个节点可以在自己擅长的领域做深做专，而不必声明自己覆盖所有资源；一个资源也可以用丰富标签描述能力，但其可信发布和发现仍受明确授权边界约束。
八、Root 在第三方接入中的作用
Root 是第三方节点接入后能否进入可信路径的关键。
链上治理层记录基础设施节点的生命周期状态，例如授权、暂停、恢复、撤销等。Root 观察这些治理状态，并结合节点 DID、服务端点、授权域和凭证材料，签发或更新基础设施授权 VC。
因此，一个第三方节点是否可信，不取决于它自己声称“我是 OAN 节点”，也不取决于某个网页是否列出了它，而取决于两类证据：治理状态是否有效，Root 授权材料是否有效。
对于 Registrar，Root 会在资源提交阶段检查 Registrar 的授权状态和授权域覆盖关系。对于 Discovery，Root 会决定哪些资源包应通知给哪些授权 Discovery 节点。Discovery 再通过验证 Root proof 和包哈希，确保自己索引的是 Root 认可的资源版本。
九、SDK 和 Skill 如何支持第三方节点
对普通用户来说，第三方节点接入不能带来额外使用负担。OAN 的设计倾向于提供统一入口和可配置 endpoint 的组合。
默认情况下，SDK 或社区 Skill 可以使用官方 baseUrl，自动解析 Registrar、Discovery、Root、CDN 等服务入口。用户如果使用第三方 Registrar 或 Discovery，也可以显式配置对应 endpoint 或 baseUrl。
这种机制的好处是：对用户来说，使用官方节点和第三方节点的方式尽量一致；对节点运营方来说，可以部署自己的服务入口；对生态治理来说，官方可以保留默认可信路径，同时允许专业节点逐步加入。
在资源注册场景中，Skill 可以帮助用户准备资源 DID、描述、能力标签和授权域，并调用选定 Registrar。在发现场景中，Skill 可以调用选定 Discovery，根据查询返回资源候选，并辅助解释结果中的 DID、Root proof、授权域和生命周期信息。
十、接入测试套件的意义
第三方节点接入不能只靠人工文档审核。OAN 规划了第三方节点接入测试套件，用于对 Registrar 和 Discovery 的关键技术行为进行一致性检查。
测试内容可以包括：节点配置和端点解析、节点 DID 一致性、授权域规范化、资源注册包校验、DID Document 与元数据绑定、Discovery 查询输入校验、发现结果可见性、生命周期状态处理、报告 PASS/FAIL 输出等。
需要强调的是，测试套件本身不是授权机构。它输出的是技术测试结论，例如“被测节点通过技术测试”或“不通过”。最终是否获得 OAN 官方授权，还需要结合运营主体、服务能力、安全要求、治理流程和 Root 授权材料。
这套机制让第三方节点准入更加客观：不是只看承诺，而是用可复现测试检查节点是否满足基础协议行为。
十一、第三方节点接入后的运行责任
第三方节点接入后，还需要长期保持运行质量。
Registrar 应持续保证注册策略清晰、超范围资源被拒绝、私钥不外泄、注册材料可追溯、服务端点稳定。Discovery 应保证同步链路正常、Root proof 和包哈希验证有效、授权域过滤生效、查询响应可验证、索引不过期。
节点还需要维护公开运维页面、安全联系人、健康检查接口、变更记录和异常处理流程。治理状态发生暂停、恢复或撤销时，节点应及时调整运行行为。特别是当节点状态失效时，服务应 fail closed，避免继续以授权节点身份对外提供可信注册或发现能力。
这也是 OAN 把节点接入看作“基础设施运营”而不是“提交一个 API 地址”的原因。
十二、结语
第三方节点接入 OpenAgenet（OAN）的意义，在于让智能体互联网的资源注册和发现从单一平台走向多方协作，同时保留可验证的信任边界。
Registrar 负责资源进入可信发布路径，Discovery 负责资源被可信发现，VC Issuer 提供扩展凭证能力，Root 负责将治理状态转化为运行时可验证授权。授权域限制节点作用范围，DID Document 表达节点和资源身份，Root proof 与包哈希保证发布材料可验证，SDK 和 Skill 则把这些机制封装成用户可以实际使用的流程。
未来，当更多行业节点、企业节点和社区节点加入 OAN，智能体资源就不必被锁在单一平台中，而可以在统一身份、统一验证和统一治理规则下跨域流通。这正是 OAN 作为智能体互联网基础设施项目的重要价值。
