个人 agent 的可见性与访问控制：服务器端该看到什么、该限制什么

服务器端要回答的不是“这是人还是机器”，而是三个更具体的问题：哪个 agent 在访问、它代表哪个用户、它被允许做什么。Cloudflare 在 2026 年 11 月 4 日的公告中把 personal agent 纳入流量分析与访问策略（See the agents, set the terms），11 月 5 日的文章则指出：agent 作为中间层，会让站点失去原本直接面对用户时拥有的信息（Agents aren’t humans (but they kinda are)）。前者给出可落地的识别与限制手段，后者说明这些手段还覆盖不到哪里。

为什么 agent 让“看到用户”变难#

Personal agent 指接受人类指令、通过控制云主机或浏览器来达成目标的自动化程序，通常由某个 Operator 以托管服务或消费级产品形式运营。对站点来说，它是中间层（intermediary）：和云浏览器、代理/VPN 一样，站点看到的是它，而不是它背后的用户。

中间层不是新问题，变化在规模。一个 agent 可以同时代表很多用户，用户与站点之间还可能叠加多个中间层。该文提出的“中间层原则”（Intermediation Principle）是：无论中间隔了什么，用户与站点之间的业务关系、各方的安全责任都应保持。难点在于，多数站点目前缺少实现这条原则所需的工具。

范围需要说明：11 月 5 日的文章主要讨论远程托管的 agent，用户自己设备上的本地 agent 不在其讨论范围内；该文抓取时被截断，以下只依据已获取的部分。

服务器端该看到什么#

流量层：先分清 agent，再看它做了什么

11 月 4 日的公告在 Security Analytics 的 Bot Analysis 图中新增 Personal Assistants 类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列；安全团队可以只筛选这一类流量，观察其随时间的变化。Top statistics 中新增的 Personal Assistants 组件列出访问站点的 agent 及各自请求量；选中某个 agent 后，其他组件会联动显示该 agent 的请求路径、收到的状态码和来源网络。

这些信号的价值在于把“无法解释的自动化流量”变成可判断的对象：某个 agent 是在登录、读商品页、走到结账，还是在它用不了的页面上反复报错。

账户层：agent 代表的是谁

对使用账户滥用防护（Account Abuse Protection，公告称处于早期访问）的站点，站点所有者和反欺诈团队可以看到每个 agent 代表哪个用户。用户总体概览页显示哪些 personal agent 在用户中活跃、有多少账户在用；每次登录和注册事件会标明是否由 personal agent 发起、是哪一个；单个账户的概览则列出为该账户服务的 agent。调查异常登录时，可以区分“用户用了数周的 agent”和“今天第一次出现的 agent”。

处置粒度也随之变化：如果怀疑攻击者通过某个 agent 操作某个账户，可以针对该账户的 Hashed User ID 下发 WAF 规则，而不是把这个 agent 对所有依赖它的用户一起封掉。这是账户级处置，不是 agent 级封禁。

看到这些，仍回答不了什么

流量分析和账户关联能回答“谁在访问、访问了什么、是否异常”，但不能回答“用户授权了这个 agent 做什么、用户是不是现有客户、有没有订阅、出了事谁负责”。公告本身也把“在 agent 中间层保留用户关系上下文”列为下一步目标，包括以隐私友好的方式传递用户上下文、帮助站点评估声誉、明确问责。这些目前还不是现成能力。

该限制什么#

策略按 agent 分层，而不是一刀切

公告把原有的 Agents 策略扩展为对受支持的 personal agent 提供更细的控制，并把设置项改名为“AI Crawler and Agent access policies”。在 Security Settings 中，可以先设一个整体 Agents 策略，再对每个受支持的 personal agent 单独选择：Allow（不阻止）、Block on pages with ads（在带广告的页面上阻止）、Block。Search 和 Training 的既有策略保持不变。添加新 zone 时，onboarding 会询问是否用广告变现页面，并据此给出推荐策略；之后可随时回到 Security Settings 修改。

公告给的例子是：一家出版方全站允许某个 agent，方便读者找到文章；另一家则在广告支撑内容的页面上屏蔽同一个 agent。两种选择都成立，取决于站点的收入结构。

判断依据是业务模型，不是“人/机器”

把人机验证当作 agent 的答案没有意义：agent 本来就不是人，把信号透传给背后的用户不会增加新信息，只会降低 agent 的效率。同样，只靠 User-Agent 识别也不够——攻击者可以复制知名 agent 的 UA 来获取同样的放行。把 agent 身份建立在可验证的目录上，比依赖自报字段更稳。

一个示意性的判定顺序

下面的伪代码只表达分层逻辑，不对应任何厂商的 API 字段，也未执行。

# 示意，未执行
category = classify(request)   # 例如 personal_assistant / verified_bot / likely_human
if category != "personal_assistant":
    return default_policy(request)

policy = agents_default_policy      # 整体 Agents 策略
if request.agent_id in agent_overrides:
    policy = agent_overrides[request.agent_id]

if policy == "block":
    return deny
if policy == "block_on_ad_pages" and request.path in ad_supported_pages:
    return deny
return allow

顺序上，先做流量分类，再查整体策略，再查单个 agent 的覆盖，最后才看页面类型。这样新增一个 agent 时，只需要改一处覆盖，不用重写整条链路。

还没解决的三件事#

11 月 5 日的文章把安全与反欺诈需要的能力归为三项：Identity（对方是否如实说明自己是谁）、Reputation（是否可信）、Accountability（谁为行为负责）。对应到 agent：agent 可以说明自己是哪个 agent，但站点无法确认它背后的用户身份、授权范围和订阅状态；新出现的 agent 没有历史可靠性可查；出错时的责任归属也没有现成规则。

该文列出的具体挑战包括账户共享、合规与年龄/地域限制、友好欺诈（用户先授权购买再否认）、人机验证失效、身份冒充、KYC/活体检测失效、agent 自身出错、基于身份的策略被绕过、资源耗尽、基于风险的身份验证失效、流量混合、未授权持卡人、无偿内容消费和用户归因等。这些不是单个站点能独立解决的，涉及 agent operator 和更广的生态协作。

给开发者的落地顺序#

1. 先测量：用流量分类和 agent 维度统计，确认哪些 agent 在访问、访问哪些路径、错误率如何。
2. 再分层：整体策略给出默认值，对个别 agent 做覆盖；按页面类型细分，而不是全站一个开关。
3. 账户级处置：发现滥用时优先定位到账户或会话，避免封掉整个 agent。
4. 保留证据：记录 agent 标识、请求路径、状态码和账户关联，便于后续调查与争议处理。
5. 不要把人机验证当作 agent 策略，也不要只信 UA。
6. 对“用户上下文传递、声誉、问责”保持关注；在能力可用前，不要假设站点已经知道用户授权了什么。

结论可以收在一句话里：当前能落地的是“基于 agent 身份的可见性与访问控制”，而不是“基于用户授权的访问控制”。把这两件事分开看，策略就不会被 agent 身份这一个维度带偏。