> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Agent 不是人，但差不多是：网站只看得见中间人 - URL: https://www.hubwiz.com/blog/agents-are-not-humans-intermediation-principle/ - Published: 2026-11-07T09:15:18.000Z - Updated: 2026-11-07T09:15:18.000Z - Description: agent 替人上网，网站只能看见中间人。于是账号共享、友好欺诈、合规核验、身份冒充全部失效。Cloudflare 的解法不是让 agent 装人，而是让网站能重新看见"它替谁在行动"。 - Author: admin - Tags: AI Agent, 隐私安全, Web Bot Auth, 互联网治理 **AI agent 现在正替上百万人在网上行动。而对一个网站来说，agent 可以有很多种形态：它可能和一个人在完成任务时无法区分，也可能看起来像一个访客背后站着一百万个用户。** 这直接抹掉了网站"识别、服务、追责"其背后用户的能力，也让网站承担了出错时的成本。Cloudflare 这篇 2026-11-05 的文章主张：网站想对 agent 开放尽可能多的访问，生态就必须发展出新的机制，来保住"站点与用户之间的关系"。 传统上，在安全与反欺诈领域，这需要三样东西：**身份、声誉、问责**。它们让网站能回答三个问题：正在行动的人有没有如实说明他是谁？这个人可信吗？出了事谁来负责？ "个人 AI agent"（下文简称 agent）是接受人类（用户）指令、通过操控一台云端电脑或浏览器来达成目标的自动化程序。它们通常由一个"运营方（Operator）"托管维护，作为托管服务或消费产品的一部分。例子包括 Meta 的 Muse 和 OpenAI 的 dots，而且新的产品一直在出现。**agent 有可能做出它的用户能做的一切动作，却没有人类的那些限制**：它们不会累、全天候运行、并行行动，还能忍受任何人都受不了的摩擦。而整个网络——从站点如何规划容量到如何赚钱——大量假设建立在这些限制之上。 从根本上说，远程托管的 agent 就是**中间人**。中间人是任何坐在用户与站点之间的东西，于是站点看到的是它而不是用户。agent 是中间人的最新形态，但中间人早就存在：云浏览器（软件代表用户操控的托管浏览器）和代理（转发用户流量的服务，包括 VPN）也是中间人。变化的是趋势：agent 流量增长很快，可能在不远的将来超过传统的真人浏览。这逼着今天每个运营站点的人重新算账。过去站点可以简单封掉中间人流量、要求用户关掉中间服务；但当大多数流量都是 agent 时，这招就不管用了。一旦封禁不再可行，站点运营者剩下的就是中间人一直带来的老问题：**站点失去了关于用户的直接信息，却必须在不掌握这些信息的情况下决定是否信任中间人。** 这篇文章讨论的是托管在用户设备之外的 agent。本地 agent（例如 OpenClaw）或运行在用户自己浏览器、自己设备上的 agent，不在本文主题范围内（见下文"关于开源与本地 agent"）。 ![没有 agent 时，用户直接与站点交互](https://www.hubwiz.com/blog/content/images/2026/11/img_b5e4d80b044024e68eb3be24a771659d-800.jpg) ![有 agent 时，站点看到的是 agent 而不是用户，而一个 agent 代表许多用户](https://www.hubwiz.com/blog/content/images/2026/11/img_bf8755918453e52983a0605d83354522-800.jpg) ![有时用户与站点之间会坐着好几个中间人](https://www.hubwiz.com/blog/content/images/2026/11/img_d1560e3ecc264d03f07100720a798919-800.jpg) 这篇文章建立在一个原则之上： > **中间化原则：用户与站点之间的商业关系，以及各方的安全责任，必须在中间化的情况下依然成立。** 站点需要新工具，去识别、服务并追责一个通过 agent 行动的用户——就像这个用户亲自来过一样。而 agent 和它背后的运营方也必须可识别、可追责，因为 agent 能做人做不到的事。agent 能够几乎无上限地放大"人的访问量"，所以即使是从前无害的行为，也会产生新的风险。 ## 中间人问题 认识一下 Ezra。她在这座城市里给人做私人助理。她最好的客户是 Amy，一位本地公司的 CEO，但她也替 Bob、Charlie 和 Debra 干活。她跑腿：买菜、预约、办手续、订机票。Ezra 混在人群里毫不起眼。 街角杂货店的老板以前认识 Amy。他知道她买什么，会把她可能喜欢的东西预留出来。现在只有 Ezra 进店，一次带着四个人的订单，店主分不清哪个偏好是谁的。他不想把 Ezra 赶走，因为她给他带来不少生意。 然后 Bob 让 Ezra 帮他买个 iPhone。一周后他打电话给商店，说他从没授权这笔支付，然后把手机留下了。要赢下这笔争议，商店必须证明是 Bob 要买的。但商店唯一见过的人只有 Ezra。 然后 Charlie 给 Ezra 一列密码："我忘了自己的，但肯定是这些里的一个。" Ezra 很有耐心地逐个在 Charlie 的银行试。银行能看出正在发生攻击，但它能封禁的只有 Ezra。而封掉 Ezra，也等于封掉 Amy、Bob 和 Debra。 这些店主对 Ezra 本人没有意见。他们的问题是**只能看见 Ezra，看不见她在替谁做事**。把 Ezra 换成 AI agent、把这些店主换成网站，就是今天的互联网。 网站主希望获得足够的可见性，既能阻止不良行为，也能有效地从站点变现或获得价值。但和 Ezra 的情况一样，这些可见性在 AI agent 面前大部分消失了。下面这些行为和场景，过去是解决过的，允许 agent 之后变得更难处理： | 挑战 | 站点的目标 | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 账号共享 | 站点需要确保一份付费订阅没有被滥用成服务多个用户。通过 agent 访问时，站点看到的还是一个账号、一个客户端。 | | 合规与非法活动 | 站点必须满足法律要求，核实用户的相关信息。例如有些站点有年龄或地域限制。站点允许 agent 访问时，agent 无法提供达到合规门槛的保证。 | | 友好欺诈 | 用户批准了 agent 的购买，事后却以"未授权"为由发起争议。站点本来可以用旁证赢：与用户过去无争议购买相同的设备、IP 和地址。但 agent 的购买来自 agent 的基础设施，这些证据不存在。即使站点赢了，争议本身也要花钱。站点需要保留结账行为记录以防欺诈；这些记录能减少额外验证带来的摩擦，降低交易拒付率，提高整体结账量。 | | 人机验证失去意义 | 站点想区分用户类型，CAPTCHA 之类的验证检查的是"操控浏览器的实体是不是人"。agent 从来就不是人。把这一信号透传给真人用户的方案，不提供任何新信息，只让 agent 更低效。 | | 身份冒充 | 站点想限制内容只对人开放，或对特定用户施加限制。agent 常跑在住宅 IP 上、用真实浏览器、与真人流量混在一起，还努力不把自己和真人流量区分开。攻击者复制知名 agent 的 user agent，就能拿到同样的待遇。 | | 身份核验失效 | 站点为了开放敏感操作或内容，可能要求额外核验用户身份。活体检测、KYC 证件核验这类手段，都假设"在场的这个人就是被核验的人"。而 agent 永远不是那个人。站点只能接受 agent 转交的核验（这削弱了检查）、拒绝 agent，或者干脆取消这项检查。 | | 失准（misalignment） | 站点想保护自己免受更新、更实验性的 agent 的误操作。agent 会犯错：拿错货、订错日期、重复下单。站点为了维护客户好感，可能得用退款和客服吞下成本，却无法分辨哪些 agent 可靠。 | | 策略被绕过 | 站点想基于身份施加策略（封禁、只允许合作方、限流），但 agent 并不总是自报身份，而且通常不带来它代为行动的用户的任何信息。 | | 资源耗尽 | 提供免费服务或依赖用户参与的站点，设计时假设了用户行为的某种上限。agent 会不停轮询（查库存、查价格）、打昂贵的端点（搜索、库存、客服对话），还会把免费试用和促销用掉。 | | 基于风险的身份验证失效 | 站点想维持基于风险的身份验证，它预期设备、位置与行为要和用户匹配。agent 跑在云基础设施上，每次看起来都很不寻常。 | | 流量混同 | 站点想保护自己和用户账号不被滥用或欺诈。当一个用户滥用共享 agent 做撞库、抓取或测卡时，站点能发现滥用，却只能封掉这个 agent——而那会连同它的所有合法用户一起封掉。 | | 未授权用卡 | 站点和支付机构需要保护持卡人免于未授权交易，同时压低争议与欺诈相关成本。当一位授权用户刷卡消费时，责任在持卡人；持卡人把卡交给非授权用户，他自己仍要为交出卡负责。agent 没有"授权用户"这个身份，所以站点无法判断用户是否支持这笔购买。实际上，当用户发起争议时，是站点付钱。 | | 无补偿的消耗 | 内容变现的站点需要看清并控制谁能访问内容，才能套用正确的变现模型。agent 读取或抽取内容（文章、商品数据、评价），到别处回答用户。站点付了带宽和算力，却没拿到访问、广告曝光或购买。 | | 用户归因 | 站点对同意授权的用户提供个性化、推荐、忠诚度等额外能力，依赖与用户会话和设备绑定的分析。agent 流量要么把许多用户归并成一个客户端，要么根本带着用户的会话。 | 上面几乎每一个挑战里，**站点都承担主要成本**。这是中间人介入后"信任如何运作"的必然结果。 ## 我们的愿景 我们的目标是这样一个互联网：所有用户对网站的访问程度，等于或超过他们此前的水平。在 agent 出现之前，站点通常可以用一整套技术来缓解这些风险，包括对用户设备、会话与历史做指纹识别。用户仍然可以用隐私浏览模式上网，我们认为 agent 也应该能这样做。但 agent 大概没法在没有任何额外验证的情况下登录银行。 这一切都不需要 agent 装成人，也不需要每个动作都真人在场。它要求的是：**站点有办法获取或要求关于用户的信息，从而在适用的时候追责——无论有没有 agent。** ## 人们试过的办法，以及为什么不够 一个常见的提议是让 agent 把站点的 CAPTCHA 转交给用户去解。这只能证明那一刻有个人在（"human in the loop"，HITL），仅此而已。HITL 主要是一种防止"失准出错"的机制。失准是运营方与用户之间的问题，解决它并不能解决上面大部分问题。例如它无法把 Bob 和其他人区分开（流量混同），也无法说明 agent 在其余时间替谁行动。更何况 agent 的存在就是为了消除摩擦，而 HITL 把摩擦又加回来，所以运营方有动机替用户把它去掉或绕开。 另一个常见提议是使用范围很窄的访问控制。但 agent 本来就是照着"用户能做的一切"去建的，所以实践中它们会申请——并且拿到——"能做一切"的权限。"一切"这个范围对站点什么也没说。而即便是很窄的范围，也只说明 agent 被允许做什么，并不说明 agent 做错时谁来负责——**而后者才是站点真正要的答案**。 ## 网络需要什么 网络需要一套工具与协议，让站点和 agent 能协作判定允许哪些行为与动作，也让站点能把偏好与策略表达给 agent，而且这一切要能被所有站点和 agent 以合理的方式支持。好消息是，这几条战线上都已经有工作在推进，其中很多（如果不是全部）可以通过应用现有标准来解决。 ### 协议 agent 与站点可以借助明确的协议来解决上面一部分问题。例如 MOLE 是一个正在推进的方案，目标是在不需要用户级标识符的情况下做限流，让站点从"隐式身份"过渡到"显式协议"来完成同样的目标。它和 x402 协议思路相近——后者希望在保持隐私的前提下让网络上能付款。我们也在积极探索如何利用现有协议解决其它问题，并在现有方案不足时设计新协议。 ### 身份 讨论 agent 身份时，**Web Bot Auth（WBA）** 是我们首选的方法。WBA 允许 agent 对自己的请求签名，从而提供一种安全的自我标识方式（并隐含地标识了运营方）。我们还需要定义一个支持多个中间人的机制：当 agent A 在浏览器 C 里使用 agent B 时，站点需要知道这件事，才能正确地理解和控制 agent A 的访问——例如防止策略被绕过。 其它类型的标识信息——会话、账号，甚至用户级 ID——可能按场景需要。我们正与相关标准组织一起探索如何传递这类标识信息。 来看用户身份的类型。归根到底，身份是一条光谱，用不同程度的信息换取不同程度的可信，同时理想情况下遵循数据最小化原则。身份提供了一个回答"你是谁"的机制，以服务于后续两个问题："你是不是你说的那个人？"和"我们能信任你吗？" 很多情况下并不需要标识信息，此时像 Privacy Pass 和 MOLE 这类隐私保护的访问调节方法，能帮我们回答"我们能信任你吗"，而不必回答"你是谁"。Private Access Tokens 是我们早期在不标识用户的前提下建立信任的一种尝试，而 MOLE 意在成为它的后继。不过，在某些场景下仍需在这条光谱上做分级披露，通常可以这样划分： - **无（Nothing）**——用户可以完全不携带任何标识符在网上行动。 - **会话（Session）**——站点需要某种方式把同一个会话里的请求关联到同一个 agent。这让站点能为某个会话建立声誉并据此行动。例如 Poppy 就为这个目的引入了会话 ID 的概念。 - **账号（Account）**——站点需要把跨会话的请求归到同一个用户。这可能是一个由运营方或第三方分配给用户的稳定标识符，在运营方账号范围内持久存在，例如同一个 agent 每天用同一个标识访问同一个站点。它能支撑的用例是："把你的站点账号和你的 agent 账号绑定"。 - **唯一（Unique）**——有些站点可能要求一个由第三方签发的、用户级唯一的标识符，跨运营方、账号、agent 和会话都持久。这对高风险动作有用，对需要限制访问昂贵资源、或有非常严格的义务与合规要求的站点也有用。政府证件、第三方身份核验，以及 Proof of Human 这类去中心化技术，都是能提供这种信息的例子。 最终，站点决定它需要哪些信息，来回答"这个请求背后的实体，此刻是否有权做这个动作"。很多情况下协议已经存在或正在制定：WBA 传达 agent 的平台身份，MOLE 传达用户声誉，OAuth 传达账号身份，等等。 ### 声明 在身份之外，有些动作需要关于真人的某个事实，比如"已满 18 岁"或"是持卡人"（对应"身份核验失效"和"友好欺诈"）。通常运营方在注册时已经核实过，或者第三方已经握有这些信息。 要让 agent 能访问带有这类限制的站点或动作，我们需要机制：让站点能请求这些信息，让运营方或第三方能提供这些信息。 ### 站点的 agent 访问策略 今天，agent 靠"试一下、看站点怎么回"（通常是看有没有被封）来推断站点的规则。这浪费双方资源，在某些情况下还让诚实的 agent 看起来像恶意的。robots.txt 说明了爬虫可以去哪里，但它并不完全适合表达 agent 可以做什么。 站点需要一种机器可读的方式，发布"允许 agent 做哪些动作"。IETF 正在积极制定一些偏好表达机制，主要在 AI Preferences 工作组里，但该组聚焦的是用途偏好（训练、推理、搜索），目前还没有工作组专注于本文讨论的、更大范围的偏好表达机制需求。 ### 关于开源与本地 agent 不作为"中间人"运行的 agent（例如设备上的 agent，或 OpenClaw 这类本地托管的 agent）会带来不同的问题。它们主要看起来像（也确实是）自动化，而且没有一个单一的一方可以建立声誉或承担责任。 对此有很多解法，其中之一是要求这类 agent 提供一个唯一 ID。不过，这不是"可信 agent 委托"（Trusted Agent Delegation）最初的关注点。 ## 下一步 站点所面临问题的现实解法，不会从碎片化的、厂商专属的机制里长出来。它们需要开放、可互操作、扎根于真实经验的标准。我们一直并继续与生态中的主要运营方、身份核验公司、支付机构、商户、出版方、代理服务商和云浏览公司合作，把运营需求与 IETF 等处正在进行的工作直接对齐。 我们的重点是在"能跑的代码"和"正在成形的规范"之间架桥，覆盖 Web Bot Auth、AIPREFs、OAuth、WIMSE 和 MOLE 等工作组与活动。具体做法之一，是共同撰写并打磨 WBA、MOLE 这样的开放协议，并大规模构建和部署这些协议的实现。 我们同时宣布**可信 agent 委托（TAD）联盟**。TAD 的目标是把生态中各方的代表聚到一起，讨论本文提出的整套问题，审视现有全部协议，然后把更明确的问题带到 IETF 去推进。我们计划在 IETF 举办边会、在将来举办工作坊来促进讨论。 如果你在构建 agent、agent 运行时，运营边缘或云平台，或者管理商业与合规应用/基础设施，我们也需要你参与进来。 ## 你今天可以做什么 开放、可互操作的基础是我们前进的方向，起点是 TAD。但你不必等新协议才开始夺回可见性与控制。就在本周，Cloudflare 客户可以做三件具体的事： **看清你站点上有哪些 agent、它们在做什么。** 安全分析（Security Analytics）现在把"个人助理"作为独立的流量类别，并新增一个组件，列出每个访问你站点的 agent、它发了多少请求、打了哪些路径、遇到了哪些错误。无法解释的自动化流量，变成可以推理的流量。至于 AI 爬虫与机器人对业务的整体影响——包括每个运营方爬了多少、又回传了多少流量——企业版 Bot Management 客户可以使用 Business Insights。 **按 agent 设定访问条件。** 用 AI 爬虫与 agent 访问策略，你可以欢迎带来生意的 agent，限制不带来的：放行整个站点、只在有广告的页面上拦、或者完全拦截。你的搜索与训练策略保持独立。 **把 agent 和它代表的用户对上——并据此处置。** 对使用账号滥用防护（Account Abuse Protection，早期访问）的站点，现在每次登录和注册都会显示这次请求是否来自个人 agent、来自哪一个。当攻击者在某个账号上滥用共享 agent 时，你可以只处置那个账号——用一条针对其哈希用户 ID 的 WAF 规则——而不必封掉它背后所有合法用户。这是对上面"流量混同"挑战的第一个具体答案：你终于能越过 agent 看到用户，并据此响应。 这些是愿景的第一批构件，且已经在生产环境上线。随着标准成熟，会有更多。 如果你的公司对 agent 持更严格的立场，我们也想听。直接联系我们，把你的问题告诉我们。我们想帮助构建这样一个互联网：站点主拥有可见性与控制，同时 agent 在这些控制之内获得尽可能合理的最大访问。你可以联系客服团队，或发邮件到 crawlercontrols@cloudflare.com。 ## 我们的整理：三个"看不见"和一个可执行的判断 这篇原文有 14 行挑战表，读起来会晕。把它压成一句话：**agent 让站点同时失去"是谁"、"是不是同一个人"、"出了事找谁"这三件事的答案。** 原文用 Ezra 的故事把三件事讲透了——杂货店丢了偏好与归因、商店丢了"Bob 授权过"的证据、银行丢了"只封坏人"的能力。 顺着这三个"看不见"，可以做一张对照表： | 丢掉的东西 | 受影响的具体行为 | 现有的替代手段为什么不够 | 方向 | | ------- | ------------------ | --------------------------------- | ------------------------------------- | | 是谁 | 账号共享、合规核验、年龄与地域限制 | CAPTCHA 只证明"有人在"，HITL 不解决"替谁行动" | 账号级/唯一级身份（OAuth、第三方核验、Proof of Human） | | 是不是同一个人 | 流量混同、撞库、测卡、资源耗尽 | 封 agent 会连坐合法用户；住宅 IP + 真浏览器让指纹失效 | 会话/账号级标识 + 按账号处置（哈希用户 ID 的 WAF 规则） | | 出了事找谁 | 友好欺诈、未授权用卡、失准造成的退款 | agent 没有"授权用户"身份，争议时站点扛成本 | 声明（claims）+ 可签名的平台身份（WBA） | 原文有一个很容易被忽略的立场，值得单独记下：**它不是要让 agent 假扮人类，也不是要每步都真人在场。** 它明确反对把 CAPTCHA 透传给用户（那只证明"有人在"，且运营方有动机绕开它），也反对靠"范围很窄的权限"解决问题（agent 本来就需要"一切"，而且"允许做什么"不等于"做错谁负责"）。 最后是一条可以自己验证的判断：如果你的站点今天无法回答"这个请求背后是一个用户还是五十个用户"，那么上面 14 项挑战里至少有一半已经在发生，只是你还没看见。原文给的第一个动作不是买什么，而是**把"个人助理"这类流量单独分出来看**——先看见，再谈策略。 原文：[Agents aren't humans (but they kinda are)](https://blog.cloudflare.com/trusted-agent-delegation/?ref=hubwiz.com)（Cloudflare Blog，2026-11-05） 本文由汇智网 · Software 2.0 完整编译，转载请注明出处。 > **这是「Agent / MCP / 自动化」专题的一部分。** 完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/) **相关阅读**：[Agent 花钱的三道门：x402 实测与护栏](https://www.hubwiz.com/blog/agent-payment-security-x402-guardrails/) · [AI 爬虫伪造流量实录：日读 600 到 2,800 的取证](https://www.hubwiz.com/blog/ai-bot-traffic-forensics-aws-waf/)