从实时搜索到自动注册：让域名服务同时服务人和 AI Agent

预计阅读时间：9 分钟

域名搜索看似只是检查一个名称是否可用，实际却要同时处理数百个后缀、不同注册局的响应速度、溢价域名规则、价格差异和状态变化。Cloudflare Registrar 的新搜索覆盖 420 多个域名后缀，并使用 Workers、Durable Objects 和 WebSockets 返回快速、透明的结果。与此同时，扩展后的 API 与 cf CLI 把搜索、注册和转移能力开放给了自动化程序与 AI Agent。

这项变化的重点不只是“搜索更快”，而是把原本偏人工的购买流程改造成可组合、可审计的基础设施能力。

域名搜索为什么适合流式返回

一次跨 420 多个后缀的查询，不太可能让所有结果同时完成。某些注册局响应很快，另一些需要更多时间；部分名称还可能涉及溢价定价或额外限制。如果服务等待最慢的后缀再统一返回，用户看到的就会是一个长时间没有反馈的页面。

WebSocket 更适合这种场景：前端建立长连接后，服务端可以陆续推送已经完成的结果。用户可能先看到常见后缀，再看到国家和地区后缀，最后补齐响应较慢的结果，而不必反复刷新页面。

从工程角度看，可以把这套组合理解为：

Workers 在边缘接收请求，完成鉴权、参数校验和结果标准化。
Durable Objects 为一次搜索或一个会话维护协调状态，处理去重、进度和连接管理。
WebSockets 把增量结果推送给浏览器或其他客户端。

这是基于相关组件能力的一种合理架构解释，并不代表未公开的内部实现细节。关键设计思想是：不要把数百个异步查询强行包装成一个必须同时完成的同步响应。

“透明结果”对 Agent 比“有结果”更重要

人可以在页面上比较价格、后缀和提示信息，但 Agent 需要结构化字段才能做出稳定决策。一个面向自动化的域名搜索结果，实践中应尽量明确表达：

域名当前是否可注册；
首年价格与续费价格使用什么币种；
是否属于 premium domain；
是否有注册资格、地域或材料限制；
搜索结果的生成时间和有效期；
当前操作是注册、续费还是转移；
失败是暂时不可用，还是明确不可注册。

这些字段是设计 Agent 工作流时值得采用的实践示例，而不是对具体 API 响应格式的描述。对 Agent 来说，“未知”和“不可用”必须分开，否则它可能因为暂时超时而错误地放弃候选域名，也可能把首年低价误认为长期成本。

扩展后的 API 和 cf CLI 还意味着同一套能力可以进入脚本、CI 流程或 Agent 工具调用链。搜索属于低风险只读操作，注册和转移则会产生费用、所有权变化与安全影响，因此不应使用同一套授权策略。

可以这样实践：给注册动作加预算和人工闸门

下面是一个可改造的 Bash 示例。由于摘要没有给出正式 API 路径和响应结构，示例假设存在 GET /domains/search 和 POST /domains/register 两个端点，并假设搜索结果位于 .results。运行前请按照当前 API 文档修改路径、字段和认证头。

脚本依赖 curl 与 jq。它默认只搜索和生成候选列表；只有显式设置 APPROVE=YES 才会提交注册请求。

cat > domain-agent.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

: "${DOMAIN_API_BASE:?Set DOMAIN_API_BASE first}"
: "${DOMAIN_API_TOKEN:?Set DOMAIN_API_TOKEN first}"

QUERY="${1:-example}"
MAX_FIRST_YEAR="${MAX_FIRST_YEAR:-25}"
APPROVE="${APPROVE:-NO}"
BASE="${DOMAIN_API_BASE%/}"

curl -fsS --get "$BASE/domains/search" \
  -H "Authorization: Bearer $DOMAIN_API_TOKEN" \
  -H 'Accept: application/json' \
  --data-urlencode "q=$QUERY" \
  > search-results.json

jq --argjson cap "$MAX_FIRST_YEAR" '
  [
    .results[]
    | select(.available == true)
    | select((.premium // false) == false)
    | select((.first_year_price // 999999999) <= $cap)
  ]
  | sort_by(.first_year_price)
' search-results.json > shortlist.json

printf 'Candidates within budget:\n'
jq . shortlist.json

if [[ "$APPROVE" != "YES" ]]; then
  printf '\nDry run only. Review shortlist.json, then rerun with APPROVE=YES.\n'
  exit 0
fi

DOMAIN="$(jq -r '.[0].domain // empty' shortlist.json)"
if [[ -z "$DOMAIN" ]]; then
  echo 'No eligible domain found.' >&2
  exit 1
fi

printf 'Registering %s\n' "$DOMAIN"

jq -n --arg domain "$DOMAIN" '{domain: $domain, auto_renew: false}' \
  | curl -fsS "$BASE/domains/register" \
      -H "Authorization: Bearer $DOMAIN_API_TOKEN" \
      -H 'Content-Type: application/json' \
      -H "Idempotency-Key: register-$DOMAIN" \
      --data-binary @-
EOF

chmod +x domain-agent.sh

export DOMAIN_API_BASE='https://api.example.invalid'
export DOMAIN_API_TOKEN='replace-with-a-scoped-token'
MAX_FIRST_YEAR=20 ./domain-agent.sh my-product-name

这个示例刻意加入了几层约束：

默认是 dry run，不会因为一次模型调用就购买域名。
排除溢价域名，并限制首年预算。
使用幂等键，降低网络重试造成重复操作的风险。
关闭自动续费，把长期费用留给后续明确决策。
将原始搜索结果和候选列表保存在文件中，方便审计。

生产环境还应检查续费价格、币种、税费、注册期限和联系人要求。预算也不应只看首年价格；更稳妥的策略是计算三年总成本，并为注册与转移分别配置权限。

接入 Agent 前的边界清单

域名自动化很适合用于品牌监控、活动站点准备、内部环境命名和批量迁移，但“能调用 API”不等于“应允许完全自主执行”。上线前至少确认以下事项：

搜索令牌是否只有只读权限；
注册、转移和 DNS 修改是否使用不同凭据；
是否设置单次、每日和每月预算上限；
是否禁止溢价域名或异常续费价格；
注册前是否保留人工审批步骤；
是否记录 Agent 的输入、候选结果、决策理由和 API 响应；
转移操作是否要求二次验证，并妥善保护授权码；
WebSocket 中断后是否能够恢复进度，而不是重复发起整批查询。

Cloudflare Registrar 的这次变化展示了一个更广泛的趋势：面向人的控制台正在演变为同时面向程序和 Agent 的操作界面。真正可靠的实现并不是让 Agent 获得无限权限，而是让搜索足够快、结果足够结构化，再用预算、幂等、审计和人工确认控制不可逆操作。

从实时搜索到自动注册：让域名服务同时服务人和 AI Agent

域名搜索为什么适合流式返回

“透明结果”对 Agent 比“有结果”更重要

可以这样实践：给注册动作加预算和人工闸门

接入 Agent 前的边界清单

相关推荐

建议反馈