Agent 怎么找到一个没接过的工具？动态发现完整拆解

01. Agent 怎么找到一个没人提前接好的工具

上一期我们说，智能体找到新工具，不等于企业已经批准它。但评论区还有一个更基础的问题：这个工具到底是怎么被找到的？这期就把动态能力发现拆开。它不是让模型随便上网搜接口，而是把工具清单变成一套可以发布、索引和搜索的基础设施。

02. 不是自己猜网址，也不是读完所有工具

先排除两个误解。动态发现不是让模型自己猜服务地址，也不是把几千份工具说明全部塞进上下文，再让模型慢慢挑。前者不可靠，后者会挤占上下文，还会让工具选择越来越混乱。真正的做法，是把大范围检索交给模型外面的搜索服务。

03. 过去是固定清单，现在是外部索引

过去，工程师先选好工具、写好配置，再把固定清单交给智能体。新增一个服务，通常要重新接入甚至重新发布客户端。动态发现把清单移到外部目录：能力提供方可以独立更新，客户端在构建时或运行时按任务搜索，不必事先知道每个服务的名字。

04. 沿着一次预览部署看完整过程

还是用一个具体任务。代码智能体完成了网页，需要部署一个临时预览站点，但它当前没有部署工具。它不会直接搜索整个互联网，而是向企业允许的发现服务提问：我需要一个临时预览能力，能够接收构建产物，并在指定时间后回收资源。接下来每一步，都围绕这句话展开。

05. 动态发现其实有三类参与者

这套系统里有三类参与者。左边是能力提供方，负责发布机器可读目录；中间是发现服务，负责收集、索引、搜索和排序；右边是智能体客户端，负责表达任务、读取候选并建立连接。发现规范统一的是中间这座桥，不是把所有执行协议重新发明一遍。

06. 提供方先发布一张机器可读目录

第一步，能力提供方在自己的域名下发布一个标准目录文件。每条记录至少说明：能力叫什么，属于哪种资源，从哪里读取详细描述。它还可以写上能力标签、版本、更新时间，以及几句用户可能怎样提出需求的自然语言例子。后面做语义搜索，主要就靠这些描述和代表查询。

07. 注册表把分散目录变成可搜索索引

第二步，发现服务收集这些目录并建立索引。它可以抓取公开网络，也可以只接企业内部清单、供应商目录或人工审核过的集合。规范不强迫注册表收录什么，也不规定怎样排名。对企业来说，更现实的做法通常不是开放全网搜索，而是只搜索经过治理的候选池。

08. Agent 搜的是任务，不是产品名字

第三步，智能体把用户任务发送给搜索接口。查询主体是自然语言，例如“部署一个六十分钟后自动删除的预览站点”；还可以附加资源类型、能力标签、发布者或版本等过滤条件。搜索服务据此返回少量最相关候选，而不是让模型一次看到整个工具宇宙。

09. 搜索分数只回答像不像，不回答敢不敢用

候选结果通常会带相关性分数，但这只表示它和任务描述有多匹配。一个恶意工具也可能把描述写得非常像需求。因此，相关性分数绝不能被当成安全、合规或可信度评分。搜索负责缩小范围，信任核对和业务批准仍是后续独立步骤。

10. 连接以前先核对它从哪里来

客户端接下来核对候选记录里的来源材料：发布者域名是否一致，身份声明能否验证，目录在传输中有没有被篡改，以及是否提供来源链或合规证明。这一步只是在确认“记录是不是来自它声称的发布者”。当前任务是否获准使用它，仍然要交给企业自己的准入策略。

11. 发现层交出地址，原生协议负责执行

核对完成后，发现层的任务基本结束。它交给客户端两样关键东西：资源类型和详细描述地址。客户端据此判断下一步应该说哪种协议。它可能读取一个工具服务器描述，也可能读取远端智能体的能力名片，或者读取传统接口文档。发现层负责带路，原生协议负责真正交流。

12. MCP、A2A 和 API 分别接过下一棒

如果候选是工具服务器，客户端连接后可以列出该服务器当前暴露的工具并调用；如果候选是远端智能体，能力名片会说明它的技能、输入输出、认证方式和服务地址，再由智能体间协议交接任务；如果是传统接口，就按接口描述调用。动态发现没有取代这些协议，而是把它们接到同一个搜索入口。

13. 为什么 MCP 的工具列表还不够

这里有个关键区别。工具列表解决的是：我已经连接到这台服务器，它里面现在有哪些工具。动态发现解决的是：面对许多服务器、智能体和接口，我一开始应该连接哪一个。前者像进店以后看菜单，后者像在地图上先找到哪家店适合当前任务，两层不能混为一谈。

14. 能力更新后，不必重新发布客户端

因为目录和索引在客户端外部，提供方可以新增能力、更新版本或标记弃用，发现服务在下一次摄取后更新结果。能力名片还可以使用缓存时长和内容标签，避免每次完整下载。这里没有魔法：这项发现规范目前仍是草案，刷新速度取决于注册表实现，刚发布的能力也不保证立刻被所有服务收录。

15. 一次动态发现应该怎样走完整流程

现在把预览部署重新走一遍：提供方发布目录，企业发现服务建立索引；智能体提交任务意图，搜索服务返回少量候选；客户端核对来源，只加载选中能力的详细说明；最后才通过它原生的协议建立连接。完整路径是发布、索引、搜索、候选、验证、连接，而不是模型临场猜一个接口。

16. 工具清单正在变成搜索索引

这期最值得记住的一句是：动态发现不是让模型记住更多工具，而是把固定工具清单变成外部搜索索引。智能体只在需要时取得少量候选，再连接真正相关的能力。它解决“怎么找到”，但不解决“能不能用”；后一个问题，就是能力准入门。

参考资料与延伸阅读

本文事实来源

以下链接于 2026-07-26 核验均返回 HTTP 200。

Google ARD 发布说明

发布方：Google Developers Blog
发布日期：2026-06-17
作者：Junjie Bu、Srinivas Krishnan
原始标题：Announcing the Agentic Resource Discovery specification
原文：https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/

ARD 官方实现文档

How ARD works
https://agenticresourcediscovery.org/how_ard_works/
How to publish
https://agenticresourcediscovery.org/how_to_publish/
How to add ARD support to your agent
https://agenticresourcediscovery.org/how_to_build_a_client/
ARD Specification v0.9 Draft
https://agenticresourcediscovery.org/spec/
Interoperability
https://agenticresourcediscovery.org/interoperability/
FAQ
https://agenticresourcediscovery.org/faq/

A2A Agent Discovery

发布方：A2A Project / Linux Foundation
文档：Agent Discovery in A2A
原文：https://a2a-protocol.org/latest/topics/agent-discovery/

MCP Tools

发布方：Model Context Protocol
规范：Tools / tools/list / notifications/tools/list_changed
原文：https://modelcontextprotocol.io/specification/2025-11-25/server/tools

成熟度与职责边界

ARD 文档标注为 v0.9 Draft / Proposal；不包装成已经稳定落地的统一行业标准。
ARD 统一资源描述与搜索接口，不规定收录范围、排名算法、刷新周期和执行机制。
发布 ai-catalog.json 不保证任何具体发现服务一定抓取或收录。
A2A Agent Card 描述远端智能体；当前 A2A 规范不规定策展注册表的统一查询 API。
MCP tools/list 列出已连接服务器内部的工具，不负责跨服务器或跨组织发现。
搜索相关性不是信任、安全或业务授权结论。