当互联网开始封堵 AI，我们为什么选择向 AI 开门？
当 AI Agent 改变互联网入口，平台应该限制还是融合？DomainRoc 通过开源 MCP 只读域名查询实验，探索安全边界与 AI 开放服务的平衡。
未来访问网站的用户，不一定会先打开浏览器。他可能直接告诉 AI 助手：「帮我查一下这个域名能不能注册。」AI 再替他调用服务，返回结果。对互联网平台来说，这会带来一个现实问题：我们到底应该把 AI 的访问一律挡在门外，还是为合理的调用建立一条明确的通道？
DomainRoc 选择先做一个很小、但可以验证的实验。我们在 GitHub 发布了开源 MCP Server，只开放一项工具：check_domain。它能帮兼容 MCP 的客户端查询域名状态和 USDT 参考报价，但不能代替用户购买域名。
为什么一些平台选择限制 AI
限制自动化访问并不一定是排斥新技术。大规模抓取可能增加服务器成本，未经授权的数据获取可能触及权利边界，滥用接口也可能造成安全问题。对于包含账户、域名资产和支付流程的平台，允许程序调用哪些功能，绝不能模糊处理。
AI Agent 并不是一张可以绕过授权的通行证。用户的余额、账户信息、注册商操作和支付动作，都不应该因为模型能发出指令，就自动变成开放接口。
但如果所有自动化请求都被视为威胁，平台也可能错过一种新的用户入口。更值得讨论的是：哪些能力适合开放，开放到什么程度，又如何保留用户的决定权？
我们先开放域名查询，不开放交易
这次的 DomainRoc AI Agent Preview 没有另造一套域名业务系统，而是复用官网原有的公开查询接口。独立 MCP Server 将它包装为一个只读工具，客户端提交域名，就能获得 available、unavailable 或 unknown 状态。
只有上游确认能够注册、且存在可靠报价时，才展示 USDT 首年参考价。购买入口指向官网查询页，而不是预先生成的订单。用户依然在官网核对价格、后缀条件和付款信息。
如果遇到限制、异常或不确定状态，工具会返回 unknown。无法确认，不等于可以注册。
这条边界是实验的一部分，不是临时省略的功能。当前 MCP 没有用户登录、创建订单、扣费、自动支付、DNS 修改或域名转移权限。原有 Spaceship、Openprovider 和结算业务也不因这个实验而改变。
技术实验必须能让别人复现
只在宣传页上写「支持 AI」没什么说服力。我们希望开发者能够自己运行，所以开源仓库提供服务端代码、Python stdio 客户端示例、自动化测试及中英文说明。
2026 年 10 月 11 日 UTC 00:58 ，我们使用官方 MCP Python SDK 客户端发起了真实查询。客户端成功发现 check_domain，随后查询到 example.com 已注册；另一个测试域名在当时被报告为可注册，返回 13.986000 USDT 的参考报价 ；无效的 URL 输入得到 unknown。
这些是带时间戳的历史测试结果，不代表此刻的域名库存和最终价格。相关命令和完整输出保存在真实演示记录。目前验证的是官方 SDK 的 MCP 协议调用，并非宣称所有 AI 客户端都能自动接入。
从「访问网页」到「表达意图」
传统网站把功能组织成页面、菜单和按钮。AI Agent 可能会把起点转变为一句话：查这个域名、比较这些候选名称、解释结果。用户未必在第一步进入网站，但真正的交易确认仍然需要明确的商业流程。
对 DomainRoc 来说，开放一个可调用的域名查询能力，是为这种新入口做准备，也让独立开发者有机会把查询整合到自己的工具中。它不会自动带来流量，更不代表搜索引擎必然给予额外排名；实际价值要看是否有人使用、引用和复现这个实验。
官网仍然承担完整注册与 USDT 支付，MCP 则保持小而独立。我们认为这比匆忙开发「AI 全自动买域名」更值得先做。
严防死守，还是融合共生？
我们并不主张互联网平台放弃安全限制，也不认为所有爬虫都值得开放。把访问权限分清，把用途讲明白，把结果做成可验证的事实，可能比简单地选择「全部开放」或「一律封锁」更有建设性。
这就是 DomainRoc AI Agent 开放实验 的出发点：先让 AI 做一件有用、可复现、风险边界清楚的小事，再讨论更远的未来。
欢迎开发者查看 GitHub 仓库，亲自运行演示，并提出技术上的不同意见。