Cloudflare 针对 Verified Bots 的持续问责机制，将身份转化为持续测试

Cloudflare 于 10 月 16 日为 Verified bots 推出持续问责机制，在此前以身份为核心的计划中加入了持续行为测试。这一转变旨在解决一个根本矛盾：爬虫可以证明运营方身份，却仍可能无视网站规则。

新系统会观察经验证的自动化程序是否尊重已发布的偏好设置，以及在网站要求其减速时是否作出响应。Cloudflare 随后会将这些观察结果转化为可解释的信任区间，而非将验证视为永久有效的批准印章。

这一区别之所以重要，是因为 Cloudflare 曾在 2025 年将 Perplexity 从其 Verified Bots 名单中移除。Cloudflare 指称，Perplexity 访问了受限内容，并在遭拦截后改变了爬取策略。Perplexity 对这一说法提出异议。这一事件暴露出 Cloudflare 现在试图解决的弱点：认证能够识别机器人，但身份本身无法保证良好行为。

针对 Verified Bots 的持续问责机制新增行为层

Cloudflare 正将验证从一次性的身份判定，转变为对行为的持续评估。

Cloudflare 的 Verified Bots 计划历来帮助网站将已知自动化程序与未知或可能存在恶意的流量区分开来。搜索爬虫、监控服务、无障碍工具和用户指令型代理都可以申请验证状态。

机器人必须通过认可的方法表明自身身份。这些方法包括加密签名、与稳定用户代理配对的已公布 IP 范围，以及反向 DNS 检查。

Cloudflare 的 Verified bot policy 还要求不得存在滥用行为。经验证的服务应遵守 robots.txt 指令，维持合理的请求速率，并避免规避网站偏好设置。

问题在于时间维度。运营方可以在注册时满足这些条件，随后部署改变爬虫行为方式的更新。配置错误也可能在并无恶意意图的情况下造成有害流量。

Cloudflare 的新系统会监测这一缺口。它衡量爬虫长期遵循网站偏好的稳定程度，并记录评估所依据的行为。

结果是一个可解释的信任区间。Cloudflare 将其描述为反映持续行为的范围，而非对某家公司或运营方作出的永久判断。

这一框架将风险与信任区分开来。风险关注特定请求或特定时刻可能造成的伤害；信任则反映多次互动中反复出现的模式。

经验证的爬虫可能因一次意外的政策违规而不再完全可信，但并不意味着它会被归类为不可信。反过来，反复无视限制的机器人，不应仅因通过了先前的身份检查就继续获得特殊待遇。

Cloudflare 表示，其首批评估信号聚焦于两个问题：机器人是否遵守已发布的指令，以及它是否会对网站的直接反馈作出响应？

这些信号聚焦于可观察的网络行为。它们不要求 Cloudflare 推断爬虫运营方的私人意图。

这种方式也为运营方提供了恢复途径。只要机器人在收到指令或速率限制响应后持续调整自身行为，信任区间就可以改善。

Cloudflare 已在内部使用该系统。该公司表示，待积累足够的行为历史并完善相关指引后，计划向客户开放这一评估结果。

客户最终将能够为处理 Verified Bot 流量选择信任阈值。Cloudflare 尚未公布正式全面可用日期，也未披露确切的评分公式。

这些未披露信息很重要。此次公告界定了指导原则和初始信号，但尚未提供完整的产品规格。

不过，方向已很明确。验证状态将越来越意味着，机器人既保持可识别性，也持续在可接受的边界内行事。

为什么身份已无法独自承担完整的信任判定

加密身份能够回答是谁发出了请求，却无法回答该请求是否应受到欢迎。

Cloudflare 多年来一直在强化机器人识别能力。用户代理字符串和 IP 地址等传统信号存在严重局限。

用户代理只是 HTTP 请求中发送的标签，其他程序可以复制它。IP 范围可能发生变化、服务于多个系统，或遭到入侵。

Web Bot Auth 改进了这一身份层。它允许机器人使用 HTTP Message Signatures 对请求签名，从而提供由获授权运营方创建请求的加密证据。

Cloudflare 会验证签名，并将流量关联至其公开机器人和代理目录 BotBase 中的条目。这减少了对容易被伪造的标识符的依赖。

底层签名格式并非 Cloudflare 独创。HTTP Message Signatures 已通过 RFC 9421 实现标准化，而 Web Bot Auth 规范仍在以开放方式持续发展。

签名验证仍然只能解决认证问题。有效签名可以证明请求来自已知运营方，但无法证明该运营方遵守了发布者的限制。

设想一个监控机器人：它正确签署每一项请求，却在一次错误部署后，开始以数百倍速度请求页面。即使其行为造成运营成本，身份仍然有效。

同样的问题也适用于 AI 爬虫。爬虫可以准确表明自身身份，却仍请求网站已标记为不适用于其用途的内容。

随着自动化承担更多角色，这一缺口愈发重要。Cloudflare 现在将经验证系统划分为搜索、模型训练、用户指令型代理、交易、安全测试、数据收集及其他活动等类别。

部分机器人还充当中介。其基础设施属于一家公司，但许多用户都可以通过它发起操作。

这形成了 Cloudflare 所称的传递性信任。网站可能信任平台运营方，却未必信任每一位指挥该平台代理的用户。

针对 Verified bots 的持续问责机制并不能完全解决这一委托问题。不过，它让 Cloudflare 能够评估由此产生的流量，而不是完全依赖运营方的身份。

这一变化也促使机器人运营方将合规性构建进生产系统。良好行为不再能只是注册时记录的一项承诺。

运营方需要可靠地获取 robots.txt、进行具备政策意识的 URL 选择、采用用途专属的身份标识，并实施自适应速率控制。他们还需要监控机制，在 CDN 记录到有害模式之前发现回归问题。

这提高了经验证自动化的工程标准。认证成为准入要求，而可观察的合规性则决定由此产生的信任能否持续。

Robots.txt 和 HTTP 429 成为证据，而非建议

Cloudflare 的机制将两个熟悉的 Web 信号转化为衡量爬虫持续信任水平的证据。

第一个信号是 robots.txt，这是位于网站顶级路径的文本文件，用于发布针对自动化爬虫的访问指令。

该协议按用户代理组织规则，并使用 Allow 或 Disallow 指令标明可访问路径。根据 RFC 9309，成功下载该文件的爬虫必须遵循其中可解析的规则。

Robots.txt 存在实际局限性。它传达的是偏好，而不像认证门槛或防火墙规则那样实施强制约束。

它也很少说明爬虫为何需要特定内容。一家运营方可能为搜索、模型训练和用户请求检索分别使用不同机器人；另一家则可能将这些用途合并。

Cloudflare 会评估观测到的流量是否持续符合网站已发布的规则。该系统强调重复出现的模式，而非将每一次孤立的不匹配视为决定性因素。

这种区分降低了暂时性错误自动破坏机器人信誉的概率，也使持续无视规则的行为更难被视为异常。

Cloudflare 提醒，robots.txt 代表的是最低边界，并不意味着网站未禁止的一切行为都获得全面许可。网站还可以通过其他响应传达继续访问并不受欢迎的信息。

HTTP 429 是第二个初始信号。服务器使用这一状态码表示客户端在给定时间段内发送了过多请求。

响应可以包含 Retry-After 标头，用于告知客户端需要等待多长时间。但这一指引并非强制要求。

相关 HTTP 标准 允许服务器灵活决定如何识别过量流量并统计请求。服务器可以按资源、凭据或其他维度实施限制。

Cloudflare 会观察机器人接下来的行为。机器人在多次收到 429 响应后减速或暂停，表明其具备适应能力；若仍以相同速率继续请求，则会失去信任。

这使速率限制处理成为已验证机器人问责机制的一部分。它也堵住了一个重要漏洞，因为爬虫即使始终位于允许访问的路径内，仍可能压垮源站。

这一组合机制形成了行为反馈闭环。发布者声明访问偏好，源站提供实时反馈，而 Cloudflare 则观察爬虫的响应。

Bot Preference Sync 支持这一闭环中的发布环节。它会将客户配置的 AI 流量偏好转换为相应的 robots.txt 条目。

Cloudflare 的 Bot Management 工具提供执行环节。客户可利用已识别类别和其他信号，允许、阻止、质询或限制流量速率。

持续评估位于这些组件之间。它考察已知机器人在遇到已发布和已执行的政策后，是否确实按预期行事。

因此，该系统在两个不同时间尺度上衡量合规性。Robots.txt 反映相对持久的网站政策，而 HTTP 429 传达即时压力。

可信赖的爬虫必须兼顾两者。它应围绕长期限制规划请求，并在当前条件变化时调整行为。

Perplexity 表明 Verified Bot 问责为何充满争议

Perplexity 争议既显示了行为证据的价值，也揭示了由单一基础设施提供商定义信任的风险。

Cloudflare 表示，在客户报告称 Perplexity 继续访问其运营方试图阻止 AI 爬虫的网站后，公司开始展开调查。

该公司创建了新的、未被索引、且受到 robots.txt 限制保护的测试域名。随后，Cloudflare 向 Perplexity 提交了需要这些域名信息的提示词。

Cloudflare 称，尽管存在这些限制，Perplexity 仍获取了详细信息。Cloudflare 还指称，当已声明的代理遭遇拦截时，爬取活动转而使用未声明的基础设施和通用浏览器身份。

Cloudflare 将这一行为与涉及 OpenAI 的测试进行了比较。该公司表示，ChatGPT 在 robots.txt 禁止访问时会停止，也会在遇到网络拦截时停止。

Cloudflare 随后将 Perplexity 的机器人从其已验证列表中移除，并新增了旨在阻止所称隐蔽爬取行为的托管检测规则。

Perplexity 否认了这一指控。据报道，该公司称 Cloudflare 的说法是一种营销推销，并认为 Cloudflare 识别出的流量并不属于 Perplexity。

这一分歧并没有因为 Cloudflare 现已提供信任等级而消失。任何行为评级仍取决于归因、测量设计和政策解读。

当 AI 服务使用多层检索机制时，归因尤其困难。一个回答可能来自已声明的爬虫、第三方索引、由用户指引的浏览器，或由其他提供商运营的基础设施。

CDN 可以观察众多网站上的请求模式，但未必总能看到每个请求背后的商业关系或用户意图。

同样，运营方可能会将用户指引的抓取与大规模自主爬取区别对待。当两种行为都复制同一受限页面时，发布者可能不会接受这种区分。

相较于二元标签，Cloudflare 提出的信任等级更适合处理此类争议。它可以呈现行为模式，并指出哪些行为影响了评估结果。

但可解释性不能止步于简短标签。运营方需要足够的细节，以识别导致较低评级的请求、政策、时间范围和补救措施。

申诉机制同样重要。错误归因可能损害合法机器人，导致客户在大量受 Cloudflare 保护的网站上将其屏蔽。

权力集中也带来了另一项担忧。Cloudflare 提供偏好设置工具、观察流量、计算信任评估，并提供执行产品。

这种整合让问责闭环具备可操作性，但也使 Cloudflare 对哪些自动化服务能够访问网络的大部分区域拥有显著影响力。

因此，该公司应披露其如何处理模糊情形、混合用途代理、共享基础设施和临时故障。缺乏程序性保障的评分，可能演变为不透明的信誉系统。

已验证机器人的问责还要求运营方提供对等的透明度。企业应记录其用户代理、用途、IP 范围、签名密钥以及对网站限制的响应方式。

为搜索、训练和用户指引的检索使用独立身份，可以减少歧义。这让发布者能够允许有价值的发现功能，而无需向所有自动化用途授予同等访问权限。

Perplexity 一案仍应被视为警示，而非普遍结论。Cloudflare 提出了技术观察结果，而 Perplexity 对相关流量的归属和解读提出了异议。

这一未解决的冲突，恰恰说明新系统需要透明证据。只有受影响方能够审查并质疑其结论时，持续测量才有价值。

信任等级仍留下关键未解问题

Cloudflare 已说明希望衡量什么，但尚未充分说明最终判断将如何运作。

该公司尚未公布 robots.txt 违规、忽略 429 响应或其他未来信号的权重规则，也尚未定义不同信任等级之间的边界。

缺少这些细节，客户无法独立预测爬虫行为将如何转化为评级。机器人运营方同样缺乏一套完整的合规技术目标。

Cloudflare 表示，它将评估持续性模式，而不是孤立事件。这是一项合理保障，但“持续”需要一个可衡量的时间窗口。

一个发送数百万请求的爬虫，即使违规率极低，也可能产生大量意外违规。较小的爬虫则可能针对单一源站发送远少于前者的请求，却造成严重损害。

原始数量会扭曲这些情形。百分比也可能掩盖暂时压垮脆弱网站的严重突发流量。

可信的评分模型需要上下文。这包括请求量、源站容量、政策的时效性、Retry-After 指令、响应一致性，以及爬虫已接收到信号的证据。

Robots.txt 还引入了另一层歧义。文件可能无法访问、配置错误、相互矛盾、在爬取期间发生变化，或被中间方修改。

Cloudflare 的 Bot Preference Sync 通过使控制面板设置与已发布偏好保持一致，减少了部分配置漂移。但它无法消除与自定义规则或源站行为之间的所有冲突。

HTTP 429 同样并不完美。有些网站会因广泛的安全设置、共享基础设施或错误识别流量而生成这类响应。

HTTP 规范并不要求服务器在高负载下使用 429。网站可以断开连接或采取其他控制措施，使爬虫获得的反馈不那么明确。

因此，Cloudflare 需要避免将每一次 429 都视为不当行为的证据。重要证据是：在信号可归因且可理解的条件下，爬虫持续未能作出调整。

客户自选阈值带来了更多复杂性。两个网站可能会以不同方式处理相同的信任等级，这支持了本地控制，却让运营方的预期更难管理。

这种设计可能优于统一的允许或屏蔽决定。发布者拥有不同的商业模式、基础设施限制，以及对 AI 发现功能的不同态度。

零售商可能欢迎频繁的代理访问，以支持商品推荐。一家依靠广告收入的发布者则可能限制训练爬虫，同时允许能带来可衡量引流的搜索系统。

Cloudflare 应保留这些差异，而不是把所有行为压缩为单一的全球道德排名。按用途划分的信任评估，比单一混合评分能提供更有用的控制。

该公司还需要说明恢复机制。机器人运营方应知道，纠正后的行为会多快改善其评估，以及历史事件是否会随时间衰减。

否则，持续问责可能换个名字就变成永久惩罚。这将与 Cloudflare 将信任描述为通过重复行为建立的说法相矛盾。

公开报告将是决定性考验。Cloudflare 表示计划通过 Radar 分享评分，但公告并未说明其中的呈现方式或可获得的证据。

可信的公开系统应区分观察结果与结论。它应展示相关时间范围、置信度、测量信号以及行为的重要变化。

它还应标注存在争议的归因。Cloudflare 的可见性很广，但可见性并不能消除不确定性。

网站所有者和机器人运营方接下来应关注什么

接下来的考验在于，Cloudflare 能否将其问责原则转化为透明且可质疑的运营体系。

首先要关注的信号是公开的 Radar 发布。Cloudflare 表示计划发布信任信息，使评分不再局限于其内部系统。

有用的问题并不是 Radar 是否新增了另一个徽章。读者应审视每个信任等级是否包含具体行为、时间窗口，以及足以解释变化的证据。

详尽的报告将强化 Cloudflare 的核心主张。一个简单标签则会削弱它，因为这要求市场在看不到评分逻辑的情况下信任评分者。

第二个信号是面向客户的可用性。Cloudflare 计划让客户选择决定如何处理 Verified Bot 流量的阈值。

这一发布将揭示，信任是作为信息字段、规则构建输入，还是自动执行机制发挥作用。这些选项带来不同的运营风险。

可见字段支持人工审查，但会增加工作量。自动执行更具扩展性，但错误可能会阻断搜索索引、监控、无障碍服务或用户指引的代理。

客户还应关注系统如何与现有允许列表交互。由于 Cloudflare 已认可已验证机器人，它们过去一直得到较为优待的处理。

动态信任阈值可以在行为变化时缩小这种特权。如果管理员仍假定“verified”意味着普遍安全，它也可能让政策管理变得更困难。

第三个信号是运营方的响应。主要爬虫提供商可以通过采用签名身份、区分用途并发布更清晰的合规实践，来验证 Cloudflare 的模型。

它们也可以用技术证据对模型提出质疑。关于请求归因、robots.txt 解读和限速处理的争议，将暴露该方法论的弱点。

关注描述 429 响应后退避行为的文档，也关注覆盖搜索、训练和用户指引检索的独立标识符。

这些做法将加强这样一种观点：可问责的自动化可以通过共享的网络标准运行。持续存在的模糊性则会强化更严格网络执行的理由。

对于网站所有者而言，对 Verified 机器人的持续问责提供了比永久验证更现实的信任模型。它承认软件变更和运营错误会在获批后发生。

它不应取代直接控制。发布者仍需要明确的偏好设置、适当的速率限制、流量日志，以及与其商业目标一致的执行规则。

对机器人开发者而言，信息同样直接。加密身份可以赢得认可，但持续行为决定这种认可是否仍然有用。

构建代理的团队应将网络访问政策视为生产要求。他们应测试 robots.txt 解析、遵守访问限制、实施自适应退避，并监测跨部署的变化。

开发者还需要保留能够说明代理为何访问某项资源的持久记录。当平台、发布者和中间方对请求用途存在分歧时，这一点至关重要。

知识工作者面临一个相关问题。代理生成的回答越来越依赖于在用户视野之外运行的检索系统。

更完善的问责层可以帮助用户了解这些系统是否以透明方式访问来源。它也能揭示，便利性何时建立在发布者明确拒绝的行为之上。

如今的网络需要的不只是机器人身份识别。它还需要一种机制，将身份、声明用途、观察到的行为和相称后果联系起来。

Cloudflare 提出了一种这样的系统，但其合法性将取决于证据和正当程序。该公司必须证明，信任等级准确、易于理解，并且能够得到纠正。

未来几个月，请关注公开评分、客户控制措施和爬虫运营方的响应。它们将共同显示，持续问责会成为共享标准，还是另一层私有化的准入把关。

网站所有者应在自动化执行前，将 Cloudflare 最终的评级与自己的日志进行比对。机器人运营方现在就应审计其对 robots.txt 和 HTTP 429 的响应。

核心问题不再是机器人能否证明其身份，而是在经历数千次请求、政策变化和不可避免的软件更新后，该身份是否仍然保持可问责性。