评价一个智能体互联网基础设施项目，不能只看概念是否新，也要看代码是否能支撑真实系统演进。OpenAgenet（OAN）的一个重要特点，是它不是把 DID、区块链、资源发现、智能体调用都堆在一个单体工程里，而是按协议核心、基础设施节点、SDK、智能体参考实现、官网、测试套件和运维工具进行模块化拆分。
这种代码组织方式，反映了 OAN 的工程定位：它不是一个单一应用，而是一组可组合、可验证、可扩展的智能体互联网基础设施组件。
一、多语言开发：不同模块使用适合的技术栈
OAN 在代码层面采用多语言开发，而不是强行用一种语言覆盖所有场景。
Rust 主要用于协议核心和基础设施服务。OAN 的 Root、Registrar、Discovery、Trust Indexer，以及 oan-protocol-common 中的协议、DID、凭证、加密、资源包、存储等核心 crate，主要采用 Rust 实现。这一选择很合理，因为这些模块承担的是基础设施职责，对类型安全、性能、并发能力、可靠性和长期维护要求较高。
TypeScript 主要用于 SDK、前端、社区 Skill、治理工具和测试套件。比如 oan-sdk-ts 面向浏览器、Node.js 和开发者工具；oan-homepage 提供官网、注册、发现和文档入口；oan-third-party-node-admission-test-kit 使用 TypeScript CLI + library 的方式实现第三方节点接入测试。这些场景更关注开发者体验、生态集成和前后端协作，TypeScript 是比较自然的选择。
Python 主要用于 Agent 参考实现。oan-agent-py 提供 Service Agent 和 User Agent 的参考代码，让 Python 智能体开发者更容易理解如何查询 Discovery、验证发现结果、调用服务端点，而不需要一开始就深入 Rust 服务端实现。
这种分工体现了一个成熟基础设施项目的思路：核心可信路径用更强类型和更高可靠性的技术栈，生态接入和用户工具用更易集成的技术栈，智能体示例使用开发者熟悉的 Python。
二、分仓模块化：每个仓库职责清楚
OAN 的代码不是一个大杂烩，而是拆成多个职责明确的仓库。
oan-protocol-common 是协议基础层，包含 DID、加密、凭证、资源包、存储、客户端、语义推荐等共享 Rust crate。它相当于 OAN 的协议和数据模型核心，避免各节点重复实现 DID 文档解析、资源包结构、签名验证、授权域处理等逻辑。
oan-root-services 是 Root 相关服务。Root 的职责是观察治理状态、签发基础设施授权 VC、验证 Registrar 提交的资源包、生成 Root proof、发布资源包，并协调 CDN 和 Discovery 分发。Root 是 OAN 可信发布路径里的关键节点。
oan-registrar-node 是注册节点实现。Registrar 面向资源提供方，负责资源接入、注册草稿、DID 文档和元数据检查、授权域检查、注册凭证和向 Root 提交资源包。它是资源进入 OAN 网络的入口。
oan-discovery-node 是发现节点实现。Discovery 从 Root/CDN 同步已验证资源包，检查 Root proof、包哈希和授权域，建立本地索引，并返回签名发现结果。它不是普通搜索服务，而是可信发现节点。
oan-trust-indexer 是治理状态读模型服务，用于索引链上治理事件，向 Root、Registrar、Discovery 或未来 VC Issuer 提供稳定的治理状态读取接口。它让服务节点不用直接处理复杂链上事件扫描细节。
oan-sdk-ts 面向开发者提供 TypeScript SDK，使应用可以访问 Registrar、Discovery、Root、CDN 等接口，并围绕 did:oan、资源包、Root proof、Discovery response 做集成。
oan-agent-py 提供 Python Agent 参考实现，帮助智能体开发者从“如何使用 OAN”入手，而不是只阅读协议文档。
oan-homepage 则是官网、注册页、发现页和 Docs 的用户入口，把底层能力呈现为可使用的网页产品。
此外，oan-third-party-node-admission-test-kit 用于第三方 Registrar/Discovery 节点接入测试，oan-trial-network 用于试验网络和社区节点申请材料，oan-operator-guides 用于运维和测试指引，oan-public-docs 则承载公开规范与说明材料。
这种分仓方式让 OAN 具备较好的边界感：协议核心、节点运行、开发者 SDK、用户入口、测试准入、文档和运维各司其职。
三、参考节点实现：不是只有协议文本
很多基础设施项目停留在协议设想阶段，最大问题是“说得通，但跑不起来”。OAN 的优势在于，它为关键节点提供了参考实现。
Root Node 已经具备治理观察、授权 VC、资源包验证、公告事实、CDN 发布和 Discovery 通知等职责边界。Registrar Node 已经围绕资源注册入口进行实现，支持 Agent Service、Skill、MCP Server、Tool/API 等资源类型。Discovery Node 已经围绕 Root-verified resource package 建立可信索引与查询能力。
这些参考节点的意义不只是演示。它们可以作为第三方节点实现的行为基准，也可以作为测试套件、SDK、官网功能和运维脚本的联调对象。未来第三方节点接入时，可以对照官方参考节点实现，检查接口、字段、错误码、授权域、DID 文档和发现响应是否兼容。
这让 OAN 更像一个可执行的基础设施工程，而不是一份孤立白皮书。
四、协议核心抽象：资源导向而不是 Agent 单体导向
从代码结构看，OAN 已经从“只描述 Agent”转向“描述智能体生态资源”。
在 did:oan 和资源包模型中，一等资源包括 Agent Service、Skill、MCP Server、Tool/API。也就是说，OAN 不是假设智能体互联网里只有 Agent 需要身份，而是把智能体可调用、可组合、可分发的各种能力都纳入资源模型。
这种资源导向设计更贴近实际生态。今天很多智能体能力不是完整 Agent，而是一个工具、一个 API、一个 MCP Server 或一个 Skill。如果基础设施只支持 Agent，就会错过大量真实能力单元。OAN 在代码层面对资源类型、协议绑定、服务端点、包信息、授权域和能力标签进行统一建模，使不同形态资源可以进入同一套注册与发现路径。
五、授权域与能力标签分离：代码层面的治理边界
OAN 的一个重要技术特征，是把 authorizedDomains 和 capabilityTags 分开处理。
authorizedDomains 是治理属性，用于判断 Registrar 是否可以接收某类资源、Discovery 是否可以展示某类资源。它需要符合授权域树和规范化规则。
capabilityTags 是搜索属性，用于表达资源能力、辅助语义匹配和排序。它可以更灵活，但不能扩大授权范围。
这种区分在代码层面非常关键。如果把能力标签当成授权依据，任何资源都可以通过添加标签伪装成某个领域资源，Discovery 也可能错误展示超出授权范围的内容。OAN 将授权域规则放入协议和节点校验路径，使治理边界不会被搜索优化逻辑冲掉。
六、SDK 与 Skill：降低接入门槛
一个基础设施项目如果只有服务端节点，对开发者仍然不够友好。OAN 提供 TypeScript SDK 和社区 Skill，把复杂的注册、发现、验证过程封装给用户和开发者。
oan-sdk-ts 提供面向浏览器、Node.js 和工具链的客户端能力。它默认支持官方服务入口，也允许配置第三方 endpoint 或 baseUrl。这为未来多节点生态保留了灵活性。
oan-community-skill 则面向普通社区用户，帮助准备资源注册材料、校验 DID 和元数据、选择授权域、调用 Registrar、查询 Discovery，并解释发现结果。它的边界也很清楚：不做官方运维，不运行 Root/Registrar/Discovery，不提交治理写操作。
这体现了 OAN 的工程思路：底层协议可以复杂，但用户入口要尽量简单；可信路径可以严格，但开发者集成不能过重。
七、测试套件与准入机制：为第三方生态做准备
OAN 还专门设计了 oan-third-party-node-admission-test-kit，用于第三方 Registrar 和 Discovery 节点接入测试。
该套件采用 TypeScript CLI + library，使用固定 fixtures、确定性预期输出和 PASS/FAIL requirement checks，对测试套件自身和未来节点准入规则进行验证。它覆盖配置解析、节点身份一致性、授权域规则、注册包校验、DID 文档绑定、Discovery 查询、生命周期状态、报告结构和可重复性等方面。
这说明 OAN 并不是简单声称“支持第三方节点”，而是在代码层面准备第三方节点如何被测试、如何被评价、如何进入后续治理流程。对一个基础设施项目来说，这种准入测试能力非常重要，因为开放生态越大，越需要客观一致的技术检查机制。
八、官网与文档：代码和内容解耦
oan-homepage 不只是宣传页面，而是包含注册、发现、Docs、Network 等功能入口。Docs 采用 markdown package 的方式组织，前端负责渲染，文档内容和展示逻辑相对解耦，并支持本地缓存和按章节预取。
这种设计让官网不仅是“项目介绍”，也是 OAN 生态的实际入口。用户可以通过官网理解概念、注册资源、发现资源、查看节点网络信息，也可以进一步跳转到 GitHub、规范、论文、SDK 和 Skill。
对开源基础设施项目来说，官网如果只做宣传，很难形成开发者入口。OAN 将官网与注册发现能力连接起来，是代码层面比较务实的设计。
九、工程优势总结
从代码层面看，OAN 的优势主要体现在几个方面。
第一，模块边界清晰。协议核心、Root、Registrar、Discovery、Indexer、SDK、Agent 示例、官网、测试套件、运维指南分别独立，便于长期演进。
第二，技术栈选择务实。Rust 承担可信核心和服务端基础设施，TypeScript 承担 SDK、前端、工具和测试包，Python 承担智能体参考实现。
第三，参考实现完整。OAN 不只是协议描述，而是具备 Root、Registrar、Discovery、Trust Indexer、SDK、Agent 示例和官网入口。
第四，面向真实生态扩展。第三方节点申请、授权域治理、接入测试套件、SDK baseUrl 配置等设计，都在为多方参与做准备。
第五，资源模型更贴近智能体互联网。OAN 不只处理 Agent，也处理 Skill、MCP Server、Tool/API 等真实能力单元。
第六，可信路径可验证。DID Document、Root proof、包哈希、授权域、Discovery response 和治理状态共同构成机器可检查的证据链。
十、结语
OpenAgenet（OAN）的代码层面特征，体现出它不是一个单点应用项目，而是一个面向智能体互联网基础设施的工程体系。它用 Rust 构建可信核心，用 TypeScript 打通开发者和用户入口，用 Python 提供智能体参考实现，用测试套件和运维文档支撑第三方生态。
这种工程结构的价值在于：概念可以通过代码验证，协议可以通过节点运行，生态可以通过 SDK 和 Skill 接入，第三方节点可以通过测试和治理进入网络。对于一个仍在快速发展的智能体互联网方向来说，OAN 的优势不只是提出了 DID、区块链和可信发现的组合方案，更在于它已经把这些方案拆解成可以开发、测试、部署和持续演进的代码模块。
