Cloudflare 开始区分 AI 爬虫与个人 Agent：网站访问控制应该怎样设计？

文章目录

- [一、Cloudflare 的新策略改变了什么](#一、Cloudflare 的新策略改变了什么)
- [二、识别 Agent 身份，比检查 User-Agent 更复杂](#二、识别 Agent 身份，比检查 User-Agent 更复杂)
- [三、如何在 Cloudflare 中配置并观察 Agent 访问](#三、如何在 Cloudflare 中配置并观察 Agent 访问)
- [四、实操：用 Node.js 模拟个人 Agent 的策略继承与访问判断](#四、实操：用 Node.js 模拟个人 Agent 的策略继承与访问判断)
- [五、Agent 访问网站后，真正需要关注哪些工程问题](#五、Agent 访问网站后，真正需要关注哪些工程问题)
- 参考资料
- 附录：示例验证范围

过去几年，网站对自动化访问的管理方式并没有发生太大的变化。搜索引擎抓取页面、监控程序检查服务状态、自动化脚本批量获取数据，这些行为虽然各有不同，但在服务器日志中经常表现为连续的 HTTP 请求。网站管理员通常通过 robots.txt、Web 应用防火墙（WAF）、速率限制和机器人识别规则处理它们。

AI Agent 的出现让这个问题变得复杂起来。

假设一名用户正在寻找适合自己的笔记本电脑。他没有直接打开电商网站，而是让 AI 助手访问多个商品页面，比较价格、配置和售后政策。对于电商平台而言，这些访问属于自动化流量；但对于用户而言，Agent 只是代替自己完成原本需要手动进行的浏览操作。

如果网站直接拦截所有自动化请求，可能同时阻止真正的用户通过 AI 助手访问内容。反过来，如果对所有声称自己是 AI Agent 的请求开放访问，又会增加恶意抓取、账号滥用以及其他自动化攻击的风险。

2026 年 11 月 4 日，Cloudflare 发布了针对个人 AI Agent 的新一轮访问控制更新。

这次更新涉及两个方面：网站可以在安全分析界面中更清楚地观察个人 Agent 的访问情况，并为部分受支持的 Agent 设置独立的访问策略。原先的 Configure AI bot policies 也更名为 AI Crawler and Agent access policies。

这项功能表面上只是增加了几个配置选项，背后却涉及网站如何识别 AI Agent、如何区分自动访问目的，以及怎样在安全控制与正常用户需求之间建立合理边界。

一、Cloudflare 的新策略改变了什么

理解这次更新，需要先区分三种容易混淆的自动化行为。

搜索类爬虫（Search）通常以建立索引为目的，提前收集网站内容，供搜索引擎或检索系统使用。它们的工作流程往往是持续发现链接、获取页面、建立索引，并在之后的用户查询中使用这些信息。

训练类爬虫（Training）则以收集模型训练或微调所需数据为主要目的。它们可能访问大量公开内容，也可能与搜索类爬虫共享部分基础设施。

Agent 类自动化访问具有不同的特征。它通常由某个用户的即时任务触发，例如查找资料、比较产品、读取帮助文档，或者在得到适当授权后执行网站操作。

这三种行为都可能使用 HTTP 请求访问页面，但访问目的、时间特征和网站所承担的风险并不相同。

Cloudflare 此前已经提供按 Search、Agent、Training 行为设置策略的能力。11 月 4 日的更新将控制粒度进一步扩展到具体的 Personal Agents。

例如，一家依靠广告收入维持运营的技术网站，可能不愿让自动化工具大量读取含有广告的文章页面，因为这类访问未必会产生与正常浏览相同的广告展示效果。

与此同时，这家网站又可能希望允许部分个人 AI 助手访问内容，让用户能够通过助手查找技术教程或获取帮助。

过去，如果策略主要针对整个 Agent 类别，网站很难为具体服务设置差异化规则。

现在，Cloudflare 支持先设置整体 Agents 策略，再针对部分受支持的个人 Agent 单独指定访问行为。

根据官方公告，相关策略包括：

策略	含义
Allow (do not block)	不通过该 AI 访问策略拦截匹配请求
Block	阻止匹配请求
Block on pages with ads	在 Cloudflare 识别到含有广告的页面上阻止匹配请求
Disallow	面向 Training 行为，通过 `robots.txt` 表达不允许抓取的偏好

其中，Disallow 有特殊的适用范围，它主要用于训练类抓取，不应当直接理解为所有 Agent 都可以使用的统一阻止方式。

robots.txt 也不具备与 WAF 相同的强制执行能力。它提供的是网站对爬虫行为的声明，是否遵守取决于访问方。Cloudflare 的 Bot Preference Sync 可以在特定条件下将部分训练抓取的拒绝偏好落实到边缘访问控制，但其作用仍受到行为分类等条件约束。

对于 Personal Agents，官方目前建议采用 Allow (do not block)。这是一项产品建议，并不意味着所有网站都应该无条件开放访问。

需要特别注意，Allow (do not block) 只表示该 AI 访问策略不执行阻止操作，并不等于请求能够绕过网站的其他安全规则、身份认证或业务权限检查。

例如，某个 Agent 可以被允许访问公开商品页面，但不能因此获得读取订单、修改用户资料或调用管理员接口的权限。

从工程角度看，这次更新的关键意义是把"自动化流量是否允许进入网站"进一步细化为"什么样的自动化行为可以访问什么资源"。

二、识别 Agent 身份，比检查 User-Agent 更复杂

网站开发者通常可以通过请求头中的 User-Agent 字段判断客户端类型。

例如：

http 复制代码

GET /articles HTTP/1.1
Host: example.com
User-Agent: ExampleAgent/1.0

如果请求头包含某个特定标识，服务器就可以据此进行日志分类。

但这种方法存在明显缺陷：User-Agent 只是客户端自行声明的字符串，任何能够构造 HTTP 请求的程序都可以修改它。

下面两条命令便能说明这一点：

bash 复制代码

curl -A "ExampleAgent/1.0" \
  https://example.com/

curl -A "Mozilla/5.0" \
  https://example.com/

它们可以发送不同的 User-Agent，却完全可能来自同一个客户端。服务器不能仅凭这一字段确认请求是否由真正的 AI Agent 发起。

Cloudflare 的机器人识别体系因此还包含 Verified Bots 机制。

根据官方文档，一个经过验证的机器人或 Agent，需要满足两个基本要求：能够可靠表明自身身份，并且遵循合理的访问行为规范。

身份识别可以使用不同的方法，例如密码学签名、已公布的 IP 地址范围与稳定的 User-Agent 组合，或者反向 DNS 验证。

其中，Web Bot Auth 是一个值得关注的方向。

它利用密码学方式为 HTTP 请求提供可验证的身份声明。与单纯填写 User-Agent 相比，签名机制能够帮助接收方判断请求是否由掌握相应密钥的主体发出。

不过，身份验证只能解决部分问题。

假设一个合法的个人 Agent 已经过验证，这并不能说明它当前执行的操作一定获得了最终用户授权。

同一个 Agent 服务可能由大量不同用户使用。有的用户只要求读取公开资料，有的用户可能要求登录账户，还有的用户可能尝试执行涉及付款或修改数据的操作。

网站需要区分两个层次：

一个层次是 Agent 服务本身的身份，也就是"是谁运营了这个自动化客户端"。

另一个层次是用户与具体任务的授权关系，也就是"这个请求代表哪个用户，以及该用户允许它做什么"。

前者可以借助机器人验证和身份签名建立一定程度的可信度，后者通常仍需要网站自身的账号体系、授权令牌、会话管理以及权限检查。

Cloudflare 在此次官方文章中也明确提出，如何让网站在 Agent 访问时保留对最终用户身份、授权范围和信任关系的理解，仍然是后续需要解决的问题。

对于开发者来说，不能因为某个请求属于 Verified Agent，就直接跳过业务层面的鉴权。

尤其是在 API 接口中，Agent 身份与用户身份应当分别处理。即使请求来自允许访问的自动化客户端，资源所有权检查、操作范围限制和审计记录仍然需要保留。

三、如何在 Cloudflare 中配置并观察 Agent 访问

这次更新已经进入 Cloudflare 的安全设置界面。

对于已有的 Cloudflare 站点，可以进入对应域名，在控制台中依次打开：

Security → Settings → AI Crawler and Agent access policies

根据官方文档，管理员可以为 Search、Agents 和 Training 选择相应操作，并对受支持的个人 Agent 单独设置策略。

这里存在一个重要的继承关系。

Personal Agents 默认继承整体 Agents 策略。如果修改整体 Agents 策略，Cloudflare 会相应更新各个 Personal Agent 的设置；如果希望继续保留某个 Agent 的特殊处理方式，需要重新检查并配置对应选项。

假设我们管理一家技术文档网站。

站点的文章页面对外公开，但部分页面包含广告。希望一般 Agent 访问含广告页面时受到限制，同时允许某个已经确认具有业务价值的个人 Agent 正常访问。

一种可供评估的配置是：

text 复制代码

Search: Allow

Training: Block

Agents: Block on pages with ads

Selected Personal Agent: Allow (do not block)

这只是一个具体业务场景下的策略示例，不能直接推广到所有网站。

如果网站完全依靠订阅收费，可能需要不同的策略。如果涉及用户账户、交易和敏感数据，也不能只依赖这几项机器人访问配置。

配置完成后，建议不要立即将所有规则推广到大量线上资源，而应结合实际流量观察其效果。

Cloudflare 在 11 月 4 日公布的新功能中，还增加了与 Personal Assistants 有关的安全分析信息。

在 Security Analytics 中，Bot Analysis 可以将 Personal Assistants 作为独立类别进行查看。Top statistics 中也增加了对应的访问统计能力，用于观察不同个人 Agent 发起的请求数量。

管理员可以进一步检查请求路径、HTTP 状态码以及来源网络等信息。

这些数据能够帮助判断：某个 Agent 主要读取公开帮助文档，还是不断访问登录接口；它的请求是否集中在少数资源上，是否出现异常错误率，或者是否触发了其他安全规则。

如果站点启用了相应的账号滥用防护功能，还可能在支持的场景中观察个人 Agent 与用户账户之间的关联。不过，这部分能力存在产品可用性条件，不能认为所有套餐和站点都默认拥有完整信息。

我更倾向于将这些数据用于策略调整，而不是简单根据 Agent 名称制定永久规则。

例如，某个个人 Agent 最初只访问公开文档，后来开始频繁请求带有用户身份信息的接口。这种行为变化即使来自已经验证的 Agent，也需要重新评估访问范围。

同样，网站不应因为某个自动化客户端在短时间内产生大量请求，就立即断定其具有恶意。正常的索引更新、大规模资料检索和自动化故障也可能产生类似现象。

实际判断还需要结合请求速率、访问路径、身份信息、错误比例和业务上下文。

四、实操：用 Node.js 模拟个人 Agent 的策略继承与访问判断

为了理解这次更新中的策略关系，可以使用 Node.js 编写一个小型访问决策程序。

这个示例并不连接 Cloudflare，也不尝试模拟 Cloudflare 的实际机器人检测引擎。它只接收已经完成分类的请求信息，再根据我们定义的规则计算是否允许访问。

这样可以把两个问题分开讨论：请求属于什么类型，以及识别之后应该采用哪项访问策略。

示例使用 Node.js 20 或更新版本，仅依赖标准库。新建一个空目录：

bash 复制代码

mkdir agent-policy-demo
cd agent-policy-demo

创建 policy.mjs 文件，内容如下：

javascript 复制代码

import { pathToFileURL } from "node:url";

// 教学用策略求值器，不调用 Cloudflare API
const validBehavior = new Set([
  "Search",
  "Agent",
  "Training"
]);

const validAction = new Set([
  "allow",
  "block",
  "block_ads",
  "disallow"
]);

export function evaluate(request, policy) {
  const {
    behavior,
    personalAgent = null,
    pageHasAds = false
  } = request;

  if (!validBehavior.has(behavior)) {
    throw new Error("unknown behavior");
  }

  let action = policy[behavior];

  // 针对已识别的个人 Agent 应用独立策略
  if (
    behavior === "Agent" &&
    personalAgent &&
    Object.hasOwn(
      policy.personalAgents,
      personalAgent
    )
  ) {
    action = policy.personalAgents[personalAgent];
  }

  if (!validAction.has(action)) {
    throw new Error("unknown action");
  }

  // 仅用于模拟训练类抓取的拒绝声明
  if (action === "disallow") {
    if (behavior !== "Training") {
      throw new Error(
        "disallow only applies to Training"
      );
    }

    return "ROBOTS_DISALLOW";
  }

  if (action === "block") {
    return "BLOCK";
  }

  if (action === "block_ads" && pageHasAds) {
    return "BLOCK";
  }

  return "ALLOW";
}

// 模拟整体 Agents 策略变化后
// 重新检查各个个人 Agent 的独立设置
export function changeAgentsPolicy(
  policy,
  action
) {
  if (
    !validAction.has(action) ||
    action === "disallow"
  ) {
    throw new Error(
      "invalid Agents action"
    );
  }

  return {
    ...policy,
    Agent: action,
    personalAgents: {}
  };
}

export const examplePolicy = {
  Search: "allow",
  Agent: "block_ads",
  Training: "block",

  personalAgents: {
    "agent-alpha": "allow"
  }
};

if (
  process.argv[1] &&
  import.meta.url ===
    pathToFileURL(process.argv[1]).href
) {
  const sample = [
    {
      behavior: "Agent",
      personalAgent: "agent-alpha",
      pageHasAds: true
    },
    {
      behavior: "Agent",
      personalAgent: "agent-beta",
      pageHasAds: true
    },
    {
      behavior: "Agent",
      personalAgent: "agent-beta",
      pageHasAds: false
    },
    {
      behavior: "Training",
      pageHasAds: false
    }
  ];

  for (const request of sample) {
    console.log(
      request,
      "=>",
      evaluate(request, examplePolicy)
    );
  }
}

这个程序定义了三类访问行为，并提供四种教学用策略操作。

其中 block_ads 表示：当页面被标记为包含广告时阻止请求，否则允许。这一逻辑对应的是 Cloudflare 官方文档中"在检测到广告的页面上阻止匹配请求"的策略概念。

但程序中的 pageHasAds 是人为传入的布尔值，并不具备 Cloudflare 检测页面广告的实际能力。

类似地，personalAgent 表示调用程序已经知道当前请求属于哪个 Agent。示例没有进行机器人验证，也没有实现 Web Bot Auth。

这是有意保留的简化。策略求值器不应该把未经认证的 User-Agent 字符串直接当作可信身份。

程序中另一个值得注意的函数是 changeAgentsPolicy()。

它模拟整体 Agents 策略发生变化后重新审视个人 Agent 配置的过程。该函数会清空独立策略映射，要求使用者按新配置重新设置例外。

这与 Cloudflare 文档描述的配置更新行为相对应，但并不意味着示例完整复现了 Cloudflare 内部的状态管理实现。

保存文件后执行：

bash 复制代码

node policy.mjs

程序会依次输出四组访问判断。为便于阅读，下面只保留核心结果：

text 复制代码

agent-alpha, ads=true  => ALLOW
agent-beta, ads=true   => BLOCK
agent-beta, ads=false  => ALLOW
Training               => BLOCK

第一组请求属于被明确允许的 agent-alpha，因此即使访问的是含广告页面，也通过了当前策略。

第二组请求属于没有独立例外设置的 agent-beta，它继承整体 Agents 策略。由于页面存在广告，结果为 BLOCK。

第三组请求同样来自 agent-beta，但页面没有广告，因此根据当前策略可以通过。

第四组属于训练类抓取，按照示例中的 Training 策略被阻止。

这个实验说明，即使属于同一个 Agent 行为类别，最终决策也可能因具体身份和页面属性而不同。

接下来可以为策略计算增加自动化测试。

创建 policy.test.mjs：

javascript 复制代码

import test from "node:test";

import assert from "node:assert/strict";

import {
  evaluate,
  changeAgentsPolicy,
  examplePolicy
} from "./policy.mjs";

test("个人 Agent 的例外策略生效", () => {
  const result = evaluate(
    {
      behavior: "Agent",
      personalAgent: "agent-alpha",
      pageHasAds: true
    },
    examplePolicy
  );

  assert.equal(result, "ALLOW");
});

test("其他 Agent 继承广告限制", () => {
  assert.equal(
    evaluate(
      {
        behavior: "Agent",
        personalAgent: "agent-beta",
        pageHasAds: true
      },
      examplePolicy
    ),
    "BLOCK"
  );

  assert.equal(
    evaluate(
      {
        behavior: "Agent",
        personalAgent: "agent-beta",
        pageHasAds: false
      },
      examplePolicy
    ),
    "ALLOW"
  );
});

test("整体策略变化后重新检查例外", () => {
  const revised = changeAgentsPolicy(
    examplePolicy,
    "block"
  );

  assert.deepEqual(
    revised.personalAgents,
    {}
  );

  assert.equal(
    evaluate(
      {
        behavior: "Agent",
        personalAgent: "agent-alpha"
      },
      revised
    ),
    "BLOCK"
  );
});

test("训练流量与 Agent 分开管理", () => {
  assert.equal(
    evaluate(
      { behavior: "Training" },
      examplePolicy
    ),
    "BLOCK"
  );

  assert.equal(
    evaluate(
      { behavior: "Search" },
      examplePolicy
    ),
    "ALLOW"
  );
});

运行：

bash 复制代码

node --test policy.test.mjs

以上两份代码已在 Node.js 22.16.0 环境中实际运行，测试结果为：

text 复制代码

# tests 4
# pass 4
# fail 0

这个实验虽然简单，但它提供了一个可以进一步扩展的基础。

如果准备将访问决策逻辑应用到真实业务，可以在此基础上增加身份信息来源、资源分类、操作类型和日志记录。

例如，可以将请求资源划分为公开文档、需要登录的内容、个人数据和管理接口。不同类别可以采用不同的授权要求。

不过，这些新增规则应由网站自己的业务权限系统负责，不能简单映射成 Cloudflare 的 AI 访问策略。

另外，示例中的 ALLOW 只是策略求值结果。它并不表示真实 HTTP 请求已经通过防火墙，也不表示用户拥有访问目标资源的权限。

如果将其用于生产环境，还需要接入经过验证的流量分类结果，并对所有影响安全性的输入建立可信来源。直接信任客户端自行提交的 behavior 或 personalAgent 字段，将导致访问者有机会伪造自己的分类。

五、Agent 访问网站后，真正需要关注哪些工程问题

Cloudflare 这次更新解决的是一个明确的网络访问控制问题，但个人 AI Agent 对网站的影响不会停留在访问是否允许这一层。

随着 Agent 能够操作浏览器、填写表单并调用在线服务，网站收到的自动化请求可能越来越接近正常用户行为。

例如，用户让 Agent 完成一次购买流程。Agent 需要搜索商品、选择规格、加入购物车、确认地址，最后可能进入支付环节。

这几种操作虽然来自同一个 Agent，却具有完全不同的风险等级。

搜索商品属于低风险读取操作。修改购物车会改变用户会话状态。确认订单和发起支付则直接涉及经济后果。

因此，网站的权限体系需要围绕资源和操作建立约束，而不能仅依据访问方是否属于受支持的 AI Agent。

具体到开发实践，至少需要考虑以下几个方面。

身份认证与用户授权必须分开处理。

如果网站识别出了某个可信 Agent，只能说明请求可能来自相应服务。用户是否已经登录、Agent 是否持有用户授予的权限、授权是否过期，仍然需要通过网站自身的认证系统检查。

对包含个人数据的接口，还应执行资源所有权验证。例如，读取订单详情时，应确认订单确实属于当前经过认证的用户。

高风险操作需要明确的授权边界。

Agent 能否读取公开页面，与能否修改账户设置、删除数据或执行支付没有必然关系。

对于高风险操作，可以考虑使用具有明确范围和有效期的授权凭据，必要时增加用户确认步骤。

这类机制不能依赖普通的自然语言提示来实现。即使提示词明确要求 Agent 不执行某些操作，服务端仍然需要强制检查权限。

速率限制依然有必要。

合法 Agent 也可能因程序错误而反复请求同一个接口，或者在复杂任务中产生超出预期的访问量。

因此，即便网站允许某个个人 Agent，也不应完全取消访问频率、并发量和资源消耗方面的管理。

速率限制的阈值应结合实际业务选择。阅读公开帮助文档和进行订单查询，通常不需要使用同一套访问额度。

日志需要同时具备技术可观测性和必要的隐私保护。

如果发生异常，管理员需要知道请求来自哪个自动化客户端、访问了什么资源、是否通过身份认证，以及最终执行了什么操作。

但记录这些信息时，也要避免把完整会话凭据、用户隐私数据或不必要的敏感内容直接写入日志。

对于使用多种 Agent 服务的平台，还需要考虑如何关联不同服务产生的操作，以及怎样在出现问题时恢复足够的审计线索。

Cloudflare 在此次更新中强化个人 Agent 流量分析，可以帮助站点观察访问来源及请求行为。但对于具体业务操作的审计，应用自身仍然需要提供相应记录。

从更长远的角度看，个人 Agent 正在使网站重新面对一个过去相对简单的问题：访问网站的主体究竟是谁？

过去，浏览器访问通常能够比较直接地关联到一个用户会话。现在，一次请求可能由用户提出目标、Agent 规划步骤、自动化工具执行网络访问，再由网站处理实际操作。

这条链路中的任何一环，都可能影响访问决策。

Cloudflare 本次增加的个人 Agent 策略，为网站提供了更细的流量管理能力。开发者可以根据自动化行为类别和具体服务调整访问范围，也可以通过安全分析数据观察这些策略的实际影响。

但对业务系统而言，Agent 的身份、用户的授权和资源本身的访问权限仍然属于不同层次。

如果网站准备支持越来越多由 AI Agent 发起的访问，比较稳妥的做法是先识别这些访问，再根据资源类型建立清楚的权限规则，通过日志和测试观察其行为，逐步调整开放范围。

这比单纯选择"允许所有 Agent"或"阻止所有 Agent"更符合真实的软件工程需求。

参考资料

$1$ Cloudflare. See the agents, set the terms: new visibility and control for personal agents . 2026-11-04.

https://blog.cloudflare.com/personal-agents-visibility-control

$2$ Cloudflare Developers. Granular access controls for the top Personal Agents . 2026-11-04.

https://developers.cloudflare.com/changelog/post/2026-11-04-personal-agent-policies/

$3$ Cloudflare Developers. AI Crawler and Agent access policies .

https://developers.cloudflare.com/bots/additional-configurations/block-ai-bots/

$4$ Cloudflare Developers. Verified bots .

https://developers.cloudflare.com/bots/concepts/bot/verified-bots/

$5$ Node.js Documentation. Test runner .

https://nodejs.org/api/test.html

$6$ Node.js Documentation. ES modules .

https://nodejs.org/api/esm.html

附录：示例验证范围

本文中的 policy.mjs 和 policy.test.mjs 是用于解释策略继承与访问决策的独立教学程序。

测试环境： Node.js 22.16.0。
依赖： 仅使用 Node.js 标准库。
已验证内容： 四组自动化测试全部通过。
未验证内容： Cloudflare 实际站点策略生效情况、真实 Personal Agent 身份检测、广告页面识别及生产环境流量。
适用范围： 理解策略设计与单元测试方法，不可直接替代 Cloudflare 的访问控制或网站的身份认证系统。

如需验证真实站点中的策略效果，应在具有管理权限的 Cloudflare 测试域名上配置相关规则，结合 Security Analytics 及实际访问日志进行检查。生产环境的任何策略变更都应经过适当的审查和回滚准备。