智能体爬虫：它是什么，以及如何构建一个

传统爬虫是一组指令：抓取这个 URL，读取 .product-price，返回文本。智能体爬虫则是一个目标：找到当前价格，无论页面今天长什么样。

这个区别听起来很学术，直到网站改版为止。执行指令的那个返回 null，你的数据管道随之陷入沉默。追逐目标的那个会看一眼页面，发现价格挪进了"查看价格"按钮背后的弹窗里，点开它，然后把数字带回来。

它听起来也像天上掉馅饼，但并不是。智能体爬虫更慢、单页成本更高，而且偶尔会以十足的自信给出错误答案——这是失效的选择器永远不会犯的错。本文讲清楚智能体爬虫（英文 agent scraper）到底是什么、构建它的三种方式、其中两种的可用代码，以及大多数文章都会跳过的那部分：在哪些具体条件下你根本不该用它。

目录

• 什么是智能体爬虫？
• 智能体爬虫如何工作？
• 智能体爬虫与传统爬虫的对比
• 构建智能体爬虫的三种方式
• 一次调用就能跑起来
• 自己写智能体循环
• 智能体爬虫为什么会在生产环境失败？
• 智能体爬虫的成本是多少？
• 什么时候不该用智能体爬虫？
• 上线前的五道防线
• 常见问题

什么是智能体爬虫？

智能体爬虫是由 LLM 推理循环而非固定脚本驱动的网页爬虫。你用自然语言给它一个目标——"找出这个站点的所有定价档位以及每档包含什么"——由它决定抓取哪些页面、何时升级到浏览器、何时信息已经够用，以及如何组织答案。没有 CSS 选择器，没有 XPath，也没有逐站点的维护成本。

有三个特性把它和此前的一切区分开来：

1. 它会规划。 请求序列是在运行时根据目标选定的，而不是提前写死的。
2. 它会适应。 一个 403、一个空结果或一个意料之外的布局，都是下一步决策的输入，而不是致命错误。
3. 它按条件终止，而不是按次数。 它在目标达成时停下——这恰恰是你必须从外部施加硬性限制的原因。

这个词被用得很随意，所以有必要说清楚智能体爬虫不是什么。调用一次 LLM 来清洗已抓取 HTML 的爬虫属于 AI 辅助爬取，控制流仍然是你的脚本。由 LLM 在开发阶段挑选选择器的浏览器自动化脚本属于 AI 生成的爬取，LLM 写出代码，之后确定性地运行。只有当模型处于循环内部、每一轮都在选择下一个动作时，你手上的才是真正的智能体爬虫。

智能体爬虫如何工作？

无论用什么框架，每个智能体爬虫跑的都是同一个六阶段循环：

1. 目标。 一个自然语言目标，外加可选的种子 URL。
2. 规划。 模型决定第一个动作——通常是一次搜索或一次抓取。
3. 执行。 它调用工具：抓取 URL、发起搜索、驱动浏览器、越过反爬墙。
4. 观察。 工具返回内容，最好是干净的 markdown 而不是原始 HTML，因为每个字节都会落进上下文窗口。
5. 评估。 目标达成了吗？如果没有，还缺什么，哪个动作能补上这个缺口？
6. 输出。 返回文字，或者更好的做法：返回经你提供的 schema 校验过的 JSON。

第 2 到第 5 阶段不断重复。而这个循环默认是没有上界的——这是关于在生产环境运行它最重要的一件事。

失败模式并不是智能体卡住了，而是智能体一直保持高产：它不停地又找到一个看起来相关的页面，于是一边做着完全合理、但你并没要求的工作，一边烧掉你的预算。所以硬性限制要放在编排层，绝不能放在 prompt 里。CrawlForge 的 agent 工具在基础设施层强制执行其中三项，模型无从讨价还价：

客客气气地要求模型"只看几个页面"不叫限制。由运行时强制执行的一个数字才叫限制。

智能体爬虫与传统爬虫的对比

两种方案谁也没有全面压倒对方。它们朝相反的方向失败，而这正是选择变得可操作的原因。

最后那行失败方式是最该记住的。失效的选择器会自己报警：行数掉到零，监控随即告警。被编造出来的字段不会。它类型正确、格式合理地抵达，而且是错的。任何为重要决策供数的智能体爬虫都需要下游校验，我们会在防线那一节回到这个话题。

构建智能体爬虫的三种方式

大多数团队应该从第一种起步，在需要自定义控制流时升级到第二种，只有当数据确实藏在普通抓取够不着的交互背后时才动用第三种。第三种也是慢得多、贵得多的一种——一个浏览器步骤耗时以秒计，而一次抓取以毫秒计。

中间那个选项正是 Model Context Protocol 体现价值的地方。由于 MCP 服务器暴露的是智能体在运行时就能读取的类型化工具 schema，你的循环不需要为每个 endpoint 手写包装层——智能体会自己发现 stealth_mode 的存在及其参数。我们在 MCP vs REST 爬取架构 中拆解了这套架构，并在 面向 AI 智能体的最佳网页爬取工具 中做了横向对比。

一次调用就能跑起来

最快的智能体爬虫是你不用写的那个。CrawlForge 把 agent 作为其 27 个 MCP 工具之一提供：它自行规划搜索、抓取并筛选页面、综合出答案——不需要你给 URL，上面那些硬性限制也已经就位。

接入 Claude Code、Claude Desktop 或 Cursor 后，自然语言版本就是全部的交互界面：

Find the current pricing tiers for Vercel, Netlify, and Railway,
and tell me what each tier includes.

在底层，这会解析成一次工具调用：

{
  "name": "agent",
  "arguments": {
    "prompt": "Find the current pricing tiers for Vercel, Netlify and Railway, and what each tier includes.",
    "maxUrls": 12,
    "maxSteps": 6
  }
}

如果答案是给人看的，返回文字没问题。但要接进数据管道，就传一个 schema，让智能体返回经过校验的 JSON——这是"一段你还得去解析的文字"和"一条你可以直接入库的记录"之间的差别：

{
  "name": "agent",
  "arguments": {
    "prompt": "Extract every pricing tier for the three vendors below.",
    "urls": [
      "https://vercel.com/pricing",
      "https://www.netlify.com/pricing/",
      "https://railway.com/pricing"
    ],
    "maxUrls": 12,
    "schema": {
      "type": "object",
      "properties": {
        "tiers": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "vendor": { "type": "string" },
              "tier": { "type": "string" },
              "monthlyUsd": { "type": "number" },
              "includes": { "type": "array", "items": { "type": "string" } }
            },
            "required": ["vendor", "tier"]
          }
        }
      }
    }
  }
}

有两个细节值得知道。当你已经清楚数据在哪时，种子 urls 能收窄搜索空间——智能体仍然自己决定怎么读这些页面，只是不用再猜从哪儿开始。另外，model: "pro" 会把默认循环换成完整的多源研究流程；它更费时间也更费 credits，所以当广度比延迟更重要时再用它。

一次 agent 调用是 8 credits，固定不变，读三个页面和读二十个页面都一样。

自己写智能体循环

当你需要自定义控制流时——自己的重试策略、自己的停止条件、写进自己存储的结果——就自己写循环，把 CrawlForge 当作工具层。这里真正关键的模式是升级阶梯：从便宜的开始，只在失败时才往上升。

const BASE = 'https://www.crawlforge.dev/api/v1/tools';

type Rung = { tool: string; credits: number; body: (url: string) => object };

// Cheapest first. Each rung costs more and handles more hostile pages.
const LADDER: Rung[] = [
  { tool: 'scrape', credits: 2, body: (url) => ({ url, formats: ['markdown'] }) },
  {
    tool: 'scrape_with_actions',
    credits: 5,
    body: (url) => ({ url, actions: [{ type: 'scroll', delay: 1500 }] }),
  },
  {
    tool: 'stealth_mode',
    credits: 5,
    body: (url) => ({ url, stealth_config: { anti_detection_level: 'advanced' } }),
  },
];

async function call(tool: string, body: object) {
  const res = await fetch(`${BASE}/${tool}`, {
    method: 'POST',
    headers: {
      'X-API-Key': process.env.CRAWLFORGE_API_KEY ?? '',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(body),
  });
  return res.json();
}

async function fetchWithEscalation(url: string) {
  let spent = 0;

  for (const rung of LADDER) {
    const result = await call(rung.tool, rung.body(url));
    spent += rung.credits;

    // A 200 with 200 characters of "enable JavaScript" is still a failure.
    const markdown = result?.data?.markdown ?? '';
    if (result.success && markdown.length > 500) {
      return { markdown, spent, via: rung.tool };
    }
  }

  return { markdown: null, spent, via: null };
}

markdown.length > 500 这个检查是大家最容易漏掉的一步，也正是大多数自制智能体爬虫悄悄崩掉的地方。反爬页面返回的是 HTTP 200。一个挑战拦截页是一次不含任何数据的成功响应，所以 res.ok 什么也说明不了——你必须先检查拿回来的内容，再判断这一级是否真的奏效。（关于升级机制所要面对的完整图景，参见用隐身模式绕过反爬检测。）

抓取层解决之后，智能体循环本身就很小了：把目标交给模型，让它挑 URL，把每个 URL 送进 fetchWithEscalation，在 schema 得到满足或步数预算耗尽时停止。让这一切负担得起的正是这道升级阶梯——大多数页面在第一级就以 2 credits 拿下，只有那些顽抗的才需要付 5 credits。

智能体爬虫为什么会在生产环境失败？

四种失败模式，大致按咬人的频率排列。

智能并不能击败指纹识别。 这是最让团队破财的一个误解。反爬保护评估的是 TLS 指纹、浏览器 API 的一致性、请求时序和请求头熵值，而 LLM 对这些信号一个都影响不到。驱动原生无头 Chromium 的智能体，被检出的概率和任何其他无头 Chromium 一样，有时还更高，因为智能体的浏览模式（直奔目标元素、不滚动、时序不规则）看起来比脚本更不像人。销售托管式爬取基础设施的 ScrapeWise 在其 2026 年 4 月的自测中，报告无辅助智能体的封禁率为 61–74%，测试对象是受 Cloudflare 和 Akamai 保护的电商站点。厂商自测的基准应当被视为方向性参考而非定论，但其机理是成立的：你为那些在 WAF 处就已阵亡、根本没走到提取环节的任务支付了推理费用。

规模一上来，经济账就反转了。 智能体爬取在几百页的量级上很便宜，到几百万页就是灾难，因为 LLM 的推理成本是按页计的，摊薄不了。一条构建一次、偶尔维护的确定性管道，在大批量场景下能把推理循环甩开一个数量级。这个交叉点比大多数团队预想的要低——见下面的成本表。

看似合理的错误答案。 一个找不到某字段的智能体，完全有能力从周围的文本里"推断"出一个来。输出符合 schema、类型正确，而且是假的。基于选择器的爬虫犯不了这种错，它只会什么都不返回。

延迟排除了高频场景。 推理会给每个页面增加数秒开销。任何需要在一分钟内、跨大量 URL 完成刷新的任务——实时价格监控、库存可用性——都属于确定性管道，智能体应当离关键路径越远越好。

还有第五点考量，它不算失败模式，而是版图的变化：越来越多的站点开始把智能体流量和爬虫流量区分对待。HUMAN Security 的 2026 State of AI Traffic 报告给出的 AI 智能体流量同比增幅为 7,851%，并指出智能体是在与站点交互，而爬虫只是读取。你可以预期，自己所处的访问政策环境还会继续变动。关于合规的部分，见我们的2026 年网页爬取是否合法。

智能体爬虫的成本是多少？

下面是诚实的算术，基于 CrawlForge 按次固定计价的 credits。美元数字按 Hobby 方案计算，即 19 美元换 5,000 credits（每 credit 0.0038 美元）；在 Professional 方案（99 美元换 50,000）下，每个数字大约再降 48%。

最后两行要放在一起读，整篇文章的教训都在里面。输出完全相同，成本只有十分之一。一旦你已经知道要哪些 URL，智能体就是错的工具：同样是这 100 个页面，批量提取便宜 10 倍。

由此得出一条干净利落的规则：用智能体去弄清楚该抓什么，用批量工具去把它抓下来。 发现环节是推理能赚回本钱的地方，批量环节是推理让你破产的地方。先用 agent 找出 100 个相关 URL、再用 batch_scrape 拉取的一次运行花费 28 credits——大约十一美分——而纯智能体版本的同一份工作要花 40 credits，耗时还长得多。

什么时候不该用智能体爬虫？

只要符合下列任意一条，就干脆别用智能体：

• 站点结构稳定且已知。 一个写一次、一年动两回的选择器，比每次运行都对同一套布局重新推理一遍更便宜也更快。
• 你每天需要的页数超过几千。 推理成本和延迟都是线性增长，而且都摊薄不了。
• 确定性是硬性要求。 财务报告、合规、任何要被审计的东西。"通常给出同一个答案"不是一个可接受的性质。
• 刷新间隔短于一分钟。 改用 track_changes 配确定性 diff。
• 输出会直接进入无人复核的自动决策。 倒不是绝对不行——但必须配上下面讲的那套校验。

最稳的生产模式不是"要智能体还是要脚本"。而是：让智能体跑一次去发现结构并生成一份确定性的提取规范，再由一个定时的确定性任务去执行它，只有当这个确定性任务开始失败时才重新唤起智能体。你为推理付费的时机是站点发生变化时，而不是每一行数据。

上线前的五道防线

1. 在编排层强制执行预算。 步数、URL 数和挂钟时间，全都放在 prompt 之外。一个模型能自我说服绕开的限制不算限制。
2. 永远传入输出 schema。 结构化输出把"它成功了吗？"变成一次可以自动化的校验。schema 校验失败就拒绝并重试，而不是把一段文字存下来。
3. 用一个已知字段做校验。 在 schema 里放一个你能独立核实的值：产品 SKU、页面标题、货币符号。如果这个字段错了，就把整条记录丢掉——说明智能体读的根本不是你以为的那个东西。
4. 记录智能体抓取过的每一个 URL。 当答案出错时，抓取轨迹是区分"页面有问题"和"推理有问题"的唯一途径。没有它，你调试的就是一个黑箱。
5. 积极使用缓存。 智能体的多次运行之间会重复大量工作。按 URL 加上一个短 TTL 的缓存，通常能把迭代式调研的 credits 开销砍掉一半。

亲自试一试

跑通你的第一个智能体爬虫，不需要框架，不需要浏览器集群，也不需要签代理合同。CrawlForge 通过一条 MCP 连接把 agent 和另外 26 个工具一并暴露出来，安全上限由运行时强制执行，按次固定计价的 credits 让你在开跑之前就能算清一次运行的价钱。

免费从 1,000 credits 开始——足够跑 125 次智能体——大约两分钟就能接进 Claude、Cursor 或你自己的循环。