1. 一个网站现在其实有不止一种“AI 访问”#

把所有 AI crawler 放在一个开关里已经越来越不准确。

Cloudflare 当前把 AI bot preferences 拆成了 Search、Agent、Training 等用途。这个分类很重要，因为三个场景的价值交换完全不同。

1
AI = allow / deny

1
AI access = purpose × bot identity × path × enforcement layer

2. Bot Preference Sync 到底做了什么？#

根据 Cloudflare 8 月 22 日的官方说明，Bot Preference Sync 会让 robots.txt 与站点在 Cloudflare zone-level dashboard 中设置的 Search、Agent、Training 偏好保持同步。

如果站点本来已经有自己的 robots.txt，Cloudflare 不会简单把整个文件覆盖掉，而是把由 Bot Preference Sync 生成的内容放在现有内容之前，同时保留已有的 Disallow 指令。

这个设计看似只是文本拼接，实际上避免了一个很危险的默认行为：基础设施平台不能为了同步 AI 策略，顺手破坏站点原有 SEO/crawler 规则。

可以把它理解成两个来源：

1
Cloudflare AI bot policy
2
          │
3
          ▼
4
 generated directives
5
          │
6
          ├──── prepend
7
          ▼
8
 existing robots.txt
9
          │
10
          ▼
11
 final robots.txt response

这里最关键的词不是 robots.txt，而是 Sync。

3. 为什么“配置漂移”才是真问题？#

假设一个团队在 Cloudflare Dashboard 禁止 Training crawler，但仓库里的 public/robots.txt 仍然允许所有 User-Agent。

此时至少存在三份事实：

1. Git 仓库认为策略是 A；
2. Cloudflare 控制面认为策略是 B；
3. crawler 真正拿到的 HTTP response 可能又是 C。

如果开发者只 review Git，就可能误判生产环境；如果运营人员只看 Dashboard，也可能不知道源站还有额外规则。

这和我们在 IAM、WAF、Kubernetes policy 中经常遇到的 drift 本质相同：

策略存在多个写入口，却缺少一个可以持续验证的最终输出。

Bot Preference Sync 的价值之一，就是让最终公开协议更接近 Cloudflare 控制面的意图。

但这并不意味着 Git 里的 robots.txt 从此可以不管。相反，我更建议把生产环境的最终响应纳入自动化验证。

4. robots.txt 不是安全边界#

这是最容易被误解的一点。

robots.txt 是声明式 crawler policy，不是身份认证，也不是网络 ACL。

一个不遵守规则的客户端完全可以请求：

1
GET /private-but-publicly-routable-page

服务器不会因为 robots.txt 写了 Disallow 就天然拒绝它。

所以一个完整架构应该把两件事分开：

1
Preference layer
2
robots.txt / crawler policy
3
        │
4
        ▼
5
告诉守规则的客户端：站点希望什么
6

7
Enforcement layer
8
WAF / bot management / auth / rate limit
9
        │
10
        ▼
11
服务器实际上允许什么

如果内容真的不能被第三方访问，就不应该依赖 robots.txt 保密。

这一点和 MCP、Agent tool permission 的设计非常像：Prompt 里的“请不要调用危险工具”不是权限系统；robots.txt 里的“请不要抓取”也不是访问控制。

5. 为什么 Search、Agent、Training 应该分开？#

站长真正需要的不是一个粗暴的“Block AI”按钮，而是一张目的矩阵。

例如一个技术博客可能希望：

这张表没有普适答案。

文档站、新闻站、个人博客、SaaS Dashboard、付费内容站的最优策略完全不同。真正重要的是不要把“AI crawler”当成单一角色。

6. 对开发者站点，最值得加的是 production contract test#

如果我给自己的博客接入这类功能，我不会只在 Dashboard 点完开关就结束，而会增加一个很轻量的 production check。

例如 CI 或定时任务验证：

1
curl -fsSL https://example.com/robots.txt

然后检查几个不变量：

1
1. 原有 Search Engine 规则仍存在
2
2. Training bot 的预期规则存在
3
3. 关键 Disallow 没有被同步逻辑删除
4
4. HTTP status = 200
5
5. Content-Type 合理
6
6. CDN 与 origin 返回结果符合预期

这里不要机械 snapshot 整个文件，因为平台可能调整生成顺序。更稳妥的方法是验证语义 predicate。

伪代码可以写成：

1
expect(robots).toContain(expectedTrainingPolicy)
2
expect(robots).toContain('/admin')
3
expect(robots).not.toContain(secretValue)

这样 robots.txt 就从“某个没人看的静态文件”变成了一份可测试的 production contract。

7. CDN 生成 robots.txt 后，要特别关注缓存#

任何“边缘层动态修改静态文件”的能力都会带来一个工程问题：你看到的到底是哪一层？

排查时至少应该分别确认：

1
Repository robots.txt
2
        ↓
3
Origin response
4
        ↓
5
Cloudflare edge transformation
6
        ↓
7
Cache
8
        ↓
9
Public response

如果刚改完策略却仍看到旧内容，不应该第一时间判断同步失败，而应该检查缓存、部署传播和请求是否真正经过目标 zone。

对于多域名项目还要进一步确认：

• apex domain 与 www 是否走同一 zone；
• preview/staging 是否应该继承 production policy；
• 静态资源域名是否真的需要 crawler；
• API 子域名是否应该直接通过认证而不是 robots policy 管理。

8. Agent 时代，robots.txt 还缺什么？#

Bot Preference Sync 解决的是“偏好同步”，但未来 Agent Web 还会需要更丰富的机器可读契约。

传统 crawler 的动作基本是：

1
fetch → index

Agent 的动作可能是：

1
fetch → reason → follow link → submit → mutate state

这时单纯的 Allow/Disallow 已经无法描述完整权限。

未来更值得期待的 Web policy 可能需要表达：

1
read: allowed
2
index: allowed
3
train: denied
4
form-submit: approval-required
5
purchase: denied
6
rate: 30 requests/minute
7
identity: signed-agent-required

这和今天 MCP 从“工具能不能发现”继续演进到 OAuth、approval、tool-level policy 的路线非常相似。

robots.txt 不太可能独自承担这些职责，但 Bot Preference Sync 至少说明一个趋势：Web 正在重新设计人与机器代理之间的访问契约。

9. 一个更实用的上线检查表#

如果你准备启用类似策略，我建议按下面顺序做，而不是只点一个开关：

10. 我更关注的不是 robots.txt，而是 Policy-as-Code 的反方向#

过去基础设施工程一直在把 Dashboard 配置迁移到 Git：Infrastructure as Code、Policy as Code、GitOps。

Bot Preference Sync 看起来却像反方向：控制台里的策略被同步到一个公开文本协议。

但两者并不冲突。

真正成熟的系统应该允许：

1
Intent
2
  ↓
3
Control Plane
4
  ↓
5
Enforcement
6
  ↓
7
Observable Public Contract
8
  ↓
9
Continuous Verification

Git 负责版本化意图，平台负责执行，外部 probe 负责验证最终事实。

如果只拥有其中任意一层，我们都很容易把“我配置了”误认为“它真的生效了”。

结语#

Cloudflare Bot Preference Sync 并不是一个会改变 Web 协议栈的大功能，但它踩中了 AI crawler 时代一个非常实际的痛点：同一个站点的 AI 使用偏好正在越来越细，而策略入口也越来越多。

对普通博客来说，它最大的意义不是让 robots.txt 变得更复杂，而是让 Search、Agent、Training 三种完全不同的价值交换第一次更明确地进入站点运维流程。

我认为开发者真正应该带走三点：

1. 不要再把所有 AI bot 当成同一种流量。
2. 不要把 robots.txt 当安全边界。
3. 不要相信某个控制台显示的配置，应该验证生产环境最终返回的 contract。

AI Agent 正在让 Web 从“给浏览器和搜索引擎看的页面”，逐渐变成“同时给人、搜索、模型和自主代理消费的接口”。当客户端角色越来越复杂，访问策略也必然从一个简单的 User-agent: * 继续向更细粒度的机器身份与用途控制演进。

参考资料#

• Cloudflare Blog, Say it once: introducing Bot Preference Sync, 2026-08-22
• Cloudflare Developers, AI crawler / bot management 相关文档
• Robots Exclusion Protocol（RFC 9309）