站点怎么接待 AI 智能体：从看见流量到分级放行

把「来访的 AI 智能体」当成需要分级接待的对象：先枚举流量，再按不标识、会话、账户、逐用户固定标识四档定要求，然后写成机器可读策略并配可复测的验收断言。

这篇教程解决什么

当访问你站点的主要是人，很多规则不用写：登录页有验证码、异常请求看 IP 与设备、付费接口靠账户。当成千上万次请求由一个替很多用户跑腿的智能体发来时，这些前提会一起失效 —— 站点看到的是智能体，不是它背后的人；一个账户被滥用，按智能体封禁会把同一智能体后面的正常用户一起挡掉。Cloudflare 在 2026 年 11 月 5 日的官方博客里把这件事称为「中介问题」，并提出中介原则：用户与站点之间的业务关系、以及各方的安全责任，不应因为多了一层中介就被抹掉。事件背景见 Cloudflare 宣布成立 Trusted Agent Delegation 联盟。

这篇教程要交付的是一套自己站点可以照做的分级接待流程：先让自动化流量变得可枚举，再按四档身份要求给不同路径定不同门槛，然后把规则写成机器可读的形式并配上能重复跑的验收断言。读完你应该能拿出三样东西：一张来访者清单、一份「哪类路径要求哪档身份」的对照表、一组可以每次变更后重跑的检查项。

不覆盖什么：不教你怎么搭建或训练智能体，不替代登录与支付风控的整体设计，不讨论具体厂商的套餐与报价，也不把还在讨论中的协议写成已经能用的能力。官方博客把 Trusted Agent Delegation 定位为一份问题陈述加一个联盟，相关协议仍在 IETF 等工作组推进 —— 本教程只取其中「现在就能做」的部分，涉及标准进度的部分一律标注待定，不写进验收项。

开始前的准备

• 一处能读的访问日志或流量分析入口，并且能按客户端类型、请求路径、状态码拆分。看不到「谁在访问、打了哪些路径、遇到什么错误」，后面所有分级都是猜的。
• 一张路径清单，把站点 URL 按后果分组：公开内容页、带广告或变现的页面、登录与注册、付费或高成本接口、写操作接口。分级是按路径后果定的，不是按页面好不好看定的。
• 能改规则的位置：边缘规则、WAF、反向代理或网关配置至少有一处可写，且改动前能回滚。只观察不拦截也可以完成本教程的前半段。
• 一名能对「误挡」负责的人。分级策略一旦写错，受损的往往是正常来访者；上线前约定谁看告警、谁执行回滚。
• 前置成本说明：要求更细的身份信息，通常意味着额外的验证环节或第三方标识服务，也意味着更多需要保管的数据；这部分成本与合规评估由站点自己承担。具体功能入口、适用套餐与是否处于早期访问阶段，以官网当前版本为准。
• 一份「待定」清单。把依赖标准进展、尚未定稿的项单独记下，避免有人把它们当成已具备的能力去写验收条件。

步骤详解

第 1 步：把自动化流量从「一团未知请求」变成来访者清单。

做什么：在流量分析里把个人智能体作为独立类别拆出来，逐条记录每个来访者的名称、请求数、命中的路径、遇到的错误码。官方博客写明本周起 Cloudflare 客户可以在 Security Analytics 里看到个人智能体单独成类，并有组件列出各智能体的请求量、路径与错误；企业侧还可用 Business Insights 对比各运营方抓取量与回带流量。具体入口名称与适用套餐以官网当前版本为准。

看到什么算成功：你能导出一份清单，每一行是一个可辨认的来访者，且能回答「它昨天打了哪些路径、其中多少次是 4xx」。如果只能看到一个笼统的「机器人」总数，先停在这里补埋点，不要往下写规则。

第 2 步：给每条路径定「后果等级」，而不是给来访者贴好坏标签。

做什么：用准备阶段的路径清单，把每组路径标成三档 —— 只读公开内容、涉及变现或广告、涉及账户与写操作。分级的对象是动作，不是身份：同一个智能体读公开文章和提交订单，本就不该是同一档要求。

看到什么算成功：每条路径只有一个后果等级，且登录、注册、付费接口、写操作接口都被单独标出，没有被「全站统一规则」吞掉。

第 3 步：按四档身份光谱，写出每档要什么、能回答什么。

做什么：官方博客把身份描述成一条在数据最小化前提下逐级披露的谱系，可归纳为四档：不提供任何标识；只提供会话级标识，让站点能把同一会话内的请求关联起来并据此建立信誉；提供账户级标识，让站点能跨会话把请求归因到同一用户；提供跨运营方、跨账户与跨会话仍稳定、且逐用户固定不与他人共用的标识，用于高风险动作或访问昂贵资源。对应可承载的机制包括 Web Bot Auth 用于智能体平台身份、MOLE 用于用户信誉、OAuth 用于账户身份等，另可结合 Privacy Pass 这类不揭示身份也能建立信任的方式。

看到什么算成功：你有一张四行表，每行写清「这一档向站点交出什么」与「站点据此能回答哪个问题」。官方的提法值得照抄进内部文档：身份用来回答「你是谁」，进而回答「你是否是所称的那个人」与「能否信任你」；而不少场景其实只需回答最后一个问题，不必先回答前一个。

第 4 步：把「允许做什么」写成机器可读的策略，别让来访者靠试探猜。

做什么：为每类来访者写明允许的动作集合：全站放行、仅在特定路径（例如带广告的页面）限制、或整体拦截；并让搜索用途与训练用途的策略保持互相独立，改一条不应牵动另一条。官方博客特别指出，现在智能体是靠「试一下再看站点是否拦它」来推断规则，双方都白白消耗资源，有时还会让守规矩的智能体显得像恶意流量；robots.txt 能说明爬虫可以去哪，却不足以表达智能体可以做什么。IETF 的 AI Preferences 工作组正在做偏好表达机制，但按官方说明其重点在训练、推理与搜索这类使用偏好，更大的「动作表达」需求尚无对应工作组。

看到什么算成功：规则是站点主动发布的、可被程序读取的，而不只是一段给人看的说明文字；且你能指出每条规则对应第 2 步的哪一组路径。这里要克制：不要假称已有成熟标准可用，把依赖工作组成果的部分记进「待定」清单。

第 5 步：为「一个智能体后面有很多用户」准备归因，而不是准备连坐。

做什么：识别流量混叠这类情形 —— 某一用户借共享智能体做撞库或试探，站点若只能看到智能体，封禁会连带该智能体背后的其他正常用户。做法是让登录与注册环节能看出请求是否由个人智能体发起、是哪一个，并在需要处置时按用户层的标识限定范围，而非整体封禁智能体。官方博客提到 Account Abuse Protection 早期访问版本可在登录与注册处显示这一信息，并支持按哈希用户标识写 WAF 规则，从而只处置那个账户。是否可用、字段名与配置方式以官网当前版本为准。

看到什么算成功：你能演示「处置一个账户，不影响同一智能体下的其他账户」。做不到就先别上自动封禁，改为人工告警 + 复核。

第 6 步：把本地与自建智能体单独列为例外，并写进「待定」。

做什么：官方博客明确把运行在用户自己设备上、或本地托管的智能体排除在首期讨论范围之外 —— 它们看起来就是自动化，且没有单一可归责的运营方。给这类流量单独定一条观察规则，别把第 3 步的四档表硬套上去。

看到什么算成功：文档里有一节写明「哪类来访者暂不适用本策略、以什么临时规则处理、由谁在什么条件下复评」。

第 7 步：写一组每次变更后都能重跑的验收断言。

做什么：至少四条 —— ① 未列入清单的新来访者走默认档，不会因规则顺序落到放行；② 仅在特定路径的限制确实只命中那组路径，公开内容页不受影响；③ 账户与写操作接口要求不低于第 3 步设定的档位；④ 按用户层标识的处置不会波及其他账户。用第 1 步的日志入口逐条核对命中记录。

看到什么算成功：四条断言都有对应的实际请求样本与状态码，能贴进变更记录；任一条无法验证，就把这次变更标为「未验收」，不要默认生效。

常见坑与排错

把 robots.txt 当成访问策略。 它表达的是抓取范围，不是动作许可；写了允许抓取不等于允许提交表单或下单。症状是策略文档看着完整，智能体仍在登录路径上反复试探。排错时先看第 4 步的规则有没有真正下发到边缘，再看解析口径。

把「能不能信任」和「是谁」混为一谈。 不少只读场景用不揭示身份的方式就能建立基本信誉，直接上账户级乃至逐用户固定的标识，会白白增加要保管的数据与验证环节。症状是标识收集了一堆，却没有对应的高风险动作需要它。回到第 3 步那张表逐行复评。

按智能体整体封禁。 这是官方点名的流量混叠问题：一个用户滥用共享智能体，封掉智能体会连带其他正常用户。症状是投诉集中在「我没做什么却进不去」。先按第 5 步把处置粒度降到账户层，再考虑更粗的规则。

把问题陈述当成已上线标准。 Trusted Agent Delegation 按官方定位是问题清单与联盟，Web Bot Auth、MOLE、OAuth、WIMSE、AIPREFs 等机制处在协同推进中；把「等标准落地」写进当前验收项，结果会是验收永远不通过。症状是验收表里躺着几条无法用现网请求验证的条件。统一移到「待定」清单。

忽略多重中介。 官方博客提出一个尚未解决的问题：当智能体 A 在浏览器 C 里又调用了智能体 B，站点需要知道这条链，否则可能被用来绕过策略。症状是同一请求里出现多个身份来源，规则只认了其中一个。现阶段把它记为已知边界并保留原始请求头供排查，不要自行下「已解决」的结论。

排错顺序固定下来：先确认第 1 步的埋点是否真的把该来访者识别出来了，再确认第 4 步的规则是否下发并被命中，最后才怀疑身份层配置。反过来查，很容易把「没看见」误诊成「标识不对」。

进阶用法

把分级接到现有可观测体系。 第 7 步的断言不该是人工翻日志，理想状态是每次变更后自动跑一遍并留下结果。若站点已有追踪与指标链路，可以给「来访者类别」「命中规则」「处置粒度」三个维度各加一个字段，做法与 把 Agent SDK 的追踪接进 OTLP 后端 是同一套思路：先把观测补齐，再谈自动化处置。

和「自己跑的智能体收紧权限」分开看。 本篇是站点侧接待来访流量，方向朝内；GitHub Agentic Workflows 四道护栏 与 给智能体配自主权契约 是开发者侧约束自己放出去的智能体，方向朝外。两套清单可以共用一套变更记录，但不要互相代替：一个管「谁可以进来做什么」，一个管「放出去的能做什么」。

给「授权」和「身份」划清边界。 能认出某个智能体并不等于它有权执行该动作；第 3 步解决的是识别与信誉，第 4 步解决的是动作许可。若站点还涉及审批流或分层放行，把 AI 代码进主干拆成判定层与放行层 里那套「判定 / 拦截 / 放行」的分层思路可以借用，但那是代码合并场景，不要照搬具体规则。

常见问题

站点流量不大，也要做这套分级吗？

可以只做前半段。第 1 步的「看见流量」与第 2 步的「路径分后果」成本很低，且即使来访者以人为主也不会白做；第 5 步的账户层归因与自动处置，等确实出现共享智能体带来的混叠再说。真正的门槛不是流量大小，而是有没有高后果路径（登录、付费、写操作）。只有公开内容页的站点，把第 4 步的策略写清楚通常就够了。

四档身份是不是要一次全上？

不建议。按第 2 步的路径后果倒推：只读公开内容往往不需要任何标识，或只需会话级关联；账户级标识对应跨会话归因；跨运营方稳定、逐用户固定的标识对应高风险动作与昂贵资源。一次全上会同时增加验证环节、数据保管范围与合规评估量，却未必有对应动作需要它。先覆盖高后果路径，再按实际出现的问题逐档加。

这些协议现在能直接接进生产吗？

按官方博客的口径，Trusted Agent Delegation 是问题陈述与联盟，不是已定稿的标准；文中列举的 Web Bot Auth、MOLE、OAuth、WIMSE、AIPREFs 分属不同成熟度，IETF 相关工作也仍在推进。因此本教程把它们当作「方向」而不是「依赖」：现在可做的是流量可见性、按来访者设访问策略、以及账户层归因这三类已经落到产品里的能力，具体是否可用、是否处于早期访问、以及配置入口，以官网当前版本为准。别把尚未定稿的机制写进验收项。

这和普通反爬、验证码有什么区别？

普通反爬多数在回答「这是不是自动化」，目标是拦住；分级接待回答的是「这个动作允许谁做、需要多少披露」，目标是在保留来访的同时把责任与授权说清。官方博客也指出，把验证码透传给用户只能证明此刻有人在，无法把请求归因到具体用户；而当智能体流量成为多数时，一律阻断本身也不再可行。所以两者是补充关系，不是替换关系。

配置入口和适用套餐在哪里查？

本篇刻意不写具体菜单路径与档位：这类信息随版本变化很快，写死反而容易误导。判断方法是先按第 1 步在流量分析里确认「个人智能体」类别是否已经可见，再按第 4 步确认访问策略是否支持按来访者分别设置，最后按第 5 步确认账户层归因功能是否对你的站点开放。三项都以官网当前版本与控制台实际显示为准；费用与额度同样以官网为准。

相关工具与内容

搭建与编排侧的入口可以看 AI智能体 分类页；涉及联网检索与内容抓取的来访者，AI搜索 与 AI工作助手 里有对应条目。工具侧可对照 Dify、n8n、Coze 的形态差异。延伸阅读：智能体编排层怎么选、给智能体配自主权契约、GitHub Agentic Workflows 四道护栏、知识工作者侧的入口选型。事件背景见 Cloudflare Trusted Agent Delegation 快讯。

一手来源（官方页面，仅作溯源）：Cloudflare 官方博客 https://blog.cloudflare.com/trusted-agent-delegation/ 。文中能力是否处于早期访问、适用套餐、字段名与配置入口，以官网当前版本为准。