使用 Web MCP 构建 AI 研究数据集抓取一次，永久复用

大多数 AI 工作流是为检索而构建的，而不是为研究。智能体获取一个页面，提取所需内容，回答问题，然后继续下一步。明天再问一个相关的问题，它又会重新获取同一个页面。对于一次性查询来说这没问题，但一旦你需要针对同一组来源持续开展研究，这种方式就会失效。

研究是累积性的。你会反复回访来源，随时间进行比较，并对旧数据提出新问题。如果每个问题都触发一次新的抓取，那么你的助手表现得就像一个搜索引擎，而不是一个研究系统。瓶颈不在于抓取，而在于缺乏记忆。

本指南将补上缺失的记忆：使用 Crawlbase Web MCP Server 构建一个持久的研究数据集。你对每个页面只抓取一次，将其作为可复用的 Markdown 快照存储到 Crawlbase Cloud Storage，此后每一次分析都针对已存储的数据集运行，而不是实时网络。一个配套仓库提供了本文通篇使用的提示词、MCP 配置、示例 URL 以及一个采集脚本。

为什么 AI 研究工作流总是从头开始

如果你之前构建过 AI 研究工作流，你就知道这种套路。你让一个智能体分析竞争对手的定价页面。它抓取页面、提取细节、给出答案，然后遗忘。几天后你就同一家公司提出另一个问题，它又重新抓取这个页面。下周你要比较十家竞争对手的 AI 功能，每个页面又被第三次抓取。

从技术上讲没有任何东西出错。这正是当今大多数 AI 抓取系统的工作方式。问题在于每个问题都从零开始，因为系统是围绕检索设计的：获取、回答、丢弃。

持续采集有时正是目的所在。AI 产品监控工具会按计划反复回访页面，正是为了捕捉新的价格、库存变化或评分波动。研究则不同。你不是在观察过去一小时内发生了什么变化；你是在构建可以反复回访、比较和重新审视数周的知识。因此，请把页面当作可复用的资产，而不是一次性的输入：抓取一次、存储，让分析针对数据集运行。

架构：从网页到研究资产

一旦你把网页内容当作数据集而不是搜索结果，采集和分析就成了两个相互独立的问题。Web MCP Server 同时处理这两者；Cloud Storage 在对话结束后保留快照；一个小型清单则是把它们串联起来的目录。

助手不再每当出现新问题就回访站点，而是针对已经存在的快照工作。清单为已采集的内容（URL、抓取时间戳、公司名称、存储 ID）建立索引，而无需把每一份文档都加载进内存。

连接 Web MCP Server

在构建任何东西之前，先把你的 MCP 客户端指向 Crawlbase Web MCP Server。如果你想先更全面地了解该服务器暴露了哪些能力，请参阅我们的Crawlbase Web MCP Server 介绍。

{
  "mcpServers": {
    "crawlbase": {
      "type": "stdio",
      "command": "npx",
      "args": ["@crawlbase/mcp@latest"],
      "env": {
        "CRAWLBASE_TOKEN": "YOUR_TOKEN",
        "CRAWLBASE_JS_TOKEN": "YOUR_JS_TOKEN"
      }
    }
  }
}

配套仓库包含一个现成的 mcp-config.sample.json。把它放进 Cursor、Codex 或任何兼容 MCP 的客户端，用你的 Crawlbase 凭据替换令牌占位符，然后重启。之后你应当能看到诸如 crawl_markdown、storage_count、storage_list、storage_get 和 storage_bulk_get 之类的工具。从这里开始，助手就能抓取、存储、检索并管理数据集，无需任何自定义代码。

只需构建一次数据集

示例 URL 列表包含二十个公开的 SaaS 定价页面。构建提示词会逐个抓取它们，存储一份 Markdown 快照，并把元数据记录到 output/dataset-manifest.json。

唯一重要的设置是 store=true。没有它，页面就只存在于当前对话中；会话一结束，内容就消失了，下一个问题又需要重新抓取。有了它，Crawlbase 会把快照保存在 Cloud Storage 中，并返回一个 RID，你以后可以用它把文档拉回来。正是这一个开关，把一连串临时的响应变成了一个可复用的数据集。

针对数据集工作，而非网络

一旦页面被存储，工作流就变了：你是在查询一个数据集，而不是在浏览站点。分析提示词从元数据开始，而不是从文档开始。

storage_count
storage_list
storage_bulk_get(as=metadata_only)

用元数据来查看有哪些内容，并决定哪些记录值得进一步细看，然后只在需要的地方检索完整的 Markdown。从这里开始，同一份提示词会构建一个跨竞争对手的比较：它对计费模式进行分类，提取套餐名称和标志性价格，并标记是否存在免费层级。到最后，你可以回答诸如哪种计费模式最常见、谁采用基于用量的定价、以及有多少厂商发布了免费套餐之类的问题，全程都无需再次触碰实时页面。

检测随时间发生的变化

"哪些竞争对手在过去三个月里更改了他们的定价模式？"是一个常见的竞争情报问题，而它只有在你保留了历史记录时才行得通。变化检测提示词会对随时间积累的快照进行比较。

当每个竞争对手只有一份快照时，它会对当前的模式进行分类，并说明目前还无法进行时间上的比较。当有多份快照时，它会对不同版本进行差异比对，并揭示真实的变化：按席位收费转向基于用量收费、统一费率转变为混合模式，或是套餐结构的彻底改版。每一次抓取都会增加一层。第一次给你可见性，第二次给你比较能力，第三次开始显现出趋势。

随着时间推移，数据集不再只是一堆页面，而是成为这些页面如何变化的记录。

复用与清理

已存储快照的回报会在采集之后显现出来：新的问题不再意味着新的抓取。复用提示词会针对同样这二十个页面运行完全不同的分析，包括谁提供免费层级、谁把年付和月付价格并排展示、谁以基于用量的定价为主打，以及谁在定价页面上主推 AI 功能。素材已经采集完毕；助手只是对它提出新的问题。如果你想让智能体在实时循环中对这些数据采取行动，而不是分析一个已存储的集合，请参阅 使用 Web MCP 构建 AI 智能体工作流。

当一个项目收尾时，清除掉你不再需要的快照，以免它们扰乱未来的会话。清理提示词会列出已存储的记录，请求确认，然后分批删除。由于删除是不可逆的，它在移除任何内容之前总会先行确认。

让采集自动化

在你还处于探索阶段时，手动运行提示词是理想的做法。一旦工作流变得例行化（相同的来源、按计划执行、数据集不断增长），就该把采集阶段自动化。仓库的 ingest_dataset.py 正是通过 Crawling API 做到这一点。

pip install -r requirements.txt
export CRAWLBASE_TOKEN="YOUR_CRAWLBASE_TOKEN"
python ingest_dataset.py --urls urls.saas-pricing.txt

脚本会读取 URL 列表，把每个页面请求为 Markdown，存储快照，并写入一份清单。请求本身刻意保持简单：

response = requests.get(
    "https://api.crawlbase.com/",
    params={
        "token": token,
        "url": url,
        "format": "md",
        "md_readability": "true",
        "store": "true",
    },
)

它以 format=md 请求 Markdown 输出，用 md_readability=true 打开可读性处理，并用 store=true 存储结果。它不是把文档正文保存到本地，而是捕捉此后检索它们所需的信息，其中最重要的就是 Cloud Storage 为每个页面返回的 RID。这些记录会落入 output/dataset-manifest.json：

{
  "generated_at": "...",
  "entry_count": 20,
  "stored_count": 20,
  "entries": [...]
}

把清单想象成目录：文档存放在 Cloud Storage 中，而清单记录了如何找到它们。它所做的工作和 MCP 工作流相同，只是可重复执行。

用基础设施取代重复抓取

构建一个研究数据集通常意味着要把一个爬虫、一个存储层、一套检索机制和一套分析工作流拼凑到一起。Crawlbase Web MCP Server 把其中大部分内容都收拢成一组工具，就住在 Cursor、Codex 和其他 MCP 客户端之内，而 Cloud Storage 会在抓取之后长久地保持快照的可触达。

这改变了成本结构。内容只采集一次，就能在许多次分析中复用，于是每个页面都成为一项研究资产，而不是一次性的响应。数据集的价值不断增长，而采集的成本大体保持不变。同样的思路也支撑着机器学习流水线，在那里，采集到的数据会在训练和评估之间被复用；关于这个角度，请参阅面向机器学习的网页抓取。对于持续的市场研究和竞争情报而言，这种转变往往比抓取本身更有价值。

关键要点

• 研究系统和检索系统解决的是不同的问题；大多数 AI 工作流是为检索而构建的。
• 为每个问题都重新抓取同样的页面，会一遍又一遍地支付采集成本。
• 持久化存储把获取和分析分离开来，于是一次抓取就能服务于许多未来的问题。
• 以元数据为先的探索，比加载每一份文档更具可扩展性。
• 正是历史快照，让趋势分析和变化检测成为可能。
• 研究数据集会随时间变得更有价值，因为采集成本被摊薄到此后每一个问题上。
• Crawlbase Web MCP Server 把抓取、存储、检索和分析整合进单一的工作流，而配套仓库就是它的一个可运行实现。

常见问题

AI 研究数据集和 RAG 知识库有什么区别？

RAG 知识库针对在查询时检索相关上下文进行了优化：文档被切块、嵌入并可被搜索，以便模型能用恰当的上下文来作答。AI 研究数据集则针对积累进行了优化：其目标是随时间收集并保存信息，从而支撑许多未来的分析，包括 RAG、竞争情报、市场研究和趋势检测。你可以从一个研究数据集构建出一套 RAG 系统，但数据集比任何单一的检索流水线都更宽泛。

为什么要存储网页，而不是每次都抓取它们？

对于一次性问题，反复抓取没问题，但对于持续的研究就效率低下。假设你今天收集了二十个竞争对手的定价页面；明天你比较 AI 功能，下周你分析年付折扣，一个月后你审视企业版套餐。这些页面也许并没有变化，然而反复抓取却让你每次都要支付采集成本。存储快照把获取和分析分离开来，于是同一个数据集就能回答许多未来的问题，而无需再次触碰原始站点。

为什么用 Markdown 而不是原始 HTML？

Markdown 保留了重要的信息，并舍弃了大部分的表现层噪声。标题仍是标题，列表仍是列表，表格仍然可读。原始 HTML 携带着导航菜单、脚本和样式，这些对研究几乎没有价值，而 Markdown 快照更易于阅读、分析、切块、嵌入以及跨版本比较。

我能把这种方法用于 SaaS 定价页面以外的数据吗？

可以。仓库之所以采用定价页面，是因为它们易于理解并能演示竞争情报工作流，但同样的架构也适用于产品文档、行业报告、公开文件、新闻文章、知识库内容、学术资源以及市场研究来源。无论你收集的是什么，获取和存储的工作流都保持不变。

Crawlbase Web MCP Server 会取代向量数据库和嵌入吗？

不会。Web MCP Server 处理的是源文档的获取、存储和检索。向量数据库和嵌入模型登场的时机，是当你想要语义搜索、RAG 流水线或基于相似度的检索时。许多团队把 Web MCP Server 用作获取层，之后再把已存储的文档喂给嵌入流水线、向量存储或智能体，于是数据集就成为其他 AI 系统据以构建的基础。

IK

Ian Kalvin

技术支持工程师 · Crawlbase

Crawlbase 技术支持工程师，从生产环境抓取与代理配置中真正出问题的第一线写作。

NZ

Neil Zamora

高级架构师 · Crawlbase

Crawlbase 高级架构师，专注大规模爬取背后的系统：代理轮换、反机器人韧性，以及隐藏这些复杂性的 API。