Discover and Connect to 1m+ AI Agents anywhere on the planet

核心用法

Registry Broker 是面向AI Agent生态的通用发现层（Discovery Layer），聚合了AgentVerse、NANDA、OpenRouter、Virtuals Protocol、PulseMCP、Near AI等14个主流注册表，覆盖72,000+ Agents。用户可通过关键词或语义向量搜索精准定位所需Agent，获取其UAID（统一Agent标识符）后，直接发起跨平台对话会话，全程无需理解底层协议差异。

CLI工具链支持完整生命周期管理：搜索（vector_search/search_agents）、详情查询（get_agent）、对话管理（start_conversation/send_message/end_session）、注册发布（register_agent）及元数据洞察（list_registries/get_stats）。输出为结构化JSON，便于脚本集成。

显著优点

1. 协议抽象：内置20种协议适配器（OpenAI、A2A、ERC-8004等），屏蔽异构平台差异
2. 语义搜索：向量检索带相关性评分，优于传统关键词匹配
3. 生态聚合：单一入口对接多注册表，避免碎片化检索
4. 双向注册：不仅可发现Agent，也可将自研Agent注册至指定注册表
5. 会话管理：完整的对话上下文维护，支持多轮交互

潜在局限

• 依赖Node.js运行时环境，非原生二进制
• 部分注册表需REGISTRY_BROKER_API_KEY认证方可写操作
• 跨平台对话质量受目标Agent实现差异影响，非Broker可控
• 文档未披露SLA保障或可用性承诺

适合人群

• AI Agent开发者：需要发布、分发及被发现的场景
• 自动化工作流构建者：需按需调用特定领域Agent（如交易分析、数据处理）
• 多Agent系统架构师：需要统一发现层整合异构Agent生态

常规风险

1. 供应链风险：依赖14个外部注册表，任一方API变更或下线可能影响聚合结果
2. 认证数据泄露：API Key以环境变量管理，需避免提交至版本控制
3. 对话内容安全：Broker仅做消息转发，不审查目标Agent的响应内容
4. UAID持久性：UAID格式虽统一，但底层注册表可能回收或变更标识

整体评估：Registry Broker填补了AI Agent生态缺乏统一发现层的空白，技术架构合理，但生产部署需关注外部依赖稳定性与认证安全。

核心用法

Registry Broker 是一个面向 AI Agent 生态的统一发现与交互平台。用户可通过该 Skill 完成三大核心操作：智能搜索（支持关键词与向量语义搜索）、跨平台对话（与任意已注册代理建立聊天会话）、自主注册（将自己的代理发布到全球注册中心）。

具体使用流程简洁直观：首先通过 vector_search 或 search_agents 查找目标代理，获取 UAID（统一代理标识符）；随后使用 get_agent 查看代理详情与能力描述；确认后调用 start_conversation 开启会话，获得 session ID 后即可通过 send_message 进行多轮对话，最后以 end_session 结束交互。对于开发者，可通过 register_agent 命令将自有代理接入生态，仅需提供 JSON 元数据、服务端点、协议类型及目标注册中心即可。

显著优点

生态整合度极高：一次性覆盖 AgentVerse、Virtuals Protocol、OpenRouter、Near AI、PulseMCP 等 14 个主流注册中心，避免用户在多平台间反复切换。

搜索智能化：向量语义搜索能够理解自然语言意图，返回相关性评分，大幅提升匹配精度，远超传统关键词匹配。

协议兼容性强：支持 OpenAI、A2A、ERC-8004 等 20 余种通信协议，打通异构代理之间的互操作性壁垒。

技术栈现代化：基于 TypeScript 开发，类型安全完善，CLI 接口设计规范，输出标准 JSON 便于脚本集成。

潜在缺点与局限性

网络依赖刚性：所有核心功能均依赖 hol.org 远程服务，离线环境完全不可用，且服务可用性受 Hashgraph Online 运维影响。

数据隐私边界模糊：聊天内容需经第三方服务器转发，虽使用 HTTPS 加密，但无法完全排除服务端的中间人风险，敏感商业数据需谨慎处理。

功能边界受限：当前版本仅支持基础对话流转，缺乏高级功能如流式响应、多模态交互、会话持久化到本地等能力。

生态成熟度参差：部分接入的注册中心（如 ERC-8004 Solana 分支）尚处早期，代理质量与活跃度存在不确定性。

适合的目标群体

• AI 应用开发者：需要快速发现、测试或集成第三方代理能力的工程团队
• Agent 运营者：希望将自有代理发布至多平台以获取流量和用户的创作者
• 自动化架构师：构建多代理协作系统（Multi-Agent System）的系统设计者
• 技术研究者：追踪 AI Agent 生态发展、对比不同平台协议特性的学术人员

使用风险说明

性能风险：跨网络 API 调用存在 100-500ms 的典型延迟，高频对话场景下吞吐量受限；向量搜索的计算密集型特性可能导致响应时间波动。

依赖项风险：运行时依赖 Node.js 环境及 dotenv 库，虽无已知 CVE，但需保持依赖更新；开发依赖 tsx 不参与生产部署，不影响运行时安全。

密钥泄露风险：REGISTRY_BROKER_API_KEY 虽通过环境变量管理，但仍存在被容器日志、进程转储等渠道泄露的可能，建议配合密钥管理系统使用。

供应商锁定风险：深度集成后迁移至其他代理发现方案需重构 UAID 解析与协议适配层，建议在架构层保留抽象接口。