OpenAgenet（OAN）：面向智能体互联网的资源注册与发现基础设施

1. 智能体互联网里资源注册与发现为什么总卡在“手工改配置”做 Agent 平台的朋友大概率都经历过这个阶段一开始只有三五个工具直接在代码里写死 endpoint 就能跑等到 MCP Server、Skill、工具 API 涨到几十个配置文件开始失控README 里贴满链接谁发布的、能不能信、适不适合当前任务全靠人肉判断。这就是智能体互联网最现实的痛点——不是模型不够聪明而是资源接入这一层没有统一的基础设施。OpenAgenetOAN想解决的正是这件事。它把智能体资源从“一条 URL”升级成“可治理对象”有身份、有授权边界、有治理状态、有可验证材料、有语义描述还能被机器发现。换句话说OAN 不是又一个资源导航站而是面向智能体互联网的资源注册与发现基础设施。它适合做 Agent 平台的工程师、写 MCP Server / Skill 的开发者、维护工具目录的团队以及研究智能体互联与可信治理的人。我试过把几个自研 Skill 按 OAN 的资源模型整理了一遍最直观的感受是以前“这个工具能不能用”要靠人读文档现在可以变成一次带元数据的注册请求加一次语义发现查询。下面这篇就按最小可用目录的思路把注册中心、发现协议、元数据模型拆开讲并给出可复制的配置和本地验证步骤。2. TaoToken 前置给 OAN 的发现与调用链路准备统一入口OAN 负责“资源在哪、能不能信”但资源被 Agent 真正调用时模型侧仍然需要一个稳定的 API 入口。这两层是分开的OAN 管目录与治理TaoToken 管模型与工具调用的统一接入。把两者串起来你的智能体才能做到“发现即调用”。TaoToken 在这里扮演的是模型与能力调用的统一网关角色。你可以在官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解整体能力实际接入时用 API 地址 https://taotoken.net/api 即可。它提供 OpenAI 兼容的调用方式意味着你现有的 SDK、LangChain、Cline、Codex 这类工具基本不用改代码只换 Base URL 和 Key。对 OAN 场景来说这个前置准备的意义在于当发现节点返回一批候选资源后Agent 需要立刻用统一的模型接口去规划、去调用、去校验结果。如果模型入口每个项目一套鉴权发现做得再好也接不起来。所以建议先把 TaoToken 的 Key 和 Base URL 固定下来作为整个智能体目录的默认调用通道。具体要准备三样东西后面配置里会反复用到Base URLhttps://taotoken.net/apiAPI Key在控制台创建形如sk-...Model ID按你实际使用的模型填写例如gpt-4o-mini或你账号下可用的其他模型创建 Key 的入口在控制台的 API Keys 页面https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。如果你更想先验证模型连通性可以直接用模型对话页面https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。长期做编码和 Agent 的可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。注意OAN 的注册节点和发现节点是资源治理层TaoToken 是模型调用层两者职责不要混。把 Key 写进 OAN 的元数据里没有意义元数据里应该写资源的调用地址和鉴权方式说明。3. 可复制配置OAN 注册中心与发现协议的最小落地这一节是全文的核心。OAN 的资源模型可以理解成三层注册中心Registrar负责接收和校验资源发现节点Discovery负责按意图检索元数据模型Metadata负责描述资源身份与边界。下面给出可直接复制的配置片段路径和字段名保持一致方便你对照修改。先看资源注册的元数据 JSON。这是提交给注册节点的最小结构包含身份、授权域、调用入口和语义描述{ resource_id: skill.text.summarize.v1, resource_type: agent_skill, display_name: 长文摘要 Skill, version: 1.0.0, publisher: { org: example-lab, contact: devexample.com }, authorized_domains: [internal.agent, partner.agent], endpoint: { protocol: https, url: https://your-host/api/skill/summarize, auth: bearer }, semantics: { intents: [summarize, condense, extract_key_points], input_schema: text/plain, output_schema: application/json }, governance: { status: active, verifiable: true, signature: sha256:REPLACE_WITH_YOUR_SIGNATURE } }字段说明用表格对照更清楚字段作用是否必填resource_id全局唯一资源标识建议带类型和版本是resource_type资源类别如 agent_skill / mcp_server / tool_api是authorized_domains授权域限定哪些节点可接入是endpoint实际调用入口与鉴权方式是semantics.intents语义发现用的意图标签是governance.status治理状态active / deprecated 等是再看注册节点的客户端配置。如果你用 TOML 管理本地环境可以这样写[oan.registrar] base_url https://your-registrar-host/oan/v1 timeout_ms 8000 retry 2 [oan.registrar.auth] scheme bearer token REPLACE_WITH_REGISTRAR_TOKEN [oan.discovery] base_url https://your-discovery-host/oan/v1 default_top_k 5 verify_result true [oan.model_gateway] base_url https://taotoken.net/api api_key sk-REPLACE_WITH_YOUR_KEY model_id gpt-4o-mini如果你更习惯用 settings 风格的 JSON比如某些 Agent 框架的配置文件等价写法如下{ oan: { registrar: { base_url: https://your-registrar-host/oan/v1, auth: { scheme: bearer, token: REPLACE_WITH_REGISTRAR_TOKEN } }, discovery: { base_url: https://your-discovery-host/oan/v1, default_top_k: 5, verify_result: true }, model_gateway: { base_url: https://taotoken.net/api, api_key: sk-REPLACE_WITH_YOUR_KEY, model_id: gpt-4o-mini } } }这里有个设计要点值得单独说authorized_domains不是装饰字段。它决定了资源能被哪些节点发现和调用。比如内部工具只写internal.agent第三方节点即使拿到 resource_id 也无法在发现结果里看到它。这就是 OAN 把“授权边界”单独建模的价值比单纯在描述里写一句“仅限内部使用”要可靠得多。配置完成后注册流程是构造上面的元数据 JSON → 调用注册节点接口 → 注册节点做元数据校验和授权域检查 → 通过后进入可发现状态。发现流程是Agent 带着任务意图查询发现节点 → 发现节点做语义检索 → 返回候选资源列表 → Agent 按verify_result决定是否复核治理状态。4. 验证请求从注册到发现跑通最小闭环配置写好了接下来要验证它真的能跑。这一步分两个动作先注册一个资源再发现它。下面用 curl 演示你可以直接复制到终端。注册请求curl -X POST https://your-registrar-host/oan/v1/resources \ -H Authorization: Bearer REPLACE_WITH_REGISTRAR_TOKEN \ -H Content-Type: application/json \ -d resource.json其中resource.json就是上一节的元数据文件。成功时返回类似{ resource_id: skill.text.summarize.v1, status: registered, governance_state: active, registered_at: 2025-01-01T10:00:00Z }看到status: registered就说明资源已经进入可发现状态。如果返回pending_review说明授权域或签名需要人工复核检查authorized_domains是否包含你当前节点所属的域。发现请求curl -X POST https://your-discovery-host/oan/v1/discover \ -H Authorization: Bearer REPLACE_WITH_REGISTRAR_TOKEN \ -H Content-Type: application/json \ -d { intent: summarize long article, top_k: 5, verify: true }成功返回的候选列表里每条都应该带resource_id、endpoint、governance_state和score。verify: true会触发对治理状态的复核确保返回的资源不是已废弃或未授权的。拿到 endpoint 后用 TaoToken 的模型接口做一次真实调用验证。下面这段 Python 演示了“发现资源 → 用模型规划 → 调用资源”的最小链路import requests MODEL_BASE https://taotoken.net/api MODEL_KEY sk-REPLACE_WITH_YOUR_KEY def discover(intent): resp requests.post( https://your-discovery-host/oan/v1/discover, headers{Authorization: Bearer REPLACE_WITH_REGISTRAR_TOKEN}, json{intent: intent, top_k: 3, verify: True}, timeout8, ) resp.raise_for_status() return resp.json()[results] def plan_with_model(intent, candidates): resp requests.post( f{MODEL_BASE}/v1/chat/completions, headers{Authorization: fBearer {MODEL_KEY}}, json{ model: gpt-4o-mini, messages: [ {role: system, content: 你是资源调度器从候选资源中选最合适的一个。}, {role: user, content: f意图{intent}\n候选{candidates}}, ], }, timeout30, ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: intent summarize long article candidates discover(intent) print(发现候选, candidates) print(模型选择, plan_with_model(intent, candidates))跑通后你会看到发现节点返回了摘要 Skill模型从候选里选出了它。这就是 OAN 加 TaoToken 的最小闭环——资源可发现模型可调用。实测下来这套链路在本地单节点环境几分钟就能搭起来关键是把元数据字段填对。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth配置和验证过程中报错基本集中在几个固定位置。下面按真实报错对照排查每个都给定位思路。401 Unauthorized最常见。先确认你用的是注册节点的 token 还是模型网关的 Key两者不能混用。注册节点报 401检查oan.registrar.auth.token模型调用报 401检查oan.model_gateway.api_key是否以sk-开头且未过期。如果 Key 刚创建注意控制台可能有几秒同步延迟。local proxy failed这个报错通常出现在本地 Agent 框架通过代理访问发现节点时。先确认base_url没有多余斜杠比如https://host/oan/v1/和https://host/oan/v1在某些客户端里行为不同。再检查本地环境变量里是否有残留的代理设置干扰了直连。把timeout_ms调大到 8000 以上也能排除一部分超时误报。reading choices这是模型返回结构解析失败典型原因是请求体里model字段填了账号下不可用的模型或者响应被中间层改写。先确认model_id与 TaoToken 控制台里可用的模型一致再用模型对话页面单独发一条消息验证。如果对话页面正常而代码报错检查你的请求是否漏了Content-Type: application/json。OAuth 相关报错如果你用 Claude Code 或类似工具接入报 OAuth 失败通常是因为鉴权方式选错了。这类工具要走 API Key 模式而不是 OAuth 模式。配置时确保三件套齐全Base URL 填https://taotoken.net/apiKey 填sk-...Model ID 填你实际使用的模型。缺任何一个都会在鉴权阶段失败。如果你用 CC Switch 或 Cline MCP 管理配置同样按这三件套填不要只填 Base URL。排查顺序建议固定成先验证模型网关单独可用 → 再验证注册节点鉴权 → 最后验证发现节点返回结构。这样能把问题范围快速缩小到某一层而不是在整条链路上瞎猜。6. 把资源目录接进你的 Agent 工作流最小闭环跑通后下一步是把它变成日常可用的东西。我的做法是把发现节点查询封装成一个工具函数注册到 Agent 的工具列表里这样 Agent 在规划阶段就能主动发现新资源而不是等人在配置里加。资源发布方则走注册节点每次版本更新重新提交元数据治理状态由注册节点统一维护。如果你还在选模型调用通道建议先把 TaoToken 的接入文档过一遍https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。需要创建 Key 就去 API Keys 页面https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。想先验证模型连通性用模型对话https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。长期做编码和 Agent 的Coding Plan 更划算https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。OAN 这类基础设施的价值短期看是省掉手工改配置的麻烦长期看是让智能体生态里的资源真正可治理、可发现、可验证。把注册、发现、调用三层分开建模再配上统一的模型入口你的智能体目录才算真正立起来。