一个 Agent 今天想调用工具，听起来很智能，实际常常卡在很笨的地方：工具要先装好，MCP server 要先写进配置，插件要先接上，工具说明还要塞进上下文。

然后模型在一堆描述里猜：哪个能用，哪个更合适，哪个不该碰。

Hugging Face 这次发布的 Discover Tool，瞄准的就是这个前置动作。它是 Agentic Resource Discovery，也就是 ARD 的参考实现：让 Agent 在运行时搜索工具、Skills、MCP 服务器和其他 Agent，而不是全靠开发者预先手工安装。

这事最值得看的一点，不是 Hugging Face 做了个“工具搜索”。而是 Agent 生态开始把“谁能被找到”这件事摆上台面。

ARD 解决的是发现，不是调用

ARD 不是 Hugging Face 私有产品，也不是工具商店。它目前是 draft/open specification，参与方包括 Microsoft、Google、GoDaddy、Hugging Face 等。

它要补的不是模型能力，也不是执行链路，而是 Agent 能力发现问题。

过去的路径是 install-first, use-later。先安装、先配置、先把工具描述交给模型，再让模型选。

ARD 想改成 search-first。Agent 先描述需求，再去外部注册表里找能力。

维度过去常见做法ARD 的方向
工具发现手工配置、预装插件运行时搜索注册表
选择位置LLM 上下文里猜外部 registry 检索和排序
可信信号工具自述为主发布者身份、标签、代表查询、合规声明
规范核心各家自定ai-catalog.json 与 POST /search
解决范围找到已接入工具发现可用资源，不包办执行安全

规范里有两个关键件。

一个是静态的 ai-catalog.json manifest。发布者可以在固定 URL 暴露自己的能力目录。

另一个是动态的 POST /search 注册表 API。客户端用自然语言查询，注册表返回排序结果。

Hugging Face 的 Discover Tool 是这个规范的参考实现。它可以搜索 Hub 上的 Spaces、Agent Skills、MCP Servers，并支持 CLI、REST API、MCP endpoint 三种入口。

比如开发者可以用 hf discover search "Generate an image" --kind mcp 找 MCP server；也可以请求 Hugging Face 的 /search 接口；还可以把 MCP client 接到它的 MCP endpoint。

这里要压住期待。ARD 让资源更容易被发现，不等于 Agent 可以安全调用任意工具。授权、权限控制、安全验证、结果审计，仍然要靠别的机制补上。

“能找到”和“能放心用”，中间隔着一整套工程债。

受影响的不是普通聊天用户，而是开发者和平台

普通聊天机器人用户短期感知不强。你不会因为 ARD 立刻看到一个全新的聊天界面。

真正要动的是 Agent 开发者、工具发布者，以及 MCP、Skills、A2A 这类生态参与者。

对象现在该关心什么可能的动作
Agent 开发者工具发现是否还要写死在配置里先把工具接入方式抽象出来，避免绑定单一 registry
工具发布者自己的工具能否被机器稳定理解补齐 manifest、标签、代表查询、合规声明等元数据
工具平台搜索、排序、身份信号谁来定评估是否支持 ARD，或提供兼容接口
模型生态观察者分发入口是否从模型上下文外移盯排序规则、默认注册表、平台偏置

对 Agent 开发团队来说，最现实的动作不是马上迁移全部工具链，而是把“发现”和“调用”拆开设计。

工具列表别再全写死。注册表也别只接一家。

如果团队已经在用 MCP server，ARD 更像一个可观察的新接口层。可以先做兼容实验，但不宜把生产安全押给它。

对工具发布者来说，问题更直接：你的工具以前是给人看的，现在要给 Agent 搜。

名字、描述、标签、示例查询、发布者身份、合规声明，都会变成被发现的材料。文档写得烂，以前只是人看不懂；以后可能是 Agent 根本搜不到。

这也是我觉得 ARD 有用的地方。它没有假装发明新世界，而是承认一个现实：Agent 生态已经有很多资源，缺的是机器可读、可检索、可排序的目录。

Hugging Face 把 Hub 里的 Spaces、Skills、MCP Servers 包进 ARD 外壳，本质上是在给已有资源补一层发现协议。这个选择不炫，但实际。

开放规范早期最缺的往往不是口号，而是一个能跑的样板。

入口之争会从排序开始

我更在意的是选择权的移动。

过去，工具选择被塞在模型上下文里。模型读一堆工具描述，然后生成一个调用决定。这个过程不透明，也很吃上下文质量。

ARD 把一部分选择动作挪到外部注册表：检索、排序、身份、合规信号，都有机会变成显式规则。

这一步很像早期互联网从“记网址”走向“用搜索引擎”。网页不是搜索引擎发明的，但流量分配从搜索开始改写。

不完全一样。Agent 工具不是网页，调用还牵涉权限、数据、成本和安全。但权力结构很像：谁掌握发现，谁就更靠近分发。

“天下熙熙，皆为利来。”放在这里并不夸张。只要有搜索，就会有排名；只要有排名，就会有优化、默认位和平台偏好。

ARD 现在强调自己不是 marketplace，这个边界很重要。它目前也确实只是草案规范和参考实现阶段，谈行业事实标准还太早。

但发现层天然会长出市场的影子。

接下来真正该看的，不是又多了多少个 demo，而是几件硬事：

  • 不同 registry 之间能不能联邦搜索；
  • 排序规则是否透明，能否被开发者理解；
  • 发布者身份和合规声明有没有可验证约束；
  • 平台会不会把自家资源放进更舒服的位置；
  • Agent 产品会不会把“搜到”误当成“可信”。

这些问题不解决，ARD 最多是一个漂亮目录。解决得好，它才可能变成 Agent 基础设施的一部分。

我不太买账的是那种轻飘飘的说法：Agent 以后会自己找工具，所以开发者不用管了。

恰好相反。越是自动发现，越要把边界写清楚。

哪些工具可以被搜到，哪些工具可以被调用，哪些调用要二次确认，哪些结果要审计，这些都不是搜索协议能替你做完的事。

Agent 生态现在缺的不是又一个炫技入口，而是秩序。ARD 往这个方向走了一步。步子不大，但踩到了要害。

开头那个笨问题会越来越贵：Agent 到底从哪里知道自己该用什么工具？

如果答案仍然是“让模型自己猜”，分发权就留在黑箱里。如果答案变成“去注册表里找”，新的入口战已经开始了。