摘要

  • ICANN 公布的争议组 CSV 为同一字符串 .agent 列出 13 个申请 ID；按该文件的行数计算，这是 263 个编号组中最大的组。
  • 按完全相同的组织名称统计不同组号，XYZ.COM LLC 出现在 100 组，Intercap Registry Inc. 出现在 54 组，Radix Technologies Inc SEZC 出现在 41 组，Charleston Road Registry Inc. 出现在 13 组，ECHO Domain Co L.L.C. 出现在 11 组。每项都包含 .agent 这一组。

一个名称冲突，背后可能是跨组申请组合

第一次看到 .agent，得到的是 13 份申请的清单。对行业决策者更有用的问题是：这些申请主体在同一份公开记录的其他组里出现了多少次？答案差异很大。.agent 的 13 个主体中，五个至少出现在 11 个编号组里，其中一个出现在 100 组。

这个数字可以从 ICANN 公布的 CSV 重算。文件有 891 行申请记录，分布在 263 个不同组号中。.agent 的 13 行都标为组号 3，但各自拥有不同的申请 ID。XYZ.COM LLC 出现在 100 个不同组号，Intercap Registry Inc. 出现在 54 个，Radix Technologies Inc SEZC 出现在 41 个，Charleston Road Registry Inc. 出现在 13 个，ECHO Domain Co L.L.C. 出现在 11 个。OPENAI OPCO, LLC 出现在 9 个。这里统计的是同一个组织名称所关联的不同组号，不是潜在胜者、客户数量或未来实际委派的域名数量。

因此，13 份申请落在同一冲突组，只能说明公开记录中有 13 份申请瞄准同一字符串。它不能说明有 13 家独立运营企业、13 项产品规划，也不能把用户需求量化为 13 份。某个申请名称反复出现，说明它在这份数据中的申请足迹更广；这仍不能证明名称相近的申请主体由同一集团控制。

记录能连接什么，不能证明什么

ICANN 公告说明，公开材料包含申请主体、申请字符串以及争议组文件，数据快照日期为 10 月 7 日。《申请人指南》第 5 模块说明，相同或变体字符串可能进入争议组，而且组的构成会随评估进展而改变。

但 CSV 不是企业股权结构图。它给出申请主体名称和申请 ID，本身并不证明最终受益所有人、共同管理、共享融资、拟任注册局运营商、商业路线图或运营准备度。每一项都需要独立证据。把法律申请名称直接当成已核实的集团关系，只会让数据集替分析者下结论。

陆恒的《唯一性协调权利法案》提供了一个治理边界：协调记录应维护唯一性与准确性，却不应被误读成更广泛的授权。在此处，争议组是对某个名称的竞争主张地图；它既不裁定谁更有资格获得命名空间，也不证明该命名空间已经形成市场。

比较申请主体，而不把它们合并

对于投资者、注册服务机构和基础设施管理者，信号不止是 .agent 在文件中组员最多。几个申请主体还出现在许多其他组，另一些只出现在一到四组。这种分布可以帮助安排尽调优先级、容量规划和情景分析，但不能预测谁会胜出，更不能确认最终由谁运营注册局。

严谨的市场模型应维护两本相互关联但各自独立的账。第一本保留申请主体的原始名称、申请 ID，以及每次出现的组号与日期。第二本记录有证据支持的母公司、关联公司、注册服务商或拟任运营商关系，并附来源与可信度。在证据真正连起两本账之前，不要把它们合并。

早期组合图很容易变成认知锚点。如果把组数当成控制力的证明，决策者可能高估市场集中度，或把申请活动误读为用户需求。如果保留身份线索并标注“尚未核实”，同一组数字仍能帮助提出问题，却不会沉淀为事实判断。

来源