智能体互联网不是简单地把更多 Agent、工具、MCP Server、Skill 放到一个搜索框里。真正困难的问题在于：当资源来自不同开发者、不同组织、不同平台甚至不同节点运营方时，系统如何判断“谁有资格发布资源”“哪个发现节点有资格展示资源”“某个资源是否仍处于有效状态”“客户端在调用前应该验证哪些证据”。
OpenAgenet（OAN）的治理设计，正是围绕这些问题展开。它没有把所有业务都放到链上，也没有让区块链承担高频搜索、注册、调用等工作，而是将区块链用于低频、关键、可审计的治理状态锚定，再通过 Root、Registrar、Discovery 等基础设施节点完成链下高性能服务。
一、OAN 为什么需要去中心化治理
在传统平台模式下，资源注册、审核、展示和下架通常由单一平台控制。这种方式在封闭生态里效率很高，但一旦进入智能体互联网场景，就会出现几个问题。
第一，资源形态更加复杂。智能体互联网里的资源不仅包括 Agent Service，也包括 Skill、MCP Server、Tool/API 等可被智能体调用、组合或委托的能力单元。它们不一定来自同一个平台，也不一定由同一个组织维护。
第二，调用关系更加自动化。人类用户可以凭经验判断一个插件、工具或服务是否可信，但智能体需要机器可读、可验证的证据，包括资源标识、发布路径、包哈希、授权状态、生命周期状态和服务端点绑定关系。
第三，节点运营会逐步走向多方参与。未来不可能只有一个官方注册节点或发现节点。行业组织、企业、研究机构、社区运营方都可能运行自己的 Registrar 或 Discovery 节点。此时系统需要明确：哪些节点被授权、授权范围是什么、节点是否仍有效、授权是否已经撤销。
因此，OAN 的治理目标不是制造一个复杂的“链上系统”，而是为开放生态提供一套可验证的信任边界。
二、治理状态与业务服务解耦
OAN 的核心设计原则是：链上治理只处理低频信任事实，链下节点处理高频业务服务。
链上治理层主要记录基础设施参与方的生命周期状态，例如 Registrar、Discovery 以及未来第三方 VC Issuer 等节点是否处于 active、suspended、revoked 等状态。它不存储资源 DID 文档，不存储资源包，不承载语义检索，也不处理用户的实时调用请求。
这样设计有两个好处。
一方面，治理状态可以被多方审计。节点是否被授权、是否被撤销、治理操作是否发生过，都可以形成可追溯记录，避免单一服务端数据库成为唯一事实来源。
另一方面，性能路径不会被链拖慢。资源注册、Root 校验、CDN 分发、Discovery 索引、语义检索、SDK 调用等高频流程仍然由专门的链下服务完成。区块链只承担“信任锚”和“治理公告板”的角色，而不是成为业务数据平面。
这也是 OAN 回应“DID 或区块链会不会导致性能问题”的关键：OAN 没有把每次发现、每次搜索、每次调用都放到链上，链上只处理治理状态这种低频但高价值的事实。
三、Root 是治理状态到运行系统的桥梁
在 OAN 中，Root Node 是治理和运行系统之间的关键桥梁。它不是普通的搜索节点，也不是资源托管平台，而是信任锚和发布控制点。
OAN 将治理状态与协议凭证分开处理。链上治理状态说明某个基础设施节点当前是否被治理体系认可，但它本身不是直接拿来做服务调用的凭证。Root 会观察最新治理状态，并在验证节点身份、DID 控制材料、授权范围等信息后，向基础设施节点签发 Root-issued infrastructure authorization VC。
因此，一个 Registrar 或 Discovery 节点要成为有效基础设施参与者，需要同时满足两个条件：其治理状态是有效的，并且持有 Root 签发的有效授权 VC。只有 VC 但链上状态已经失效，不应继续被认为有效；只有链上状态但没有 Root 授权凭证，也不能直接参与服务间信任流程。
这种双层结构让系统既保留去中心化治理的可审计性，又让链下服务可以用 VC、签名、Root proof 等标准化材料进行高效验证。
四、Registrar 的治理边界
Registrar Node 负责资源注册入口。开发者或资源提供方通过 Registrar 准备并提交 Agent Service、Skill、MCP Server、Tool/API 等资源的注册材料，包括 did:oan DID Document、资源描述、能力标签、授权域、服务端点、包元数据和必要签名。
但 Registrar 不是任意资源都可以接受。它自身也有治理授权边界。OAN 的授权域设计明确区分了两个概念：
authorizedDomains 是治理边界，用来说明某个节点或资源被授权在哪些领域发布、接收或展示。
capabilityTags 是搜索和语义发现信号，用来帮助 Discovery 更好地匹配用户查询。
这一区分很重要。能力标签不能扩大授权范围。一个资源即使写了很多与金融、医疗、法律相关的标签，如果 Registrar 没有对应授权域，或者资源本身的授权域不符合规范，它也不应该被正式发布到 Root 信任路径中。
Registrar 的治理职责可以概括为：帮助用户完成资源材料，但不绕过授权边界；检查资源 DID 文档和包元数据中的授权域；确保资源注册请求与自身授权范围一致；再将通过检查的材料提交给 Root。
五、Discovery 的治理边界
Discovery Node 负责资源发现，但它也不是一个无边界搜索引擎。OAN 的 Discovery 节点从 CDN 同步 Root 已验证的资源包，验证 Root proof、包哈希、公告事实等材料，然后建立本地索引，并对外提供带签名的发现结果。
Discovery 的治理约束主要体现在两个方面。
第一，它只能作为被授权的基础设施节点运行。Discovery 节点同样需要有效治理状态和 Root 授权 VC。如果其治理状态失效、撤销或过期，应停止作为授权发现节点提供服务。
第二，它只能展示授权域覆盖范围内的资源。比如一个 Discovery 节点只被授权展示法律和合同相关资源，它就不应该因为某个通用资源在语义上匹配用户查询，就把不在授权域范围内的资源返回给用户。语义相关性解决“像不像”，授权域解决“能不能展示”。
这种设计使 Discovery 结果不仅是搜索结果，也是带有治理约束和可验证证据的资源候选集。
六、did:oan 将治理语义写进资源身份
OAN 的 did:oan 不是只给资源生成一个 ID。它把智能体互联网资源需要的关键语义放进 DID Document 和相关包材料中，包括资源类型、控制关系、验证方法、服务端点、协议绑定、能力描述、能力标签、授权域、生命周期提示、包信息、Root proof 引用等。
这样，资源身份不再只是数据库里的一行记录，而是可以被 Registrar、Root、Discovery、SDK 和客户端共同理解的一组可验证材料。
例如，一个 Skill 可以拥有稳定的 did:oan 标识，版本升级时 DID 可以保持不变，而包版本、包哈希、Root proof 和生命周期状态发生更新。客户端发现该 Skill 后，不只看到“有一个技能匹配你的查询”，还能检查它是谁发布的、经过哪个路径接受、当前版本是什么、包哈希是否一致、发现节点是否有资格展示它。
这就是 OAN 将 DID 与治理机制结合的关键价值：身份、描述、授权、分发和验证不是割裂的，而是围绕资源形成一条可信发布路径。
七、典型治理实施流程
一个基础设施节点接入 OAN 的流程，可以抽象为以下步骤。
首先，节点运营方准备自身的 did:oan 身份材料、服务端点、授权域申请和运维信息。治理流程根据准入规则，将符合条件的 Registrar 或 Discovery 节点标记为有效状态。
然后，Root 观察治理状态，验证节点身份和 DID 控制关系，为节点签发基础设施授权 VC。节点在后续服务间交互中使用该 VC 证明自身身份和授权范围。
当资源提供方提交资源时，Registrar 检查 DID 文档、资源元数据、签名、授权域和包字段，并将通过检查的材料提交给 Root。Root 再检查 Registrar 的授权状态、资源材料一致性、包哈希、授权域覆盖关系和策略约束。
Root 接受资源后，生成可验证的发布证明，并将资源包、DID 文档、元数据和证明材料发布到分发层。Discovery 节点同步这些材料，验证 Root proof 和哈希后建立索引。用户或智能体查询 Discovery 时，获得的是可解释、可验证、可追溯的发现结果。
八、去中心化治理不是放弃管理，而是让管理可验证
很多人会把去中心化治理理解成“没有中心”或“所有节点自由加入”。这不是 OAN 的实际设计。
OAN 的去中心化治理更接近一种多方可参与、状态可审计、证据可验证的基础设施治理方式。它仍然可以有官方节点、默认入口、运营规则、准入测试和授权流程；区别在于，这些权威行为不只存在于某个后台数据库或口头承诺中，而是通过治理状态、Root 授权 VC、Root proof、包哈希和签名响应形成可检查的证据链。
这对智能体互联网尤其重要。因为未来调用资源的主体不一定是人，很多判断会由 SDK、Agent Runtime 或企业安全策略自动完成。系统需要把“可信”变成机器能验证的结构化事实，而不是页面上的一个认证图标。
九、OAN 方案的工程特点
从工程角度看，OAN 的治理实施方案有几个特点。
第一，职责分层清晰。链上治理记录低频状态，Root 负责授权和发布控制，Registrar 负责资源接入，Discovery 负责验证索引和发现响应，CDN 只负责分发，不承担信任判断。
第二，授权域和能力标签分离。授权域是治理边界，能力标签是检索信号。这避免了用自由文本标签替代治理授权的风险。
第三，支持第三方节点。第三方 Registrar 和 Discovery 可以在获得治理授权后接入网络，同时仍遵循统一的 DID、Root proof、包哈希、授权域和发现响应规则。
第四，保持协议中立。OAN 不替代 MCP、A2A、HTTP API 或其他调用协议，而是在调用前提供身份、发布、发现和验证层。
第五，性能路径可扩展。高频检索、索引和调用不依赖链上交易，链上治理只处理关键状态变化，因此更适合大规模资源注册与发现。
十、结语
智能体互联网需要的不只是更多工具和更多协议，还需要一套能够支撑开放协作的信任基础设施。OpenAgenet（OAN）的去中心化治理方案，并不是把复杂性简单推给区块链，而是把链上治理、Root 授权、资源注册、可信分发、语义发现和客户端验证组织成一条完整的工程路径。
在这条路径中，区块链承担治理锚定，DID 承担资源身份表达，Root 承担可信发布控制，Registrar 和 Discovery 承担可扩展服务能力。这样的设计让智能体资源可以在多方生态中被注册、发现、验证和使用，也为未来第三方节点接入、行业域治理和智能体互联网标准化提供了更坚实的基础。
