Namefi

AI 智能体如何无需人工购买域名(2026)

2026 年 4 月,域名注册进入智能体层。了解 AI 智能体如何搜索、定价和注册域名,以及仍不可忽视的安全护栏。

Aileen WrightAileen Wright作者Victor ZhouVictor Zhou编辑卞芬薇卞芬薇译者2026年7月10日约 20 分钟阅读
  • ai-agents
  • domains
  • explainer
分享到 X

过去二十年来,注册域名始终遵循同一套小小的仪式:在搜索框中输入名称,等待绿色勾选标记,填写银行卡号,在照片中辨认出人行横道来证明自己是人类,然后点击购买。这套仪式在某种程度上本就是刻意设置的筛选器——CAPTCHA、结账表单和银行卡字段都旨在拖慢一切非人类的操作。

2026 年 4 月 15 日,这个筛选器不再普遍适用。Cloudflare 将 Registrar API 以公开测试版推出,行业报道用一句直白的话概括其定位:Cloudflare“将这笔交易移入了智能体层”——在这一架构层级中,发起购买的是软件,而不是点击表单的人。过去因默认键盘前坐着人类而难以完全自动化的注册、DNS 和其他一些任务,悄然不再以此为前提。

本文将专门讲解这一转变:技术上发生了什么变化,AI 智能体代表你注册域名时实际会做什么,以及——因为“无需人工”这个说法值得保持怀疑——要让它安全,还必须满足哪些条件。如需了解如今各个平台分别提供什么,请参阅AI 智能体域名平台:2026 指南Cloudflare、Name.com 与 Namefi 对比;如需理解注册商究竟具备哪些条件才能让智能体使用,请参阅什么是智能体原生域名注册商?

技术上发生了什么变化

域名行业并没有在 2026 年 4 月重写规则。早在那之前,注册商就已拥有可编程 API 数十年;变化的是,哪些主体能够理解并调用这些 API。

传统注册商的结账流程围绕人类阅读页面、填写银行卡信息,并在购买完成前证明自己不是机器人而设计——这三项假设对智能体而言都是一道墙。CAPTCHA 的存在就是为了阻止任何非人类操作,因此它既能阻止滥用,也同样有效地阻止遵照人类指令行事的合法智能体。一份基于 Cloudflare 公测版的第三方 MCP 教程直言不讳地描述了旧模式:“域名注册商是为人类打造的:CAPTCHA、控制台、表单、信用卡字段。对智能体并不友好。”

有三项技术取代了这一模式;它们是叠加关系,而非相互竞争:

  • 经身份验证的 REST API,让购买可以通过 HTTP 调用完成,而非通过渲染出的结账页面。Cloudflare 的公测版以这种方式支持搜索、可用性查询和注册;根据发布报道,标准域名的注册可“在数秒内同步完成”。
  • MCP(模型上下文协议,Model Context Protocol),其官方文档将它描述为“用于将 AI 应用连接到外部系统的开源标准”——它带来的差别在于:智能体不再只能拿到定制集成代码,而是可以发现注册商的工具(searchregisterset_dns_record),并在 Claude、Cursor 或任何其他兼容客户端中直接调用它们。Cloudflare 将其 Registrar API 接入这一层;按照它自己的表述,“在 Cursor、Claude Code 或任何 MCP 兼容环境中工作的智能体,可以发现并调用 Registrar 端点”,无需另行进行集成。
  • llms.txt 发现机制,这是一项纯文本约定——“提议通过使用 /llms.txt 文件提供信息,帮助 LLM 在推理时使用网站”——使从未见过某个注册商的智能体无需先由人类把 API 文档粘贴进对话,就能了解该注册商可以做什么。

这三部分单独来看都不新鲜;MCP 在 2024 年末推出,llms.txt 也在同年被提出。新鲜的是,一家主流注册商将三者全部置于实际可用的购买流程之后——正是这部分,让“AI 智能体注册域名”从爱好者演示变成了新闻标题。

智能体实际会做什么

抛开营销包装,智能体购买域名是一段简短而机械的流程——与人类在结账页上遵循的步骤相同,只是由 API 调用取代了点击。它涉及三方:智能体、注册商 API,以及其背后的注册局

  1. 搜索。 智能体调用注册商的搜索端点(或等效的 MCP 工具),传入候选名称或所需名称的描述,然后获得可用和已被注册的变体列表。
  2. 查询可用性和价格。 对于某个具体名称,智能体会查询实时可用性和准确价格——注册费、任何溢价加价,以及适用时的 ICANN 交易费。精心筛选的 TLD 列表在这里很重要:包括 Cloudflare 在内的若干智能体原生公测版,推出时只覆盖热门 TLD 的一个子集,而非完整目录。
  3. 认证并获得授权。 智能体提供注册商能够以程序化方式验证的凭证——与已注资账户关联的 API 密钥,或钱包签名——而不是登录页面后保存的银行卡信息。
  4. 注册。 智能体调用注册端点。注册商通过 EPP 向域名的注册局转发请求;EPP 即可扩展供应协议,自 2004 年达到 Proposed Standard 状态以来,注册商便一直借此与注册局通信。注册局创建记录,API 返回确认,通常只需数秒。
  5. 配置 DNS。 在成功取得域名后,智能体会设置域名服务器(NS 记录)或单独的 DNS 记录——例如指向服务器的 A 记录、指向托管平台的 CNAME——而且往往就在注册域名的同一段对话中,作为紧随其后的下一次调用完成。
  6. 向人类确认。 在设计良好的智能体流程中,人类不会事后从信用卡账单上才得知购买;智能体会反馈域名、价格,以及该域名被指向了什么位置。

第六步的作用比看上去大得多——下一节正是讲它。

安全护栏:“无需人工”仍需要由人设定的政策

“无需人工”描述的是机制,不是治理方式。API 不需要有人在交易中途点击按钮——但仍必须有人预先决定,智能体可以如何使用被授予的权限。Cloudflare 自己的公测版文档明确指出了责任所在:“由人类负责设计一种不会未经你批准就购买域名的智能体流程。”API 让没有结账页的注册成为可能;它并不会自行决定何时注册——这是集成智能体的人必须写下的政策。

实践中,三道安全护栏承担了大部分工作:

  • 不是裸露银行卡号的付款授权。 对预付或记账余额收费的 API 密钥,会从机制上限制总体风险暴露——智能体无法支出超过已注入的金额。钱包签名交易则针对每次购买单独授权,且无法被重放。与没有内置上限的已保存信用卡相比,这两种方式的风险形态有实质差异。
  • 由人类在智能体行动前设定的支出上限和确认阈值。 Cloudflare 对“设计良好的智能体流程”的建议是:调用注册端点前,先让用户确认域名和价格,而非事后确认——API 支持这种模式,但并不强制。
  • 清晰的法律风险承担者。 智能体注册域名并不能消除一个域名有登记在案的注册人这一法律现实。一篇讨论智能体持有域名的文章直言其中的风险:“如果智能体注册的域名后来引发商标冲突,却没有人类来回应 UDRP 投诉。”如果没人监控以其凭证注册的内容,移除结账页并不会移除 UDRP(统一域名争议解决政策) 流程、续费期限或 WHOIS(与 RDAP) 记录;仍必须有人刻意构建这种监控。

这点值得仔细想想:能够注册域名的智能体,也能在无人逐笔审核交易的情况下花钱并积累域名组合——这正是它有用的能力,也正是政策层不可或缺的原因。

如今谁在提供这项服务,以及“经销商”论点

Cloudflare 的公测版是这一转变中报道最多的案例,但并非唯一。Name.com 自 2025 年年中起围绕同样的 MCP 与 OpenAPI 方法构建了类似 API;Namefi 则运行 MCP 服务器,并提供跳过账户创建的、由钱包签名的结账流程。它们在功能上的差异——定价模式、TLD 覆盖范围、付款是否需要已有账户——请参阅Cloudflare、Name.com 与 Namefi 对比;完整格局(包括大型面向消费者的注册商在哪些方面尚未进入这一类别)请参阅AI 智能体域名平台:2026 指南

比任何单一平台都更新的是:智能体获得这项能力后,开始用它做什么。CircleID 在 2026 年年中的域名行业调查如此表述:“AI 智能体日益充当域名经销商,在没有人工干预的情况下检查可用性、注册域名并配置 DNS。”经销商”是刻意的用词——这是一个既有角色,指在注册商的认证授权下销售或提供域名的一方,而不是自己持有该项认证。将智能体视为非正式经销商,而非一种新类别,意味着尽管操作者不是人类,这套工作流仍然可辨认:代表他人进行搜索、定价、注册、配置,并且可批量执行。我们在2026 年智能体域名管理现状中追踪了这种模式实际发展到了什么程度、哪些仍只停留在发布阶段;Namefi 自己的 MCP 服务器则是经销商式智能体会调用的工具的一个具体例子。

常见问题

2026 年 4 月 15 日究竟发生了什么变化?

Cloudflare 将 Registrar API 以公开测试版推出,支持域名搜索、可用性和价格查询以及注册,并接入 Cloudflare MCP 服务器;该服务器已用于 Cursor 和 Claude Code 等工具中的智能体。这并不是第一个可由智能体调用的注册商 API——Name.com 的在 2025 年年中推出,Namefi 的已在运行——但这是大型、知名注册商让整个购买过程由智能体完成而非仅能在浏览器结账的、报道最广的案例。

AI 智能体每次注册域名都需要我的许可吗?

在 API 层面默认不需要——端点一旦收到有效、已授权的凭证,以及可供扣费的价格,便会完成注册。是否设置确认步骤,取决于智能体的配置方式,而不是注册商自动强制的内容。Cloudflare 自己的指引明确表示,构建智能体流程的人有责任在购买前要求审批。

不逐笔盯着交易,让 AI 智能体购买域名真的安全吗?

它的安全程度取决于你预先设置的安全护栏,并不会默认更安全。可行的模式包括:限制总体风险暴露的预付或记账余额、为单次购买授权且不可重复使用的钱包签名,以及在你选定的阈值之上设置确认步骤。这个领域没有任何平台替你强制执行通用的支出上限;必须由你自己设定。

如果 AI 智能体注册了域名,谁要在法律上负责?

域名仍有一名登记在案的注册人——可以是个人或组织,而不是 AI 模型本身——该注册人要承担商标争议、UDRP(统一域名争议解决政策)投诉或续费期限带来的风险。将人类从购买步骤中移除,并不会把人类从所有权记录中移除;除非你构建了这种监控,否则只意味着可能没人正在留意这些风险。

AI 智能体会在正式、获认证的意义上成为域名经销商吗?

不会是在 ICANN 认证的意义上——经销商通常是在注册商认证协议下运营的公司。CircleID 使用“经销商”一词是描述性的,指的是行为模式,而非法律身份。这种行为是否会整合成一个获得正式认可的类别,仍是2026 年智能体域名管理现状提出的开放问题之一。

这适用于所有 TLD,还是只适用于热门 TLD?

这取决于平台——应当直接核实,而不是假定覆盖完整。Cloudflare 的公测版推出时,根据其自己的材料,提供的是精心筛选的一组热门 TLD,而非完整目录。随着公测逐步成熟,覆盖范围往往会扩大;因此,在依赖某个特定后缀之前,应先根据平台的实时文档核实当前 TLD 支持情况。

用自己的智能体注册下一个域名,无需结账页面

Namefi 运行着与本文所述相同类型的智能体原生购买路径:智能体可直接连接的 MCP 服务器、有文档说明的 REST API,以及完全跳过账户创建的钱包签名结账流程;如果你希望域名本身成为智能体钱包可持有的资产,还提供代币化所有权。只需设定一次支出政策,之后就让智能体按本文所述处理搜索、定价和注册。

在 Namefi 搜索并注册域名

来源与延伸阅读

贡献者

Aileen Wright
艺术与历史撰稿人 • Namefi

Aileen Wright 是一名二十多岁的学生,现居纽约。在这里,从博物馆的展墙走到图书馆阅览室 不过几步之遥,却足以度过一个漫长的下午。她通过艺术和历史走进了有关名字的写作领域: 一幅肖像、一枚硬币或手稿页边的一行字,都能让一个名字跨越数个世纪,并在流传中改变含义。

大多数时候,你会看到她拿着一本平装书待在中央公园,或是在安静的公共阅览室里追查一个名字 的真正出处,而不是照搬名字清单声称的含义。她还在自学编程,这让她对拼写、排序,以及决定 一个名字能否经得住时间考验的细微之处格外严谨。

她为 Namefi 撰写域名背后的历史与文化、品牌更名时所承载的故事,以及好故事与可靠来源之间 的区别等相关文章。

Victor Zhou
创始人兼标准编辑 • Namefi

Victor Zhou 是一位专注于数字身份与信任的科技创业者和标准编辑。他创办了 Namefi,编辑 以太坊改进提案,此前还曾在 Google Labs 负责智能合约架构工作。

他的工作位于命名、所有权,以及人们用来建立网络身份的系统三者交汇之处。这一视角让他尤其 关注名字如何在个人意义、公众认知和数字基础设施之间流转。

在 Namefi,Victor 把域名视为持久的数字身份,并围绕这一主题编辑和撰写内容:名字如何成为 可拥有的链上资产,代币化如何改变托管与信任,以及命名可以从人们建立网络身份所使用的系统 中学到什么。

卞芬薇
卞芬薇译者
软件开发者与撰稿人 • Namefi

卞芬薇是一名三十多岁的软件开发者,工作时间泡在 pull request 里,周末双手不是沾着 泥土,就是沾着木屑。多年参与 GitHub 开源项目的经历让她明白,名字就是接口:好名字清晰, 如实说明自己的作用,也为下一位使用它的人着想。

她喜欢园艺,因为它奖赏耐心,也会惩罚一厢情愿;她也做木工,因为接合处要么严丝合缝, 要么就是不合。这两种习惯同样体现在她关于命名的写作中:量两遍,核实来源,别把粗糙处 磨平后就指望没人注意到。

她为 Namefi 撰写域名市场实际如何运转、域名代币化与转手交易的现实取舍,以及如何选择一个 二十年后仍会庆幸自己拥有的域名。

相关指南

讨论这篇文章

在 Namefi Discuss 查看讨论