智能体找不到自己的工具 — 运行时工具发现层

问题是什么

如今AI智能体获取工具的方式是「先安装、后使用」。开发者把MCP服务器URL手动写进配置文件，智能体才能用上那个工具。这种方式在规模变大后就崩了，因为智能体没办法在工作途中动态发现一个陌生工具。常见的变通做法——把所有工具描述塞进LLM上下文窗口——也有明显的上限。token预算卡住它，工具一旦超过几十个，模型就分不清该选哪个。结果智能体的能力被困在开发者事先想象并接好的那批工具里。用户说「把这份PDF放进会计系统」，如果那个会计连接器没有被预先安装，智能体根本不知道它存在。换成人类只需搜索就能找到，智能体却做不到。工具本身正在爆炸式增长——上千个MCP服务器、AI技能和ML应用——可偏偏缺少那一层，让智能体在运行时从中找到并选出合适的那一个。BAT与字节跳动各自的智能体平台都在堆工具，却没人把这一层做扎实。

为什么是现在

催生时机的是标准的出现。Hugging Face联合微软、谷歌、GoDaddy等发布了ARD（智能体资源发现）草案规范。模型很简单：你在域名的知名路径上发布ai-catalog.json，注册表对其建立索引，智能体用自然语言意图搜索，然后验证发布者并通过MCP、A2A或普通API连接。这就是给智能体用的DNS加电话簿。规范定义了两套机制——静态清单（ai-catalog.json）和动态注册表API（自然语言POST /search）。标准落地意味着一块竞争的场地刚刚打开，正如域名系统标准化之后才催生了DNS服务商和注册商。眼下规范还处于草案阶段，而真正要紧的部分——一个好用到能上手的注册表，具备过硬的索引质量、排序与发布者验证——还是空的。标准本身并不决定谁搜得更好。对同一个意图把哪个工具排在第一，那份排序质量才是产品的竞争力，而这个位置还没有主人。

怎么构建

构建一个实现ARD规范的工具发现注册表。核心有三点。第一，抓取与索引——把散落在各域名的ai-catalog.json收拢起来，把每个工具的描述、代表性查询和标签做成嵌入建立索引。第二，意图排序——当智能体用自然语言搜索「我想做X」，按置信度返回合适的工具。不是关键词匹配：把发布者身份、合规证明和真实使用信号加权进去以提高精度。第三，验证闸门——不要把任何工具都暴露出去，验证发布者、过滤掉恶意或冒充的工具，让智能体安全连接。收入从两侧收取：向工具发布者收（曝光与优先索引的B2B费用），向智能体开发者收（按调用计费的搜索API）。别想着第一天就覆盖所有工具；挑一个垂直领域——比如金融科技连接器或数据管道工具——把它的索引质量做到远超他人，在那里坐稳标准注册表的位置。像Hugging Face的Discover Tool这样的参考实现已经存在，所以差异点在于你能多准、多安全地找到那个合适的工具。