从单个智能体到开放网络
大模型让“智能体”从概念变成了可运行的软件形态。一个智能体可以调用工具、读写文件、访问数据库、连接外部服务，也可以与其它智能体协同完成复杂任务。早期阶段，开发者更关心单个智能体是否聪明、提示词是否稳定、工具调用是否准确。但当智能体开始跨组织、跨平台、跨协议协作时，问题会从“如何做出一个智能体”转向“如何让大量智能体和相关资源可信地互联”。
OpenAgenet（OAN）关注的正是这一层基础设施问题。OAN 并不把智能体互联网理解为某一个聊天机器人平台，也不把它理解为单一协议的胜出。它把 Agent Service、Skill、MCP Server、Tool/API 等都视为可发现、可验证、可治理的资源。不同资源可以继续使用 MCP、A2A、ANP、HTTP API 或其它交互协议，但在进入开放网络之前，需要有统一的身份、注册、分发、发现和验证机制。
基础设施要回答的问题
如果没有基础设施层，智能体生态很容易走向碎片化。开发者可能在 GitHub、模型平台、企业内部门户、MCP 市场、个人网站中发布能力描述；调用者则需要自己判断资源是否来自真实发布者、是否仍然有效、是否适用于某类场景、是否被某个可信节点验证过。对人类用户来说，这已经很麻烦；对需要自动规划和自动调用的智能体来说，摩擦更大。
OAN 的基本判断是：智能体互联网不能只靠“能连上”。它还需要回答几个更底层的问题：资源是谁发布的？资源描述是否被篡改？哪个注册节点接收了它？Root 是否验证并发布过它？Discovery 返回的结果是否来自 Root 认可的资源包？资源属于哪些授权域？能力标签是自由描述，还是能够被节点保存、索引并用于机器检索？这些问题如果留给每个应用自行解决，就会造成重复建设，也会让互操作缺乏共同基础。
OAN 的协议对象和角色分工
在 OAN 的设计里，资源不是一条孤立的目录记录，而是一组可验证协议对象。资源用 did:oan:<semantic-code>:<suffix> 形式获得稳定标识；DID 文档表达控制者、公钥、服务入口、协议绑定、资源描述和 OAN 扩展元数据；注册提交对象绑定资源 DID、资源类型、DID 文档哈希、元数据哈希、包哈希和主体控制证明；Root 验证通过后形成 ResourcePackage 和 Root Proof；Discovery 只索引经过验证的资源包，并对查询响应进行签名。这些对象共同组成“发现前可验证、调用前可核验”的基础设施链路。
| 角色 | 主要职责 | 不能做什么 | 对生态的意义 |
|---|---|---|---|
| Registrar | 接入资源、辅助注册、收集草稿和控制证明 | 不能单方面定义信任 | 降低资源进入门槛 |
| Root | 验证 DID、元数据、包哈希与证明 | 不能替代业务调用 | 提供可信发布事实 |
| CDN | 分发资源包和索引材料 | 不能充当信任权威 | 保障分发效率 |
| Discovery | 同步已验证资源、返回签名候选 | 不能绕过 Root 事实 | 提供可信发现入口 |
| SDK / Skill | 降低接入和调用成本 | 不能替代协议验证 | 让开发者更容易上手 |
因此，OAN 采用角色分离的基础设施设计。Registrar 负责资源接入和注册辅助；Root 负责可信验证、资源包归档、Root Proof 生成和分发协调；CDN 负责资源包分发但不承担信任权威；Discovery 负责同步 Root 验证后的资源，并对外提供可查询的候选结果；SDK 和 Skill 则降低开发者接入成本。每个角色都有自己的职责边界，避免把所有能力塞进一个中心化平台。
从代码到研究材料的闭环
这种角色分离也体现在代码结构里。oan-protocol-common 提供 Rust 协议类型、DID、资源包、签名请求、语义推荐等共享能力；oan-root-services、oan-registrar-node 和 oan-discovery-node 分别对应 Root、注册和发现节点；oan-sdk-ts 给前端和开发者工具提供 TypeScript SDK；oan-agent-py 用 Python 展示智能体侧实验；oan-homepage 和 oan-public-docs 则承担网站和公开文档入口。基础设施核心使用 Rust，不是为了堆技术栈，而是因为注册、验证、索引和签名响应对并发、类型约束和运行稳定性有较高要求。
OAN 的公开材料也在把这套工程实现与更大的智能体互联网问题连接起来。白皮书讨论的是开放智能体网络为什么需要资源身份、可信发现和治理框架；黄皮书进一步把 did:oan、资源包、Root 证明、授权域等机制落到协议对象；AONA 方向强调智能体互联网不应只有端到端交互协议，还需要可治理、可发现、可验证的网络层能力。这些材料对应到代码里，并不是单纯概念：注册接口、发现接口、资源包校验、SDK 默认入口和第三方节点测试套件，都是把同一套思路变成可运行系统的组成部分。
对开发者和生态的价值
这种基础设施化思路对智能体生态有两个直接价值。第一，它让资源发布者有稳定的进入路径：准备 DID 文档、提交注册、通过 Root 验证、进入 Discovery 索引。第二，它让资源消费者有更可靠的选择路径：查询 Discovery、获得候选资源、检查 DID 文档、Root Proof、资源包哈希和签名响应，然后再决定是否调用。
从产业视角看，多智能体协作不会只发生在一个厂商内部。企业工具、行业平台、个人开发者能力、科研原型、开源 Skill、MCP Server 和各类 API 都会进入同一个大生态。越开放，越需要底层信任机制。OAN 的定位就是在这些协议和应用之下，提供一个开放治理、统一标识、可信注册和可信发现的基础设施层。
智能体互联网真正成熟时，用户不应该只是在网页上搜索“有没有某个工具”，而应该能让自己的智能体自动发现、验证和接入合适资源。要达到这一步，基础设施不是锦上添花，而是智能体从“单点工具”走向“开放网络”的前提。
与传统方式的差异
| 传统方式 | 在 OAN 中 | 变化 |
|---|---|---|
| 人工维护资源目录 | 使用 did:oan 标识资源 |
资源身份更稳定 |
| 依赖发布者自述 | 绑定哈希和 Root Proof | 资源状态可验证 |
| 只做搜索和推荐 | 同时提供治理和发现 | 更适合自动调用 |
| 每个系统各自接入 | 统一资源包、注册和发现流程 | 生态协作成本更低 |
这里的核心不是把所有智能体做成同一种形态，而是把资源进入网络之后的身份、验证、发现和治理过程变成公共能力。
从基础设施视角看 OAN 的价值
在这些讨论里，重点并不是“单次调用能不能跑通”，而是“资源怎么被可信地进入网络、怎么被验证、怎么被发现、怎么被持续更新”。这正是智能体互联网从应用走向基础设施时必须补齐的能力。
| 关注点 | 如果没有基础设施层 | 有了 OAN 之后 |
|---|---|---|
| 资源进入网络 | 只能靠人工分发链接 | 先注册，再验证，再分发 |
| 资源可信性 | 只能相信发布者自述 | 可核验 DID、哈希和 Root Proof |
| 资源发现 | 只适合搜索，不适合调用 | 可得到可验证候选资源 |
| 生态扩展 | 每个项目各做一套 | 共享同一套注册与发现语义 |
这类基础设施适合哪些人
对开发者来说，它降低了发布和接入门槛；对研究者来说，它提供了可讨论、可复现的协议对象；对节点运营者来说，它把治理、分发和发现拆成了清楚的职责边界。这样，OAN 才不是一组演示页面，而是一套能长期演进的网络底座。
