个人 agent 流量该按什么标记：Cloudflare 的类别、策略与账户三层

简短结论：本次材料没有给出任何一套公开、通用的请求头或字段，可以用来标记“个人 agent”。Cloudflare 在 2026 年 11 月初的两篇公告中，把识别放在平台侧完成：先在分析里把 Personal Assistants 单列为一个流量类别，再把访问策略细化到单个受支持的 agent，最后在账户层关联到具体用户。对自建服务器而言，可迁移的是“类别—身份—账户”这三层分离的思路，而不是照抄某个标记值。Cloudflare 公告

个人 agent 与普通爬虫的差别#

按 Cloudflare 的定义，个人 AI agent 是从人类用户处接受指令、通过控制云计算机或浏览器来追求目标的自动化程序，通常由 Operator 作为托管服务或产品的一部分运行（Agents aren’t humans）。它和传统爬虫的关键差别在目的：用户可能让 agent 比较商品、查找支持文章或完成购买，这些操作背后是一个真实客户。对站点来说，这几种交互都表现为自动化流量，但一刀切封掉可能等于封掉客户。

这也正是标记的难点。远程托管的 agent 是用户与站点之间的中介：站点看到的是 agent，不是用户；一个 agent 还可能同时代表很多用户。材料把这一点概括为中介问题，并给出中介原则——用户与站点之间的业务关系、各参与方的安全责任，不应因为中介存在而失效。第二篇公告在 “User attribution” 处被截断，其完整结论可能在该片段之后，不能仅凭现有内容断言其全部方案。

Cloudflare 给出的三层做法#

类别层：把“代表人类的自动化”单列

在 Security Analytics 的 Bot Analysis 里，Personal Assistants 成为独立类别，安全团队可以只筛出个人 agent 流量。Cloudflare 称其维护着全球最大的已验证 bot 目录，这次是把该目录的信息引入流量详情。Top statistics 新增的 Personal Assistants 组件列出正在访问站点的 agent 及各自请求数；筛选单个 agent 后，其余组件联动显示它的请求路径、收到的状态码和来源网络。

这一设计隐含的判断是：“是否自动化”和“是否代表人类”是两个维度，而不是人机二分。这是根据公告内容作出的推断，不是公告原文的表述。

策略层：按 agent 和页面性质两个维度

原有的 Agents 策略扩展为可对每个受支持的个人 agent 单独设置，设置项更名为 AI Crawler and Agent access policies。选项有三个：Allow（不阻止）、Block on pages with ads、Block。可以先设全局为 Block on pages with ads，再对某个想欢迎的 agent 单独放行；已有的 Search 和 Training 策略保持不变。新 zone 接入时，onboarding 会询问是否靠广告变现，并据此给出推荐策略。策略粒度因此落在“哪个 agent”和“什么页面”两个轴上。

账户层：缓解落在用户，而不是整个 agent

Account Abuse Protection 让站点所有者和欺诈团队看到每个 agent 代表哪个用户：概览页显示哪些个人 agent 在用户中活跃、多少账户在使用；每次登录和注册事件显示是否由个人 agent 发起、是哪个 agent；账户概览显示代表该账户行动的 agent。调查异常登录时，可以区分一个客户已使用数周的 agent 和当天首次出现的 agent。若怀疑攻击者借 agent 操作某个账户，可对该账户的 Hashed User ID 下 WAF 规则，而不必封掉该 agent 背后所有用户。

为什么 User-Agent 和人机验证不够#

材料明确列出两个障碍。其一，agent 常常运行在住宅 IP、使用真实浏览器、混在人类流量中，并会刻意不把自己与人类流量区分开；攻击者也会复制知名 agent 的 User-Agent 字符串来获得同样待遇。其二，CAPTCHA 一类人机验证判断的是控制浏览器的实体是不是人，而 agent 本来就不是人，把信号透传给背后用户不会增加新信息。

由此可以推断，按某个新 UA 前缀或单一头部来标记个人 agent 并不可靠。识别需要平台侧的多信号判断。但材料没有说明 Cloudflare 具体使用了哪些信号、对应哪些字段，这部分待核实。

自建服务可以借鉴什么#

• 先分类别，再谈放行。至少把“代表人类的自动化”和“批量采集”分开归类，避免所有非人类流量都落到同一个 bot 桶里。
• 身份记录到 agent/operator 一级，但不以 UA 为唯一依据。材料已说明 UA 可被复制，且 agent 有意模糊自身特征。
• 策略按场景分层。Cloudflare 的“有广告页面”是一个例子；自建服务可以按付费内容、写操作、高频接口等维度划分，而不是全局开关。
• 能关联到账户时，缓解落在账户。这是材料中 Hashed User ID 加 WAF 规则所体现的思路，可减少对同一 agent 其他用户的连带影响。
• 预留“代表谁”的上下文位。Cloudflare 称下一步目标是让站点保留与用户关系的上下文，例如是否为现有客户、授权范围、订阅状态、应适用哪些保护，并需要隐私感知的方式传递用户上下文、评估声誉、建立问责。这是其目标，不是已交付能力。

边界与待核实项#

• 第二篇材料为截断片段，且明确将本地 agent（如 OpenClaw）或运行在用户自己浏览器、设备上的 agent 排除在主要讨论范围之外。
• Account Abuse Protection 处于早期访问，可用区域与计费方式待核实。
• 本次材料未提供 agent 流量占比、增长率等可核验统计数字，也没有公开的标记字段规范。
• 若要在自建 API 网关上实现类似分层，判定信号、阈值与误判处理都需要另行设计与测试；本文不提供实测结论。