大规模代理式网页数据提取：当智能体取代爬虫时

这个 Demo 只需 20 分钟就能构建完成。你粘贴一个 URL，大语言模型（LLM）读取 HTML，结构化数据就从另一端输出了。这感觉就像网页数据提取的未来已经到来。

然后，你以每小时 1,000 页的速度运行它。成本飙升，屏蔽不断积累，提取出的字段开始以一种看起来不像错误的方式发生偏移——它们看起来像正常数据，直到你的下游流水线已经默默地摄取了三周的垃圾。“LLM 读取页面”的模式并没有错，只是它的定价更适合原型的吞吐量。

智能体（Agentic）网页提取确实解决了传统爬虫无法解决的问题。但要将其扩展到概念验证（PoC）阶段之后，需要理解一组与大多数团队预期不同的故障模式。

为什么传统爬虫最先失效

传统的网页爬虫在 HTTP 和 DOM 层面运行：它们获取 HTML，应用 CSS 选择器或 XPath 表达式，并返回匹配项。这在失效前一直有效，而“失效”到来的速度逐年加快。

现代 Web 应用程序通过 JavaScript 框架渲染内容，而这些内容并不存在于初始 HTML 响应中。如果一个抓取 https://example.com/products 并读取 <div class="price"> 的爬虫在页面加载时价格是由 React 注入的，那么它将一无所获。据估计，传统 HTTP 级别的爬虫会漏掉约 30% 的动态渲染内容。

除了渲染，网站还通过行为信任评分积极防御爬虫。现代反机器人系统不再仅通过 IP 或 User-Agent 进行屏蔽，而是跟踪鼠标抖动、滚动速度、点击精度和交互时机。人类的点击带有噪音；而爬虫的点击具有数学上的精确性。这种行为指纹在几秒钟内即可识别。

通过真实浏览器会话运行的 AI 智能体在设计上避开了渲染问题——它们看到的就是用户看到的。而且因为它们通过实际的浏览器输入事件进行交互，它们继承了一些行为噪音。这就是为什么当 CSS 选择器持续失效时，团队会转向使用智能体。

原型在哪里崩盘

朴素的架构很简单：获取页面，将 HTML 连同提取指令发送给 LLM，解析输出。这在 Demo 规模下有效，原因有两个，但在生产环境中这两点都会消失。

Token 成本随页面卷集成比例增长。 以这种方式提取的平均网页，仅 HTML 内容就会消耗大约 800-1,200 个输入 Token，这还没算上系统提示词（system prompt）或输出 Schema。在每小时 1,000 页的速度下，每小时大约需要 100 万个输入 Token。按照前沿模型的定价，对于任何不是按提取记录收取溢价的生产流水线来说，这在经济上都是不可持续的。

智能体不会自动限流。 传统爬虫遇到 HTTP 错误（如 429、503）会大声报错。通过浏览器会话运行的智能体首先会被软屏蔽（soft-blocked）：响应变慢、内容质量下降、出现机器人检测验证码（CAPTCHA）。智能体不会自然地将这些解释为限流信号。如果没有检测软限流并退避的显式逻辑，智能体就会继续请求那些返回内容越来越没用的页面，从而在产量递减的情况下累积成本。

行为指纹仍然会识别出智能体。 Canvas 哈希、WebGL 签名、TLS 指纹和插件状态，在自动化浏览器会话和真实会话之间都存在差异。在大规模运行下，当许多并行会话显示出相同的指纹时，网站就会察觉。该 IP 段的行为信任评分会下降，屏蔽模式随之开始。

布局偏移导致静默损坏。 这是团队最晚发现且最后悔的故障模式。当网站重命名 CSS 类或重构其 DOM 时，传统爬虫会立即大声报错。智能体会适应——它能在页面的某个地方找到价格数据——但可能会将其返回到错误的字段中，完全跳过可选字段，或推断出不存在的关系。提取成功了；但数据是错的。行数保持稳定；但字段质量在下降。如果没有下游的 Schema 监控，这种情况可能会在数周内都不被察觉。

混合架构

生产系统不会在确定性选择器和智能体之间做二选一。它们会将两者分层。

这种模式非常直接：对稳定的页面区域使用快速的 CSS/XPath 提取，仅在选择器失效时才回退到基于智能体的语义提取。确定性提取成本低、速度快且可验证。智能体处理长尾的布局变化、新页面模板以及积极抵制基于选择器方法的网站。

一个典型的实现分为三层：

首选层（Primary）： 针对已知稳定页面元素的 CSS 或 XPath 选择器。即使类名发生了变化，产品页面的价格几乎总是位于具有一致属性的语义元素中。针对 [itemprop="price"] 或 data-testid="product-price" 的选择器在大多数重新设计中都能幸存。

回退层（Fallback）： 如果首选选择器返回空值或未通过类型验证检查，智能体将接收渲染后的页面和提取 Schema。智能体基于完整的语义页面上下文运行，而不是依赖于精确的元素位置。

审核队列（Review queue）： 两个层级都无法确信解决的提取将被标记为人工验证，并可选择排队等待智能体使用不同策略重试。

与纯智能体方案相比，采用这种分层方法的公司报告称，在复杂网站上的提取成功率显著提高，且每页成本大幅降低，因为昂贵的层级仅在需要时才运行。

大规模反爬虫指纹识别

在大规模场景下解决指纹识别问题，本质上是一个基础设施问题，而不是提示词工程（Prompt Engineering）问题。

无头 Chrome（Headless Chrome）的指纹并不是秘密。每一个在默认配置下运行的 Playwright 或 Puppeteer 实例都会产生相同的 Canvas 哈希、相同的 WebGL 供应商字符串和相同的 TLS 签名。在低流量时，这是不可见的。但在高流量下，对于任何能够聚合跨会话行为信号的机器人检测系统来说，这种模式都极其明显。

在生产规模下真正有效的方法包括：

原生 CDP 浏览器交互。 与其通过注入 JavaScript 补丁来覆盖指纹表面，不如在基础设施层通过 Chrome DevTools Protocol（CDP）进行操作，从而继承真实的浏览器属性。相比于 JS 补丁方案，基于这种方法构建的工具在面对受保护网站时表现出显著更高的成功率。

会话一致性。 真实用户在不同会话之间拥有一致的分辨率、时区、语言和插件状态。为每个请求重新创建的 Agent 具有随机化或默认状态，行为评分系统会注意到这一点。会话持久化和一致的环境配置比任何单一的指纹表面都更重要。

行为噪声注入。 类似人类的鼠标轨迹、滚动模式和交互延迟不需要做到完美——它们只需要是非零的。数学上的精确性才是破绽所在，而不是具体的模式。

代理多样性与轮换。 在大规模场景下，IP 层的信号与行为信号同样重要。带有会话固定（Session Pinning）功能的住宅代理池是实现持续、大规模数据提取的基本门槛。

监控：网站变化 vs. Agent 困惑

在 Agent 提取中，最难的运营问题是归因：提取失败是因为网站发生了变化，还是因为 Agent 产生了困惑？

这两种情况需要不同的应对措施。网站布局变化意味着需要更新选择器或重新训练提取逻辑。而 Agent 困惑事件则意味着需要调试 Agent 的上下文——它可能幻听了周围内容中的字段值，混淆了两个相似的产品，或者在页面变体上应用了错误的 Schema。

以下三种监控模式可以区分它们：

选择器健康指标。 独立记录每个主要 CSS 选择器的匹配率。如果昨天匹配的选择器今天返回为空，说明网站发生了变化。如果选择器匹配但提取的值未通过类型验证，则可能是 Agent 或 Schema 的问题。

字段基数追踪。 监控提取字段值的分布情况——价格范围、库存状态字符串、字段存在率。这些分布的突然转变预示着网站的变化。如果你运行的是同一个模型端点，那么在没有阶跃式变化的情况下的逐渐漂移可能预示着模型行为的漂移。

结构化 vs. 语义化告警。 结构性故障（选择器未命中、4xx/5xx 响应、遇到验证码）属于网站端问题。语义性故障（类型错误、不可能的数值、尽管页面已加载但缺少必填字段）属于 Agent 端问题。区分这些告警类别可以显著减少误报升级。

一个能够区分这两类故障并将其路由到不同应对方案的监控层，与提取逻辑本身同样重要。

工具层的结构化输出 Schema

提取指令与提取架构同样重要。直接传递自由格式指令（如“提取产品价格”）的团队会得到不一致的结果。而将提取绑定到类型化 Schema 的团队则能获得可验证的输出。

目前的模式是将提取定义为带有类型化参数的工具调用（Tool Call）。提取 Schema 指定字段名称、类型和可选性，模型被指令要求调用工具，而不是生成自由格式的输出。像 Instructor 这样的库通过自动验证和重试逻辑封装了这种模式——如果模型输出不符合 Schema，验证错误会返回给模型进行修正。

类型化 Schema 与受限输出模式（函数调用或结构化输出 API）的结合，使得针对合作网站上定义良好的 Schema，其提取可靠性可以达到 99% 以上。这对下游流水线的安全尤为重要——Schema 违规会作为捕获的错误显现，而不是作为静默的错误数据在你的数据库中传播。

吞吐量上限与成本模型

在构建 Agent 提取系统之前，必须明确成本模型。

考虑到计算和 LLM 推理成本，通过托管浏览器沙箱进行的基于 Agent 的提取，每页成本大约是确定性提取的 10-15 倍。在每月 10,000 页的规模下，这是可以承受的。但在每月 1,000 万页的规模下，成本将主导系统设计。

全 Agent 提取的盈亏平衡点出现在：

• 页面足够复杂且动态，导致基于选择器的提取成功率低于 ~60%
• 提取的数据具有足够的下游价值，可以消化每页的推理成本
• 提取频率足够低，成本增长不会快于价值增长

对于大多数生产环境的提取工作负载——产品目录、列表、定价数据、新闻文章——以 Agent 作为回退层的混合架构是正确的默认选择。纯 Agent 方案适用于高度交互的网站（多步导航、登录限制内容、验证码处理），以及每页成本次要的低流量、高价值提取。

最挣扎的团队通常是那些因为速度快而使用 Agent 开发原型的团队，他们在前 100 页展现了令人印象深刻的准确率，但在没有确定性回退机制的情况下遇到了扩展瓶颈。

生产环境的真实需求

构建用于生产环境的智能代理（agentic）网页提取是一个带有 AI 组件的分布式系统问题，而不是一个带有一些工程辅助的 AI 问题。

AI 部分——对页面内容的语义理解、模式驱动（schema-driven）的提取、处理布局变化——确实很有价值，而且越来越可靠。但是，决定其能否大规模运行的基础设施问题则是常规的：速率限制（rate limiting）、会话管理、队列深度、成本分摊、故障分类和监控。

交付可靠的智能代理提取系统的团队会优先设计基础设施层，并在 AI 能够提供优于确定性方法（deterministic approaches）的价值时才加入 AI 层。而那些优先围绕 AI 能力进行设计，随后才添加基础设施的团队，则会在项目的后半段忙于将速率限制和监控逆向适配到一个从未为此设计的系统中。

混合架构并不是一种妥协。这种架构反映了每个层级真正擅长的领域。