Cloudflare 这篇文章的核心案例是一个跑腿助理，叫 Ezra。
Ezra 替四个客户办事：Amy 是当地一家公司的 CEO，Bob、Charlie、Debra 也是她的客户。她买杂货、跑预约、办手续、订机票。这四个人里只有她每天出现在店里。
街角杂货店以前认识 Amy，知道她买什么，会给她留货。现在只有 Ezra 来，一次带四个人的单子，店家分不清哪份偏好是谁的。他不想赶走 Ezra，因为她带了大笔生意。
这个寓言换到 web 上，就是 agent 时代站点面对的问题：站点看得见 agent，看不见 agent 背后的人 。
用户直接访问时，链路只有三段：用户、浏览器、站点。
用户直接访问站点时的三段链路
图：没有 agent 时，站点与用户之间只有浏览器。来源：Cloudflare。
agent 上网站点之后，中间多了一层：多个用户指向同一个 Operator，Operator 里是 Agent 和浏览器，站点只看到 Operator 这一端。站点原本用来判断「这个人是谁」的证据，全部断在中间。
多个用户经由同一个 Operator 访问站点
图：多个用户共用一个 Operator，站点只能看到 Operator 这一端。来源：Cloudflare。
#三件具体的事，全都坏了
赖账。Bob 让 Ezra 买一部 iPhone，一周后打电话给店里说这笔消费他没授权，手机留下。店家要赢下争议，得证明是 Bob 要买的，可它只见过来跑腿的人。换成 agent，购买请求从 agent 的服务器发出，设备、IP、地址这些传统证据全部断开。
账号共享。一个付费订阅被拿来服务很多人，站点这边看到的只是一个账号、一个客户端。
合规。有些站点对用户年龄、地区有法定核验义务。允许 agent 访问，就失去了完成核验的依据。
这三件事以前都有成熟解法：看设备指纹、看行为、看历史订单。它们都建立在一个前提上：屏幕上那个人，就是账号背后那个人。
#封禁的悖论
还有更麻烦的一种：有人把一串密码交给 Ezra，让她挨个去银行试。银行的风控看得见攻击，但能封的只有 Ezra。
封了 Ezra，Amy、Bob、Debra 一起被拒。她们本身没有任何问题，问题是站点只看得见那个跑腿的。
中间人问题换了个版本。云浏览器、代理、VPN 都是中间人，历史上站点可以简单地拒绝中间人流量，要求用户关掉代理。这条路在 agent 流量占多数之后会失效。
#Cloudflare 的答案：三件套 + 一条原则
他们给的原则叫 Intermediation Principle：用户与站点之间的业务关系和各自的安全责任，不因为中间人的存在而消失。
落到工程上，站点需要能回答三个问题：
- 身份 ：这个 agent 在替谁行动，能不能验证。
- 信誉 ：这个 agent 和它背后的操作者，过往行为如何。
- 追责 ：出了事，谁承担。
这三个问题都不是 agent 单方面能证明的，需要协议层和站点侧共同配合。Cloudflare 认为 agent 流量可能超过传统人类浏览，站点没法靠一封了之。
#结语
agent 身份问题常被当成协议问题讨论（OAuth、令牌、委托链）。Cloudflare 这篇把它还原成责任问题：站点要回答的是它背后那个人能不能签字、签了字算不算数。