过去 18 个月里，一种模式已经逐渐成型。那些真正在生产环境中发挥作用的 AI 系统，并不只是查询模型然后返回结果。它们在推理时从实时数据源检索信息，将检索结果作为上下文传递给模型，让模型基于最新的可用信息进行推理。
这种模式有很多名字。RAG 是最常见的一个，此外还有工具调用、函数调用、基于网络搜索的生成。叫法各异，架构本质相同。模型本身只知道训练数据中的内容，而具备检索能力的模型则可以回答训练截止日期之后的问题。
没人深入探讨的部分是检索本身，具体来说，是什么决定了目标网站是否真的会向 AI 系统提供它所需要的页面。
检索失败的模式
设想一个生产环境中的 AI 智能体，需要回答”这个商品在 amazon.com 上的当前价格是多少？“该智能体构造一个搜索请求，访问搜索索引，获取 URL，抓取其中一个，解析 HTML，找到价格，然后返回结果。
这个流程有六个步骤，每一步都可能失败。失败最频繁、却获得最少工程关注的，是抓取这一步。目标网站收到请求后，会决定是提供真实页面、降级页面，还是直接拒绝，而这个决定在很大程度上取决于网站对上游 IP 的判断。
如果请求来自 AWS、GCP 或 Azure 的出口 IP，网站会认为这极有可能是爬虫。Amazon、Google、Reddit、X 以及各大新闻网站等主流平台，都对数据中心流量设有严格的防御机制。返回的页面往往是空白页、CAPTCHA 验证、403 错误，或者（最隐蔽的情况）一个剥离了价格、库存和实质内容的精简版页面。
下游的 AI 系统并不知道收到的页面已经被降级。它解析所获得的内容，找不到有用信息，要么凭空捏造一个答案，要么返回”我没有关于该内容的最新信息”。这两种失败方式都比不检索更糟糕。
为什么住宅代理能改变这一局面
住宅 IP 从定义上说，是真实消费者 ISP 分配给真实家庭用户的 IP 地址。它背后有多年的正常流量记录，包括流媒体、网页浏览、视频通话、移动应用使用等。从目标网站的角度来看，来自该 IP 的请求与家庭用户的访问无法区分，因为它们确实来自家庭用户的网络。
针对数据中心流量触发的防御层，大多不会对住宅流量生效。返回的页面就是家庭用户看到的页面。处于抓取下游的 AI 系统，获取的是真实页面的真实内容。
这正是住宅代理网络作为一个产品类别存在的根本原因。也正因如此，那些需要实时网络数据的生产级 AI 系统，如今已有数千个，即便在公开的架构图中没有提及，也会悄悄购买住宅代理基础设施。
三类 AI 工作负载，三种不同形态
检索模式在表面上看起来相似，但代理需求因工作负载类型的不同而存在显著差异。
基于搜索的对话。 用户提出问题，模型并行展开网络搜索，抓取前 3 到 10 个结果，进行摘要。最合适的原语是在大型住宅 IP 池中按请求轮换，每次抓取使用新 IP，无需会话保持，最大化地理和 ISP 多样性。工作负载具有突发性且难以预测，按带宽计费的方案更合适，因为总带宽随问题量线性增长。
比价购物智能体。 智能体帮助用户比较各供应商的价格。每次访问供应商可能需要浏览多个页面，包括搜索结果、商品详情、评价，有时还需要模拟结账流程。最合适的原语是粘性会话，每个供应商会话使用同一个住宅 IP 约 5 分钟，让供应商网站看到的是一个连贯的购物者，而非成千上万个爬虫。地理精度很重要，因为供应商价格因城市而异。延迟同样重要，因为用户在等待结果。
持续数据管道。 监控系统每隔 N 分钟抓取一次价格、新闻、监管文件、社交媒体提及等内容。高并发、可预测、大量并行。按请求轮换，在需要网站级会话一致性时使用大型 sid 池，严格控制带宽预算。这是最接近传统爬虫的工作负载，在代理技术栈上也最为成熟。
如果你的 AI 系统具备检索能力，却没有有意识地思考自己属于哪种形态，那么默认配置很可能至少对其中一种场景是错误的。
代码层面的实现
一个围绕住宅代理构建的最简落地抓取封装如下所示：
import os, requestsfrom urllib.parse import urlparse
SHIFTER_USER = os.environ["SHIFTER_USER"]SHIFTER_PASS = os.environ["SHIFTER_PASS"]
def grounded_fetch(url, country="us", session_id=None, timeout=20): """Fetch a URL through a residential IP. Returns response.text or raises.""" auth_user = f"customer-{SHIFTER_USER}-country-{country}" if session_id: auth_user += f"-sid-{session_id}" proxy = f"http://{auth_user}:{SHIFTER_PASS}@p.shifter.io:443" resp = requests.get( url, proxies={"http": proxy, "https": proxy}, timeout=timeout, headers={"User-Agent": "Mozilla/5.0 (Macintosh) AppleWebKit/537.36"}, ) resp.raise_for_status() return resp.text
# Use case 1: search-grounded chat, fresh IP per fetchfor url in search_results: html = grounded_fetch(url, country="us") # ... parse and feed to LLM
# Use case 2: comparative shopping, sticky IP per vendorfor vendor_url in vendors: domain = urlparse(vendor_url).netloc session = f"agent-{user_id}-{domain}" html = grounded_fetch(vendor_url, country="us", session_id=session) # ... navigate within session
# Use case 3: continuous pipeline, per-request rotation, country fan-outfor country in ["us", "uk", "de", "jp"]: for url in monitoring_urls: html = grounded_fetch(url, country=country) # ... feed to indexer三种模式只有一个参数的差异。落地系统无需了解代理的底层机制，只需根据工作负载类型以正确的会话粘性语义调用 grounded_fetch 即可。
需要注意的问题
如果你正在基于住宅代理网络构建 AI 数据落地系统，以下三种失败模式占据了大多数生产事故的原因：
静默内容降级。 目标网站返回 200 状态码，但页面内容已被精简。你的管道不会报错，只是将垃圾数据喂给了模型。缓解方案：在将内容传递给 LLM 之前验证响应结构。如果页面长度比该域名的中位页面短 80%，将其视为软失败并使用不同 IP 重试。
地理漂移。 请求指定 country=us 并通过美国住宅 IP 路由，但目标网站的地理位置查询将该特定 IP 定位到了加拿大。页面以加元和加拿大库存返回。缓解方案：当地理位置重要时使用城市级定向，并在消费响应前验证其是否与请求的地区匹配。
会话在流程中途过期。 多步骤智能体流程从住宅 IP A 开始，会话 TTL 到期后，下一个请求落到了住宅 IP B，目标网站察觉到变化，抛出重新验证挑战。缓解方案：将会话 TTL 延长至能覆盖最长预期流程，或主动检测重新验证挑战并有意识地进行 IP 轮换。
更深层的意义
AI 系统现在已成为住宅代理基础设施最大的客户群体之一。原因并不在于 AI 有什么特殊之处，而在于 AI 会放大糟糕检索的代价。聊天机器人给出一个错误价格，只是一次错误回答；给出一百万个错误价格，则是一个影响用户信任的问题。
基础设施层早已存在，它是为爬虫、广告验证和价格情报而构建的。AI 数据落地是其上最新、规模最大的工作负载类别，但需求与每个严肃的数据团队十年来面临的需求完全相同：真实的住宅 IP、真实的地理分布、真实的会话控制、可预测的成本。
如果你的 AI 系统以实时网络为数据基础，那么当你购买住宅代理方案时，实际上购买的是一个朴素的保证：目标网站向你的系统展示的页面，就是它会向真实用户展示的页面。这是地基，地基之上的一切，包括嵌入、检索、提示词工程、微调，都只有在地基稳固的前提下才能正常运作。