个人 AI agent 访问网页时，网站如何区分自动化流量与真人流量

网站不能只靠一个信号可靠回答“这是真人还是自动化”。更可落地的判断是分层的：先把请求归入已验证机器人、疑似真人、疑似自动化、自动化，或 Cloudflare 新增的“个人助手（Personal Assistants）”；再看它访问了哪些路径、拿到什么状态码、来自哪些网络，以及是否关联到某个登录账号；最后按页面类型和账号设置放行或拦截。Cloudflare 在 2026 年 11 月 4 日的发布说明中给出了这套观测与控制能力。边界也要先讲清：该文没有披露分类算法、判定阈值和准确率，也没有列出支持的个人 agent 名单；这些需要查官方文档或自行验证，本文不补造。

为什么“真人还是自动化”不再是二分#

个人 agent 是人与互联网之间的中介：它把人的指令转成网站请求和动作。来源举了三个场景：让 agent 比较产品、查找支持文章、完成购买。对站点来说，这三种交互都会表现为自动化流量；如果一刀切封禁，可能把仍想访问业务的客户挡在外面。Cloudflare 在文中也明确说，全面阻止 agent 看似最安全，但可能意味着失去客户。

因此，区分的目的不是给流量贴一个永久标签，而是决定“这类访问在我这里适用什么条款”。同样一个个人 agent，在内容页可以欢迎，在广告变现页可能限制，在登录或结账页则要更谨慎。

站点能看到的两类信号#

流量分类：个人助手成为独立类别

在 Security Analytics 的 Bot Analysis 图表中，Personal Assistants 成为一个新类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列。安全团队可以只选这个类别，查看个人 agent 流量随时间的变化。Cloudflare 称其维护着全球最大的已验证 bot 目录，并把这项情报接入了流量详情；这是来源的主张，本文未独立核验目录规模。

从命名看，Likely Human 和 Likely Automated 带有概率判断的意味；但文章没有给出判定信号、阈值或误判率。可以确认的是结果层：分类标签已经出现在分析界面中，而不是站点自己从 User-Agent 猜出来的结论。

在 Top statistics 中，新的 Personal Assistants 小组件会列出哪些 agent 正在访问站点、各自发送多少请求。选中一个 agent 后，其他小组件会只显示它的流量细节：请求路径、收到的状态码、来源网络。这样可以看出它是在登录、读产品页、到达结账，还是在它无法使用的页面上反复报错。

账号维度：early access 中的补充信号

对于使用 Account Abuse Protection（账户滥用防护，目前为 early access）的站点，还能看到每个 agent 代表哪个用户。用户总体概览页显示哪些个人 agent 在用户中活跃、有多少账号使用它们；登录和注册事件会标明请求是否由个人 agent 发起，以及是哪一个。每个账号的概览也会列出为该账号服务的 agent。来源举例说，调查异常登录时，可以分辨它来自客户使用数周的 agent，还是当天首次出现、需要进一步查看的 agent。

如果怀疑攻击者正在某个账号上使用 agent，欺诈分析人员可以针对该账号的 Hashed User ID（哈希后的用户 ID）施加 WAF 规则，而不必对依赖同一 agent 的其他用户全部封禁。该功能的可用性、支持范围与规则细节本次材料未展开，需以官方文档和实际环境为准。

这张表只总结来源展示的能力，不代表所有 Cloudflare 套餐或所有站点都可用。

判定之后，策略怎么落地#

Cloudflare 把原有 Agents 策略扩展为可对受支持个人 agent 做更细粒度控制，并将设置重命名为“AI Crawler and Agent access policies”。在 Security Settings 中，可以先设一个总的 Agents 策略，再为每个受支持的个人 agent 选择：Allow（不阻止）、Block on pages with ads（在带广告的页面阻止）、Block（阻止）。来源给出的例子是：总策略设为“在带广告页面阻止”，再对希望欢迎的某个 agent 单独设为 Allow。既有的 Search 与 Training 策略保持不变。

添加新 zone 时，接入流程会询问站点是否用广告变现，并据此调整推荐策略；之后仍可在 Security Settings 中修改。这个设计把“是否靠广告支撑内容”放进了策略选择，而不是要求所有站点套用同一答案。

建议按以下顺序落地，而不是先封再问：

1. 先在 Bot Analysis 看 Personal Assistants 是否构成有意义的流量，集中在哪些路径。
2. 在 Top statistics 按单个 agent 筛选，检查它的状态码和网络来源；高频 4xx/5xx 可能说明它在撞不可用页面，而不是正常完成任务。
3. 如果站点使用账号滥用防护，把登录、注册事件与账号概览关联起来，区分长期使用的 agent 和首次出现的 agent。
4. 按页面类型设条款：内容页、广告页、登录页、结账页可以不同；对可疑账号优先做账号级处置，而不是封禁整个 agent。
5. 记录每次策略变更、生效范围和回滚方式，便于事后解释“为什么放行/阻止”。

这些步骤是建议，不是来源规定的唯一流程。来源本身只说明有哪些观测点和策略档位；具体页面分类与风险阈值要由站点按业务决定。

开发者容易忽略的边界#

分类标签不是用户身份

站点可能认出“是哪个 agent 在请求”，但仍缺少原本会有的用户信息：这个人是不是现有客户、授权 agent 做什么、有没有订阅、应适用哪些保护。Cloudflare 把这一点列为下一步目标，并提出需要隐私友好的三种能力：让用户上下文随 agent 传递、帮助站点评估声誉、在出问题时明确责任。在这些能力补齐之前，把 Personal Assistants 标签直接当作授权凭证是不稳妥的；它更适合作为风控和观测信号。

建议对高风险动作保留用户在场的确认或二次验证，例如修改密码、支付、导出数据；对普通读取页面再按 agent 策略放行。这里的“高风险动作”是建议分类，不是来源给出的清单。

日志和接口设计要留下判断依据

如果站点自行记录 agent 访问，建议至少保留：时间、主机、路径、方法、边缘返回的 bot 分类、agent 名称（若有）、账号哈希、命中策略、实际动作和原因。不要只记录 User-Agent；它不能替代分类和授权判断。下面只是字段示意，未执行，也不是 Cloudflare 的日志格式：

{
  "ts": "2026-11-05T00:00:00Z",
  "host": "www.example.com",
  "path": "/checkout",
  "bot_category": "personal_assistant",
  "agent_name": "YOUR_AGENT_LABEL",
  "account_ref": "hashed-user-id",
  "policy": "block_on_ads_pages",
  "action": "allow",
  "reason": "supported_agent_override"
}

对 API 来说，还要区分“拒绝这次请求”和“限制这个账号”：前者是流量策略，后者是账号安全处置。个人 agent 可能代表真实客户反复重试，错误页和重试路径也应纳入观测，否则容易把“agent 不会用这个页面”误判成恶意行为。

结论#

可操作的答案是：用分类发现个人 agent，用路径、状态码、网络和账号事件判断它正在做什么，再用总策略加单 agent 覆盖表达业务条款。Cloudflare 这次提供的是观测与访问控制，不是完整的用户授权模型；后者仍需生态补齐。对开发者的直接动作是，先看 Personal Assistants 的路径和状态码，再决定哪些页面 Allow、哪些在带广告页面 Block、哪些需要账号级处置。分类准确率、支持的个人 agent 名单和 early access 的具体可用性，本次材料未提供，应另行核实。