个人 agent 访问网页：可见性与控制权该由谁声明

把问题压缩成一句话：当一个人让 agent 代替他打开你的站点，这次访问的“身份”和“规则”由谁说了算？就本次材料覆盖的范围而言，答案是没有哪一方能单方面完成这个声明。站点能声明的是访问规则，agent 运营方声明的是自己的身份（但这是自报的），用户能声明的是自己委托了什么（但站点通常收不到）。Cloudflare 在 2026 年 11 月 4 日和 5 日发布的两篇文章，正好把这件事拆成两半来看：前一篇给出站点侧的可见性与控制手段（Cloudflare Blog，2026-11-04），后一篇把剩下的一半，也就是身份、信誉和问责，明确列为待解决的问题（Cloudflare Blog，2026-11-05）。

站点侧现在能声明什么#

按第一篇的说明，Cloudflare 把“个人 agent”定义为人类与互联网之间的中间层：它把人给出的指令翻译成请求和动作。对站点来说，比对商品、查帮助文档、完成购买这三种交互长得都一样，全是自动化流量。全封掉可能等于把客户赶走，因此它提供的是“先看见，再决定”。

可见性：把说不清的自动化流量拆开

按文章说明，Security Analytics 里的 Bot Analysis 图新增了 Personal Assistants 分类，与 Verified Bot、Likely Human、Likely Automated、Automated 并列；Top statistics 里新增 Personal Assistants 组件，列出哪些 agent 在访问、各发多少请求。选中其中一个 agent 后，其它组件会跟着过滤，显示它请求了哪些路径、拿到什么状态码、来自哪些网络（来源）。

在账户层面，文章称 Account Abuse Protection（目前处于 early access）可以让站点所有者和反欺诈团队看到每个 agent 代表的是哪个用户：登录和注册事件会标注请求是否由个人 agent 发出、是哪一个；账户概览会显示代表该账户活动的 agent。调查时可以区分“客户用了好几周的 agent”和“今天第一次出现、需要多看一眼的 agent”。如果要处置某个账户，可以用针对 Hashed User ID 的 WAF 规则，而不会把依赖同一 agent 的其他用户一起封掉。

这些描述的适用条件需要写清楚：它们是 Cloudflare 自有产品在特定阶段的说明，支持范围限于“supported personal agents”，账户相关能力还处于早期访问。具体覆盖哪些 agent、在哪些套餐可用，材料未给出，待核实。

策略：从整体开关到逐个 agent 声明

文章称此前（“今年夏天”）引入的 AI bot policies 允许站点为 Search、Training、Agent 三类行为分别设定访问控制；这次把 Agents 策略扩展到对受支持的个人 agent 做细粒度控制，并把设置项更名为 “AI Crawler and Agent access policies”。可选值有三档：Allow（不阻止）、Block on pages with ads、Block。用法是先在 Security Settings 设置整体 Agents 策略，再对个别 agent 覆盖，例如整体设为“在带广告的页面上阻止”，再对某个想欢迎的 agent 单独设为 Allow。原有的 Search 和 Training 策略保持不变。添加新 zone 时的引导流程会询问页面是否靠广告变现，并据此给出推荐策略。

要把这条信息放进正确的位置：这是站点侧声明，它表达的是“我允许哪一类访问者、以什么方式访问我的哪些页面”，并不表达“这次请求背后是哪个具体的人”。

agent 侧的自报身份为什么不够#

第二篇把问题讲得更直接：远程托管的 agent 本质上是一种中间层，站点看到 agent 而不是用户，而一个 agent 可以同时代表很多用户。文章用“中间层原则”概括立场：用户与站点之间的业务关系，以及各方的安全责任，不应因为中间层的存在而失效。它也界定了范围，本地 agent（例如文中提到的 OpenClaw）或运行在用户自己浏览器里的 agent 不在主要讨论内；文中举出的托管型产品例子（Muse by Meta、dots by OpenAI）属于来源方的举例，本次未核实。

在这个框架下，“agent 自报我是谁”很难独立支撑归因，文章列出的原因包括：

• 标识可以照抄。攻击者可以复制知名 agent 的 user agent 字符串，拿到同样的放行待遇；agent 也常使用住宅 IP 和真实浏览器，刻意不把自己和人类流量区分开。
• 粒度对不上。站点看到的是一个 agent，实际委托可能来自很多账户，也可能同一账户被多人共用。
• 人机验证不解决问题。CAPTCHA 之类判断的是“控制浏览器的是不是人”；agent 本来就不是人，把这层信号透传上去也不增加新信息。
• 强验证前提失效。活体检测、KYC 这类流程假设“在场者即被验证者”，而 agent 永远不是那个人。站点要么接受 agent 转交的验证结果（削弱检查强度），要么拒绝 agent，要么放弃这项检查。

真正缺的是“用户委托了什么”#

第一篇在结尾也承认，agent 身份只是故事的一部分。站点可能认得出 agent，却缺少原本会有的用户信息：是不是老客户、被授权做什么、有没有订阅、该适用哪一层保护。文章给出的后续方向是三条，并强调要用对隐私友好的方式实现：(1) 让用户上下文能够穿过 agent；(2) 帮助站点评估信誉；(3) 出问题时能明确问责。第二篇把同一件事表述为安全和反欺诈的三要素：身份、信誉、问责，对应三个问题——行动的人对自己的身份是否诚实、这个人是否可信、谁来为这个动作负责。

换句话说，今天站点能拿到的只有“agent 这一层的身份”，而站点真正要判断的是“用户这一层的关系”。下面这张表根据第二篇文章汇总，列出这种断层会落在哪些具体决策上（表中描述为来源方观点，不是通用定律）：

对开发者的含义#

下面是基于以上材料的工程建议，不是材料原文结论：

1. 把“阻断”和“归因”当成两件事。阻断只需要一个可判定的信号（IP、UA、路径、速率）；归因需要用户上下文。把两者混在一个开关里，最后往往只能在“误伤”和“放开”之间二选一。
2. 日志里留两类字段。一类是 agent 侧证据（声明的标识、来源网络、请求模式、状态码分布），一类是用户侧证据（账号 ID 或其哈希、会话、授权范围）。缺少任何一头，事后都无法判断这是不是同一个客户。
3. 不要用可伪造的标识做唯一放行依据。标识只能用于降低摩擦，不能用于授予高权限。
4. 账户级处置优于 agent 级处置。第一篇里“用 Hashed User ID 的 WAF 规则处置单账户、而不封整个 agent”就是这种思路，值得在自建系统里照搬。
5. 把策略写成可覆盖的层次。整体策略加个别覆盖，比单一全局开关更容易随业务调整。

如果你的站点不在 Cloudflare 后面，上述产品功能自然用不上，但字段和策略位可以自己补。下面只是说明这类判定的结构，未执行，也不是可直接运行的代码：

# 示意：策略分层，非可运行代码
policy = {
  "default": "block_on_ad_pages",
  "agent_overrides": {
    "supported-agent-x": "allow",
  },
}
# 判定所需的两类证据
decision_input = {
  "agent": {"declared_id": ..., "network": ..., "path": ...},
  "user":  {"account_hash": ..., "delegation_scope": ...},
}

还没定下来的部分#

• 用户上下文如何“穿过” agent，材料只说方向（隐私友好的携带、信誉评估、问责），没有给出协议形态或时间表，待核实。
• 第二篇文章的抓取内容在“用户归因”一节被截断，其完整结论与后续方案未包含在本次材料中，不做推断。
• 各功能的具体套餐、定价、支持区域与 agent 清单，材料未提供，待核实。

回到标题的问题：可见性目前由站点侧声明，控制权也由站点侧声明，agent 侧和用户侧只能各自提供一部分、且都不完整。可操作的结论不是等一个统一标准，而是现在就把“agent 这一层的身份”和“用户这一层的关系”分开建模——前者决定要不要放行，后者决定放行之后给什么。