AI 爬虫的用户代理有几十个，训练类和检索类要分开挡吗

AI 爬虫的用户代理有几十个，但按名字一条条记不如按用途分：训练类、检索类、用户发起类。分开挡的理由是三者的收益完全不同——训练类把你的内容吸收进模型，站点得不到回流；检索类和用户发起类会直接把访客带回站点。清单只解决「有哪些名字」，分组才解决「哪些该放、哪些该挡」。

训练类和检索类分别指哪些用户代理

按用途分组后，常见的用户代理可以这样归类：

一份 2026 年的可见度优先清单给出的是 14 个相关用户代理名，另一份按月更新的清单已经列到 35 个 AI 爬虫。条数差异来自收录口径不同：前者只挑与可见度直接相关的 token，后者把各家产品线的抓取程序都算进来。所以「几十个」是常态，但要处置的是类别，不是全部名字。

训练类的判定可以参考官方描述：GPTBot 收集的内容可能被用于训练其生成式基础模型。这正是它适合与检索类分开处理的原因。

robots.txt 里怎么只挡训练不挡检索

robots.txt 的表达能力是按用户代理分组写规则，所以分开挡的写法是：为训练类单独起一组 Disallow，检索类和用户发起类各自单独允许。写的时候有两个要点。

第一，token 名要逐条列。笼统地写一个「AI 爬虫」分组不起作用，规则只识别具体的用户代理名。第二，同名不同程序要分别核对，例如搜索类与训练扩展类是两个名字，收紧其中一个不等于收紧另一个。

对以可见度为目标的站点，通行的建议是放开检索类与用户发起类、对训练类做限制，方向与「挡所有 AI」正好相反。这不是立场问题而是指标问题：如果你要的是被引用和带回访客，那么把带流量的抓取一起挡掉，等于同时削掉了可见度来源。

只写一条 Disallow 为什么会连带影响被引用

一条覆盖全部用户代理的 Disallow 是粗暴做法的典型后果：训练类、检索类、用户发起类被一并拒绝，站点确实不再被拿去训练，但也不会再出现在回答里。分组写规则的意义就是把这三类拆开决定，让「限制训练」和「保持可见」能同时成立。

另一个常见错误是只改 robots 而忽略访问控制的其他层。robots.txt 表达的是抓取意愿，服务器侧的限速与拦截是另一套机制，两边口径不一致时，实际到访的就会与预期不符。

AnQiCMS 后台改 robots 与生成 llms.txt 的操作顺序

两者分工不同：robots.txt 控制能不能访问，llms.txt 控制大语言模型该读哪份导航。AnQiCMS（安企内容管理系统）后台提供 Robots.txt 配置，并支持自动生成站点的 llms.txt，便于大语言模型理解与索引站点内容，GEO 相关的后台模块与 SEO 模块在同一组配置面里。

操作顺序建议这样排：先按分组整理用户代理清单，再改 robots 配置，确认生成结果与预期一致，然后检查 llms.txt 里指向的内容入口是否是希望被引用的页面，最后用一段时间看服务器日志里实际到访的用户代理，验证规则是否按预期生效。

常见问题

直接封全部 AI 爬虫省事吗

省事但代价明确：训练类被挡住的同时，检索类与用户发起类也被拒，站点的可见度与回流一起下降。分组处置的成本只多写几行规则。

清单要多久更新一次

按季度看一次足够，重点不是把所有新名字抄进规则，而是判断新名字属于哪一类。归好类之后，加名字只是同组里追加一行。

改了 robots 多久能看到效果

抓取侧的变化通常在数天内体现，但要以日志为准。核对方式是统计规则修改前后各类用户代理的到访量，而不是凭印象判断。

llms.txt 能代替 robots.txt 吗

不能。llms.txt 是导航建议，不构成访问控制；要真正限制某类抓取，仍需在 robots 配置与服务器侧同时表达。