本章说明 OpenAgenet (OAN) 为什么需要面向智能体互联网的可信资源基础设施，以及系统目标如何落实为身份、注册、可信发布、内容分发、发现、治理和调用前验证等设计原则。章节重点不在列举单一产品功能，而在说明这些机制如何共同解决资源不可识别、来源难验证、版本难追踪、能力难发现和调用前缺少判断依据的问题，并明确开放互操作、最小信任、证据可追溯和职责分离之间的关系。

1.1 OAN与智能体互联网

OpenAgenet (OAN) 面向智能体互联网提供一套资源互联基础设施。它关注的不是某个具体智能体的对话能力，而是让智能体服务、技能包、MCP 服务和工具 API 具备稳定的身份、可验证的控制关系、可描述的能力、可追踪的发布状态和可复用的发现入口。OAN 将这些对象视为网络资源，使资源能够脱离单一平台的人工目录，通过统一的 did:oan、资源元数据、注册协议和发现协议参与跨节点互联。

OAN 的核心结果是把“有什么能力”和“能否信任这个能力”连接起来。资源提供方在本地准备 DID文档和资源描述，经注册服务节点接入后，由根平台验证注册服务节点授权、资源控制证明、元数据和版本信息，再通过内容分发平台提供给获得授权的发现服务节点。调用方获得搜索结果后，还需要根据 DID、VC、根平台证明、治理状态和端点信息完成调用前验证。这样的组织方式既保留不同资源类型和业务协议的差异，也为资源的发现、组合和后续治理提供共同基础。

从使用者角度看，OAN 的目标可以归纳为四个连续结果：资源能够被识别，资源来源能够被验证，资源能够在授权范围内被发现，调用方能够在连接前获得足够的判断依据。这四个结果分别由身份材料、注册与发布证据、发现索引和调用方验证共同支撑，不能由单一页面、目录或搜索分数替代。

1.2 OAN 所解决的问题

当智能体、技能包、MCP 服务和工具 API 分散在不同团队、不同代码仓或不同运行环境中时，资源提供方通常只能通过网页、文档、配置文件或人工沟通说明资源位置和能力。这种方式难以稳定表达资源的控制者、版本、端点、依赖、适用协议和使用条件，也难以判断一个搜索结果是当前版本、历史版本还是已经被暂停的资源。资源数量增加后，目录维护、重复登记、版本更新和跨组织协作都会产生持续的人工成本。

对调用方而言，名称或文本匹配只能解决“可能相关”，不能单独解决“是否为真实资源、是否由授权节点发布、是否仍处于有效状态、是否可以在当前授权域内使用”。如果注册、发布、发现和调用没有清晰的责任边界，任何一个中间目录都可能把未经验证的资源混入结果，或者继续展示已撤销、已替换和来源不明的版本。OAN 以 DID 控制证明、节点授权、根平台发布、资源包哈希、发现服务节点授权域过滤和调用前验证分别承接这些问题，而不是用一个平台标签替代全部信任判断。

可以把问题与 OAN 的处理方式对应起来：资源端点分散，首先需要统一的资源身份和服务描述；来源难核验，需要控制证明、注册 VC 和根平台可信发布证明；版本状态不透明，需要把版本、哈希和生命周期状态绑定到资源记录；跨组织发现困难，需要发现节点、授权域、能力标签和语义查询共同工作。这样，OAN 解决的不是“再做一个资源列表”，而是把资源登记、来源核验、网络传播和调用前判断组织成可追踪的过程。

{
  "problem": "同一任务需要在多个团队和运行环境中寻找可复用能力",
  "resource": {
    "type": "skill",
    "did": "did:oan:example",
    "version": "1.0.0",
    "capabilities": ["repository-search", "project-structure-summary"]
  },
  "required_evidence": ["DID document", "control proof", "publication status", "endpoint policy"]
}

上例只表示问题分析和资源描述的最小形状，不代表固定的生产字段或可直接提交的注册请求。真实字段、证明和校验规则以资源模型、DID 方法、注册协议和附录中的数据模式为准。

1.3 资源优先的互联模型

资源优先意味着 OAN 的注册、发布、分发和发现对象首先是一个具有资源类型、资源 DID、描述、能力标签、用例、端点、版本和状态的资源版本，而不是某个必须运行在统一平台中的智能体实例。智能体服务可以提供面向会话或任务的服务，技能包可以作为可复用能力单元，MCP 服务可以暴露工具集合，工具 API 可以提供具体接口；它们在业务形态上不同，但都通过统一的资源身份和元数据进入网络。

统一模型只统一共性，不抹平类型差异。资源类型决定必填字段、端点形态、协议绑定、调用约束和版本处理方式；资源 DID 标识具体可控制对象，资源包绑定该版本的表示和证明，能力标签与用例支持结构化和语义发现。资源之间可以通过 DID、版本或包哈希表达依赖与组合，但“可发现”只说明资源满足目录和信任条件，不自动说明组合关系中的每个业务调用都已获授权。

资源优先模型可以用一个抽象对象理解：身份字段回答“这是哪个资源”，描述字段回答“它能做什么”，版本和哈希回答“当前看到的材料是哪一版”，端点和协议字段回答“如何接入”，证明和状态字段回答“为什么可以把它作为候选资源”。不同资源类型可以共享这些公共信息，但不能因此把技能包当成智能体服务、把 MCP 服务当成工具 API，或把资源的发现结果当成业务调用授权。

{
  "resourceType": "skill",
  "resourceDid": "did:oan:example",
  "version": "1.0.0",
  "description": "检索代码仓库并总结项目结构",
  "capabilities": ["code-search", "structure-summary"],
  "protocol": "skill",
  "endpoint": "https://example.invalid/skill",
  "status": "published"
}

这是用于解释资源优先模型的示例对象；资源类型的正式字段、端点格式、哈希和签名材料仍由对应章节定义。

1.4 可信注册、发布、发现与调用

OAN 的可信链路不是一次请求完成的单一动作，而是由资源控制方、注册服务节点、根平台、内容分发平台、发现服务节点和调用方共同完成的连续过程。资源控制方先在本地生成或导入身份材料，准备资源 DID文档、资源元数据、能力标签、端点和控制证明；注册服务节点负责接入校验和向根平台提交；根平台负责验证授权、签名、哈希、版本和治理条件；后续节点只传播和索引已形成的可信事实；调用方则在业务连接前重新验证相关证据。

对于一个资源版本，读者可以按下面的顺序判断“走到哪一步”：

1. 本地材料是否已经生成，且控制方能够使用对应私钥完成证明；
2. 注册服务节点是否受理并返回登记结果；
3. 根平台是否形成该版本的接受和可信发布事实；
4. 内容分发和发现服务节点是否完成校验、同步和授权域过滤；
5. 调用方是否完成 DID、VC、版本、状态、端点和业务策略检查。

任何一步失败，都应保留可定位的状态或错误信息，使读者能够判断是材料问题、节点授权问题、传播延迟、索引问题还是调用方策略拒绝。

1.4.1 资源注册与控制证明

资源注册从资源提供方本地生成资源版本开始。客户端应根据资源类型收集名称、描述、能力标签、用例、协议绑定、端点、版本和依赖等信息，并将资源 DID 与控制密钥、公钥和 DID文档建立可验证关系。提交给注册服务节点的内容应能够证明请求方对资源 DID 的控制权；注册服务节点可以执行格式、字段、标签、端点和策略校验，但其受理不等于根平台已经接受资源。

控制证明解决的是“谁能够代表该资源提交登记”这一问题，不能替代资源质量、端点可用性或调用权限判断。失败时应返回可定位的字段或证明错误，并保持本地草稿和密钥材料不被服务端接管。相同 DID 的再次提交还应区分相同版本的重复请求与有授权的新版本更新，分别交由幂等处理和版本更新规则处理。

1.4.2 根平台验证与可信发布

根平台接收注册服务节点的签名上游请求后，应先确认请求新鲜度、请求体哈希、随机数和注册服务节点的有效授权，再验证资源 DID文档、资源控制证明、资源类型、元数据哈希、资源包和版本转换条件。只有这些事实一致且满足治理与发布策略，根平台才形成该资源版本的接受记录和根平台可信发布证明。根平台的接受记录应绑定 DID、版本、表示哈希、授权域、状态、时间或序列信息，避免后续节点仅凭可读文本判断来源。

根平台验证成功后，发布通常通过持久化任务、消息或同步游标异步推进。资源提供方可以拿到注册服务节点返回的登记结果，但在内容分发、根平台发布完成和发现服务节点索引完成前，资源不应被表述为已经在全网可发现。验证拒绝、隔离、重试和重新发布应具有可观察状态，不能用一次 HTTP 成功响应覆盖整个传播链路。

1.4.3 内容分发与发现服务节点索引

内容分发平台承载根平台已经验证的资源包、DID文档、元数据、证明和索引所需材料，发现服务节点从分发层或根平台通知中获取候选版本。发现服务节点必须重新计算哈希、验证根平台证明和治理状态，并依据自身授权域过滤资源，然后才把合格资源写入结构化索引和语义索引。分发层提高可访问性和同步效率，但不取得根平台的信任权威。

分发和索引具有异步性，因此存在根平台已发布而发现服务节点暂未可见、结构化索引已完成而语义索引尚在重试、或节点暂时只能提供旧快照等正常中间状态。实现应保存同步游标、版本新鲜度、拒绝原因和待处理任务，使运营者能够区分未发布、未同步、校验失败、授权域不匹配和搜索索引失败。

1.4.4 调用前验证与接入

调用方从发现服务节点获得候选资源后，不应把搜索结果直接当作调用许可。至少应验证响应来源和新鲜度、资源 DID文档、资源控制关系、注册 VC 或相应登记证据、根平台可信发布证明、资源包哈希、当前版本、生命周期状态、发现服务节点授权域以及目标端点的协议和认证声明。对于高风险操作，还应在实际请求中使用时间戳、随机数、目标 DID、请求体哈希和签名，防止结果被重放或替换。

验证通过只说明候选资源满足 OAN 信任路径和调用方本地策略的前置条件，最终能否执行仍取决于资源服务端点自身的认证、授权、业务状态和安全策略。验证失败时，客户端应明确区分 DID 或签名错误、凭证状态错误、根平台证明不匹配、版本过期、治理状态无效、授权域不符和端点调用失败，避免把所有问题归结为“搜索不到”。

1.5 资源控制、节点授权与治理的分离

资源控制权由资源 DID 对应的控制密钥和控制证明表达，回答“谁有权代表这个资源提交或更新文档”；节点授权由根平台授权材料及其治理状态表达，回答“哪个注册服务节点、发现服务节点或其它基础设施节点有资格执行某类网络动作”；链上治理记录表达节点授权变化等治理事实，回答“授权何时生效、暂停、恢复或撤销”。根平台发布证明则回答“某个资源版本已经通过根平台验证并进入发布链路”，它不是资源所有权凭证。

这三类事实在验证时应分别检查。拥有资源私钥不能让一个未授权节点获得注册资格，持有旧节点授权 VC 也不能绕过当前治理状态，资源已经被根平台发布也不能替代调用方对端点和业务权限的判断。分离设计让 OAN 能够在不接触资源控制私钥的前提下管理基础设施授权，同时允许治理状态、资源身份和发布状态分别更新。

1.6 联邦化、互操作与渐进式采用

OAN 的联邦化体现在多个注册服务节点和发现服务节点可以在同一根平台信任与发布规则下独立运行。注册服务节点面向不同组织、团队或接入场景提供资源受理，发现服务节点可以按授权域、网络位置或服务能力提供索引；根平台负责统一验证和发布事实，而不是要求所有资源都集中存储在一个业务平台中。第三方节点只有在完成身份、授权、接口和符合性检查后，才能进入相应的运行状态。

渐进式采用可以从单个组织或试验网络开始：先采用 did:oan 资源身份和注册发现流程，再接入现有 Agent、MCP 或工具 API，随后增加多个节点、授权域、语义标签和治理读模型。互操作的重点是保持 OAN 的身份、证明、版本和状态边界，同时通过协议适配层接入既有业务系统，不要求业务系统立即改造成统一运行时。

一个组织可以按“先可见、再可信、后联邦”的顺序推进：第一阶段整理已有资源并建立资源身份和描述；第二阶段接入注册服务节点，形成控制证明、注册 VC 和根平台发布证据；第三阶段部署或接入发现服务节点，启用结构化和语义查询；第四阶段增加多个组织节点、授权域、治理同步和协议映射。每个阶段都可以保留原有业务端点，OAN 主要负责资源身份、登记、发布、发现和调用前判断，不要求一次性替换现有业务系统。

资源整理与身份建立
    -> 注册和可信发布
    -> 发现节点索引
    -> 多节点接入与授权域治理
    -> 与既有 Agent、MCP、Tool/API 协议映射

1.7 控制面、数据面与语义面

控制面维护身份、授权、版本、生命周期和发布状态等决定“能否进入网络、能否传播、能否被视为有效”的事实；数据面承载 DID文档、资源包、元数据、证明和面向客户端的分发内容；语义面维护能力标签树、标签层级、别名、描述和查询解释，用于注册时的选择推荐以及发现阶段的语义匹配。根平台同时承担三个有边界的枢纽职责，但各平面维护的事实不能互相替代。

三平面存在明确依赖顺序。语义匹配可以帮助发现服务节点找到相关资源，数据分发可以让节点取得资源包，但只有控制面确认资源版本已被接受、发布且在发现服务节点授权域内，候选结果才具有可信可发现资格。语义相关性、端点可访问性或界面展示都不能反向授予 DID 控制权、节点授权或治理资格。

1.8 公开可见性、可发现性与调用授权

注册完成表示注册服务节点已对请求进行受理或登记处理，关联证据通常是注册响应、注册 VC 或登记记录；根平台已发布表示根平台已经接受某个资源版本并形成相应发布证明；发现服务节点已索引表示某个获得授权的发现服务节点已经完成资源包校验并写入本地索引；授权域内可见表示该节点依据自身授权范围允许向特定查询方返回资源；调用许可则是调用方在完成 OAN 证据验证后，结合端点认证和自身业务策略作出的本地判断。

这些状态可以按顺序推进，也可能因异步任务或故障暂时不一致。旧快照可以在刷新失败时继续提供有限的已验证历史结果，但必须带有新鲜度或状态信息；资源暂停、撤销、版本替换和节点授权变化应在相应状态传播后影响发现和调用前验证。任何公开门户、统计页面或缓存都只是观察界面，不能成为替代根平台接受记录、治理状态和签名验证的信任来源。

下图把本章的目标压缩为一个可检查的资源版本流程。每个箭头代表事实或材料向下一阶段传递，不表示前一阶段的结果自动授予下一阶段权限；异步分发和索引可能产生时间差，调用方仍需在最终连接前重新验证。

flowchart LR
    A[资源提供方准备资源与本地身份]
    B[注册服务节点受理并校验]
    C[根平台验证节点授权与控制证明]
    D[根平台形成可信发布事实]
    E[内容分发平台传递发布材料]
    F[发现服务节点校验并建立索引]
    G[调用方检索并执行调用前验证]
    A -->|DID文档、元数据、控制证明| B
    B -->|登记结果或注册凭证| C
    C -->|通过校验| D
    D -->|资源包、哈希、根平台证明| E
    E --> F
    F -->|候选资源及来源状态| G

可发现不等于可调用。 发现服务节点返回候选资源，调用方仍须根据自身权限、端点认证、资源状态和业务风险完成最终判断。

本章的设计原则可以用三条验收问题复核：资源是否有可验证身份，发布是否有可追踪证据，发现结果是否能够携带足以支持调用前判断的来源和状态信息。若其中一项只能依赖页面文字或名称匹配，则不能视为完整的可信互联流程。

参考来源