Agent Name ServiceAI 代理的通用身份系统当 AI 代理开始互相通信第一个问题永远是你是谁我凭什么信你Agent Name ServiceANS给出了一个和 DNS 一样优雅的答案。一个正在到来的世界2026 年AI 代理已经不只是帮你写代码的工具了。它们开始互相调用、协作、谈判。你的开发代理调用安全代理做代码审计。安全代理调用数据分析代理查日志。数据分析代理调用另一个团队的报表代理要数据。这听起来很美好。但在这一切发生之前有一个根本问题必须先解决——身份和信任。当代理 A 想调用代理 B 时它怎么知道 B 存在它怎么知道 B 能做什么它怎么确认 B 真的是 B而不是某个冒充者它怎么知道 B 返回的数据是可信的这些问题在人类的世界里我们靠域名系统DNS、HTTPS 证书、OAuth 来解决。但在 AI 代理的世界里还没有一个通用的基础设施。直到现在。ANS 是什么Agent Name ServiceANS是一个基于 DNS 理念的 AI 代理身份与发现系统。它由 OWASP GenAI 安全项目开发Linux 基金会正在推动其标准化。你可以把它理解为DNS for AI agents。DNS 把example.com解析为一个 IP 地址。ANS 把security-agent.acme.corp解析为一组可信的代理信息——包括它能做什么、通过什么协议通信、用什么密钥验证它的身份。它的核心架构包含几个关键层ANSNameDNS 风格的命名每个代理都有一个结构化的名字和域名一样分层security-agent.security.acmecorp code-review.dev-tools.myorg>PKI 证书加密级别的身份验证ANS 使用公钥基础设施PKI来验证代理身份。每个代理注册时都带有一个证书通信时可以通过加密签名来验证对方是否持有对应的私钥。这和 HTTPS 的工作原理一样——当你访问一个网站时浏览器检查证书是否有效。ANS 中的代理也做同样的事情。Protocol Adapter Layer协议适配层这是 ANS 很巧妙的一个设计。目前 AI 代理的通信协议有好几种A2AAgent-to-AgentGoogle 提出的代理间通信协议MCPModel Context ProtocolAnthropic 的模型上下文协议ACPAgent Communication ProtocolIBM 的代理通信协议它们各自有各自的适用场景但彼此不兼容。ANS 的协议适配层作为一个中间层让不同协议的代理可以互相发现和通信。这意味着一个使用 MCP 的代理可以查到并使用一个使用 A2A 协议的代理——它们不需要改造自己的底层协议ANS 在中间做翻译。JSON Schema结构化的通信格式ANS 定义了标准的 JSON Schema 来描述代理的能力、输入和输出。这使得代理之间的交互是可预测的、可验证的。一个代理注册的完整流程当一个新代理上线时大概是这样注册到 ANS 的1. 代理生成自己的密钥对公钥 私钥 2. 代理向 ANS 注册中心提交注册请求包含 - ANSName如 code-review.dev-tools.myorg - 公钥证书 - 能力描述用 JSON Schema - 支持的通信协议MCP / A2A / ACP - 端点信息 3. ANS 验证请求的合法性 4. 注册成功后其他代理可以通过 ANS 查询到这个代理 其他代理查询时 1. 输入 ANSName → code-review.dev-tools.myorg 2. ANS 返回该代理的证书、能力、协议信息 3. 查询代理使用公钥验证对方身份 4. 建立安全通信通道谁在用ANS 不是纸上谈兵的标准草案。它已经有实际的开源实现——ruvnet/Agent-Name-Service 提供了一个基于 TypeScript 的参考实现包括核心 ANS 服务注册、查询、验证与 Mastra.ai 的集成用于高级威胁建模和安全分析对 A2A、MCP、ACP 协议的支持完整的注册与安全处理示例为什么这件事很重要说几个现实场景场景一企业内部的多代理协作你所在的公司有十几个 AI 代理——代码审查的、安全扫描的、日志分析的、部署监控的。如果没有一个统一的身份系统每个代理都要硬编码其他代理的地址和密钥。代理挂了、迁移了、升级了所有依赖它的代理都要改配置。有 ANS 之后代理只需要知道对方的 ANSName查询、验证、通信一次搞定。场景二跨组织的代理调用你的 CI/CD 流水线在构建完成后需要调用一个第三方提供的安全审计代理做最终检查。这个第三方代理不在你的网络里你没法把它写死在配置里。有 ANS 之后你的 CI 代理查询 ANS 找到这个安全代理验证它的证书发起调用——整个过程不需要人工介入。场景三审计与合规合规审计要求证明每次代码合并前安全审查确实发生了。有 ANS 之后每次代理间的调用都有签名记录——谁调用了谁、什么时候、结果是什么。审计追踪是基础设施的一部分不是事后追加的。挑战ANS 要真正普及还有一些挑战需要克服标准化进度虽然在 Linux 基金会和 IETF 的推动下规范草案已经发布draft-narajala-ans-00但距离成为广泛采纳的标准还需要时间隐私一个公开的代理注册中心天然会暴露你的组织有哪些代理在运行这个信息。如何平衡可见性和安全性需要仔细设计证书管理PKI 是好方案但证书的颁发、轮换、撤销本身就是一个复杂的基础设施问题写在最后DNS 的发明让互联网从一个实验性的网络变成了全球基础设施。在它之前你要访问其他计算机只能靠 hosts 文件手动管理 IP 地址。在它之后一切都是自动的、分层的、可扩展的。AI 代理的生态正在经历同样的阶段。现在大多数代理之间的通信还靠手动配置和信任假设。ANS 要做的事情就是成为那个DNS 时刻。当有一天你只需要一句话就能让你的 AI 代理发现另一个代理、验证它的身份、建立安全通信——那时你会意识到身份系统这件事从一开始就不该被当作可有可无的东西。本文基于 Open Source Watch 发布的文章 “Agent Name Service: The universal AI agents identity system” 及相关技术资料整理。Sources:Agent Name Service: The universal AI agents identity system - Open Source WatchAgent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery - IETFAgent Name Service (ANS) - GitHubAgent Name Service (ANS) for Secure AI Agent Discovery - OWASP