验证过的机器人，为什么还会被Cloudflare拉黑？

一张驾照能告诉你这个人是谁、他通过了驾驶考试，但它没法保证他以后开车一定规矩。机器人也是同样的道理：验证运营者身份能建立问责基础，但信任取决于它接下来做什么。一个身份已知的机器人，照样可能无视网站偏好、压垮源站、绕过控制手段。这未必是恶意，很多时候只是配置错误或者一个bug。

Cloudflare在博客里把验证机器人拆成两个问题："你是不是你自称的那个人？"和"我们能不能信任你？"要成为Cloudflare验证机器人，大致要满足三条标准：

• 准确且安全地表明自己的身份
• 只做自己声明会做的事
• 不从事滥用行为

机器人通过Web Bot Auth对请求签名来确立身份，BotBase再以开放格式把这些身份编入目录。身份问题解决之后，重点就落到第二条：不得作恶。

这里要区分风险和信任。风险描述的是某一个请求或某一时刻的行为有多大可能造成伤害，它随时可能变化；信任则是通过长期、反复、一致的行为积累起来的。举个例子，2025年Perplexity的机器人被从验证机器人名单中移除，原因是它试图访问那些明确选择退出抓取的网站资源，并在请求被拦截后试图绕过控制。

"不从事滥用行为"听起来像句废话，但里面门道不少。当爬虫不尊重网站偏好，信任就被削弱；当网站要求爬虫不要抓取或者放慢速度，爬虫却无视这些要求，信任同样被削弱。

Cloudflare开发了一套系统来衡量爬虫尊重网站偏好的频率，这些观察会转化成一个可解释的"信任区间"——一个显示机器人有多稳定地尊重网站偏好、以及哪些观察到的行为支撑了这一评估的范围，而不是对某个机器人或其运营者下的永久判决。目前评估的初始信号有两个：机器人是否遵守指令？它是否对直接反馈作出回应？

这些被视作"常识"规则，是对那些提供机器人所需信息的运营者的一种礼貌。未来这些分数会在Radar上公开分享，衡量方式也会扩展。这套分数给负责任的机器人运营者提供了一条途径，证明信任在长期得到维护。验证，但要持续再验证。

robots.txt文件是传达网站所有者偏好的主要方式。这套系统会考察机器人的实际流量是否长期与已发布的偏好一致。robots.txt告诉所有或特定机器人只能抓取网站的特定部分。孤立的违规和其他一次性行为可能并不严重，真正要找的是反复出现的、无视网站偏好的行为模式。对负责任机器人的期望很简单：查阅并遵守网站发布的偏好，符合RFC 9309。

需要说清楚的是，robots.txt设定的是机器人不应做什么的最低规则，但这不意味着没写出来的就都可以做。比如，网站可以通过其他信号传达继续访问不受欢迎，robots.txt并不需要写明机器人必须停止。

机器人完全可能待在允许的路径内，却给访问的网站带来巨大负载。网站最明确的反击方式之一是HTTP 429（"请求过多"）响应。429是在指示访问者降低请求速率，有时还会给出等待多久再重试的指引。这套系统会考察机器人在收到该信号后流量是否调整：它是放慢、暂停，还是以同样节奏继续发送请求？这种行为会随时间被纳入机器人的信任区间——持续放慢或暂停会提升信任，反复无视信号则会降低信任。

观察这些信号只是让验证自动化实现长期问责的第一步。把机器人身份与持续行为的证据配对，能让网站所有者更有信心：他们选择放行的机器人正在尊重其偏好；也让机器人运营者有办法证明自己值得信任；同时为网站所有者提供关于到达其站点的自动化流量的背景信息。

这套系统与Bot Preference Sync、Bot Management一起，构成自动化流量的问责闭环。Bot Preference Sync帮助网站所有者发布偏好，观察机器人如何与这些偏好互动则显示验证机器人是否长期遵守它们，Bot Management让网站所有者决定如何处理这些流量。三者合力，确保信任是通过透明、可问责的行为赢得的，而不是仅凭身份就被假定拥有。

Cloudflare已经在内部使用这套系统评估验证机器人遵守网站偏好的稳定程度。因为信任是长期建立的，评估的是持续模式而非孤立事件。这一初始阶段用来积累历史、打磨如何把观察转化为有用的指引。在此基础上，计划让所有Cloudflare客户都能使用这套系统，客户可以选择用哪个信任阈值来决定如何处理验证机器人流量。目标很直接：让网站偏好保持有意义，确保信任通过持续行为赢得。