简介
想象一下，未来的AI智能体（Agent）不再是一个孤独的模型，而是一个能够调用成千上万外部工具（比如查天气、订机票、写代码、发邮件）的“数字打工人”。问题来了：当有上百万个工具可用时，智能体该怎么找到最合适的那个？
现有的方案大致分两类，一种是集中式检索，把所有工具的描述都塞进一个向量数据库里，然后每次查询都做一遍全量相似度计算。复杂度是 。当 到几万甚至几百万时，延迟和计算开销会变得非常夸张。第二种是上下文注入，把所有工具的描述都塞进LLM的提示词里。几百个工具还能勉强应付，几万个工具？光是输入token就能让模型崩溃。
这两种方案本质上都是在应用层之上又叠了一层发现服务——我们可以戏称为第8层或第9层。每有一个新框架，就要从头搭一套中心化的注册中心、一套SDK、一套治理规则。
我们忍不住问一个问题：难道非得重新发明轮子吗？
本文介绍我们的工作 —— ToolDNS。它的核心思想非常简单，但又非常激进：直接把AI工具发现这件事，搬到互联网上最古老、最健壮、规模最大的命名系统——DNS上面去。与其在应用层再搭一个脆弱的空中楼阁，不如把工具的语义和信任信息编码进域名层次结构里。这样一来，一次昂贵的语义搜索，就变成了轻量级的 域名解析。
在ToolDNS的设计中：
- 工具按照功能分类并形成多级目录，放在类似
history.weather.tools这样的域名下；
- 智能体发送一个携带自然语言意图的DNS查询（通过EDNS0扩展）；
- DNS服务器（各级权威服务器）用轻量级LLM做语义剪枝，逐级返回最相关的子域名；
- 最终，客户端拿到工具的SRV记录，直接调用。
我们构建了一个包含33,688个真实工具（涵盖MCP、A2A、RESTful、Skill四种协议）的异构评测集。实验表明：
- 搜索空间减少95.26%（仅两层分类）；
- 检索准确率持平甚至超越向量检索基线；
- 网络开销降低一个数量级（UDP vs HTTP）；
- 而且，完全兼容现有DNS基础设施，无需新服务器、新SDK，增量部署。
Remark 1（一点感悟）：我们习惯了“遇到问题就加一层”，却往往忽略了脚下已经铺好的“地基”。DNS或许不是为语义检索设计的，但通过巧妙的扩展，它可能比任何新建的“第10层”都更靠谱。
现有方案的困境：为什么我们一直在重复造轮子？
现有方案主要分为三种主流范式
- 向量检索（如ToolLLM）
- 为每个工具计算 embedding，存入全局索引。
- 查询时计算 query embedding，然后做全量相似度搜索。
- 问题： 复杂度，中心化索引成为性能和信任的瓶颈。工具更新需要周期性重索引，存在同步延迟。
- 上下文注入（如OpenClaw）
- 把所有工具的描述直接塞进LLM的上下文窗口。
- 问题：上下文窗口有限，几百个工具就塞满了。推理成本随上下文长度呈平方级增长。动态更新需要重新生成整个 prompt。
- 中心化注册表（如ANS、AgentDNS）
- 搭建一个专用注册服务器，存储所有工具的元数据。
- 问题：单一控制点（治理挑战），单点故障风险，需要额外的基础设施和运维成本。
除了上述问题，这些方案还有一个共同缺点：都在OSI应用层之上再叠一层新东西。每出现一个新框架，社区就从零开始设计一套“工具发现协议”——新的注册中心、新的API、新的SDK、新的治理规则。但有没有可能，这个问题的答案，其实藏在比应用层更低的“基础设施层”？
图1：现有发现范式 vs ToolDNS的DNS原生方法：左边是层层堆叠的高层架构，右边是直接扎根于DNS的简洁设计。
ToolDNS的方案：把工具发现转化成域名解析
服务发现，本质上是一个命名问题。当智能体问“哪个工具可以把英文翻译成中文”时，它其实是在问：满足“翻译”和“中英文”这两个约束的服务，叫什么名字？而DNS恰恰是互联网上最大、最成功、最健壮的命名系统。它的层次化命名空间、递归解析、分布式缓存、委派机制（NS记录）、安全扩展（DNSSEC），与大规模工具发现的需求之间存在一种深刻的语义同构，如下表所示，工具发现的各个需求都可以用DNS已有的机制解决。因此ToolDNS的核心理念就是：不替换DNS，而是复用并扩展它。
需求 | DNS机制映射 |
层次分类 | 域名层级 |
高效检索 | 递归解析 + 缓存 |
负载均衡 | SRV记录 |
可验证信任 | DNSSEC + 委派链 |
去中心化治理 | NS记录 + 多子域共存 |
层次化语义命名空间
图2：ToolDNS层次化域名空间架构：从.toolsTLD出发，经过weather.tools、history.weather.tools，最终定位到具体的工具实例。
我们在
.tools 这个顶级域下构建一棵功能树。每个节点代表一个功能类别，路径从根到叶子编码了逐步精细的功能描述。例如，一个“英文翻译成中文”且由“阿里”提供的工具，可以放在：
nlp：自然语言处理（大类）
translate：翻译（子类）
alibaba：提供方
english：目标语言（更细粒度）
每个非叶子节点对应一组子类别或工具实例，叶子节点则直接存放工具的资源记录（SRV记录）。
Remark 2（搜索空间缩减）：一次查询从根向下走，每一步需要检查的候选数受限于当前节点的分支因子 。经过 层后，候选集从全量 缩小到叶子节点的工具数量 。复杂度从 降为 ，在平衡树结构下就是 。
逻辑子域：让去中心化治理成为可能
但是传统DNS有一个缺点：每个子域只有一个管理者。那如果
weather.tools 这个功能类别下，HKU、Google、NOAA都想独立创建并运营自己的域名服务，怎么办？传统方案下，只能接受单一实体的管理垄断，每家都做一个查询平台，这样会导致严重的碎片化并阻碍互联互通。。而ToolDNS引入了“逻辑子域”的概念：把功能子域（
weather.tools）和组织子域（hku、google）都考虑进去。那么一个子域其实可以分成两种类型：- 公共通用类：
weather.tools（由社区或注册局管理，作为开放入口）
- 认证信任类：
hku.weather.tools、google.weather.tools（由各组织独立管理）
智能体如果只信任HKU的工具，可以直接查询
_mcp._tcp._hku.weather.tools。解析过程中，.tools 服务器会返回多个NS记录（包括公共和认证类的），由客户端自行选择。这样信任和治理可以分散到已有的组织实体上，而不需要引入一个全局的信任锚点。只要父域（.tools）的权威性足够，委派给 hku.weather.tools 的NS记录就隐含了“这是HKU管理的域”的语义。让DNS学会语义检索的三大关键技术
1. 部分展开域名：编码搜索状态
传统DNS查询必须知道完整的域名。但智能体只知道意图，不知道具体域名。因此我们引入“部分展开域名”概念，在标准SRV格式中插入一个下划线作为“搜索光标”。搜索状态被编码在域名中，递归解析器不需要维护任何每查询状态机。完全兼容现有DNS解析器。
首先我们根据解析状态（解析完成/未完成），将查询请求中的域名分成两种类型
- 完全展开域名：
_mcp._tcp.api.history.weather.tools.（已到达叶子节点）
- 部分展开域名：
_mcp._tcp._history.weather.tools.（光标在_history前，表示还要继续往下走）
解析过程像“展开卷轴”一样，光标逐步左移：
- 初始：
_mcp._tcp._tools.
- 匹配到
weather.tools→_mcp._tcp._weather.tools.
- 匹配到
history.weather.tools→_mcp._tcp._history.weather.tools.
- 到达叶子节点，移除光标，得到
_mcp._tcp.history.weather.tools.，查询SRV记录。
2. EDNS0语义负载：携带自然语言意图
DNS中，域名长度被限制为253字符，因此无法承载长文本意图，我们使用EDNS0扩展机制，在DNS查询包中添加额外选项。我们定义了一个新的EDNS0负载格式：
- Version (8 bits)：版本号（当前0x00）
- Length (16 bits)：负载长度
- K (8 bits)：每层返回的最佳匹配数
- Payload (variable)：UTF-8编码的自然语言意图，如
"historical weather Hong Kong"
图3：语义负载在EDNS0中的协议设计
递归解析器在迭代解析过程中，将这个EDNS0选项原封不动地转发给每一级权威服务器。不支持该选项的DNS服务器会直接忽略，查询失败——但这没关系，因为只有ToolDNS-aware服务器才能做语义剪枝。
Remark 3（一个具体例子）：智能体的意图是“fetch historical weather data for Hong Kong”。EDNS0负载中包含该字符串。当查询到达
weather.tools 服务器时，服务器会将该字符串与子域（history.weather.tools、forecast.weather.tools 等）的语义摘要进行匹配，返回最相关的 个子域。3. LLM增强的语义剪枝：无全局索引的在线匹配
和中心化平台等传统方案不同，ToolDNS的效率核心在于，每一级权威服务器都能够根据意图和EDNS0负载，实时返回最相关的子域或工具。这个匹配过程是无状态、无全局索引、完全在线的。在这种情况下，DNS服务器有两种身份：
- 非叶子服务器（TLD/中间层）：维护子域的语义摘要（关键词或短句）。收到查询后，用轻量级LLM（或embedding+余弦相似度，或BM25）计算意图与每个子域摘要的相关性，返回Top-K子域的NS记录。
- 叶子服务器：直接维护工具实例的功能描述。匹配过程类似，返回Top-K工具的SRV记录。
这使得整个系统不需要某一个服务器维护全局索引，全局地添加、删除或更新工具，只需在叶子服务器的区文件中追加或修改一条SRV记录。下一次查询立即生效，并且修改仅限于一个叶子服务器。这彻底解决了向量检索系统中周期性重索引的同步延迟问题。
图4：ToolDNS完整架构与解析流程：从客户端发起查询，到递归解析器逐级迭代，再到各级权威服务器的语义剪枝，最终返回工具端点。
实验：我们搭建了一套原型并进行测试
数据集构建：33,688个真实工具
由于目前没有统一的、大规模的异构工具发现评测集，我们自己构建了一个。数据来源包括：
- RESTful API：ToolBench的G1任务集
- MCP工具：MCPZoo
- OpenClaw Skills：社区维护的技能列表
- A2A：Google官方A2A示例
通过多阶段清洗（Qwen3-30B + DeepSeek辅助），最终得到33,688个高质量工具，并构建了层次化的分类体系。
1. 检索准确率：持平甚至超越向量检索基线
实验设置：对比ToolDNS（层次化解析）和ToolLLM（平面向量检索）。测试集为保留的40%数据，严格按ToolLLM原始方法重训。
图5：ToolDNS的整体命中率高于ToolLLM基线。这说明层次化剪枝不只是在缩减搜索空间，它实际上通过将候选池限制在语义连贯的簇中，抑制了检索噪声。平面检索中那些“看起来相似但实际不相关”的干扰项，在层次化解析中被提前剪掉了。
2. 搜索空间缩减：95.26%的恐怖降幅
实验设置：模拟不同规模的工具仓库 到 ，比较集中方案的搜索空间大小。ToolDNS配置为每层返回Top-1子域，共2层分类目录。
图6: ToolDNS的搜索空间显著小于传统方案，包括线性搜索和OpenClaw的上下文方案。
- 工具时，一层分类将搜索空间缩减到4,888（减少80.65%）；两层分类缩减到1,197（减少95.26%）。
- 工具时，两层分类相比OpenClaw的全量上下文注入，搜索空间减少了超过99.99%。
需要注意的是，我们的分类深度只有2层。更深、更平衡的层次结构理论上可以达到 \(O(\log N)\) 的复杂度上限。
3. 网络效率：UDP vs HTTP，降维打击
实验设置：超过13,000次真实查询，对比ToolDNS与两个HTTP基线（AgentDNS、ANS）。采用保守设置，HTTP基线只保留核心字段，刻意偏向它们。
表2 各种方案的网络延迟和压力对比
方案 | 总流量(MB) | 总包数 | 每查询延迟(ms) |
AgentDNS | 15.69 + 24.10 = 39.79 | 145,107 + 133,020 = 278,127 | ~2035.51 |
ANS | 14.66 + 18.96 = 33.62 | 145,108 + 133,022 = 278,130 | ~2042.68 |
ToolDNS | 9.70 + 4.40 = 14.10 | 40,198 + 40,198 = 80,396 | ~5.62 |
ToolDNS的总流量和总包数都降低了60%以上，每查询延迟从约2秒降到约5.6毫秒，大约降低了三个数量级。这得益于DNS的轻量级UDP报文（避免了TCP握手、HTTP头部、JSON结构等冗余开销）。
4. 层次化结构对抗“注意力稀释”
实验目的：对比两种信息呈现方式对LLM决策质量的影响，我们分别测试了
1）层次化方案：LLM逐层做决策，每层只评估当前节点的子节点。
2）平面化方案：所有叶子子域展开成一个列表，LLM一次性选出最相关的。每个候选都附带完整的层次路径信息（如
translate.nlp.tools），以控制信息量一致。
图7：层次化方案与平面化方案的准确率对比。层次化方案在所有域上的命中率都显著高于平面方案。这说明层次化命名空间不仅仅是“组织上的便利”，更是一种功能性的机制，用于减轻LLM在大规模搜索空间中的“注意力稀释”问题。
平面方案中，所有候选同时竞争注意力，大量语义上相似但实际不相关的项会引入噪声，误导模型。而层次化方案实现了一种“分而治之”的策略：每一步只评估少量、语义聚焦的子集，模型有效地忽略了绝大多数无关分支。
ToolDNS方案的几大优势
部署成本极低，无需修改客户端操作系统、网络栈或现有DNS基础设施。这是ToolDNS相比其他提案最显著的优势：增量部署、零配置、现网兼容。全局部署ToolDNS只需要两件事：1）IANA或适当机构委派
.tools TLD，并部署支持语义剪枝的TLD服务器；2）各组织在相应功能前缀下注册自己的逻辑子域。ToolDNS天然具有信任模型，1）逻辑子域机制继承DNS委派的信任模型。如果智能体信任HKU，直接查询
hku.weather.tools，响应来自HKU的权威服务器。2）DNSSEC可叠加用于完整性验证（.tools 区和组织区签名）。3）可使用DoT或DoH加密客户端与递归解析器、递归解析器与权威服务器之间的信道，提高安全性与隐私性。总结
- 我们证明了，对于某些类别的发现问题，基础设施原生方法值得被重新审视。DNS的设计中已经蕴含着层次化分类、委派信任、分布式缓存等解决工具发现问题的“种子”。
- 通过把功能语义和信任信息编码进域名，昂贵的语义搜索被“降维”成了几次轻量级域名解析。这是一个根本性的复杂度转换：。
- 在不改变DNS协议的情况下，通过“功能子域+组织子域”的方式，实现了工具检索多组织平等共存、可选择性信任、灵活安全隔离。
- 我们不仅提出了想法，还构建了33k+工具的异构评测集，并在其上系统评估了准确率、搜索空间缩减、网络开销、注意力稀释等维度。实验证明，ToolDNS在各方面都优于或持平现有方案，同时在部署成本和可扩展性上具有压倒性优势。
ToolDNS不试图“取代”现有的向量检索或上下文注入方法——它们在自己的适用场景中依然有效。我们想展示的是，有时候，最好的新系统，不是从零开始建造的新系统，而是用最小的代价，最大的敬意去整合利用已经运行了多年的旧系统。
随着AI智能体的数量持续增长，最健壮的工具发现基础设施，很可能来自多种方法的共存与协同。我们希望通过ToolDNS，为这个多元化的生态提供一个轻量、可扩展、可互操作的“基座”。
如果你觉得这篇文章对你有帮助，欢迎引用我们的工作：