分布式标识 DID 在智能体互联网基础设施中的应用：以 OpenAgenet（OAN）为例

智能体互联网正在从概念走向工程实现。

当 Agent、MCP Server、Skill、工具 API、知识服务、自动化工作流等资源开始跨平台、跨组织、跨节点流动时，一个很基础的问题会变得越来越重要：

智能体如何识别、验证、发现和使用外部资源？

在传统互联网应用里，一个服务地址、一个账号体系、一套证书机制，通常就能支撑大量业务场景。但智能体互联网面对的不是单一平台内部的服务调用，而是多主体、多节点、多协议、多资源形态之间的开放协作。

这也是 OpenAgenet（OAN）选择围绕 did:oan、资源注册、授权分发、语义发现和链上治理构建基础设施的原因。

项目地址：

• 官网：https://www.openagenet.xyz/
• GitHub：https://github.com/OpenAgenet

一、智能体互联网为什么需要新的标识基础设施

在智能体系统中，“资源”不再只是一个接口地址。

它可能是：

• 一个 Agent Service；
• 一个 MCP Server；
• 一个 Agent Skill；
• 一个 Tool/API；
• 一个知识服务；
• 一个数据服务；
• 一个自动化工作流；
• 一个第三方组织运营的注册或发现节点。

这些资源在被智能体调用之前，需要回答的不只是“地址在哪里”，还包括：

• 这个资源是谁发布的？
• 资源描述是否可信？
• 当前版本是否仍然有效？
• 资源属于什么能力范围？
• 资源是否处于某个授权域内？
• 资源是由哪个注册节点接入的？
• 发现结果是否可以被验证？
• 第三方节点是否具备相应的运营资格？

如果只使用传统的“分配 ID + 证书”方式，确实可以解决一部分身份认证问题，例如“谁签发”“证书是否有效”。这套机制成熟、简单、工程经验丰富，在单中心或强中心系统里非常可靠。

但智能体互联网还需要更丰富的资源表达能力。它不仅需要证明“这个主体是谁”，还要表达“这个资源是什么、能做什么、通过什么入口调用、属于什么授权域、有哪些版本和证明材料、如何被发现和复核”。

这正是 DID 在智能体互联网场景中的潜力所在。

二、DID 不是为了复杂，而是为了降低跨平台协作摩擦

DID 经常被误解为一种“为了去中心化而去中心化”的复杂设计。

但在 OAN 的语境里，DID 的价值并不在于追求理想化的无中心网络，而在于提供一种更适合开放协作的资源描述框架。

传统 ID 往往依赖某个分配方。资源进入另一个平台时，经常需要重新解释：

• 这个 ID 是谁分配的；
• 对方系统是否认可；
• 资源元数据在哪里；
• 服务入口在哪里；
• 能力标签如何映射；
• 授权范围如何表达；
• 版本和证明关系如何校验。

而 DID 的优势在于，它可以把标识、控制权、公钥材料、服务端点、元数据引用和验证关系放进一套可解析、可扩展的文档模型中。

在 OAN 中，did:oan 不是只给 Agent 起名字，而是面向智能体资源设计。

一个资源可以通过 did:oan 绑定：

• 资源类型；
• 发布者或控制者；
• 服务入口；
• 能力描述；
• 授权域；
• 版本信息；
• 包哈希；
• Root 证明；
• 生命周期状态；
• 发现所需的语义信息。

这样，资源就从“一个链接”变成了“一个可验证、可发现、可治理的对象”。

三、OAN 中的 did:oan：面向资源，而不只是面向账号

很多身份系统的核心对象是账号、用户或组织。

而 OAN 更强调 Resource First，也就是优先把智能体互联网里的可调用资源作为核心对象。

OAN 当前重点支持的资源形态包括：

• agent_service
• skill
• mcp_server
• tool_api

这些资源可以对应不同协议、不同实现语言、不同托管平台，但在 OAN 中可以共享一套资源身份和生命周期模型。

这带来几个工程优势。

第一，资源身份更稳定。

资源升级版本时，资源 DID 可以保持不变，版本信息、包哈希、元数据和证明材料随资源包更新。这样既方便发现节点追踪新版本，也避免每次升级都改变资源身份。

第二，资源描述更机器友好。

智能体不是人类浏览器用户。它需要结构化字段来理解资源能力、入口、协议、标签和适用范围。did:oan 将这些信息纳入资源描述，有利于注册、发现和自动化调用。

第三，跨平台复核成本更低。

当资源从一个节点传播到另一个节点时，接收方不必完全依赖原平台说明，而可以根据 DID 文档、签名、哈希、Root proof 和治理状态进行复核。

第四，生态扩展空间更大。

未来如果存在多个注册节点、多个发现节点、多个第三方运营方，统一的资源标识和验证模型会比平台私有 ID 更适合扩展。

四、区块链在 OAN 中的作用：治理锚点，而不是业务数据库

关于 DID + 区块链，最常见的疑问是性能：

如果 DID 依赖区块链，那未来注册、发现、检索、调用是不是都会被链拖慢？

这个疑问需要认真解释。

在 OAN 的设计里，区块链并不是用来承载所有业务流量，也不是把所有资源内容、DID 文档、发现请求都放到链上。

更合理的分工是：

链上承担低频、关键、需要审计的治理事实；

链下承担高频、复杂、需要性能的业务流程。

具体来说，区块链在 OAN 中更像一个治理锚点，用于记录和验证：

• 注册节点是否被授权；
• 发现节点是否被授权；
• 节点是否处于 active、suspended、revoked 等状态；
• 节点授权域是否发生变化；
• 治理事件是否可追溯；
• Root 相关授权是否有可信来源；
• 第三方节点准入状态是否可复核。

而高频操作仍然在链下完成，包括：

• 资源注册表单提交；
• 资源包处理；
• 元数据校验；
• 发现节点索引；
• 语义检索；
• 用户查询；
• SDK 调用；
• Agent 实际调用 MCP、API 或 Skill。

所以，不能按“所有业务都上链”的假设来推导 OAN 的性能瓶颈。

OAN 的设计重点恰恰是链上链下分层：链上负责可信状态，链下负责高效执行。

五、为什么不是简单沿用“分配 ID + 证书”

“分配 ID + 证书”是一条成熟路线。它的优势很明确：

• 工程实现简单；
• 运维经验丰富；
• 认知成本低；
• 与传统 CA、TLS、企业身份体系兼容性好；
• 在强中心系统里很容易落地。

但它并不天然覆盖智能体互联网的全部需求。

智能体互联网更关心开放协作和资源流动。这里的关键对象不是一个固定账号，而是大量可调用、可发布、可发现、可更新的智能体资源。

这些资源需要表达：

• 资源身份；
• 能力描述；
• 服务入口；
• 协议绑定；
• 版本状态；
• 授权域；
• 生命周期；
• 注册与发现证据；
• 跨节点复核关系。

如果仍然完全依赖平台分配 ID 和证书体系，容易出现几个问题：

• 不同平台之间 ID 语义不一致；
• 资源元数据需要重复适配；
• 证书证明了主体身份，但不一定表达资源能力边界；
• 第三方节点接入需要大量私有规则解释；
• 资源发现结果难以携带统一验证证据。

因此，传统证书体系适合解决“连接是否安全、主体是否可信”的一部分问题；

而 DID 更适合承载“开放资源如何表达、如何迁移、如何被发现和复核”的问题。

这两者不是非此即彼。

在 OAN 中，DID 可以与签名、证书、链上治理状态、Root proof、资源包哈希等机制组合使用。

六、OAN 的技术优势在哪里

从技术路线看，OAN 的优势不只是使用 DID 或区块链，而是把它们放在了比较合适的位置。

1. 资源模型更贴近智能体互联网

OAN 不是只给人、机构或服务账号建身份，而是把 Agent Service、Skill、MCP Server、Tool/API 都作为一类可注册、可发现的资源对象。

这比传统账号身份更贴近智能体调用外部能力的实际需求。

2. DID 负责资源身份和描述，区块链负责治理事实

OAN 没有把区块链当成万能数据库，而是让它承担治理锚点角色。

DID 文档负责表达资源身份、端点、能力、元数据和证明关系；链上治理负责节点授权、状态变更和审计。

这种分工可以兼顾可信性和性能。

3. 注册节点和发现节点职责清晰

Registrar 负责资源进入网络前的结构化注册和校验。

Discovery 负责在授权范围内索引和返回资源候选。

这让资源接入和资源发现不再混在一个模糊目录里，而是形成更清晰的工程边界。

4. 授权域让节点协作有边界

authorizedDomains 是 OAN 中很重要的治理字段。

它可以表达资源和节点的授权范围，避免“任何节点都能注册任何资源、任何发现节点都能暴露所有资源”的混乱状态。

对于未来第三方注册节点和发现节点接入，这一点尤其重要。

5. 发现结果强调可验证，而不只是相关性

普通搜索返回的是“看起来相关”。

OAN 更强调发现结果背后的身份、状态、授权和证明材料。

对智能体来说，这很关键。

因为 Agent 一旦自动调用外部资源，错误资源、过期资源、伪造资源都会直接进入执行链路。

6. 支持从官方节点走向多节点生态

OAN 当前可以通过官方节点提供默认入口，也允许未来第三方提供自己的 baseUrl、Registrar 和 Discovery 节点。

这意味着它既能先从可控的官方服务起步，也保留了后续扩展到多运营方生态的空间。

七、性能问题如何理解

DID + 区块链路线最容易被质疑的一点，就是性能。

但需要区分三类操作：

第一类：高频业务操作

例如资源查询、语义检索、页面访问、SDK 调用、Agent 调用工具。

这些操作应该走链下服务、数据库索引和缓存，不应该上链。

第二类：中频资源流程

例如资源注册、版本更新、注册状态同步、发现索引更新。

这些可以由 Registrar、Root、Discovery、Indexer 协同处理，必要时引用链上治理状态，但不需要每一步都写链。

第三类：低频治理操作

例如授权 Registrar、授权 Discovery、暂停节点、恢复节点、撤销节点、更新授权域。

这些才适合链上记录，因为它们频率低、重要性高、需要审计。

因此，在 OAN 的设计中，区块链不会成为每次资源发现或每次智能体调用的性能瓶颈。

真正的性能优化重点仍然在链下，例如：

• PostgreSQL 索引；
• 语义检索；
• 缓存；
• 批量同步；
• 异步发布；
• Discovery 排名；
• SDK 请求路径优化；
• 节点运行监控。

区块链承担的是“谁被授权、状态如何变化、治理事实是否可追溯”的角色。

八、对开发者意味着什么

如果你是开发者，OAN 这套技术路线带来的直接意义是：

• 你可以把自己的 MCP Server、Skill、Tool/API 注册成可发现资源；
• 资源不只是一个链接，而是带身份和元数据的对象；
• 资源可以通过 Discovery 被自然语言查询找到；
• 资源的授权域和能力标签可以帮助系统做过滤和匹配；
• SDK 和社区 Skill 可以帮助降低接入成本；
• 未来第三方节点可以在统一规则下接入生态。

对于做智能体平台的人来说，OAN 提供的是一套可参考的资源治理范式：

不是把所有能力塞进一个平台，而是让资源在统一身份和治理模型下流动起来。

九、一个务实判断

我认为，在智能体互联网基础设施中，DID + 区块链路线的价值不在于“更炫”，而在于它更适合解决开放协作场景下的几个问题：

• 多主体资源如何统一表达；
• 资源身份如何跨平台复核；
• 节点授权如何透明可审计；
• 资源发现如何附带信任证据；
• 第三方节点如何在统一规则下接入；
• 资源升级和生命周期如何持续追踪。

传统“分配 ID + 证书”路线仍然有价值，尤其适合中心化、强管理、快速落地的场景。

但当系统走向多节点、多组织、多协议、多资源形态时，DID 提供的可解析、可扩展、可验证资源描述能力，会有更高的长期上限。

OAN 正是在这个方向上的一次工程化探索。

结语

智能体互联网不会只需要更强的模型，也需要更可靠的资源基础设施。

在 OAN 中，did:oan 负责让资源拥有可验证身份，Registrar 负责资源注册，Discovery 负责资源发现，Root 和链上治理负责节点授权与状态锚定，Indexer 则把治理事实转化为运行时可查询能力。

这套设计的核心不是“把所有东西上链”，而是让区块链在最适合的位置发挥作用：

记录低频但关键的治理事实，为高频链下注册、发现和调用提供可信基础。

如果未来智能体互联网会走向多组织、多节点、多协议协作，那么类似 OAN 这样的资源身份与治理基础设施，会变得越来越重要。