个人 agent 的可见性与控制：服务器端怎样区分人与代理流量

直接回答：服务器端没有可靠办法把“人”和“代理”做成一次判断的真值。请求级特征（User-Agent、IP、TLS 指纹、访问节奏）可以给出概率性分类，但都可被复制或伪装。工程上可行的是把问题拆成四层——分类、绑定、策略、问责——每层用不同数据回答不同问题，并明确每层的置信度上限。Cloudflare 在 2026 年 11 月 4 日与 5 日的两篇博客中，分别给出了前两层与第三层的部分能力，第四层仍是公开的路线图方向。

先拆问题：四个不能混在一起的判断#

把“区分人与代理”当成一个判断，会得到互相矛盾的实现。拆开之后，每层有独立的输入和误差来源：

Cloudflare 在第一篇博客中把个人 agent 描述为人与互联网之间的中间层：它把用户的指令转成请求与动作，于是比价、查支持文章、完成购买这三种行为在站点侧看起来都是自动化流量；而直接封禁虽然“最安全”，代价是丢掉这些客户（See the agents, set the terms）。

请求级信号为什么单独用不住#

第二篇博客列举了站点在允许 agent 之后会重新遇到的难题，其中几条直接说明了请求级识别的失效方式：

• 身份伪装：agent 常跑在住宅 IP 上、使用真实浏览器、混在人类流量里，并刻意不把自己与人类流量区分开；攻击者则复制知名 agent 的 User-Agent 字符串来套取同样的放行。
• 人机验证失去意义：CAPTCHA 检验的是控制浏览器的实体是不是人，而 agent 从来不是人；把这一信号透传给背后的人不增加新信息，只会让 agent 更低效。
• 基于风险的认证断裂：设备、位置、行为三要素的匹配假设被打破，agent 每次运行在云基础设施上，看起来都不一样。
• 流量混杂：一个用户滥用共享 agent 做撞库、爬取或卡测试，站点能发现滥用，但只封 agent，就会连带封掉它的全部合法用户。

因此，“已验证”比“自称”更值钱。Cloudflare 的做法是把自己的 bot 目录比对结果带进流量明细，即将“未解释的自动化流量”变成可处置对象。这也是任何自建方案要面对的现实：没有第三方核验的自称标签，等于没有标签。

厂商现在给出了哪些字段#

按第一篇博客的描述，可在 Security Analytics 中核对到的能力有三组：

1. 分类视图

Bot Analysis 图表新增 Personal Assistants 类别，与 Verified Bot、Likely Human、Likely Automated、Automated 并列，选中后只看个人 agent 流量。

2. per-agent 明细

Top statistics 新增 Personal Assistants 组件，列出访问本站的各个 agent 及其请求量；筛选某一个 agent 后，其余组件联动显示它请求的路径、收到的状态码与来源网络。实际价值在于能看出 agent 是在登录、读商品页、触达结算，还是在它用不了的页面上报错。

3. 账户级绑定

使用 Account Abuse Protection（材料称处于 early access，正式可用范围与时间待核实）的站点，可以看到每个 agent 代表哪个用户：登录与注册事件标记该请求是否由个人 agent 发起、是哪一个；账户概览列出作用于该账户的 agent；可疑登录可以区分“客户用了数周的 agent”与“今天首次出现的 agent”。处置上，材料给出的方式是针对该账户的 Hashed User ID 下发 WAF 规则，而不是把 agent 对所有用户封掉。

第三组是分层里最关键的一步：它把“agent 是谁”换成“agent 替谁办事”，从而把封禁粒度从 agent 降到账户。

策略不是一个开关，而是一组按维度展开的选择#

第一篇博客说明，原先的 Agents 策略扩展为可按受支持的个人 agent 分别设置，设置项随之更名为 AI Crawler and Agent access policies，Search 与 Training 的既有策略保持不变。每个受支持 agent 可选：

• Allow（不拦截）
• Block on pages with ads（在带广告的页面上拦截）
• Block

也就是说策略是“总体策略 + 单 agent 覆盖”的两级结构：可以整体设为在有广告的页面上拦截，再对某个想欢迎的 agent 单独放行。添加新 zone 时的引导流程会询问是否用广告变现，并据此给出推荐策略，之后仍可在 Security Settings 中修改。博客给出的对照例子是两类发布方：一类全站放行某 agent 以便读者找到文章，另一类在广告支撑内容的页面上拦截同一个 agent——两者都是有效取舍。

由此可以推出的实现约束（属推断）：策略维度目前是“agent 身份 × 页面属性”，不是“agent 身份 × 具体用户权限”。后者需要下一节的能力。

仍然缺的那一块：用户上下文#

第一篇博客明确把下一步目标写成“在个人 agent 充当中介时保留站点与用户关系的上下文”：站点可能认得出 agent，却拿不到本该有的用户信息——是不是既有客户、授权 agent 做了什么、有没有订阅、该适用哪些保护。博客列出的三个方向是：让用户上下文穿过 agent 传递、帮助站点评估信誉、在出问题时确立清晰的问责，并说明将与 agent 运营方及生态其他方合作推进。

第二篇博客把同一问题表述为中间层原则：用户与站点之间的业务关系、以及各参与方的安全责任，不应因中间化而失效；传统上这需要 Identity、Reputation、Accountability 三件事，对应“是否如实表明身份”“是否可信”“谁为行为负责”。该文正文抓取在挑战清单处被截断，结论可能在未提供部分，因此这里不推定其提出的具体机制。

对开发者的含义是：不要把“已识别 agent”当成“已识别用户”。在用户上下文可传递的机制落地前，任何依赖用户身份的风控分支都需要保留“agent 背后未知”的降级路径。具体规范、字段与可用时间，材料未给出，待核实。

自查清单#

1. 分类结果是否被当成真值使用？若是，把它降级为特征之一，并与账户态、业务规则组合。
2. 封禁粒度是 agent 还是账户？若只能封 agent，先确认共享同一 agent 的合法用户会被连带影响。
3. 是否记录了 agent 与账户的关联事件？登录、注册、结算三类事件至少要能回答“是否由 agent 发起、哪一个”。
4. 策略是否按页面类型分档？广告页、付费墙、结算页、支持文档页对自动化的容忍度不同。
5. 昂贵端点是否单独限流？搜索、库存、支持聊天、免费试用是被轮询与耗尽的重点。
6. 是否保留了“背后用户未知”的分支？未知不等于恶意，应导向更严格的验证或更低权限，而不是直接拒绝。

下面是一个仅用于说明字段组织方式的记录结构，未执行，也不是任何产品的真实 schema：

{
  "request_id": "req_demo_0001",
  "agent_class": "personal_assistant",   // 分类层输出，概率标签
  "agent_id": "demo-agent",              // 需第三方核验，勿用自称 UA
  "account_ref": "hashed_user_id",       // 绑定层，匿名访问为空
  "page_type": "checkout",
  "policy_applied": "block_on_ads",
  "user_context": "unknown"              // 上下文传递机制落地前的默认值
}

回到最初的问题：服务器端区分人与代理，能做的是把一次不可靠的判断，替换成一组各自可核对、各自有明确误差的字段与策略。分类与账户绑定的能力已有产品支撑，用户上下文的传递与问责仍是未完成的部分；具体可用性、支持范围与价格需以官方文档为准，本文材料未提供，待核实。