智能体互联网正在从概念走向工程实现。
当 Agent、MCP Server、Skill、工具 API、知识服务、自动化工作流等资源开始跨平台、跨组织、跨节点流动时，一个很基础的问题会变得越来越重要：
智能体如何识别、验证、发现和使用外部资源？
在传统互联网应用里，一个服务地址、一个账号体系、一套证书机制，通常就能支撑大量业务场景。但智能体互联网面对的不是单一平台内部的服务调用，而是多主体、多节点、多协议、多资源形态之间的开放协作。
这也是 OpenAgenet（OAN）选择围绕 did:oan、资源注册、授权分发、语义发现和链上治理构建基础设施的原因。
项目地址：
一、智能体互联网为什么需要新的标识基础设施
在智能体系统中，“资源”不再只是一个接口地址。
它可能是：
- 一个 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_serviceskillmcp_servertool_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 这样的资源身份与治理基础设施，会变得越来越重要。
