DNS 革命：在去中心化世界中，AI 智能体是如何相互发现的

• 问题空间简介
• 解释为什么智能体发现（Agent Discovery）至关重要
• 讨论不同的实现机制
• 分享关于 DNS-AID 实现的见解
• 关于未来影响的总结

AI 智能体的“通讯录”问题

还记得互联网刚起步时，只有寥寥几台计算机，你必须背下 IP 地址才能访问任何内容吗？后来我们用 DNS（域名系统）解决了这个问题——它将人类可读的域名转换为机器地址。现在，想象我们正面临类似的挑战，但这次不是计算机与 Web 服务器之间的对话，而是 AI 智能体试图在去中心化网络中相互发现并进行交互。

这正是 AI 智能体社区的开发者们正在探索的问题空间，坦率地说，这是近年来我见过的最令人着迷的技术挑战之一。

为什么智能体发现比你想象的更重要

问题在于：随着 AI 智能体变得越来越专业化且数量日益庞大，它们相互发现的能力将成为基础架构。想想看——你的智能体需要将任务委派给另一个智能体；你的智能体想要调用一个它自身并不具备的特定功能；你的系统在与智能体交互前需要验证其真实性。

如果没有发现机制，这一切都无法实现。

令人兴奋的是，目前正在涌现出多种方法，并且它们正以巧妙的方式利用现有的基础设施。

寻找 AI 智能体的三种路径

通过对这一领域的探索，我发现了三种正在兴起的智能体发现主要机制：

AI 资源目录 (ARD) 方案

ARD 作为一种开放规范，用于在联邦网络中描述、发现和搜索智能体资源。其妙处在于它遵循现有的 Web 范式——智能体将自己的能力发布到目录中，而发现过程就变成了查询该目录的过程。

你可以把它想象成智能体的公开个人资料页，上面包含了所有你可以与其交互的方式。

DNS-AID：利用互联网的骨干网

这是最有趣的部分。DNS-AID 利用互联网现有的去中心化命名基础设施来进行智能体发现。它没有重新发明轮子，而是通过 DNS 记录来发布发现信息。

它的强大之处在于 DNS 已被证明的可靠性和全球分布能力。互联网花了数十年时间来完善这一基础设施——为什么不直接使用它呢？

ANS：注册表与透明度

ANS 采取了不同的路径，它充当注册表和透明日志。它为智能体分配唯一的、带版本的名称，并提供验证机制。这对于智能体之间交互时的信任和问责制尤为重要。

DNS-AID 实现深度解析

这里是我发现特别值得讨论的地方。在实现 DNS-AID 时，实际上有两种路径，其中一种比另一种要健壮得多。

初级方案：直接发布 SVCB

这种简单的方法通过 DNS SVCB 记录直接发布智能体端点。当智能体只暴露单个接口时，这种方法运行良好；但问题在于——当一个智能体拥有多个端点（例如同时支持 A2A 和 MCP 协议）时，情况就会变得混乱。

结果是？客户端可能会尝试调用一个根端点并期望某种特定协议，结果却收到了 404 错误。这虽然不至于造成灾难，但确实不够优雅。

优雅的解决方案：智能体卡片指针 (Agent Card Pointers)

更聪明的方法是使用 SVCB 记录指向一个“智能体卡片”，而卡片中包含了所有的端点信息。由于智能体卡片可以描述具有特定路由的多个接口，发现过程会变得更加灵活且准确。

对于任何构建严肃智能体基础设施的人，我都会推荐这种方法。这种额外的间接层在灵活性方面会带来丰厚的回报。

这对开发者和初创公司意味着什么

如果你正在构建或计划构建 AI 智能体应用，那么这个“发现层”是你必须理解的内容。目前关于智能体如何相互发现所做的选择，将塑造未来多年智能体系统的架构。

以下是几点考量：

• 互操作性取决于发现能力——你的智能体生态系统的优劣，取决于它寻找并与其他智能体通信的能力。
• 基于 DNS 的方案具有优势——利用现有基础设施意味着更少的维护成本和更高的可靠性。
• 协议多样性是现实存在的——智能体将使用多种“语言”（A2A、MCP、普通 HTTPS），因此你的发现机制需要考虑到这一点。
• 信任与验证至关重要——随着智能体自主交互，确认你正在与正确的智能体对话变得至关重要。

前沿领域才刚刚开启

这个领域最让我震撼的是，我们仍处于早期阶段。今天正在探索的发现机制将会不断演进、融合，并可能带给我们惊喜。为了探测这些不同机制而构建的“对比引擎”工具，正是我们所需要的基建——让我们能够理解并驾驭这一新兴领域的方法。

对于开发者和初创公司来说，这既是挑战也是机遇。现在理解这些模式，意味着当智能体生态系统趋于成熟时，你将能更好地构建能够参与其中的系统。

游戏才刚刚开始，坦白说，我迫不及待想看到它的发展。