AI agent 从 demo 走向网络化调用的关键一步，做 agent 开发或基础设施的团队值得关注 DNS 这个老基础设施的新用法。
Linux Foundation 旗下的 DNS-AID 项目旨在为 AI agents 构建基于 DNS 的发现机制，类似于互联网的电话簿。通过类似 `_agent._protocol._agents.example.com` 的 DNS 记录，agents 可以找到彼此并获取 MCP、A2A、HTTPS 等连接信息，无需硬编码地址或中心化注册表。这解决了 agent 互发现的基础设施问题，复用现有 DNS 体系，支持 DNSSEC 验证，便于企业纳管。但后续的身份信任、权限控制、责任归属和结算问题仍需解决。
AI Agent 的下一场基础设施战，可能从 DNS 开始。 DNS 在当下互联网里的重要性不言而…
AI Agent 的下一场基础设施战，可能从 DNS 开始。
DNS 在当下互联网里的重要性不言而喻。而未来的 agent-to-agent 网络，也极有可能需要一套类似 DNS 的发现机制：让一个 agent 知道另一个 agent 是谁、在哪里、该怎么安全连接。
The Register 这篇讲了一个挺有意思的项目：Linux Foundation 下面的 DNS-AID。它想给 AI agents 做一个基于 DNS 的“电话簿”。
以后一个 agent 要找另一个 agent，可以查类似：
`_agent._protocol._agents.example.com`
然后拿到 MCP / A2A / HTTPS 等连接信息。
这件事带来的好处：
1. Agent 不用再靠硬编码地址、配置文件、端口探测来找服务。
2. 直接复用 DNS 这套全球基础设施，缓存、解析、运维体系都已经成熟。
3. 每个域名所有者都能发布自己的 agent 信息，减少中心化 registry 被平台卡住的风险。
4. DNSSEC / DANE / JWS 可以帮调用方验证来源，至少知道“这个 agent 信息确实来自这个域名”。
5. 企业更容易纳管，因为 DNS、证书、域名、审计本来就在现有 IT 流程里。
6. 它对协议相对开放，MCP、A2A、HTTPS 都可以被描述进去。
但这只是第一步：你是谁、你在哪里、我该怎么连。
真正麻烦的部分还在后面：能不能信你、给你什么权限、调用出事谁负责、agent-to-agent 交易怎么结算。
我的判断：如果 AI agent 真要从 demo 走向互相调用的网络，发现层大概率会回到域名体系。很多 AI 新东西落地到最后，还是要靠互联网老基础设施兜底。