我先联网核实这个 “智能体命名服务” 开放标准到底叫什么名字、哪个基金会下的哪条工作线负责，以及它想解决什么问题。
我找到了关键节点：11 月 10 日，Linux 基金会正式宣布接纳 Agent Name Service（ANS）。接下来，我要把公告全文和标准的技术细节读全。
核对完了：11 月 10 日盐湖城 KubeCon 上，Linux 基金会宣布 ANS 正式成为该基金会项目，这跟 6 月那次 “宣布意向启动” 是两件事。规格由 7 份文档组成，ANS v2 草案的技术细节也能互相对上。以下是第 16 篇。
2026 年 11 月 10 日，在盐湖城 KubeCon + CloudNativeCon North America 上，Linux 基金会宣布 Agent Name Service（ANS，智能体命名服务）正式成为基金会项目—— 注意，这不是 6 月 23 日那次 “宣布有意启动”，那次只是意向，这次是规格定稿、由项目技术指导委员会接管治理。ANS 的核心是一套建在 DNS 和网站已经在用的证书体系之上的命名与验证规则：每个智能体拿到一个 ans://v{版本号}.{域名} 形式的地址，域名是它的永久住址，版本号随每次软件变更而变；注册机构（RA）用 ACME 协议验证域名所有权，然后签发两张证书 —— 公网 CA 的 Server Certificate 绑定稳定域名，私有 CA 的 Identity Certificate 绑定这个版本化的 ANSName；每一次生命周期事件都被封存进只追加、不可篡改的 Transparency Log。完整规格由 7 份文档组成，分别覆盖域名锚定命名、注册与版本管理、DNS 发布、公开日志审计、完整性监控、智能体间互认证。目前有 11 家组织参与贡献或采用：Cisco、Cloudflare、DigiCert、DistributedApps.ai、GoDaddy、HOL、Infoblox、Radix、Salesforce、OWASP、Trustmodel.ai；早期落地已经出现两个 ——AGNTCY 的 Agent Directory Service 支持验证 ANS 身份，ANS Finder 实现 Agentic Resource Discovery（ARD）规范并通过了注册表一致性测试。
先把时间线摆清楚：6 月和 11 月不是同一件事
这条消息很容易被读成 “6 月就发布了，11 月又发一遍”。实际是两台阶：
| 时间 | 事件 | 性质 |
|---|---|---|
| 2026-05-27 | Linux 基金会接纳 DNS-AID 项目（Infoblox 贡献），用 DNS 记录做智能体发现 | 邻居项目，解决 “在哪连” |
| 2026-06-23 | Linux 基金会宣布有意启动 ANS | 意向阶段，规格未定稿 |
| 2026-11-10 | Linux 基金会正式接纳 ANS 为基金会项目，规格定稿，技术指导委员会接管 | 落地阶段 |
Linux Foundation6 月那版公告里，ANS 还只是一个 “框架描述”；到 11 月，它变成了 7 份可执行的技术文档，并且有了两个跑起来的实现。Linux 基金会 CEO Jim Zemlin 的表态也很直白：“自主 AI 智能体已经在全球系统里交易和运行，但没有可验证的身份，它们无法成功。”
一个 ans:// 地址，拆成三段
ANS 最直观的产物就是这套命名格式。它把 “哪个域名下的哪个智能体、哪个版本” 压缩进一个字符串：
ANSName = "ans://v" version "." agentHost
version = 1DIGIT "." 1DIGIT "." 1DIGIT
agentHost =
| 组成 | 示例 | 约束 |
|---|---|---|
| 协议 | ans | 固定，永远是 ans |
| 版本 | 1.0.0 | 语义化版本，纯数字 major.minor.patch；v 是语法里的字面前缀，不算版本内容 |
| 主机名 | sentiment-analyzer.example.com | 符合 RFC 1035 / RFC 1123 的 FQDN，不超过 237 字节 |
完整示例：ans://v1.0.0.sentiment-analyzer.example.com。整串不超过 400 字节，留出 HTTP 头、TLS 字段和数据库列的传输余量。为什么要卡 237 字节？因为 RA 要在主机名前面拼标签去生成 DNS 记录名，最长的是 _acme-challenge.{agentHost}，占掉 17 字节，253 减去 16 就是 237。
关键设计在于：域名不变，版本会变。 一个智能体从 1.0.0 升到 1.1.0，域名和 Server Certificate 保持不变，ANSName 重新生成一次。这样做的目的是让 “声誉” 能累积在域名上，而不是每次升级都清零重来。TL 事件里的 supersedes 字段负责把版本链条串起来。
配套的 DNS 侧还有一条 _ans TXT 记录，相当于 “连接提示”，告诉调用方这个智能体支持什么协议、元数据在哪：
_ans.{agentHost} IN TXT
"v=ans1; version=v1.0.0; p=a2a;
url=https://agent.example.com/.well-known/agent-card.json"
其中 p 可以是 a2a、mcp、http，不填表示任意协议；mode=direct 表示直接连主机，有 url 就去取，两者都没有就回退到 /.well-known/agent-card.json。
双证书加透明日志：这套身份为什么 “可验证”
这是 ANS 和 “自己建个注册表发个 ID” 最本质的区别。它用了两套信任根、两条吊销路径：
| 证书 | 签发方 | 绑定对象 | 吊销路径 |
|---|---|---|---|
| Server Certificate | 公网 CA | 稳定的 FQDN（TLS 端点） | 公网 OCSP / CRL |
| Identity Certificate | 私有 CA | 版本化的 ANSName（带 ans:// 的 URI SAN） | RA 通过 TL 事件吊销 |
为什么非得两张？因为 ans:// 这个 URI 方案，公网 CA 按规范是签不出来的，只有私有 CA 能在自己的签发策略下把它放进 SAN。所以 “网站那套证书” 负责证明域名归你，“私有 CA 那套证书” 负责证明这个版本的智能体归你。
注册流程是六步，第三步是 “不可逆点”：
- 托管平台（AHP）提交注册请求
- RA 用 ACME 验证域名控制权（DNS-01 或 HTTP-01）
- RA 取得 Server Certificate 和 Identity Certificate
- RA 把事件封进 Transparency Log—— 这一点之后不可撤回
- RA 把证书和 DNS 记录内容返给托管平台
- 托管平台去配置 DNS
IETF透明日志本身是一个只追加的密码学结构，对齐 IETF SCITT 架构，能出两类证明：包含证明（证明某条事件确实在日志里）和一致性证明（证明日志只增未改）。每次事件有单调递增的序号，KMS 给每个检查点签名，验证方拿到 /root-keys 就能离线验证，不需要回头找 RA。
验证强度还分了三档，让调用方按交易风险自选：
| 档位 | 依赖 | 适用场景（按草案设计意图） |
|---|---|---|
| Bronze | 仅 PKI | 低风险交互，能确认证书链即可 |
| Silver | PKI + DANE | 中等风险，加了 DNS 侧的证书绑定 |
| Gold | PKI + DANE + 透明日志 | 高风险交易，要求可审计的历史记录 |
IETF为什么不干脆建一个中心化注册表
这是 ANS 在设计上最值得说的一点。它没有新建一套查询网络，而是把身份锚在 DNS 上，把发现交给市场。RA 只负责验证、签证书、封存事件；索引和搜索由独立的 Discovery Service 去做，任何 DNS 服务商、搜索引擎、市场平台都可以自己开一个。这套分离带来两个后果：
| 维度 | 中心化注册表 | ANS 的 DNS 锚定方案 |
|---|---|---|
| 控制权 | 一家公司说了算 | 谁拥有域名，谁控制自己的身份 |
| 故障面 | 注册表挂了全挂 | DNS 是全球分布式，单点故障影响有限 |
| 迁移成本 | 换平台等于换身份 | 换托管平台，域名不动，身份连续 |
| 审计 | 依赖运营方自证 | 透明日志可独立验证，含一致性与包含证明 |
| 生态门槛 | 需接入某家 API | 任何解析器、注册商都能参与 |
Linux 基金会援引的数据是，DNS 每秒处理超过 1 亿次查询 —— 这是现成的、全球已部署的信任基础设施，不需要从零建。
它和 MCP、A2A、DNS-AID、AGNTCY 是什么关系
这四个名字经常被混着说，其实各自解决的是不同层的问题：
| 项目 | 解决的问题 | 归属与状态 |
|---|---|---|
| MCP | 智能体怎么连工具和数据源 | Anthropic 发起，2025-12 捐给 LF 的 Agentic AI Foundation（AAIF） |
| A2A | 智能体之间怎么通信、协商、委派任务 | Google 2025-04 发起，2026-06 转入 LF；1.0 稳定版，150+ 组织支持，已集成进 Azure AI Foundry、Copilot Studio、AWS Bedrock AgentCore |
| DNS-AID | 智能体的服务端点在 DNS 里怎么发布 | Infoblox 贡献，2026-05-27 由 LF 接纳，用 SVCB/HTTPS 记录 |
| AGNTCY | 多智能体的目录、身份、消息、可观测性一整套基础设施 | Cisco 贡献，2025-07-29 由 LF 接纳，65+ 公司 |
| ANS | 这个智能体是谁、代表谁、哪个版本、有没有被改过 | 2026-11-10 正式成为 LF 项目 |
Linux Foundation一句话概括：MCP 和 A2A 定义 “怎么说话”，ANS 定义 “你是谁、能不能信”。 这两个通信协议都明确把 “身份” 问题留在了门外 —— 这正是 ANS 要补的位。而 DNS-AID 解决的是 “在哪连”，和 ANS 是上下游关系，GoDaddy 在 DNS-AID 的公告里就直接点明：DNS-AID 给发现提供 DNS 层协议，ANS 再加一层验证与识别，两者可以叠加在应用层之上。
11 家支持方，和两个已经跑起来的实现
支持名单里几家公司的表态，其实把各自的角色划得很清楚：
| 参与方 | 角色定位 |
|---|---|
| Cloudflare | DNS 与网络安全基础设施，强调 “先知道智能体代表谁，再决定是否信任它行动” |
| DigiCert | 公共 CA，把 ANS 比作 “AI 智能体的护照”，落点在证书体系 |
| Infoblox | DNS 与威胁情报，把域名看作智能体与 MCP 服务器的全球命名与发现层 |
| GoDaddy | 域名注册商，强调 “任何组织用自己已有的域名标识智能体，没有专有命名空间、没有守门人” |
| Radix | 顶级域名注册机构，强调域名与 DNS 是 “最开放、最自主” 的身份载体 |
| Salesforce | 企业平台，Agent Fabric 对齐 ANS 做治理与可追溯 |
| Cisco | 把 ANS 接入 AGNTCY 目录，让 “可验证” 和 “可发现” 合在一处 |
| DistributedApps.ai | ANS 初始开发者 Ken Huang 所在公司，他将进入技术指导委员会 |
| HOL、OWASP、Trustmodel.ai | 分别涉及跨生态发现、安全研究、信任评分（TrustScores 锚定 ANS 身份） |
PR Newswire两个早期落地值得单独看：AGNTCY 的 Agent Directory Service 支持 ANS 身份验证，意味着 “能查到” 和 “能验真” 开始合流；ANS Finder 通过 ARD 注册表一致性测试，说明这套身份可以被第三方发现机制接入，而不是只能在自己家里用。
还没解决的四件事
- 域名被劫持就等于身份被劫持。 草案自己写明了这条：如果攻击者控制了 DNS 区、注册商账户、权威 DNS 服务商账户或发布流水线，就能发布恶意的智能体绑定。建议是给注册商和 DNS 账户加强认证与操作管控，DNSSEC 可以用但不是强制。
- 透明日志的签名密钥是新的单点。 草案明确写了：KMS 密钥一旦泄露，日志里每一条封存记录都变得不可信。缓解手段是密钥与日志主机分离、检查点锚定到公共分布式账本。
- 采用度还在早期。 ANS 目前是 11 家组织，对比 A2A 在一年内做到 150+ 组织、22000+ GitHub stars、5 种语言 SDK，量级差得不小。标准能不能活，最终看有多少解析器真的去实现。
- IETF 侧还有十几个同类草案在竞争。 有提案主张彻底去中心化、反对任何全球索引；也有把身份直接做成 /.well-known/ 文档的。ANS 走的是 “DNS 锚定 + 注册机构 + 透明日志” 这条中间路线，能不能收敛成共识，现在没有答案。
相关 FAQ
问题 1：Linux 基金会推出的智能体命名服务 ANS，本质上解决什么问题？
回答 1：ANS 解决的是 “这个 AI 智能体到底是谁” 的问题。MCP 和 A2A 这类协议定义了智能体怎么连工具、怎么互相通信，但都明确把身份问题留在门外。ANS 智能体命名服务给每个智能体一个 ans://v{版本}.{域名} 的地址，用 ACME 验证域名所有权，用双证书绑定域名和版本，用透明日志记录每一次变更，从而让调用方能够验证 “它代表哪个组织、有什么权限、代码和历史有没有被改过”。
问题 2：ANS 的 ans:// 地址格式是怎么构成的，为什么版本会变而域名不变？
回答 2：ANS 地址（ANSName）由三段组成：固定的 ans 协议前缀、语义化版本号（纯数字 major.minor.patch）、以及符合 RFC 1035/1123 的 FQDN 主机名，例如 ans://v1.0.0.sentiment-analyzer.example.com。主机名限制在 237 字节内，整体不超过 400 字节。域名保持不变、版本每次软件变更就重置，是为了让声誉累积在域名上 —— 智能体从 1.0.0 升到 1.1.0 时，域名和 Server Certificate 不变，只换新的 Identity Certificate 和新的 ANS 注册记录，历史通过 supersedes 字段串起来。
问题 3：智能体命名服务 ANS 为什么要用双证书，一张不够吗？
回答 3：一张不够，因为要证的是两件不同的事。公网 CA 签发的 Server Certificate 绑定的是稳定的 FQDN，证明 “这个 TLS 端点属于这个域名”；私有 CA 签发的 Identity Certificate 绑定的是版本化的 ANSName，证明 “这个版本的智能体属于这个注册主体”。关键在于 ans:// 这个 URI 方案公网 CA 按规范签不出来，只有私有 CA 能在自己的签发策略下放进 URI SAN。两条证书还对应两条独立的吊销路径：公网走 OCSP/CRL，私有侧通过透明日志事件吊销。
问题 4：智能体命名服务 ANS 的透明日志起什么作用，和普通数据库记录有什么区别？
回答 4：区别在 “不可改” 和 “可独立验证”。ANS 的透明日志是只追加的密码学结构，对齐 IETF SCITT 架构，能出包含证明（某条事件确实在日志里）和一致性证明（日志只增未改），每条事件有单调递增序号，KMS 给检查点签名。普通数据库记录由运营方自己维护，改了你也不知道；透明日志让第三方拿着 /root-keys 就能离线验证，不需要信任 RA 的自证。这也是 ANS 把验证分成 Bronze、Silver、Gold 三档时，Gold 档要求叠加透明日志的原因。
问题 5：智能体命名服务 ANS 和 MCP、A2A 是替代关系还是互补关系？
回答 5：是互补，不是替代。MCP 管智能体连工具和数据源，A2A 管智能体之间的通信、协商与任务委派，两者都在 Linux 基金会的 Agentic AI Foundation 治理下；ANS 智能体命名服务管的是身份、验证与发现，回答 “你是谁、代表谁、哪个版本、有没有被改过”。GoDaddy 在 DNS-AID 公告里的表述最清楚：DNS-AID 给发现提供 DNS 层协议，ANS 再加一层验证与识别，两者都能和应用层叠加。实际用法是：用 ANS 确认身份，用 DNS-AID 找到端点，用 A2A 或 MCP 完成通信。
参考资料
- [2026-11-10]（Linux Foundation Welcomes Agent Name Service to Bring Verifiable Identity and Discovery to AI Agents）PR Newswire
- [2026-06-23]（Linux Foundation Announces Intent to Launch Agent Name Service to Establish Trusted Identity Infrastructure for AI Agents）The Linux Foundation
- [2026-05-27]（Linux Foundation Announces DNS-AID Project to Advance Decentralized AI Agent Discovery）The Linux Foundation
- [2026-04-21]（Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity）IETF Internet-Draft
- [2026-04-09]（A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year）The Linux Foundation
- [2025-07-29]（Linux Foundation Welcomes the AGNTCY Project to Standardize Open Multi-Agent System Infrastructure and Break Down AI Agent Silos）The Linux Foundation
- [2025-05]（Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability）arXiv
免责声明
本文基于 Linux 基金会官方公告、PR Newswire 新闻稿与 IETF 互联网草案整理，仅作标准解读与产业信息梳理，不构成技术选型建议、合规意见或对标准最终形态的预判。ANS 的技术细节以项目技术指导委员会发布的正式规格文档为准，IETF 草案属于进行中的工作，尚未成为 RFC，字段、流程与验证档位均可能随版本调整。文中 ans:// 格式、双证书模型、三级验证、透明日志机制均引自 ANS v2 草案，落地实现可能与草案存在差异。11 家支持组织的名单与角色描述来自 2026 年 11 月 10 日公告，后续成员可能变化。任何组织在采用该标准前，应自行评估域名与 DNS 账户安全、私有 CA 运维能力及透明日志可用性带来的实际风险。