ChatGPT-User

1. ChatGPT-User 是什么

ChatGPT-User 是 OpenAI 在一次实时 ChatGPT 对话当场需要某个页面时所发送的用户代理。有人提了问题、贴了链接，或者用到了某个 Custom GPT，而要回答这个问题，就得去取一个模型手里没有的网址。

OpenAI 在爬虫文档里把这条界线划得很清楚：ChatGPT-User「不会以自动方式抓取网页」（见 Overview of OpenAI Crawlers）。它是代表某个人去取页，而不是机器按自己的排期去取，后面所有的特殊之处都由此而来：robots.txt 的例外、独立的 IP 基础设施、安全厂商把它归入与两个同类完全不同的类别，根源都是同一件事，有人刚刚问了。

OpenAI 这一组程序里，它负责用户触发这一路，另外两个是 GPTBot（训练）和 OAI-SearchBot（搜索索引）。屏蔽其中任意一个，后果都与屏蔽另外两个不同，完整的推演见 AI 爬虫。

有一条结论比后面所有细节都更基本：日志里出现一次 ChatGPT-User 请求，就说明此刻有一个真人的问题落在你这一页上。这次请求失败，读者就在答案中途落了空，而且没有任何重试队列会把它补回来。

2. 什么会触发一次取页

OpenAI 点名了三个场景：

这里有一处空白，与其猜测不如挑明：OpenAI 的文档没有说明 ChatGPT 的定时任务发送的是哪个用户代理。robots.txt 例外的理由是「动作由用户发起」，可定时任务在凌晨六点运行时，提出请求的人还在睡觉，与这条理由并不贴合；那些运行到底携带什么令牌，公开资料里也没有任何一方说清。

触发方式决定了流量的形态：请求随对话而起，一阵一阵，而不是成批扫过整站；某个话题被讨论时来一簇，没人问的时候一个都没有。它的量级取决于外界的注意力，与你站点地图的大小无关。

这也意味着，多数团队习惯查看的那些报表里恰好看不到它：取回器不运行 JavaScript（见 §8），客户端统计因此从不触发。ChatGPT-User 只存在于服务器日志里。

3. OpenAI 不发送令牌的那些场景

ChatGPT-User 并不等于 OpenAI 代表用户取页的全部流量。只按它一个来写策略，实际管住的范围会比预想的小得多。

由浏览器驱动的那两类场景，从设计上就落在用户代理管控之外。它们是真正的 Chromium 实例，像人的浏览器一样渲染页面；即便表明身份，用的也是密码学签名，而不是产品令牌。OpenAI 没有为 agent 流量公布 IP 段文件：chatgpt-agent.json 返回 404，而 chatgpt-user.json 返回一份完整列表。

身份验证接下来的走向，就是这种带签名的 agent 请求。IETF 为自动化流量制定的 HTTP 消息签名规范已有多家大型基础设施厂商支持，Cloudflare 也记录了哪些程序会出示签名。而 ChatGPT-User 今天没有签名，核验它仍然只能靠 IP，见 §5。

OAI-AdsBot 补齐了 OpenAI 有文档的四个令牌。它只访问被提交为广告的页面，OpenAI 说明它收集的内容不用于训练基础模型。

4. robots.txt 与用户发起的例外

关于这个程序，问得最多的那个问题有明确答案，而答案的措辞本身很关键：

由于这些动作由用户发起，robots.txt 规则未必适用。

注意这里的分寸。是未必适用，不是不适用。OpenAI 把这块模糊地带原样留着，没有往任何一边收紧。

文档本身的写法里还有第二个容易被略过的信号。OpenAI 的总起句是：「OpenAI 使用 OAI-SearchBot 和 GPTBot 的 robots.txt 标签，让站长管理自己的站点和内容如何与 AI 交互。」这份可用于管控访问的标签清单里没有 ChatGPT-User。同样没有的还有 robots.txt 用户代理标记，也就是爬虫在抓取 robots 文件本身时附加的那段后缀，OpenAI 只为另外两个同类记录过它。一个根本不读这份文件的程序，自然也没有理由给那类请求打标记。

这套表述是在 2025 年 12 月 9 日收窄的。此前的版本用一句总起语涵盖了它列出的全部程序；修订把 robots.txt 管控明确限定到 OAI-SearchBot 和 GPTBot，并加上了「未必适用」那一句（见 Search Engine Roundtable）。准确的说法是 OpenAI 收窄了一句总起语，而不是撤回了一项承诺：更早的文本从未把 ChatGPT-User 单独确立为一个可用 robots.txt 管控的程序。

这套做法并非 OpenAI 独有。 Google 对自家用户触发取回器给出的说明如出一辙，措辞甚至更不留余地：

由于该次取页由用户请求发起，这些取回器一般会忽略 robots.txt 规则。

Cloudflare 的程序目录从外部得出了同样的结论：它把 ChatGPT-User 标记为不遵守 robots.txt，同时把 GPTBot 和 OAI-SearchBot 标记为遵守；而且这个判定覆盖它整个 AI 助手类别，涉及众多运营方旗下的数十个用户触发取回器。三条互相独立的线索指向同一个结论：OpenAI 自己的政策、Google 的平行先例，以及一家 CDN 对整个类别的归类。

有些第三方程序目录和 SEO 文章仍写着 ChatGPT-User 会遵守 robots.txt。这与 OpenAI 自己的文档相抵触，凡是把建议建立在这一说法上的工具，都值得复核一遍。

没有任何标准能裁定这件事。RFC 9309 完全没有涉及取页的动机，协议里也没有任何词汇能把一次排期抓取和一次为某个人发起的取页区分开。IETF 关于使用偏好表达的工作至今仍是草案，没有正式 RFC；更早一份提案想给协议补上用途令牌，也已过期未获采纳。各家运营方是在一处真实存在的空白里各自表态，所以今天能给出答案的是厂商文档，不是规范。协议本身的机制以及具体指令怎么写，见 robots.txt。

5. 在日志里辨认 ChatGPT-User

OpenAI 公布的完整用户代理字符串：

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot

规则只匹配裸令牌 ChatGPT-User，不要匹配版本号。 OpenAI 给这条字符串的标注是「完整用户代理字符串」，而给 GPTBot 和 OAI-SearchBot 的标注是「示例用户代理字符串（版本号可能变化）」。第三方程序目录对是否存在更高版本各执一词，而一条钉死在 1.0 上的规则，会在版本变化的那天悄无声息地失效。主流爬虫管理厂商都只匹配裸令牌，正是这个道理。

ChatGPT-User 有自己独立的 IP 段文件，这份文件本身就是一个可以直接核实的结构性事实。下表的数字是 2026 年 7 月 18 日从 OpenAI 公布的端点直接取回的：

这张表说明两件事。ChatGPT-User 占用的地址空间比两个同类高一个数量级，而且一段都不共用，这与它的工作方式吻合：取页要在人等着的时候完成，对延迟敏感，需要的出口比后台抓取宽得多。另一边，GPTBot 与 OAI-SearchBot 共用 6 个网段，正对应 OpenAI 说明过的做法：站点把两个都放行时，一次抓取可以同时用于两个用途。

核验只能靠 IP。ChatGPT-User 不出示任何请求签名，所以能用的手段只有两样：AI 爬虫里讲过的前向确认反向解析，以及上面这份公布的 IP 段。具体该 grep 什么、怎么确认真正到达服务器的是谁而不只是谁自称是谁，见 AI 爬虫访问审计。

Cloudflare 把 ChatGPT-User 列为已核验程序，这里还有一处实操细节值得知道：只有较高档位的套餐才能按厂商的检测 ID 写规则，其余套餐都要退回到匹配用户代理字符串。所以上面那条只匹配裸令牌的规则并不是写法偏好，对多数站点来说是唯一可行的写法。

6. 它到底有多少量

下面每一个数字都只在某一家厂商的样本里成立，而这些样本彼此不可比。一家 CDN 看的是自己的整张网络，一批出版商看的是自己的站点，两者对同一个程序给出的结论可以相差一个数量级，而各自放回自己的分母里都没错。这里给出的数字都注明了日期和样本口径，凡是这两样凑不齐的一律没有写进来。

在 Cloudflare 网络、2024 年 7 月至 2025 年 7 月这段区间里，ChatGPT-User 占 AI 与搜索程序合计流量的比例从 0.1% 升到 0.9%，占纯 AI 程序流量的比例从 0.2% 升到 2.4%。同一区间、同一张网络上，Cloudflare 按用途拆分的结果是：训练类从 72% 升到 79%，搜索类从 26% 降到 17%，而用户动作类只从 2% 温和升到 3.2%。

最后这个数字值得强调，因为它和一个流传很广的说法正好相反。在出版商样本里，也就是那些最常被人拿去问 ChatGPT 的新闻与参考类站点，检索型取页在 2025 年增长迅猛，训练类抓取则在下滑，ChatGPT-User 占 AI 流量的比例大致翻了一倍。两组结果对各自的样本都准确，但谁也不能推到对方身上；把出版商样本的数字当成全网事实来引用，就是错的。

引用这个程序的数字时还有两点要当心：

• 方向在 2026 年反转了。 多家追踪机构测到 ChatGPT-User 在 2026 年年中逐月下滑，同期竞争对手的程序则在上升。谈 2025 年的增长时要讲明那是当时的情况；「ChatGPT-User 正在增长」并不是当前数据支持的说法。
• 抓取引流比是按平台公布的，不是按令牌。 那些被反复转引的数字描述的是某家运营方的全部抓取，多数还停在 2025 年初的读数，而且被一个无法量化的因素抬高了：原生应用带来的引荐不发送 Referer 头，这一点 Cloudflare 在说明自家数据时也讲过。目前没有可信的、只针对 ChatGPT-User 的抓取引流比，凡是以这个名义出现的数字都是外推。

7. 屏蔽它的代价

关于这个程序，最昂贵的一处误解有一句成文说明可以直接澄清：

ChatGPT-User 不参与决定内容能否出现在搜索中。管理搜索的退出与自动抓取，请在 robots.txt 里使用 OAI-SearchBot。

屏蔽 ChatGPT-User 不会把你移出 ChatGPT 搜索，管那件事的是 OAI-SearchBot；也不影响训练，管训练的是 GPTBot。它唯一做到的，是让此刻正问到你这一页的那个人，在他提问的那一刻查不到你。

这笔账因此严重失衡：付出的是一个读者的答案，而在自动化那一侧几乎什么也没挡下，因为这个取回器本来就不会自作主张收集任何内容。

一键开关这一项，连谨慎的团队也会栽进去。Netlify 的文档对这一类别的表态相当直接，明确建议不要屏蔽：

这一类别的流量通常量不大，且直接由真人用户的请求发起。一般不建议屏蔽或限速这些请求，因为它们说明你的内容正被 AI 系统判定为相关而呈现出来。

然而行业里出的同类一键开关，实际上都把这个令牌和批量爬虫捆在一起。分类口径和产品行为经常对不上，所以判断一个预设要看它实际匹配了什么，而不是看它的标签承诺了什么。

Cloudflare 那个旧的「屏蔽 AI 爬虫」设置限定在训练用途，它「屏蔽的是被归类为以 AI 训练为目的进行抓取的已核验程序」，ChatGPT-User 因此落在范围之外，但这是限定范围带来的结果，并不是刻意留的口子。这一点将在 2026 年 9 月 15 日改变：Cloudflare 的文档写明，届时新接入的域名会在展示广告的页面上默认屏蔽 agent 类别的程序，搜索类别仍然放行，而 ChatGPT-User 正属于 agent 类别。如果你的站点今天还在依赖这种顺带放行，就该把这个日期当成必须把选择明确下来的期限。

所以稳妥的做法比一刀切要克制：训练与检索分开决定，判断依据见 AI 爬虫；指令怎么写见 robots.txt，同时心里清楚它对这个程序未必有约束力；最后在网络层核验真正到达服务器的是什么，而不是听信令牌或预设的说法。

8. 让这次取页能够成功

放行只是容易的那一半。更难的问题是，这次取页最终有没有取回值得被引用的东西。

它不执行 JavaScript。 Vercel 与 MERJ 在 2024 年针对大量 AI 爬虫请求的实测发现，OpenAI 的取回器会取走 JavaScript 文件却从不运行，一个纯客户端渲染的页面因此只会返回一个空壳。这项结论已有几年，OpenAI 也没有公布过任何变化，可以把它当作当前的工作假设，而不是一条永久保证。真正的例外是 §3 里由浏览器驱动的那两类场景：agent 模式和 Atlas 跑的是真正的 Chromium，会正常渲染。

同一项研究还发现，OpenAI 的取页里有相当可观的比例撞上了 404 和跳转。这一点值得多想一层：大量失败的 AI 取页其实只是普通的链接失效和跳转链，并没有什么高深的机制。修掉过期的站内链接，是这件事上成本最低的一项改进。

超时时长没有可信的公开数字，流传的那些具体秒数都找不到出处。与其给一个听上去笃定的猜测，不如承认这里有一处空白，按通用原则把响应做快，而不是去迎合某个来路不明的阈值。

还有一种失败方式值得点出来，因为它从站点内部完全看不见。为单个读者发起的取页，按限速和挑战规则的判定恰恰就是异常：来自陌生网段的一个孤立请求，周围没有任何抓取模式为它作证。针对采集器调校过的防护经常会拦下它，而拦下之后的失败又因为 §2 说过的原因不会出现在统计里。怎么诊断，见 AI 爬虫访问审计。

取页成功之后，这一页会不会被引用是另一个问题，取决于另一组因素：结构是否清晰、段落是否自足、论断被单独摘出来之后是否依然站得住，详见可引用性。至于 ChatGPT 什么时候才会去检索、检索之后倾向引用什么，见 ChatGPT 搜索。

llms.txt 常被一起提起，这里一并说明：OpenAI 没有任何文档表明 ChatGPT-User 会读它，发布一份 llms.txt 并不能改变这个取回器的行为。

9. 相关条目

• AI 爬虫：三分类模型，以及如何按类别决定放行还是屏蔽
• GPTBot：OpenAI 的训练爬虫，退出训练时该动的是它
• OAI-SearchBot：OpenAI 的搜索索引程序，管搜索收录的是它
• robots.txt：协议本身，以及指令怎么写
• llms.txt：它是什么，以及没有文档表明它能控制什么
• OpenAI：这四个令牌背后的运营方
• 可引用性：取页成功之后，这一页值不值得被引用
• AI 爬虫访问审计：核验真正到达服务器的是什么
• ChatGPT 搜索：这些取页所服务的引擎

参考资料

Primary

• OpenAI — Overview of OpenAI Crawlers
• OpenAI — Publishers and Developers FAQ
• OpenAI — ChatGPT-User published IP ranges
• Google Search Central — List of Google user-triggered fetchers
• IETF — RFC 9309: Robots Exclusion Protocol
• IETF — RFC 9421: HTTP Message Signatures
• IETF — A Vocabulary For Expressing AI Usage Preferences (draft)
• Cloudflare — Block AI bots
• Cloudflare — AI Crawl Control bot reference
• Netlify — User agent categories

Secondary

• Cloudflare — The crawl-to-click gap（2025 年 8 月 29 日）
• Cloudflare — Your site, your rules: new AI traffic options（2026 年 7 月 1 日）
• Vercel / MERJ — The rise of the AI crawler（2024 年 12 月 17 日）
• Search Engine Roundtable — OpenAI Updates Its ChatGPT Crawler OAI-SearchBot（2025 年 12 月 9 日）
• TollBit — State of the Bots, Q3/Q4 2025：出版商样本数据，样本量未披露，且该厂商销售爬虫变现产品