智能体域名系统2.0一文讲透：智能体怎么“上户口”、怎么被找到、怎么验明正身（原理拆解＋注册实操＋合规清单）

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

2026年9月29日，中国互联网络信息中心（CNNIC）在第七届中国互联网基础资源大会上发布了智能体域名系统2.0。用一句大白话讲：它要给每一个AI智能体发一个全网通用的名字，让别的智能体能按名字找到它，还能验证它是不是冒牌货。

和今年4月的首个版本相比，公开信息里明确新增的东西有四样：带语义标签的中文域名、面向开发者的域名注册API、智能体检索发现服务，以及按地域、行业、企业规模划分的观测视图。

底层思路一点都不玄：复用已经稳定运行几十年的DNS，再叠上数字证书、透明日志、DNSSEC这几样成熟技术，分三档回答“你是谁、你在哪、你靠不靠谱”。

对普通开发者和站长来说，眼下能做的事有三件：把自己的域名和解析权限管好，读懂可信注册的流程，把备案和AI内容标识这些合规动作提前排上日程。

下面这张表是给赶时间的朋友准备的：

想看完整拆解，往下翻。

一、先把问题讲明白：智能体为什么突然需要一个“域名”

1.1 从“一个人干活”到“一群智能体搭伙”

先交代一个词。智能体（AI Agent），指的是那种能自己理解目标、拆分任务、调用工具、最后把事情办完的AI程序。它和聊天机器人最大的区别在于：聊天机器人只负责说，智能体还负责做。

前两年大家玩智能体，基本都是在一个平台里面折腾。你在某个平台上搭一个写周报的助手，它调用的是这个平台给的插件，数据也留在这个平台里。这种玩法有个隐含前提：所有参与方都在同一个屋檐下，平台就是天然的“熟人介绍人”，谁是谁、能干什么、出了事找谁，平台说了算。

今年情况变了。智能体开始走出平台，替不同的公司互相打交道。我举个虚构的例子帮大家找感觉：一家做小家电的工厂，有一个负责采购的智能体。它要买一批冷轧钢板，于是需要去找钢材贸易商的报价智能体询价，找物流公司的调度智能体问运力，再找银行的结算智能体确认账期。四个智能体分属四家公司，用的大模型不一样，开发框架不一样，部署的云也不一样。

这时候麻烦就来了，而且不是模型聪明不聪明的问题，是更基础的问题：采购智能体怎么知道那个报价智能体在哪？怎么确认对面真是那家贸易商派出来的，而不是有人冒名顶替？谈崩了或者被骗了，凭什么追责？

行业里把这种场景叫“跨域互联”。域，可以理解成一个组织自己说了算的地盘。跨域，就是从你的地盘走到别人的地盘。

1.2 没有统一名字，会卡死在三件事上

我自己琢磨下来，跨域这件事会在三个地方卡住，按顺序依次是：找不到、信不过、管不了。

这三件事有一个共同的前提：每个智能体得先有一个全局唯一、别人认得出、还能查得到的名字。没有名字，后面的发现、认证、治理全都无从谈起。

这也不是我一个人的看法。中国信通院的专家在今年9月的一次公开报告里表达过类似的意思，大意是智能体要走向开放互联，绕不开互联、可信、人机可辨这几类问题，而它们的共同基础就是让每个智能体都能被唯一地标识、解析和认证。三部门在5月印发的《智能体规范应用与创新发展实施意见》里，也专门提到要探索建立智能体注册平台，提供数字身份管理、检索发现、能力声明这类服务。

政策、研究机构、基础资源管理机构，三方不约而同指向同一个点。这就是智能体域名系统出现的大背景。

1.3 为什么选域名，而不是另起一套

给智能体起名字，技术路线其实不止一条（第六章我会横向比较）。CNNIC这条路线选的是域名，我觉得道理很朴素：能复用的就别重造。

域名系统（DNS）是互联网的“查号台”。你在浏览器里敲一个网址，背后是DNS把这串好记的名字翻译成机器认识的地址。这套东西有几个特点，恰好是智能体起名最需要的。

它天生全局唯一。同一个域名在全世界只归一个持有者，不会撞名。

它是分层授权的。顶级域管二级域，二级域的主人可以随便往下开子域，谁的地盘谁做主，不需要事事找中心审批。一家公司有一百个智能体，在自己的域名下面开一百个子域就行。

它的基础设施是现成的。全球的解析服务器、缓存、各种编程语言里的解析库，几十年攒下来的家底，智能体拿来就能用，不需要所有人重新装一套新软件。

它的管理制度也是现成的。在国内，域名注册要实名，网站上线要备案，出了问题能顺着注册信息找到人。这一点对“管得住”特别关键。

所以我对这条路线的理解是：网站时代，域名是门牌号；到了智能体时代，域名再多兼一份工，变成智能体的户口本首页。

当然，域名也不是万能的。它擅长解决“叫什么、去哪找”，但“凭什么信你”光靠一个名字是不够的，还得配证书和日志。这部分留到第四章细讲。

1.4 顺手厘清一组容易混的概念

刚接触这个话题的朋友，经常把标识、地址、身份凭证三样东西搅在一起。我用一张名片来打比方：

┌──────────────────────────────────────────────┐
│  标识（名字）    相当于名片上的姓名          │
│                  例：某个智能体的域名        │
├──────────────────────────────────────────────┤
│  地址（端点）    相当于名片上的办公地址      │
│                  例：这个智能体对外服务的URL │
├──────────────────────────────────────────────┤
│  凭证（证明）    相当于随身带的身份证        │
│                  例：权威机构签发的数字证书  │
└──────────────────────────────────────────────┘

名片谁都能印，所以光有名字和地址不够，还得亮身份证。反过来，光有身份证没有名片，别人也不知道该上哪找你。智能体域名系统做的事情，就是把这三样东西通过域名串在一起：名字是域名，地址写在域名的解析记录里，凭证的指纹也挂在域名下面供人核对。

记住这个三件套，后面的内容读起来会顺很多。

二、半年时间线：从首个版本到2.0，中间发生了什么

很多报道只盯着9月29日这一天。但我翻了一圈公开资料之后发现，如果不把前面半年的事情连起来看，很难理解2.0为什么长成现在这个样子。所以这一章我按月份捋一遍。

2.1 四月：域名系统和网关一起亮相

今年4月，在工业和信息化部信息通信管理局的指导下，CNNIC、中国电信、万联易达在北京联合开了一场发布会。按《科技日报》的报道，那场会上同时发布了三样东西。

第一样是智能体互联网域名系统，由互联网域名管理技术国家工程实验室牵头研发，当时对外讲的能力是四项：全网通用标识、跨域服务发现、一致的安全认证，以及行业发展治理。这可以看作是1.0。

第二样是AI智能体网关系统，由中国电信的云网操作系统研发中心研发，负责智能体的编排调度、服务监控、标准化发布和网络能力调用。打个比方，域名系统管“查号”，网关管“接线和通话质量”。

第三样是产业应用成果，由万联易达在自家平台上面向钢铁这类大宗商品交易场景做的试点，让多类智能体跨域互联去做供需匹配。

这三样东西摆在一起，其实已经透露出思路：底层有标识和寻址，中间有网络通道，上面有真实业务场景来验证。

2.2 五月：政策和标准同时落地

5月是个密集的月份。

5月8日，国家网信办、国家发展改革委、工业和信息化部联合印发《智能体规范应用与创新发展实施意见》。这份文件被不少业内人士看作国家层面第一次对智能体做系统性部署。和本文主题直接相关的是“布局发展智能互联网”那一条，里面写到要研究建立智能互联网体系架构，探索建立智能体注册平台，研究智能体身份标识、可信互联、合规支付、安全防护等基础技术，还提到要探索建立智能互联网监测指标体系。原文可以在中国网信网查到：https://www.cac.gov.cn/2026-05/08/c_1779979789523320.htm

5月22日，国家标准化管理委员会发布公告，批准了一批国家标准化指导性技术文件，其中“人工智能 智能体互联”系列（编号 GB/Z 185）一口气覆盖了七个部分：总体架构、身份码、身份管理、智能体描述、智能体发现、智能体交互、智能体工具调用。指导性技术文件不是强制标准，但它给行业画了一张公共的地图。

同样在5月，中国信通院联合多家企业和高校发起了智能体可信握手协议（ATH）1.0，聚焦的是多智能体跨主体、跨平台交互时的身份互验、权限管控和行为审计。

你看，一个月之内，政策说了“要做什么”，标准说了“大致怎么分层”，协议说了“握手时怎么互验”。

2.3 七月到九月：产业侧开始接力

进入下半年，动作从“发布”转向“能用”。

云厂商这边，阿里云帮助中心上线了一套叫 Agent 可信服务（ATS）的产品文档，文档里写明这是阿里云与CNNIC联合共建的AI Agent可信基础设施服务，基于成熟的PKI证书体系和DNS基础设施，提供可信注册、证书签发、DNS锚定、透明日志封存和可信发现。我写这篇文章时看到的文档版本，最近一次更新是在9月初。第五章的实操部分，我主要就是对照这套公开文档来梳理的。

运营商这边，7月的中国互联网大会上有专门的智能体安全论坛，中国电信发布了面向智能体的安全产品体系，思路是从资产发现、上线前体检、运行时防护到事后追溯全链路覆盖。

研究机构这边，9月16日，中国信通院等单位组织了“智能体标识与身份网络暨智能体可信互联中心（北京）”试运行启动会。这条线走的是去中心化标识符（DID）的技术路线，和域名路线并行推进。

2.4 九月二十九日：2.0登场

铺垫了这么多，终于到正题。

9月29日，2026（第七届）中国互联网基础资源大会在北京召开，主办方是CNNIC，联合了中国互联网协会和中国科学院计算机网络信息中心。智能体域名系统2.0是在大会的智能体标识与安全论坛上发布的。

官方发布信息里对2.0的描述，我归纳成三层意思：架构上强调高扩展性，核心是让域名充当枢纽，把多种标识融合起来；功能上新增了语义标签中文域名、注册API、检索发现和观测视图；定位上明确它依托身份标识和解析服务这些底层能力，去支撑智能体可信基础设施（ATI）的建设，提供可信身份认证。

产业落地方面，环球网的报道给了一个具体的数字：万联易达的产业智能体互联网里，有9家制造业领域的代表性企业，其经纪人智能体拿到了“智域.中国”智能体域名身份，成为首批通过相关指南评估的企业级智能体。至于这份指南具体评哪些项，公开信息没有展开，我这里也不乱猜。

把上面的事件排成一张表，脉络就清楚了：

2.5 我从这条时间线里读出来的东西

莫潇羽@无忆研习社 在这里说点个人观察，不一定对，供参考。

这半年的节奏很有章法：先放出一个能跑的技术原型，再由政策明确方向，标准跟上画框架，产业侧提供可操作的入口，最后底座再升一级。五个月从1.0到2.0，速度不算慢。

另一个感受是，2.0新增的几样东西，几乎每一样都能在5月那份实施意见里找到对应的句子。注册API对应“注册平台”，检索发现对应“检索发现、能力声明”，观测视图对应“监测指标体系”。所以与其说2.0是一次产品迭代，不如说它是在把政策里的“探索”一条一条变成可以调用的功能。

看懂了这一点，下一章拆功能的时候就不会觉得零散。

三、拆开看2.0：这次到底多了什么

先说明一下边界。截至我写稿的时候，CNNIC对2.0公开的是功能层面的描述，完整的技术白皮书和接口文档我没有查到公开版本。所以这一章里，凡是“官方说了什么”我会直接讲，凡是“我怎么理解”我会明确标出来，大家别把我的推测当成官方口径。

3.1 一个总思路：让域名当“总线”

官方对2.0架构的概括里，有一个关键提法是多标识融合，并且是以域名作为枢纽。

这话听着抽象，我换个角度讲。现实里一个智能体身上往往已经挂着好几种编号：在开发平台里有一个平台内ID，在企业内部有一个资产编号，如果它申请了证书就有证书序列号，如果走了去中心化标识那条路还有一个DID，按国家指导性技术文件的框架还可能有一个身份码。这些编号各有各的用处，但彼此不认识。

我的理解是，2.0并不打算把别的标识都干掉，而是让域名站到中间当“总线”：你手里有哪种标识都行，最后都能挂到一个域名上；别人只要知道这个域名，就能顺藤摸瓜查到其余的标识和凭证。

        平台内ID      证书标识      DID      身份码
            \            |          |         /
             \           |          |        /
              ▼          ▼          ▼       ▼
          ┌────────────────────────────────────┐
          │      域名（全网通用的那个名字）     │
          └────────────────────────────────────┘
              |              |              |
              ▼              ▼              ▼
          服务发现        安全认证       观测治理

这样设计的好处是兼容。不同行业、不同平台已经投入建设的标识体系不用推倒重来，接上总线就行。官方强调的“高扩展性”，我猜也有这层意思：以后再冒出新的标识类型，继续往上挂。

3.2 语义标签中文域名：让名字自己会说话

这是2.0里我个人最感兴趣的一项。

所谓语义标签，就是域名的各级标签本身带有含义，人和机器读到名字就能大致猜到这个智能体是谁家的、干什么的。再叠加中文，对国内用户就更直观了。公开报道里提到的“智域.中国”就是一个中文域名，从字面看，首批企业智能体的名字很可能是挂在它下面的某一级。具体的命名规则，比如哪一级放企业名、哪一级放行业或功能，目前没有公开细则，以CNNIC后续发布为准。

可能有朋友会问：中文域名在技术上到底怎么跑的？DNS底层只认英文字母、数字和连字符啊。

答案是转码。国际化域名（IDN）有一套叫 Punycode 的编码规则，能把中文标签转成以 xn-- 开头的一串ASCII字符，DNS实际查询的是转码后的结果，展示给人看的时候再转回中文。我在本地终端里用Python自带的编码器试了一下：

names = ["智域.中国", "示例智能体.智域.中国"]
for n in names:
    print(n, "->", n.encode("idna").decode())

跑出来的结果是这样的：

智域.中国 -> xn--cjst35a.xn--fiqs8s
示例智能体.智域.中国 -> xn--tqq1ev74eser61i.xn--cjst35a.xn--fiqs8s

其中 xn--fiqs8s 就是“.中国”这个顶级域在DNS里的真实面目。“示例智能体”是我随手编的名字，只是为了演示多一级标签时长什么样，不代表真有这个域名。

语义化的名字对大模型尤其友好。智能体做任务规划的时候，面对一串候选服务，读到一个带含义的中文名字，比读到一串随机字符更容易判断该不该调用它。

不过我要泼一点冷水：名字好懂，不等于名字可信。任何人都可能起一个听上去很正规的名字。所以语义标签解决的是可读性，信任还得靠第四章讲的证书和日志。千万别因为名字里带着某个大品牌的字样就默认它是真的。

另外提醒一句，.中国 域名本身有一些既有的注册规则，比如主流注册商页面上写明单个标签的长度上限是二十个汉字，注册后需要在规定期限内完成实名认证才能正常使用。智能体域名建立在这套体系之上，实名这道关大概率是绕不开的，这其实是好事。

3.3 注册API：从“人工办证”到“程序办证”

官方信息提到，2.0提供智能体域名注册API接口。

这一项的意义要放到数量级里看。网站时代，一家公司的域名也就几个到几十个，人工去注册商后台点一点完全应付得来。智能体不一样，一家中等规模的企业，各部门各业务线加起来可能就有成百上千个智能体，而且新增、下线、换版本非常频繁。靠人工逐个填表，根本跟不上。

有了API，智能体的“上户口”就能嵌进研发流程：代码合并，测试通过，流水线自动调用接口去申请域名、绑定身份，然后才上线。

为了帮新手理解，我写一段伪代码示意这个过程。注意，这只是帮助理解的示意，接口名和字段都是我虚构的，不是真实接口，真实的调用方式请等官方文档：

// 伪代码，仅作理解用，非真实接口
请求：为智能体申请域名
  申请主体   = 已完成实名的企业
  期望名称   = "采购助手"
  语义标签   = { 行业: "家电制造", 功能: "采购询价" }
  服务端点   = "https://agent.example.cn/a2a"
  支持协议   = ["A2A", "MCP"]

返回：
  域名       = 分配或确认后的智能体域名
  状态       = 待审核 / 已生效
  后续动作   = 需要添加的解析记录清单

这里有个细节值得留意。我对照的那份云厂商可信注册文档里明确写着，Agent注册目前必须通过控制台完成，不支持通过SDK或API实时注册。而CNNIC这边2.0宣布的是提供注册API。两者说的不是同一个系统的同一个环节，一个是产业侧的可信服务入口，一个是底层域名系统的能力，开放节奏不同很正常。但这也提醒我们：程序化注册这件事还在逐步放开的过程中，实际能用到什么程度，一定以各家当期的官方文档为准，别想当然。

3.4 检索发现：既能“按名查”，也能“按需找”

发现这个词，在智能体语境里有两种含义，新手很容易混。

一种是我已经知道对方的名字，想查它的详细信息，比如入口地址、支持什么协议、凭证指纹是多少。这本质上是解析，DNS最拿手，相当于打查号台报名字问电话。

另一种是我不知道该找谁，只知道我需要一个“能报冷轧钢板价格的智能体”。这是检索，相当于翻黄页，按行业和业务找商家。

1.0阶段对外讲的主要是跨域服务发现，偏向前一种。2.0明确把检索和发现并列提出来，我的理解是后一种能力补齐了。前面讲的语义标签在这里正好派上用场：标签越规范，按条件筛选就越准。

对应到产业侧，我看到的可信注册文档里有一个类似“广场”的功能，可以按关键词和通信协议浏览已经注册的可信智能体。这大概就是检索发现在应用层的样子。

3.5 观测视图：给行业装一块仪表盘

2.0还围绕地域、行业、企业规模等维度构建了智能体观测视图，官方的说法是为行业发展分析提供数据支撑。

这项功能普通开发者平时用不上，但它对整个生态的意义不小。域名注册数据天然带有主体信息，把这些数据按维度聚合起来，就能回答一些过去没人说得清的问题：哪些地区的智能体多，哪些行业跑得快，中小企业和大型企业的参与程度各是多少。

CNNIC做这件事算是老本行。大家熟悉的《中国互联网络发展状况统计报告》就是它长期在做的。把同样的统计思路搬到智能体上，顺理成章。而且前面说过，5月的实施意见里专门提到要探索建立智能互联网监测指标体系，观测视图可以看作这句话的一个落点。

我个人挺期待以后能看到公开的智能体发展统计数据，那会比各家咨询机构的估算靠谱得多。

3.6 支撑可信基础设施：从“有名字”走向“可验证”

最后一项不是新功能，而是定位。官方明确说，2.0依托智能体身份标识和解析服务这些底层能力，支撑智能体可信基础设施（ATI）的建设，为智能体提供可信身份认证服务。

ATI 这个缩写后面会反复出现，我先用一句话解释：它是一整套让智能体身份可以被验证的设施，包括签发证书的机构、记录操作的日志、存放指纹的解析记录等等。域名系统在里面扮演的是地基，所有的凭证最后都要锚定到域名上。

3.7 一张表对比两个版本

根据两次发布的公开报道，我整理了一张对比表。表里只写公开信息里有据可查的内容，查不到的我就标“未见公开说明”：

一句话总结这一章：1.0证明了“用域名给智能体起名”这条路走得通，2.0则是把名字变得更好读、申请变得可编程、查找变得更灵活、全局变得看得见。

四、底层原理：两个陌生智能体从“互相找到”到“放心握手”

这一章是全文最硬的部分，但我保证不用一个你看不懂的词而不解释。原理部分我主要参考的是公开的 Agent 可信服务（ATS）产品文档，因为它是目前我能查到的、把这套基于域名的可信机制讲得最具体的中文公开资料，而且文档写明是与CNNIC联合共建的。需要再强调一次：它展示的是可信基础设施在产业侧的一种落地形态，不等于智能体域名系统2.0的全部内部实现。

4.1 先补三种DNS记录

DNS不只能把域名翻译成IP地址。一个域名下面可以挂很多种“记录”，每种记录存不同的信息。和智能体相关的主要是下面三种：

再补一个概念：指纹。把一份数据丢进哈希函数，会得到一串固定长度的字符，数据哪怕只改一个字节，这串字符也会面目全非。所以比较指纹就等于比较原文，而且省事得多。

4.2 名字怎么写：把智能体标识绑在域名上

在这套可信服务的文档里，每个智能体有一个全局唯一的信任标识，叫 ATI Name。它的写法是把版本号和域名拼在一起：

独立域名模式： ati://v{版本}.{访问域名}
共享域名模式： ati://v{版本}.{标识域名}

举例：        ati://v1.0.0.agent.example.cn

这里出现了两种模式和两种域名，我解释一下。

独立域名模式，是一个智能体独占一个域名，访问它用这个域名，标识它也用这个域名，二者合一，最简单。

共享域名模式，是多个智能体跑在同一个平台上，共用一个主域名作为流量入口，同时各自再领一个一级子域名当作身份标识。这样入口统一，身份又互不干扰。文档里专门强调，一个标识域名只对应一个智能体和一份身份证书，不能多个智能体合用。

把版本号写进标识里是个挺细心的设计。智能体升级之后能力可能变了，行为边界也可能变了，1.0.0和2.0.0严格来说不是同一个东西，分开标识有利于追溯。

4.3 两张证书各管一摊

文档里说，每个智能体要管理两张证书。很多人看到这里会犯迷糊：一张不够吗？

不够，因为它们回答的是两个不同的问题。

CA 是证书颁发机构的缩写，可以理解成发证机关。注册机构（RA）则是负责收材料、核验身份、把申请递交给发证机关的窗口。

两张证书配合起来，再加上一种叫 mTLS 的握手方式。普通的HTTPS只是客户端验证服务器，mTLS 是双向的：我验你，你也验我。两个智能体都亮出证件，再建立加密通道。

这种“场所归场所、人归人”的拆法我觉得很合理。服务器证书大家本来就有，用现成的；身份证书是智能体时代新增的需求，由具备公信力的机构来发。

4.4 透明日志：把“发过证”这件事记在公开账本上

光有证书还有一个隐患：万一发证环节出了岔子，签了一张不该签的证书，外界怎么发现？

解决办法是透明日志。智能体的注册、证书签发、身份变更这些关键操作，全部写进一本只能追加、不能涂改的公开账本。任何人都可以独立检查某条记录在不在账本里。

这本账为什么改不了？靠的是一种叫默克尔树（Merkle Tree）的数据结构。原理我用四条记录的小例子演示，下面的公式我都写成了纯文本，H 代表哈希函数，‖ 代表把两段数据首尾拼接：

第一层（叶子）：  h₁ = H(记录1)   h₂ = H(记录2)   h₃ = H(记录3)   h₄ = H(记录4)

第二层：          h₁₂ = H(h₁ ‖ h₂)          h₃₄ = H(h₃ ‖ h₄)

树根：            root = H(h₁₂ ‖ h₃₄)

树根只有一个，而且任何一条记录被改动，都会一路传导上去，让树根变样。运营方会定期对树根做数字签名并公布，相当于给整本账盖了骑缝章。

现在假设我想确认“记录3”确实在账本里。我不需要下载全部四条记录，只需要对方给我两个值：h₄ 和 h₁₂。然后自己算一遍：

第一步： 算出 h₃ = H(记录3)
第二步： 算出 h₃₄ = H(h₃ ‖ h₄)
第三步： 算出 root′ = H(h₁₂ ‖ h₃₄)
第四步： 比较 root′ 与公布的 root 是否相等，相等即证明记录3在册

对方给的那两个值，就叫默克尔证明。它的妙处在于效率：

需要的哈希计算次数 ≈ log₂(n)，其中 n 是账本里的记录总数

n = 4 时，       约 2 次
n = 1000 时，    约 10 次
n = 1000000 时， 约 20 次

也就是说，账本里哪怕有一百万条记录，验证其中一条也只要二十次左右的哈希运算。这个量级，智能体在握手的那一瞬间就能算完。

文档里还提到一个叫 Badge 的东西，我把它理解成“在线有效凭证”：它由透明日志系统实时颁发并带有密钥管理服务的签名，调用方拿到之后结合默克尔证明验一下，就能确认对方的注册记录此时此刻仍然有效，而不是一张早就被注销的旧证。

4.5 DNSSEC 和 DANE：防止“路牌被人换了”

前面的机制都默认一件事：我从DNS查回来的记录是真的。可如果有人在半路上动了手脚，把我引到一个假地址呢？

这就轮到 DNSSEC 出场。它给DNS的每一份应答都附上数字签名，从根域一级一级往下形成信任链，查询方可以验证“这条记录确实出自域名主人之手，路上没被改过”。

DNSSEC 保住了记录的真实性之后，DANE 才有用武之地。DANE 的做法是把证书公钥的指纹写进一条 TLSA 记录，握手的时候，调用方把对方亮出来的证书算一下指纹，和DNS里登记的比对。两边一致，才算过关。

这样做相当于上了双保险。即使某个发证机关出了问题，签出一张冒名的证书，只要冒名者改不了域名主人登记在DNS里的指纹，这张假证就过不了关。反过来，即使DNS这边出问题，还有证书链那一道关。

4.6 三档认证：按风险选强度

把上面这些零件组装起来，文档里给出的是一个渐进式的三档认证。认证级别不是注册时写死的，而是由智能体实际验证通过了哪些DNS记录动态决定：

最后一列是我的个人判断，文档里只给高级档举了金融级场景的例子。

分档的好处是成本可控。不是每个智能体都需要顶格防护，小团队可以先从基础档起步，业务变重了再往上加记录升档，文档里说升降档都不需要重新注册。

4.7 串起来：一次完整的“找到并握手”

把前面的内容连成一条线，两个陌生智能体的一次协作大致是这样走的：

采购智能体（调用方）                         报价智能体（被调用方）
      │                                              │
      │ ① 通过检索或已知名字，拿到对方的域名         │
      │                                              │
      │ ② 查询 DNS：_ati.{对方域名} 的 TXT           │
      │    得知对方已注册、支持哪些协议、描述文件在哪│
      │                                              │
      │ ③ 发起连接，双方互相出示证书（双向握手）────▶│
      │◀──── 对方出示服务器证书与身份证书 ───────────│
      │                                              │
      │ ④ 校验证书链能否追溯到可信的根               │
      │    校验证书里的标识与对方域名是否一致        │
      │                                              │
      │ ⑤（增强档）查 _ati-badge，取在线凭证         │
      │    用默克尔证明确认注册记录当前有效          │
      │                                              │
      │ ⑥（高级档）验证 DNSSEC 签名                  │
      │    把证书指纹与 TLSA 记录比对                │
      │                                              │
      │ ⑦ 全部通过，建立加密通道，开始谈业务 ───────▶│

回头对照第一章的名片比喻：第②步是看名片，第③④步是查身份证，第⑤步是打电话到发证机关确认证件没挂失，第⑥步是确认你打的那个电话号码本身没被人掉包。

4.8 我对这套设计的几点看法

讲完原理，说说我自己的评价，有夸的也有保留的。

值得肯定的地方是务实。全套方案里几乎没有新发明的密码学，证书、哈希树、DNSSEC、ACME 都是久经考验的东西，组合方式也和网站证书领域已有的做法一脉相承。成熟技术意味着工具链齐全、懂的人多、踩过的坑有据可查。

我有保留的地方有三点。

其一，高级档依赖 DNSSEC，而很多域名并没有开启它。域名持有者要先确认自己的注册商和解析服务商都支持，才谈得上用高级档。这是个现实门槛。

其二，是“悬空记录”的风险。国外讨论同类草案方案的技术文章里反复提到这个问题：一个智能体下线了，但它在DNS里的记录忘了删，而原来的服务地址又被别人接手，冒名顶替就有了可乘之机。这其实是域名运维的老毛病，只不过到了智能体时代后果更重。所以注销流程一定要走完整，文档里也写了注销时证书会同步撤销、解析记录会清理。

其三，信任的根在少数机构手里。这是所有基于证书体系的方案共有的特点，谈不上缺陷，但意味着发证机构自身的安全和审核质量至关重要。透明日志正是为了约束这一点而存在的。

看到这里，原理部分就算过关了。下一章动手。

五、动手篇：照着公开文档，把“可信注册”流程走查一遍

先把话说在前面，免得误导大家。这一章的控制台步骤，是我对照阿里云帮助中心公开的 Agent 可信服务（ATS）文档逐节梳理出来的，入口在这里：https://help.aliyun.com/zh/document_detail/3046976.html 。其中凡是能在本地执行的命令，我都亲手跑过并贴了真实输出；需要企业实名和真实业务域名才能走完的控制台环节，我是按文档描述整理的流程和注意点，界面细节请以你登录后看到的为准。

另外，这是目前公开资料最完整的一个产业侧入口，不代表它是唯一入口。CNNIC自己的智能体域名注册渠道和API如何开放，请留意官方后续通知。

5.1 开工前的准备清单

顺带解释三个协议名。MCP 是模型上下文协议，主要解决智能体怎么调用外部工具和数据；A2A 是智能体之间直接对话的协议；OpenAPI 就是大家熟悉的描述REST接口的那套规范。后两章还会提到它们。

5.2 第一步：注册人实名认证

注册智能体之前，账号下至少要有一个审核通过的注册人。操作上就是在控制台的注册人设置页面添加注册人，填好信息后提交，等人工审核。

这一步看着平淡，却是整套体系“管得住”的根基。每个智能体最终都要关联到一个实名的主体，这和域名实名、网站备案是同一个逻辑。

5.3 第二步：填写注册表单

表单分基本信息和端点配置两块。我把关键字段和容易填错的地方列出来：

关于描述那一栏我多说一句。150个字符很短，但它是别的智能体在检索时判断“要不要找你”的重要依据。我的建议是按“给谁用、能做什么、不做什么”的顺序写，少用形容词，多用名词和动词。比如“面向家电制造企业，提供冷轧钢板现货报价与库存查询，不处理合同签署”，就比“智能高效的一站式采购助手”有用得多。

5.4 第三步：域名控制权预检

表单提交后，系统会要求你证明这个域名确实归你管。用的是 ACME 协议里的 DNS-01 验证方式，申请过免费HTTPS证书的朋友应该不陌生：系统给你一段随机字符，你把它作为一条TXT记录加到域名的解析里，系统去查，查得到就说明你管得了这个域名。

需要加几条，看模式：独立域名模式一条；共享域名模式两条，主域名一条用于证书签发，子域名一条用于证明标识域名归你。

加完记录别急着点验证，解析生效需要时间，不同服务商快慢不一。可以先在自己电脑上查一下记录是否已经能查到。常见的查询命令是下面这两种，把域名换成控制台给你的那个主机记录：

dig +short TXT _acme-challenge.agent.example.cn
nslookup -type=TXT _acme-challenge.agent.example.cn

命令里的主机记录名只是ACME验证的惯用写法，实际以控制台显示的为准。能查到预期的值，再回控制台触发预检。预检通过之后，申请会提交到CNNIC做终检。

5.5 第四步：在本地生成密钥和证书签名请求

这是整个流程里唯一需要敲命令的环节，也是最容易出安全事故的环节。先记住一条铁律：私钥只在你自己的机器上生成和保存，任何情况下都不要上传到任何平台。 文档里也用加粗反复强调了这一点，承办方只接收包含公钥的签名请求，不碰私钥。

证书签名请求（CSR）可以理解成一张申请表：里面有你的公钥和身份信息，并且用你的私钥签了名。发证机关审核通过后，据此给你签发证书。

第一条命令，生成密钥。文档给了两种算法，我选的是椭圆曲线那种，密钥更短，握手更快：

openssl ecparam -genkey -name prime256v1 -noout -out identity.key.pem

第二条命令，生成签名请求。注意最后一个参数，它把智能体的信任标识写进了证书的“使用者可选名称”字段，这个值必须和你注册时填的版本号、域名一字不差：

openssl req -new -key identity.key.pem -out identity.csr.pem -sha256 -utf8 \
  -subj "/C=CN/O=示例科技有限公司/CN=示例客服智能体" \
  -addext "subjectAltName=URI:ati://v1.0.0.agent.example.cn"

上面的公司名、智能体名、域名都是我为了演示编的。实际操作时，控制台会根据你填的信息自动生成这条命令，强烈建议直接复制，不要手工改占位符。

第三条命令，检查生成的请求内容对不对：

openssl req -in identity.csr.pem -noout -text -nameopt utf8

我在本地（OpenSSL 3.0.13）跑完之后，输出里关键的几行是这样的：

Subject: C=CN, O=示例科技有限公司, CN=示例客服智能体
    X509v3 Subject Alternative Name:
        URI:ati://v1.0.0.agent.example.cn
Signature Algorithm: ecdsa-with-SHA256

三行分别确认了主体信息、信任标识、签名算法都符合预期。中文主体名能正常显示，说明 -utf8 参数起作用了。

最后把 identity.csr.pem 的内容粘贴到控制台的身份证书输入框，再把服务器证书的公钥部分（只要最末端那张证书，不需要中间证书链）粘贴到另一个输入框，提交。提交后状态变成等待签发。

顺便分享一个帮助理解的小实验。前面讲过，高级认证要把证书公钥的指纹登记到解析记录里，系统会自动替你算。如果你好奇