Cloudflare 在 2026 年 11 月 4 日推出对个人 AI 智能体流量的细化可视化与逐代理访问策略，允许网站按单个受支持代理查看请求轨迹并设定不同阻断策略，但识别代理并不等同于确认用户授权或代理信誉。部分账户关联功能仅通过 Account Abuse Protection 的企业客户早期访问提供，且需启用 User ID 与正确标注端点。
Cloudflare于2026年11月4日宣布，为网站新增个人AI智能体流量分析，并把现有的智能体访问策略细化到单个受支持代理。网站运营者不仅可以了解哪些助手正在代用户访问页面，还能分别决定是否阻止它们，而不必把所有智能体一并放行或封锁。
这项更新针对的是一个逐渐具体化的问题：替消费者比较商品、查找帮助文档的AI助手，在服务器看来也是自动化流量。它可能代表一名真实客户，也可能带来异常登录或访问风险。Cloudflare在官方公告中提出的新方案，是先让网站看清这些访问，再赋予更细的控制权；但识别一个代理，并不等于已经确认其背后的用户、授权范围或行为安全。
从“自动化请求”中看见个人助手
按照公告，Security Analytics中的Bot Analysis图表新增了“Personal Assistants”分类，与已验证机器人、可能为人类、可能为自动化和自动化等类别并列。安全团队选择这一分类后，可以单独查看个人智能体流量随时间的变化。
Top statistics区域还增加了同名统计组件，列出访问网站的代理及各自的请求数量。选定一个代理后，其他统计组件会同步筛选，显示它请求的路径、收到的HTTP状态码和来源网络。
这些信息的价值不只是给流量贴上标签。例如，运营者可以据此观察一个助手是在读取商品页面、访问登录入口、到达结账流程，还是反复遇到无法使用的页面。不过，请求路径和状态码反映的是访问轨迹，不能单独证明购物已经完成，更不能证明每次操作都获得了用户授权。
同一网站，可以对不同代理作不同选择
访问控制的变化发生在已有的Agents策略之下。Cloudflare将设置名称调整为“AI Crawler and Agent access policies”，网站可以先制定整体智能体策略，再为单个受支持的个人代理设置不同选项。
公告列出三种选择：Allow（不阻止）、Block on pages with ads（在带广告的页面阻止），以及Block（阻止）。例如，网站可以对智能体整体采取“在带广告页面阻止”，同时对希望接纳的某个受支持代理选择“不阻止”。原有Search和Training策略保持不变。
这里的“不阻止”描述的是这项访问策略的选择，不应被理解为对代理行为的安全背书。公告也将逐代理控制限定在“受支持”的个人代理，并未宣称能够为互联网上所有自动化程序提供同等识别和独立配置。
新域名接入Cloudflare时，平台还会询问网站是否通过页面广告变现，并据此调整推荐策略；运营者之后仍可回到Security Settings修改设置。对于出版机构，这意味着可以在希望内容被助手发现与保护广告支撑的页面之间作不同取舍，而不是只有全面开放或全面封锁两个选项。
关联到具体账户，还有接入门槛
流量层面的可见性，与知道代理代表哪个账户，是两项不同能力。Cloudflare称，已经使用Account Abuse Protection保护用户账户的网站，可以进一步查看哪些个人代理活跃于用户群体、多少账户使用了它们，以及登录和注册事件是否由个人代理发起、由哪个代理发起。
在单个账户视图中，调查人员还能查看该账户使用过的代理。公司举例说，分析异常登录时，可以区分一个长期使用的代理与一个刚出现的代理；如果怀疑攻击者正在借助代理操作某个账户，可以针对该账户的Hashed User ID建立Web应用防火墙（WAF）规则，而不必把同一代理对其他用户的访问一并阻止。这是公司对功能用途的说明，并不构成已经自动判定欺诈或阻止账户接管的效果证明。
这部分能力并非默认向所有网站开放。Account Abuse Protection官方文档将服务标为Early Access，面向Bot Management Enterprise客户，需联系Cloudflare账户团队申请接入。网站还需要启用User ID，并确认相关登录、注册端点得到正确识别；非常规端点可能需要另外标注。
文档称，Hashed User ID是网站区域专属的不透明标识，其他Cloudflare客户无法访问这些用户档案。因此，公告中的账户关联不能被解读为：只要打开个人助手流量统计，网站就能看见所有访问者的真实身份。它依赖账户保护服务、相应配置和可识别的账户活动。
新增的是细粒度控制，而非首次区分AI用途
这次更新建立在Cloudflare此前的流量分类之上。公司在2026年7月1日的公告中，已经把搜索、智能体和训练列为可分别管理的AI用途：搜索用于收集或索引内容，以便日后回答查询；智能体通常代表用户实时完成任务；训练则用于开发或微调模型。
AIFlux此前关于Cloudflare“禁止AI训练”设置的报道也讨论了这一分工：拒绝内容用于模型训练，不应简单等同于放弃搜索曝光。11月4日的新进展，则是在既有Agents类别中增加个人助手分析和逐代理策略覆盖，而不是重新发明三类访问控制。
这一区别关系到网站如何理解AI流量的商业意义。批量收集训练数据与一名用户要求助手读取商品信息，可能产生相似的自动化请求，却对应不同目的。新的统计和策略使运营者有更多依据作选择，但不能仅凭分类就推断一次访问给网站带来了收入，或准确判断它是否损害了广告收益。
知道“哪个代理”，仍不等于知道“获准做什么”
Cloudflare在公告中承认，代理身份只是问题的一部分。即使网站认出了发出请求的智能体，也可能不知道背后的人是不是现有客户、是否拥有订阅、授权代理完成了哪些任务，以及应当适用哪些保护措施。
公司将以注重隐私的方式传递用户上下文、帮助网站评估信誉，以及在出错时确立责任，列为接下来与代理运营方及生态伙伴合作的目标。这些目标不属于此次已经交付的完整能力。
因此，本次更新更明确的意义，是把个人智能体访问从笼统的自动化流量，推进为网站可以单独观察、按代理设置规则，并在符合条件时结合账户活动调查的对象。它增加了运营与安全团队的选择，但用户授权如何传递、代理信誉如何判断、发生错误后由谁负责，仍未因新增一个分析分类或访问开关而得到解决。