别再给 Agent 预装一堆插件了,它该学会自己搜索能力

过去我们用 AI Agent，基本是一个思路：

先把工具装好，再让它干活。

要查网页，就提前接搜索工具。

要操作数据库，就提前配数据库连接。

要调用某个 API，就先安装插件、MCP Server 或 Skill。

这套方法没错。

但它有个明显的问题：太像“固定工具箱”了。

你提前放进去锤子，它就会敲钉子。

你提前放进去螺丝刀，它就会拧螺丝。

可如果明天用户要做一件新事，而工具箱里刚好没有呢？

这就是现在很多 Agent 系统的尴尬。

模型越来越聪明，但它能做什么，仍然被“提前装了什么工具”限制住。

Hugging Face 最近提到的Agentic Resource Discovery，简称 ARD，想解决的就是这个问题。

一句话说：

未来的 Agent，不只要会使用工具，还要会自己寻找工具。

先安装，再使用，这套模式快不够用了

现在的 Agent 能力，大致靠三类东西扩展。

第一类是 MCP，也就是 Model Context Protocol：它让 Agent 用统一方式调用外部工具，比如搜索、文件系统、数据库、浏览器、API 服务。

第二类是 Skills：它更像一套任务说明书，告诉 Agent 遇到某类任务时，应该按什么流程做。

第三类是 A2A，Agent-to-Agent：一个 Agent 可以把任务交给另一个更专业的 Agent。

这些都很有用，但它们默认有一个前提：

你已经知道要接哪个工具
你已经知道要安装哪个 Skill
你已经知道要找哪个 Agent

在小范围里，这没问题，你每天只用 GitHub、浏览器、文件系统，提前装好就行。可真实任务往往不是这样，用户可能会说：

“帮我找一个能把录音转文字的工具。”
“帮我找一个可以生成图片的 MCP Server。”
“帮我找一个适合微调文本模型的资源。”
“帮我找一个能处理机票预订流程的 Agent。”

这时候，问题就变了，用户不知道工具名，开发者也不可能提前装好全世界所有工具，就算真把几百个工具描述塞进上下文里，模型也会选晕，所以 Agent 需要一种更像搜索引擎的能力，不是按名字调用工具，而是按意图搜索能力。

ARD 是什么？

ARD，全称是 Agentic Resource Discovery。可以把它理解成：面向 AI Agent 的“资源发现标准”。它不是某个平台自己的插件市场，也不是一个单独 App。它更像一套规则，告诉工具、技能、Agent、MCP Server 这些资源：

你应该怎么描述自己
别人应该怎么索引你
Agent 应该怎么搜索你
搜索到之后，又该怎么判断你是否可信

以前的流程是：

开发者手动配置工具
用户手动选择插件
Agent 只能使用预装能力

ARD 想推动的流程是：

资源发布者公开能力描述
注册中心把这些资源索引起来
Agent 用自然语言搜索
系统返回匹配结果
Agent 再判断要不要连接和调用

也就是说，Agent 的能力边界不再只是“本地装了什么”，而是变成：

它能在网络里发现什么，这件事有点像搜索引擎之于网页。只不过，这次搜索网页的不是人，而是 Agent。

ARD 解决的不是“调用”，而是“发现”

这里很容易混淆，MCP 解决的是怎么调用工具，Skills 解决的是怎么使用某类能力，A2A 解决的是怎么调用其他 Agent。但在调用之前，还有一个更早的问题：我怎么知道有哪些工具可以调用？这就是发现问题。没有发现层，Agent 只能盯着提前配置好的工具列表。列表太短，能力不够。列表太长，上下文浪费，模型选择也更困难。

ARD 的思路是，把“找工具”这件事从提示词里拿出来，交给外部注册中心和搜索系统。Agent 不需要背着几百份工具说明书工作。它只需要在需要时发出请求：

“我需要一个音频转写工具。”
“我需要一个图片生成 MCP Server。”
“我需要一个能帮我微调语言模型的 Skill。”

然后资源发现服务返回结构化结果。

这比把所有工具描述一次性塞给模型，更适合大规模生态。

ARD 怎么工作？

Hugging Face 文章里提到两个核心设计。

第一个是静态清单文件。资源发布者可以放一个 ai-catalog.json 文件，用来描述自己提供的能力。它大概会告诉外界：

我这里有哪些工具。
这些工具能做什么。
谁发布的。
怎么访问。
属于哪种类型。
是不是 MCP Server、Skill 或其他资源。

第二个是动态搜索 API。注册中心可以提供类似 POST /search 的接口。Agent 或客户端用自然语言提交需求，注册中心返回排序后的结果。这样，整个流程就跑通了：

发布能力。
索引能力。
搜索能力。
验证来源。
连接并调用。

从用户角度看，只是说了一句需求。从系统角度看，Agent 已经从“固定工具箱”走向了“动态能力网络”。

Hugging Face 做了一个参考实现

Hugging Face 在文章里介绍了自己的 Discover Tool。它做的事情很直接，把 Hugging Face Hub 上已有的资源，变成 Agent 可以搜索的能力。Hugging Face Hub 本来就有很多东西：

Spaces
Gradio 应用
MCP Server
Agent Skills
模型演示
机器学习应用

过去，这些资源主要是人打开网页去搜。

现在，Hugging Face 做了一层适配，让 Agent 也能按标准方式搜索。

比如 Agent 可以搜索：“生成图片”、“转写音频”、“微调语言模型”、“找一个可用的 MCP Server”

Discover Tool 会把相关资源转换成 ARD 规范下的目录条目，再返回给 Agent。

这件事的信号很清楚：Hugging Face Hub 不只是模型和应用平台了。它正在变成 Agent 能力发现网络的一部分。

ARD 和 RAG，不是一回事

很多人会把 ARD 和 RAG 放在一起看，但它们找的东西不一样，RAG 找的是知识。

比如用户问：“Transformer 是什么？”Agent 要去查文档、读网页、找论文，然后组织答案。

ARD 找的是能力。比如用户说：“帮我找一个可以把录音转成文字的工具。”这时候 Agent 不是找答案，而是找一个能完成任务的工具、MCP Server 或 Skill。

所以可以简单记：RAG 是检索知识，ARD 是检索能力。

未来成熟的 Agent 系统，大概率两者都会用。先用 RAG 理解背景。再用 ARD 找工具。最后通过 MCP 或 API 执行任务。这才像一个完整的工作助理。

ARD 和 MCP，也不是替代关系

MCP 很重要，它解决的是工具怎么连接、怎么调用。但 MCP 本身没有解决一个问题：这个 MCP Server 从哪找？

ARD 补的就是这一层，可以这样理解：

MCP 是插头标准，ARD 是设备目录。

MCP 让 Agent 知道怎么用工具，ARD 让 Agent 知道去哪找工具。

没有 MCP，调用不统一。没有 ARD，发现不规模化。

两者配在一起，Agent 才有机会从封闭工具箱走向开放网络。

自动发现工具，也会带来新风险

让 Agent 自己找工具，听起来很美。但问题也马上出现：

它找到的工具可信吗？
发布者是谁？
工具有没有被篡改？
它会访问哪些数据？
它会不会把用户文件传出去？
它是否符合企业的安全和合规要求？

这不是小题大做，Agent 不只是读信息，它还会执行操作。比如读取企业数据、调用支付接口、访问用户文件、连接内部系统。如果发现机制没有验证，Agent 可能会把任务交给一个不可靠的外部服务。所以 ARD 不能只是“工具搜索框”。它还需要信任机制。比如发布者身份、域名归属、签名校验、权限说明、运行状态、安全标签。

一句话：没有验证的发现，只是在规模化地信任陌生人。

对开发者来说，新的分发入口来了

如果 ARD 这类规范继续发展，开发者要适应一个变化：以后你的工具，不只是给人看，也要给 Agent 看。

过去你写 README，是为了让人读懂。未来你可能还要写 ai-catalog.json，让 Agent 读懂。

过去你优化的是人类搜索结果，未来你还要优化 Agent 搜索结果。

这会带来一套新的工程习惯：

为 Agent 描述能力
为 Agent 标注使用场景
为 Agent 提供可验证元数据
为 Agent 说明权限边界
为 Agent 提供稳定入口

谁的工具更容易被 Agent 发现，谁就更可能进入自动化工作流，这可能会变成新的流量入口。

以前是用户搜索产品，以后是 Agent 搜索能力。

对普通用户来说，体验会更简单

普通用户感受到的变化，会更直接，以后你可能不需要知道某个工具叫什么。你只要说：

“帮我找一个能处理 PDF 表格的工具。”
“帮我找一个能生成教学动画的工具。”
“帮我找一个能从网页提取结构化数据的工具。”
“帮我找一个能把播客转成文章的 Agent。”

Agent 自己去搜索、筛选、验证、连接。今天很多 AI 应用还是固定功能软件。能写文案、能画图、能总结文档、能查资料，未来的 AI Agent 更像一个动态能力入口。它真正厉害的地方，不是预装了多少工具，而是知道什么时候该找什么工具。

为什么这件事值得关注？

很多 Agent Demo 看起来很强，但真正落地时，经常卡在这些地方：

工具要提前配置。
任务一变就要重新接入
工具多了，模型选不准
工具描述太长，占上下文
企业权限和安全不好管
不同生态之间互不相通

ARD 想解决的，是 Agent 生态怎么规模化的问题。当工具、技能、MCP Server、其他 Agent 都能用标准方式发布和发现，Agent 才可能进入“按需组装能力”的阶段。

这有点像网页从孤立页面走向搜索引擎。也有点像移动应用从单个 App 走向应用商店。只不过这一次，搜索者不是人，是 Agent。

结语

过去，我们关心模型能不能回答问题。后来，我们关心 Agent 能不能调用工具。接下来，一个更重要的问题会出现：Agent 能不能自己找到正确的工具？

ARD 的价值就在这里，它让 Agent 不再困在固定工具箱里，而是进入一个可搜索、可验证、可连接的能力网络。

短期看，它是一套技术规范。中期看，它会影响工具、Skill、MCP Server 的分发方式。长期看，它可能成为 Agent 互联网的一层底座。

未来真正强大的 Agent，不一定是预装最多工具的 Agent。而是最会发现、判断和调用外部能力的 Agent。