大规模AI工具发现:只需DNS

arXiv cs.AI 论文

摘要

本文提出ToolDNS,一个将语义工具发现改造到DNS基础设施上的框架,实现了可扩展的O(log N)解析,并在包含超过33,000个跨多种协议的真实世界工具的基准测试中,将搜索空间减少了95.26%。

arXiv:2607.18242v1 Announce Type: new 摘要:自主AI智能体的时代即将到来,这需要一种能够导航数百万工具的发现机制,然而现有的解决方案在O(N)复杂度和集中式治理下举步维艰。我们并未构建另一个脆弱的覆盖层,而是提出了ToolDNS,一个激进的框架,将语义工具发现改造到互联网最具韧性的基础架构上:域名系统(DNS)。通过将功能意图和组织信任嵌入到层级命名空间中,ToolDNS将昂贵的语义搜索转变为一系列轻量级的O(log N)名称解析。我们引入了三种符合协议规范的增强功能,以实现去中心化治理和语义剪枝:部分展开的名称、EDNS0意图载荷和逻辑子域。为了在碎片化的工具生态中严格评估该方法,我们构建并发布了一个大规模异构基准测试,包含33,688个覆盖MCP、A2A、RESTful和Skill协议的真实世界工具。在该数据集上,ToolDNS将每次查询的搜索空间削减了95.26%,同时匹配最先进的检索精度。此外,其UDP原生设计相比基于HTTP的注册表,将发现延迟降低了数个数量级。我们的工作表明,可扩展的AI互操作性并不需要更多的中间件,而是需要更智能地利用我们脚下已有的基础设施。
查看原文
查看缓存全文

缓存时间: 2026/07/22 08:19

# 大规模AI工具发现:你只需DNS 来源: https://arxiv.org/html/2607.18242 作者: Yulin Shao 香港大学 香港 中国 [email protected] (https://arxiv.org/html/2607.18242v1/mailto:[email protected]) ###### 摘要。 自主AI代理时代即将到来,这需要一种能够在数百万个工具中导航的发现机制,但现有解决方案在O(N)\mathcal{O}(N)复杂度和中心化治理下不堪重负。与其构建另一个脆弱的覆盖层,我们提出ToolDNS,一个激进的框架,将语义工具发现改造到互联网最有弹性的基底:域名系统(DNS)。通过将功能意图和组织信任嵌入到分层命名空间中,ToolDNS将昂贵的语义搜索转化为一系列轻量级的、O(log⁡N)\mathcal{O}(\log N)名称解析。我们引入了三种符合协议规范的增强功能,以实现去中心化治理和语义剪枝:部分展开名称、EDNS0意图载荷和逻辑子域名。为了在碎片化的工具生态中严格评估这种方法,我们构建并发布了一个大规模异构基准数据集,包含33,68833,688个跨越MCP、A2A、RESTful和Skill协议的真实世界工具。在该数据集上,ToolDNS将每次查询的搜索空间减少了95.26%95.26\%,同时达到了最先进的检索精度。此外,其基于UDP的原生设计相比基于HTTP的注册表将发现延迟降低了几个数量级。我们的工作表明,可扩展的AI互操作性不需要更多的中间件,而是需要更智能地利用我们已经拥有的基础设施。 ††版权声明:无

## 1. 引言

AI代理的迅速普及标志着一个新计算范式的开端:孤立的模型正在演变为协作的社会,自主代理之间相互调用彼此的工具,如函数、API、技能或整个代理工作流(Yang et al., 2024 (https://arxiv.org/html/2607.18242#bib.bib22); Yao et al., 2022 (https://arxiv.org/html/2607.18242#bib.bib23); Shao et al., 2024 (https://arxiv.org/html/2607.18242#bib.bib3))。这一演化的核心是一个基本但未被充分重视的问题:服务发现(Schick et al., 2023 (https://arxiv.org/html/2607.18242#bib.bib24); Patil et al., 2024 (https://arxiv.org/html/2607.18242#bib.bib25); Cui et al., 2024 (https://arxiv.org/html/2607.18242#bib.bib5))。为了让代理能够在上百万或数十亿候选工具中找到并调用最合适的工具,生态需要一种可扩展、安全、可增量部署且协议无关的发现机制(例如,MCP(Ray, 2025 (https://arxiv.org/html/2607.18242#bib.bib14))、A2A(Ehtesham et al., 2025 (https://arxiv.org/html/2607.18242#bib.bib11))、RESTful API(Fielding, 2000 (https://arxiv.org/html/2607.18242#bib.bib19))、Skill(Xu and Yan, 2026 (https://arxiv.org/html/2607.18242#bib.bib13)))。

现有解决方案大致分为两大类,都在OSI应用层(第7层)之上引入了临时增加的层,可称之为第8层或第9层结构。
- • 第一类,以ToolLLM(Qin et al., 2023 (https://arxiv.org/html/2607.18242#bib.bib6))及类似的向量检索系统(Ehtesham et al., 2025 (https://arxiv.org/html/2607.18242#bib.bib11))为代表,构建中心化注册表或全局索引。对于每个查询,系统需要计算与所有已知工具的相似度,带来O(N)\mathcal{O}(N)的计算成本和在大规模下无法接受的延迟。
- • 第二类,以OpenClaw框架(Team, 2024 (https://arxiv.org/html/2607.18242#bib.bib9); Weidener et al., 2026 (https://arxiv.org/html/2607.18242#bib.bib10))为代表,将所有工具描述注入到大语言模型(LLM)(Zhao et al., 2023 (https://arxiv.org/html/2607.18242#bib.bib34))的上下文窗口中。当工具集增长到几百条以上时,这种策略变得不可行,因为上下文窗口被耗尽,推理成本呈二次方增长。

除了性能问题,这两种方法都存在单点故障、治理孤岛(不同组织无法就单一注册表达成一致)以及高部署障碍:任何新的发现服务都需要从头构建和运营全新的全球基础设施,并且通常要求访问它的客户端集成特定的SDK或专有API。

本质上,社区有陷入过度工程循环的风险,不断创建更加沉重的层结构,而忽略了已经存在的健壮、全球部署的基础设施(Reed, 2010 (https://arxiv.org/html/2607.18242#bib.bib29); Wirth, 2002 (https://arxiv.org/html/2607.18242#bib.bib31); Handley, 2006 (https://arxiv.org/html/2607.18242#bib.bib32); Shao et al., 2021 (https://arxiv.org/html/2607.18242#bib.bib12); Stoica and Shenker, 2021 (https://arxiv.org/html/2607.18242#bib.bib30))。

图1 (https://arxiv.org/html/2607.18242#S1.F1)将这一趋势与我们提出的方向进行了对比。 参见图注

**图1.** 现有发现范式(左)与ToolDNS的DNS原生方法(右)。

本文从一个简单但激进的重新审视开始:*服务发现,当通过基础设施设计的视角来看待时,可以在很大程度上简化为一个命名问题,而非纯粹的语义匹配问题*。具体来说,通过将功能和信任属性嵌入到分层命名空间中,寻找合适工具的行为就等同于解析一个域名。当一个代理问“哪个工具可以把英文翻译成中文?”时,它实际上是在询问一个满足一组约束的服务的名称。域名系统(DNS)作为有史以来最成功、最可扩展的命名系统,自然提供了这样的能力:其分层命名空间、递归解析、分布式缓存、加密扩展(例如DNSSEC(Arends et al., 2005 (https://arxiv.org/html/2607.18242#bib.bib21)))和委派(Elz and Bush, 1997 (https://arxiv.org/html/2607.18242#bib.bib17))(NS记录)与大规模工具发现的需求表现出深刻的语义同构性,包括分层分类、高效检索、负载均衡、可验证信任和去中心化治理。然而,主流研究将DNS视为“仅用于静态主机名”,忽视了诸如EDNS0(Damas et al., 2013 (https://arxiv.org/html/2607.18242#bib.bib16))和SRV(Gulbrandsen et al., 2000 (https://arxiv.org/html/2607.18242#bib.bib33))记录等标准中编码的潜在可扩展性。这种疏忽导致社区反复构建脆弱且缺乏互操作性的注册系统。

我们提出ToolDNS,一个通过重用而非替换现有DNS基础设施来解锁AI工具发现的框架。ToolDNS作为一个分层系统运行,反映了组织现实:一个指定权威机构管理一个官方域名,如.tools和weather.tools,而任何其他机构(例如大学、公司、标准组织)都可以申请并在其下管理自己的独立子域名,例如hku.weather.tools或google.weather.tools。工具注册通过标准DNS NS记录委派给这些权威区域,代理通过现有递归解析器树进行发现。没有新服务器,没有中央权威,也没有强制性的SDK。此外,基于DNS的无连接设计,ToolDNS仅依赖UDP数据包,这可以减少网络开销和传输压力。

然而,将DNS用于语义发现并非易事。首先,标准DNS是为精确、确定性的查找设计的,客户端必须事先知道确切的域名。相比之下,AI代理只表达模糊的意图(例如,找一个天气API)。其次,根据RFC 2181(Elz and Bush, 1997 (https://arxiv.org/html/2607.18242#bib.bib17)),域名每一部分最长63个字符,整个域名不超过253个字符,对于自然语言查询来说太短。第三,在现有DNS中,单个实体控制每个子域名,造成了治理垄断,与开放的跨组织工具生态相冲突。

ToolDNS克服这些不匹配的方法不是通过增加重量的中间件来扩展DNS,而是通过三种轻量级的、符合协议规范的增强:1)部分展开域名,将未知目标转化为逐步缩小的搜索游标;2)EDNS0,支持显著更大的长度来携带语义意图载荷,而不破坏标签长度限制;3)逻辑子域名,将功能层次结构与管理控制解耦,允许hku.weather.tools和google.weather.tools在相同的weather.tools分支下共存,各自拥有独立的治理。这些创新将DNS从一个静态映射器转变为一个语义发现框架,无需修改解析器的任何一行代码。

通过这些增强,ToolDNS继承了DNS的所有原生优势:无需部署新基础设施,客户端零配置(仅需支持EDNS0),原生缓存目录结构,以及增量可部署性。此外,它直接解决了信任和治理差距。通过允许代理仅查询特定组织子域名(例如,仅\*.hku.tools),ToolDNS实现了灵活的安全策略,而无需中央信任锚。该框架也是协议无关的:MCP、A2A、RESTful API、Skills都适合使用_service._proto编码,提供轻量级、可扩展的元数据方案。

总之,本文做出以下贡献:
- • 我们提出了ToolDNS,一个基于基础设施原生的分层架构,用于AI工具发现。通过将功能、领域和协议属性编码到.tools TLD下的语义命名空间中,我们将工具发现改造到现有的DNS层级上。这种设计绕过了在传统的新第8或第9层重建中心化注册表的路径,实现了低工程迁移成本、与标准DNS客户端和解析器的双向兼容性,以及从DNS基础设施本身继承的全局高可用性。层级结构将每次查询的搜索复杂度从O(N)O(N)降低到O(log⁡N)O(\log N)。
- • 我们引入了一种基于逻辑子域名和标准DNS NS记录的委派信任与治理机制。通过继承父域名的层级背书,子域名通过权威机构的既有声誉提供了可验证的身份和安全治理。同时,该机制规避了传统DNS的管理垄断,允许多个实体在共享功能命名空间下管理各自独立的资源。代理可以将发现查询限制在仅信任的子域名,实现去中心化的信任管理、灵活的安全隔离以及无需中央权威的对等多租户治理。
- • 我们设计了一种使用EDNS0扩展的、由LLM增强的无索引检索协议。该方法不维护全局向量索引,而是实时进行语义剪枝:递归解析器将用户的自然语言意图和一个KK参数携带到每个权威服务器,权威服务器通过轻量级LLM评分返回最相关的top‑KK子域名。这避免了周期性的索引重新训练,并自然地适应动态工具库。新工具只需作为最底层子域名的新条目出现,在查询时即可被发现,消除了同步滞后。该协议将每次DNS迭代转变为自适应的语义缩小步骤,使发现过程与底层工具库的更新频率无关。
- • 我们创建并发布了一个大规模异构基准数据集,包含33,68833,688个跨越MCP、A2A、RESTful和Skill协议的真实世界工具。使用该数据集,我们经验性地验证了ToolDNS通过仅两层层级剪枝将每次查询的搜索空间减少了95.26%95.26\%,同时达到了与最先进的向量检索基线相当的检索精度。此外,与穷举扫描方法相比,ToolDNS将响应延迟提高了数个数量级,展示了在超大规模部署场景中平衡高精度和低开销的能力。

## 2. 问题形式化

本节形式化AI工具发现问题,建立捕捉其固有挑战的指标,并刻画理想解决方案必须满足的特性。

### 2.1. AI工具发现

令T={t1,t2,...,tN}\mathcal{T}=\{t_{1},t_{2},\dots,t_{N}\} 表示一组NN个工具。每个工具tt代表一个由AI代理或服务暴露的可调用能力。每个工具关联:
- • 功能描述d(t)d(t),通常是自然语言字符串,指定工具的功能、输入/输出模式和使用约束。
- • 协议规范p(t)∈Pp(t)\in\mathcal{P},其中P\mathcal{P}是支持的调用协议集合(例如MCP、A2A、RESTful、Skill)。
- • 访问端点e(t)e(t),通常是网络地址(IP和端口)或URI。
- • 组织信任锚a(t)a(t),表示发布并担保该工具的实体(例如HKU、Google)。

代理查询qq是自然语言话语,表达代理发现和调用工具的意图。例如,q=q=“获取香港过去一周的历史天气数据”。

###### 定义1. 发现系统是一个函数,给定代理查询qq,返回被认为相关的工具t~(q)∈T\tilde{t}(q)\in\mathcal{T}。实践中,系统可能返回一个大小为KK的排序列表(top‑KK发现),记为DK(q)⊆T\mathcal{D}_{K}(q)\subseteq\mathcal{T}。

为了评估发现系统的精度,我们进一步为每个工具t∈Tt\in\mathcal{T}定义一个相关集RtR_{t}。该集合Rt⊆TR_{t}\subseteq\mathcal{T}包含与tt属于相同语义类别的所有工具。在分层命名空间中,RtR_{t}通常对应于共享相同叶子子域名的所有工具记录。

为了衡量发现质量,我们定义两个指标。

###### 定义2(命中率)。给定一个查询qq和一个正确满足qq的真实工具t∗t^{*}(例如代理应该调用的工具),命中率是t~(q)⊆Rt∗\tilde{t}(q)\subseteq R_{t^{*}}。当在查询集上平均时,它衡量了正确工具出现在top‑KK结果中的查询比例。

###### 定义3(查询工具数量)。对于查询qq,查询工具数量C(q)C(q)是在发现过程中被主动检查(例如评分、比较、检索)的不同工具的数量。一个设计良好的发现系统应实现C(q)C(q)在NN上呈次线性关系:(1)limN→∞C(q)N=0.\lim_{N\to\infty}\frac{C(q)}{N}=0.特别地,C(q)=O(log⁡N)C(q)=\mathcal{O}(\log N)或O(1)\mathcal{O}(1)是理想的。

除了这些定量性能指标,一个面向开放AI代理生态的实用发现系统还必须满足以下特性。
- • 系统必须运行在现有互联网基础设施之上,无需新的全局服务、自定义SDK或修改客户端网络栈(超出广泛可用的功能)(Reed, 2010 (https://arxiv.org/html/2607.18242#bib.bib29))。

相似文章

设备如何自行发现加密DNS

Lobsters Hottest

本文解释了指定解析器发现(DDR)协议,该协议让设备能够自动发现加密DNS端点。它描述了查询如何工作、解析器如何响应,以及从普通DNS进行机会性升级的局限性。

@VincentLogic: 一个程序员突发奇想: DNS 解析器会把域名记几天—— 那能不能拿来存文件? ↓ 他找到了全网 390 万个开放 DNS 解析器 把文件切碎 撒遍整个互联网 没有硬盘 没有数据库 没有云 文件活在无数台服务器的缓存里 而那些服务器根本不知…

X AI KOLs Timeline

一个程序员利用全网390万个开放DNS解析器的缓存来存储文件碎片,创建了一个名为dnsfs的荒诞开源项目,文件随着缓存过期而消失。