个人 AI agent 访问网站：可见性分类、策略枚举与开发者核对边界

个人 AI agent 把用户的一句话变成对网站的请求。对站点来说，这些请求仍然落在自动化流量里，但背后可能是正在比价、找支持文档或完成下单的真实客户。Cloudflare 在 2026 年 11 月 4 日的发布中给了两层能力：看清是哪个 agent 在访问，以及按 agent 设置允许或屏蔽（来源）。需要先说明限制：材料描述的是控制台中的分析与策略项，没有给出 API 端点、请求头或字段 schema。下文不列具体字段名，凡涉及程序化配置的部分都要回官方文档核对。

可见性：把“自动化流量”拆到具体 agent#

Security Analytics 的 Bot Analysis 图新增 Personal Assistants 类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列。安全团队选中该类别，就只看到个人 agent 的流量曲线。这一步的价值在于把“解释不了的自动化流量”变成可以分类观察的对象。

按单个 agent 下钻

Top statistics 中新增 Personal Assistants 组件，列出访问站点的 agent 以及各自发送的请求数。选中其中一个 agent 后，其他组件联动，显示它请求的路径、收到的状态码、来源网络。于是“它在登录、在读产品页、走到结账，还是在不可用页面上不断撞错误”从猜测变成了可读的观察项。

账户级视图：agent 代表谁

对使用 Account Abuse Protection 的站点（该功能处于 early access），站点所有者与反欺诈团队能看到每个 agent 代表哪个用户。population overview 页面显示哪些个人 agent 在用户中活跃、多少账户在使用它们；每次登录与注册事件都会标注是否由个人 agent 发起以及是哪一个；账户可以按 AI assistant 事件或 assistant 数量过滤。单个账户的概览列出为该账户行动的 agent。

这让风控判断具体了一步：一个异常登录，是客户用了好几周的 agent 发起的，还是当天首次出现、值得进一步查看的 agent 发起的。处置粒度也值得注意——如果怀疑攻击者借某个 agent 操作某个账户，可以针对该账户的 Hashed User ID 下发 WAF 规则，而不必把该 agent 的所有使用者一起屏蔽。

控制：总体策略加单 agent 覆盖#

Security Settings 中先设一个总的 Agents policy，再对每个受支持的 personal agent 单独选择策略。Search 与 Training 的既有策略保持不变。该设置项由原来的 AI bot policies 扩展并更名为 AI Crawler and Agent access policies，以反映范围变大。

发布方给的示例是：总体 Agents policy 设为 Block on pages with ads，再对想欢迎的 agent 单独设为 Allow。添加新 zone 时，onboarding 会询问是否用广告变现页面，并据此给出推荐策略；推荐不是强制，之后仍可在 Security Settings 修改。

策略选择取决于站点自身。材料里的对照是：一个发布者可能全站允许某个 agent，让读者能找到文章；另一个可能在该 agent 访问靠广告支撑的页面时屏蔽它。两种都是按业务做的取舍，没有通用正确答案。

开发者要核对的边界#

• 受支持名单：策略只覆盖“受支持的 personal agent”。材料没有列出具体名单和更新节奏，接入前要查文档确认。
• 更名的连带影响：设置项改名后，Terraform provider、管理 API、审计脚本、内部 runbook 里的旧名称是否同步，材料未涉及，待核实。
• 策略合并规则：总体 Agents policy 与单 agent 覆盖之间谁优先、未列出的 agent 走哪个默认值，材料只给了示例，没有给完整优先级表。建议先在测试 zone 上验证再上生产。
• Hashed User ID 的可用前提：它出现在 Account Abuse Protection（early access）的语境中，可用性和字段口径要按账户实际开通情况核对。
• 用户上下文仍是缺口：材料明确把“通过 agent 携带用户上下文、帮助站点评估信誉、建立明确问责”列为下一步目标，并要求隐私友好的实现方式。因此当前不要把“站点已知该用户是现有客户、其授权范围、订阅状态”当作已具备的能力。
• 分类本身是判断而非事实：Likely Human、Likely Automated 这类标签带有概率性质；Personal Assistants 的判定依据与误判处理方式，材料未展开。

一个可执行的核对流程#

1. 先在 Security Analytics 里取一段时间窗的个人 agent 流量，记录 agent 名称、请求数、主要路径、状态码分布、来源网络。这一步只观察，不改策略。
2. 把“希望的访问”写成可判定条件：哪些路径允许、哪些页面不允许、登录与结账等敏感路径是否需要单独处理。
3. 在测试 zone 上同时配置总体 Agents policy 与单 agent 覆盖，验证合并结果符合第 2 步，重点看未列入名单的 agent 和名称变体。
4. 若已开通 Account Abuse Protection，核对登录与注册事件上的 agent 标注能否用于风控规则，并把 Hashed User ID 规则的命中范围写成明确语句。
5. 把设置变更纳入变更记录：更名后的配置项、修改人、生效 zone、回滚方式。材料没有提供 API 层的幂等或版本语义，这部分需自行验证。

这次更新把个人 agent 流量从不可解释的自动化流量里分了出来，并给了按 agent 的策略开关。可以直接使用的事实是分类名称、三个策略取值和账户级视图的存在；暂时不能直接使用的是请求字段定义、策略优先级规则和用户上下文传递机制。把这些未定项留在配置层和核对清单里，比先写死一套字段映射稳妥。