个人 agent 访问网站：可见性与授权条款如何落地

要让个人 agent 访问网站这件事变得可控，需要把它拆成两层：第一层是可见性——在流量分析里把“个人 agent 代表某个用户发起的请求”从泛化的自动化流量中分出来，看清是哪个 agent、访问了哪些路径、收到什么状态码、关联到哪个账号；第二层是条款——对受支持的个人 agent 逐个选择允许、仅在带广告的页面阻止，或直接阻止。Cloudflare 在 2026 年 11 月 4 日的博客中发布了这两部分能力（See the agents, set the terms）。具体套餐范围、区域可用性与受支持的 agent 名单，材料未列出，文末统一列为待核实项。

为什么“一律封禁”不该是默认答案#

材料对个人 agent 的描述是：它处在人与互联网之间，把用户指令转成网站上的请求与操作。用户可能让它比价、查找帮助文档、完成购买。对站点所有者来说，这三种交互看起来都是自动化流量；如果不清楚谁在访问、在做什么，就很难判断这段流量是在带来客户还是制造风险。全部封禁看起来最安全，但代价可能是丢掉客户。

需要说明的是，这是发布方的立论，不等于每个站点都成立。是否放行，判断依据应当来自你自己的流量数据，而不是这段论证。

可见性：先分清是谁在访问#

流量分析中的新类别

• Security Analytics 的 Bot Analysis 图表新增 Personal Assistants 类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列，可单独筛选，只查看个人 agent 流量随时间的变化。
• Top statistics 新增 Personal Assistants 组件，列出哪些 agent 在访问站点、各自发送多少请求；选中某个 agent 后，其他组件会联动，只显示它的请求路径、收到的状态码和来源网络。由此可以看出该 agent 是否在登录、读取商品页、进入结账流程，或在不适合它的页面上频繁报错。

这套分类依赖“已验证机器人目录”的识别能力（材料称其规模为世界最大，属发布方表述）。一个合理的推断是：未能被目录识别的 agent 更可能落入 Likely Automated 或 Automated，因此“Personal Assistants 为空”并不等于“没有 agent 访问”，需要与其他类别合并观察。这是基于分类设计的推断，材料未直接说明识别覆盖率或误判率。

账号维度：agent 代表的是谁

对使用 Account Abuse Protection 的站点（材料注明处于 early access），可以看到每个 agent 代表哪个用户：总览页展示哪些个人 agent 在用户群中活跃、有多少账号在使用它们，用来判断 agent 流量是否已成为业务中的有意义部分；每次登录和注册事件都会标注是否由个人 agent 发起、是哪一个；欺诈团队可以按 AI 助手事件或 AI 助手数量筛选账号。单个账号的总览页会列出为其服务的 agent，调查异常登录时能区分“客户用了数周的 agent”和“当天首次出现、需要多看一眼的 agent”。若怀疑攻击者借某个 agent 操作账号，可以针对该账号的 Hashed User ID 下发 WAF 规则处置，而不必对该 agent 的所有使用者一并封禁。

这条路径的关键是把 agent 身份与账号身份分开处置。代价是它依赖账号体系与一个 early access 功能，未开通时能拿到的只有流量层可见性。

授权条款：把判断写成配置#

配置入口在 Security Settings → AI Crawler and Agent access policies。这个名字是本次调整后的结果：原有 Agents 策略扩展为可对受支持的个人 agent 做更细粒度控制，因此改名；既有的 Search 与 Training 策略保持不变。

可选项为三档：

• Allow (do not block)：不阻止。
• Block on pages with ads：仅在带广告的页面上阻止。
• Block：阻止。

可以先设定一个总体的 Agents 策略，再对每个受支持的个人 agent 单独覆盖。材料给的例子是：总体设为“在带广告的页面阻止”，再把某个希望欢迎的 agent 设为“不阻止”。新增 zone 时的引导流程会询问是否用广告变现，并据此给出推荐策略，之后可随时回到 Security Settings 修改。

材料还给了两个对照场景：一个发布者可能全站允许某个 agent，方便读者找到文章；另一个发布者可能在同一个 agent 访问靠广告支撑内容的页面时阻止它。两种做法都是按自身业务做的选择——也就是说，不存在通用的最优配置。

一个可执行的落地顺序（建议）#

以下是根据上述能力整理的操作建议，不是材料中的实测流程，也未在真实账号中执行验证。

1. 先观察再决策。在一到两周内只看不改：筛选 Personal Assistants，记录活跃 agent、请求路径分布与状态码构成；同时看 Likely Automated 的规模，估算识别盲区的量级。
2. 按页面类型分层。把公开可读内容、带广告的页面、需要登录的页面、结账与支付路径分开。分层是为了让策略能对应到具体路径，而不是全站一刀切。
3. 用“总体加例外”写配置。总体取保守值（例如在带广告的页面阻止），再对确认带来转化的 agent 逐个放开。
4. 行为处置落到账号维度。异常优先用 Hashed User ID 的 WAF 规则处理，避免因一个滥用者封掉整个 agent。
5. 留下证据。记录每次调整的时间、当时的流量数据和调整理由；策略变更后流量结构如有变化，才有对照基线。

同样的思路适用于接口侧：先把调用方分类做成可筛选的维度，再谈谁能调用什么。

边界：认出 agent 不等于拿到用户上下文#

材料明确指出这只是第一步。站点可能认出了发起请求的 agent，却缺少原本能拿到的用户信息：是否为既有客户、授权 agent 做了什么、是否有订阅、应适用哪些保护。发布方称下一步需要隐私友好的方式解决三件事：(1) 让用户上下文穿过 agent 传递；(2) 帮助站点评估信誉；(3) 在出问题时明确责任归属。这些属于方向性描述，目前没有可核验的接口、字段或规范细节。

对开发者的实际含义：如果你的系统靠“用户是谁”来做授权或风控，现在不能假设 agent 会替你带上这些信息。按“请求来自 agent，用户身份另行确认”来设计会更稳妥；也正因为如此，本文开头说的两层里，第二层目前只能落在 agent 这一粒度上，落不到具体用户。

如果你在做 agent 一侧#

以下是建议，不是材料中的事实：让 agent 的请求可被稳定识别（一致的 User-Agent 与来源说明），遵守站点的 robots 与访问条款，正确处理 403 与 429，不要用轮换身份的方式绕过站点策略。可识别性既是站点授予访问权限的前提，也是被误封时申诉的依据。

待核实清单#

• Personal Assistants 分析与逐 agent 策略的套餐范围、区域可用性。
• Account Abuse Protection 的正式可用时间与开通条件（材料仅标注 early access）。
• “受支持的个人 agent”具体包含哪些。
• Bot Analysis 各分类的判定依据与识别覆盖率。