Cloudflare 重构了 AI 爬虫管控体系：原先“一键拦截所有 AI 机器人”的总开关，被拆成 Search、Agent、Training 三个独立选项，而且包括免费版在内的客户都可以分别配置。变化看似只是多了几个开关，实质上却把一个模糊的“是否允许 AI”问题，变成了三种目的、三套收益与三类风险的访问决策。
同样读取页面，业务目的并不相同
三段式分类最重要的价值，是把访问者身份之外的“使用目的”纳入策略。
- Search：抓取内容用于建立索引，并在用户查询时返回搜索结果或答案。站点通常需要在内容曝光、引用机会和流量回流之间权衡。
- Agent：智能体代表用户访问网站，例如读取页面、比较信息或执行任务。它更接近实时交互，可能访问动态页面，也可能触发登录、下单或表单提交等敏感流程。
- Training：收集内容用于模型训练。它带来的即时回流通常不如搜索明确，却可能涉及版权、许可、商业数据和内容再利用边界。
过去的总开关会迫使站点二选一：全部放行，或者全部拒绝。拆分以后，一个内容站可以允许 Search、谨慎开放 Agent，同时拒绝 Training；一个 SaaS 控制台则可能对三类爬虫全部关闭，只通过正式 API 向经过授权的智能体提供数据。
需要注意的是，分类解决的是策略粒度，不会自动解决身份可信度。User-Agent 可以伪造，机器人也可能改变用途。真正的执行仍要依赖平台识别能力、访问日志、速率限制、认证机制和应用层授权。
不要把 Agent 当成另一种搜索爬虫
Agent 与 Search 的关键区别，是前者可能执行动作。搜索抓取通常集中在公开、可缓存的内容；智能体访问则可能进入具有副作用的接口。
因此，开放 Agent 不应等价于允许它访问整个站点。可以按路径划分边界：
| 路径类型 | 建议策略 | 原因 |
|---|---|---|
| 公开文章、产品文档 | 可按需允许 | 内容本身面向公开访问 |
| 搜索和只读目录接口 | 限速后允许 | 容易被高频调用，需要控制成本 |
| 账户、账单和订单页面 | 要求认证 | 包含用户数据或业务状态 |
| 创建订单、发送消息等写接口 | 默认拒绝，单独授权 | 请求具有副作用 |
| 内部管理后台 | 拒绝 | 不应暴露给公共爬虫或通用智能体 |
即使 Cloudflare 控制面允许某类 Agent，也应继续在源站执行最小权限原则。边缘层回答“这类流量能不能进来”，应用层还要回答“这个主体能读取什么、能执行什么”。
可以这样实践：把三类决策写成可审查策略
下面不是 Cloudflare 官方配置格式，而是一份可以直接改造的内部策略模板。它适合放进代码仓库，让安全、内容和产品团队共同审查，再把最终结论同步到 Cloudflare 控制面。
创建 ai-crawler-policy.yaml：
categories:
search:
action: allow
paths:
- /blog/
- /docs/
rate_limit_per_minute: 120
agent:
action: allow_limited
paths:
- /docs/
- /catalog/
deny_paths:
- /account/
- /checkout/
- /api/write/
rate_limit_per_minute: 30
training:
action: block
paths:
- "*"
review:
owner: security@example.com
expires_on: 2026-06-30
安装依赖并运行一个最小校验器：
python -m pip install pyyaml
python validate_ai_policy.py ai-crawler-policy.yaml
validate_ai_policy.py 内容如下：
#!/usr/bin/env python3
import sys
from datetime import date
from pathlib import Path
import yaml
REQUIRED = {"search", "agent", "training"}
ACTIONS = {"allow", "allow_limited", "block"}
def main() -> int:
if len(sys.argv) != 2:
print("usage: validate_ai_policy.py POLICY.yaml")
return 2
path = Path(sys.argv[1])
policy = yaml.safe_load(path.read_text(encoding="utf-8"))
categories = policy.get("categories", {})
missing = REQUIRED - set(categories)
if missing:
raise ValueError(f"missing categories: {sorted(missing)}")
for name in sorted(REQUIRED):
rule = categories[name]
action = rule.get("action")
if action not in ACTIONS:
raise ValueError(f"{name}: invalid action {action!r}")
if action == "allow_limited" and not rule.get("rate_limit_per_minute"):
raise ValueError(f"{name}: allow_limited requires a rate limit")
expires = date.fromisoformat(policy["review"]["expires_on"])
if expires < date.today():
raise ValueError(f"policy review expired on {expires}")
print("AI crawler policy is valid")
for name in sorted(REQUIRED):
print(f"- {name}: {categories[name]['action']}")
return 0
if __name__ == "__main__":
raise SystemExit(main())
这份策略文件不能替代 Cloudflare 的实际开关或防火墙规则，但能解决两个常见问题：避免管理员凭感觉临时配置，以及防止策略长期无人复审。expires_on 可以接入 CI，在到期后阻止变更合并或触发提醒。
robots.txt 可以表达意愿，但不能承担安全职责
站点仍然可以通过 robots.txt 为已知爬虫声明允许和禁止的路径，例如：
User-agent: *
Allow: /blog/
Allow: /docs/
Disallow: /account/
Disallow: /checkout/
Disallow: /api/write/
这段配置可以直接作为基础模板，但部署前应核对现有搜索抓取需求。更重要的是，robots.txt 是协议信号，不是访问控制：不遵守协议的客户端仍可请求这些地址。账户数据、写接口和管理页面必须依靠认证、授权、WAF 规则以及服务端校验保护。
上线时按收益和风险分别验收
采用三段式管控时，可以使用下面的检查清单：
- 为 Search、Agent、Training 分别指定业务负责人，不再使用笼统的“AI 流量负责人”。
- 记录每一类流量允许或拒绝的理由，并设置复审日期。
- 对 Agent 单独检查写操作、登录态、个人数据和支付路径。
- 对允许访问的类别设置速率限制，观察源站 CPU、带宽和缓存命中率。
- 从日志验证规则是否误伤正常搜索流量，也要检查被允许流量是否访问了意外路径。
- 不把 User-Agent 或
robots.txt当成身份认证手段。 - 在更改 Cloudflare 开关前后保留基线数据，比较抓取量、搜索引荐、错误率和基础设施成本。
这次重构的核心不是让站点拥有更多按钮，而是要求团队明确回答三个不同的问题：是否希望内容进入搜索与答案系统，是否允许智能体代表用户实时访问，以及是否同意内容被用于训练。把三个答案分开，策略才有可能同时兼顾分发、自动化、成本与内容权利。