直到不久前，开放 Web 上的流量大致呈现两种形态。一种是人工浏览——断断续续、受注意力限制，受制于一个人在一次浏览中能阅读多少页面。另一种是程序化爬取——高并发、扇形展开、大多无状态，对用户几乎不可见。
第三种形态正在迅速崛起。使用浏览器的 AI 智能体——Anthropic 的 Computer Use、OpenAI 的 Operator，以及各类开源自主智能体——代表用户驱动真实浏览器依次访问多个页面。它们产生的流量与前两种都不相同。曾经成功抵御爬虫的网站，面对这种流量还不知道该如何应对。支撑这些智能体的基础设施提供商，也仍在摸索合适的基础原语。
本文是对当前生产环境中 AI 智能体流量实际形态的一次快照，以及它如何塑造了支撑它的基础设施栈。
流量在网络层面的表现
一个典型的 AI 智能体流程：用户要求智能体”帮我找八月下旬从纽约到东京最便宜的直飞航班”。智能体启动一个无头 Chromium，导航到 Google Flights，填写表单并提交，解析结果，跟进最便宜的选项进入航空公司网站，导航到预订页面，确认可用性，最终返回答案。
整个过程涉及 8 到 15 个 HTTP 请求，历时 30 到 90 秒，具有以下特征：
突发性。 要么零请求，要么持续的一连串请求，中间没有稳定状态。智能体在用户发出请求之前处于空闲状态，一旦触发便全力运行一分钟。
突发期内有状态。 智能体的流程包含 cookie、会话和 User-Agent。从目标网站的角度来看，第 N+1 个请求必须看起来像第 N 个请求的延续。流程中途更换 IP 会破坏会话。
访问端点异构。 每次智能体运行会访问多个不同的网站——搜索引擎、航空公司 A、航空公司 B，可能还有比价聚合平台。每个网站都有各自的反爬虫策略。
地理位置与用户绑定。 用户想查询从 JFK 出发的航班，而不是从某个随机数据中心出发的。智能体的流量应当在地理位置上合理地对应用户所在地，或至少对应用户希望显示的预订地。
对延迟敏感。 用户就在那里等待。单次请求延迟从 200ms 增加到 800ms，乘以 12 个请求，意味着”智能体 30 秒内给出答案”和”智能体 1.5 分钟后才给出答案”之间的差距。
这种形态既不符合人工浏览模型（速度太快、在机器速度下过于有状态），也不符合爬取模型（每次会话请求数太少、过于依赖会话、与用户地理位置绑定太紧）。
为何朴素的基础设施方案会失败
经验丰富的数据团队惯用的一些模式，在这里并不适用：
对大型住宅代理池进行逐请求轮换。 这是默认的爬取模式。对智能体而言是错误的，因为会话需要 IP 一致性、登录 cookie、搜索状态和指纹绑定。逐请求轮换会在第 2 个请求时破坏会话。
使用数据中心代理以获得速度优势。 因其延迟特性而颇具吸引力。但这是错误的，因为智能体访问的上游目标（Google、航空公司、电商、银行）会对数据中心流量采取强力防御。智能体一半的运行会因 CAPTCHA 而失败。
使用单一静态住宅 IP。 因其一致性而颇具吸引力。但这是错误的，因为该 IP 会在智能体之间迅速耗尽——一个 IP 服务数千个智能体流程，在前 100 次运行后看起来就像一个爬虫。
有效的形态更接近于：在住宅代理上使用粘性会话，每次智能体运行使用一个全新的会话，地理定向与用户意图匹配，会话生命周期与运行的自然生命周期绑定。
有效的模式
大多数生产环境智能体部署最终收敛到的架构：
user_request → agent.spawn( proxy_session_id=hash(user_id, request_id), # unique per user-run pair proxy_country=user_geo_or_intent, proxy_ttl=longer_than_expected_run, # don't expire mid-flow ) → browser navigates target sites through that session → agent returns result → proxy session expires naturally代理抽象是以每次运行为单位的，而非以每个请求为单位。在一次运行内，智能体拥有一个一致的住宅 IP。跨运行时，每个智能体流程都会从一个新的 ISP、通常来自一个新的城市获取一个全新的 IP。代理池的多样性防止任何单一 IP 因重复的智能体流量而被封禁；会话一致性则防止目标网站在流程中途将智能体标记为可疑。
这在功能上与比价机器人使用的模式相同——每个会话使用粘性住宅会话，通过稳定的 sid 进行每客户归因。AI 智能体的特殊之处在于，流量规模大幅提升（每个触发智能体运行的用户查询都是一个会话），而持续时间更短（大多数智能体流程在 2 分钟以内）。
按带宽计费的住宅基础设施天然契合这一模式：智能体运行是受带宽限制的事务，而非受并发限制的事务。按智能体传输的 GB 数付费；并发是智能体运行时的问题，而非代理的问题。
目标网站的应对
目前大多数什么都没做。大多数主流网站仍然将 AI 智能体流量与爬取流量同等对待——相同的反爬虫规则，相同的封锁策略。这种情况将很快朝两个方向改变：
从智能体流量中受益的网站将主动适配。 预订流程、电商结账、比价购物。智能体是通过自动化层服务的真实用户；转化依然是真实的。聪明的网站开始发布对智能体友好的端点，类似 robots 的声明，表示”将携带此 User-Agent 和此 Header 的流量视为人工介导的智能体，不要封锁，可以限速”。
从智能体流量中受损的网站将加强防御。 任何依赖广告的网站都面临真实问题——智能体不看广告、不点广告、不为广告主带来转化。新闻网站、免费内容网站、任何依靠展示量变现的网站都有动机专门检测并封锁智能体流量。这将成为反爬虫军备竞赛的下一个阶段，而且会比爬虫时代更加激烈，因为智能体层背后有强大的企业支持者——如果他们的智能体被封锁，他们就会受损。
夹在中间的基础设施层——也就是我们以及住宅代理网络领域的同行——处于一个有趣的位置。我们是让智能体访问那些尚未欢迎它们的网站的接入层。随着网站与智能体提供商之间的博弈逐渐明朗（可能通过合同、付费关系以及修订版 robots.txt 式协议的组合来实现），纯基础设施提供商在”已获许可”路径上的角色将收窄，在”需要 IP 层多样性”路径上的角色将扩大。
2026 年值得关注的信号
如果你正在基于智能体进行构建，以下几个信号值得追踪：
流程中途需要重新认证的智能体运行比例。 目前在正确使用粘性会话的情况下接近于零。如果这一比例开始上升，说明目标网站已经学会检测智能体指纹，并在会话中途发起挑战。缓解措施需要在智能体侧改善浏览器指纹，或采用不同的代理策略。
多步骤智能体流程的延迟 p99。 目前主要由网络和目标网站响应时间决定。如果代理网关在并发智能体负载下成为瓶颈，基础设施层需要扩容。
智能体流量的地理分布。 目前大多数智能体流量的地理位置对应智能体运行时的托管地（主要是美国东部）。随着智能体开始介导真实用户的交易（购物、预订、银行业务），流量需要对应用户所在位置，网站逻辑才能正确运行。这是城市/ASN 精度的住宅基础设施成为默认选项的乐观预期。
对智能体友好的网站声明。 关注类似 agents.txt 的标准或结构化的”我欢迎在以下约束条件下的智能体流量”声明的出现。如果这一机制落地，代理层的角色将收窄；如果没有，代理层将继续作为接入中介。
结语
AI 智能体是一种真实存在的全新流量形态。它不是爬取，不是浏览，也不是 RAG 检索——它与三者都有共同点，但与任何一种都不完全吻合。底层基础设施必须灵活适配，以支持在爬取量级并发下的每次运行粘性会话，同时满足与用户绑定的地理定向，以及爬取所能容忍延迟三分之一的延迟目标。
对基础设施提供商而言，好消息是：构建得当的住宅代理网络已经天然支持这种形态。每次智能体运行的粘性会话、每次会话的全新 IP、地理精度、随用量扩展的带宽计费。那些在服务爬虫和比价机器人过程中成熟起来的基础原语，正是智能体所需要的。
未来两年的产品问题，不在于智能体流量是否会成为一个真实的品类——它已经是了。而在于基础设施栈与目标网站生态系统，能否清晰地收敛到双方都能接受的条款上。到明年的发布文章时，我们将有更清晰的答案。