写爬虫这件事，真正费时间的部分往往发生在敲下第一行代码之前。数据藏在哪、站点怎么把它暴露出来、哪些请求能一次拿全又不做无用功，这些都得先摸清楚。Zyte MCP 在这件事上帮到了我：它让我的 AI 代理通过 Zyte 的工具访问网站，我可以直接让它去调查一个站点，再一起决定怎么抓才划算。
我的起点通常很朴素：“我想从这个站点拿这批数据，最好的办法是什么？”
要回答这个问题，代理必须真的去看网站。如果它被拦了、撞上验证页，或者够不到 JavaScript 加载的内容，它对这个站点的认知从一开始就是残缺的。Zyte MCP 把 Zyte 的抓取、浏览器渲染和提取工具交给它，于是它能取回页面、看到页面背后的数据，包括那些基础 HTTP 请求搞不定的站点。对话随即变得具体：代理查看现状、试一种路子，然后带回我能用的证据。
我要确认的第一件事是数据该从哪来。渲染后的商品页是最直观的入口，但同样的信息也可能躺在 HTML 里，或者来自站点自用的某个 API；站点地图可能给我一条发现商品 URL 的直路；分类页则可能让我把抓取范围收窄到真正想要的那部分目录。
这些选择同时影响实现方式和运行成本。如果更简单的请求就能返回所需内容，把每个页面都渲染一遍就是浪费；只想要一个分类却爬了整个站，同样是浪费。我让代理在动手之前把这些选项都探一遍，它还能提前查清 Zyte API 是否支持该域名、在那里一次 HTTP 请求和一次浏览器请求各是什么成本，两者的差价就成了我权衡每个选项的依据。
不过效率得对着数据需求来衡量——更便宜的请求只有在返回了任务所需内容时才有意义。所以我会要求把样本记录和对比一并纳入调查。如果代理找到一个看起来不错的 API，我想知道它的响应和页面相比如何：必需字段是否齐全，某些细节是不是来自另一个请求，选这条路会不会在数据集里留下缺口。
配套的视频说明了这件事为什么重要。在某个站点上，一个 API 提供了获取商品信息的可行路径，但把它和渲染后的页面一对比，缺字段就露出来了，其中包括 UPC、重量和尺寸。这个发现直接改变了抓取的需求。没有这次对比，很容易做出一个“成功采集了记录”却漏掉我需要的信息的爬虫。
这些检查也让取舍变得明确。有时 API 响应就够了，有时缺失的字段值得再补一个请求，有时我只需要一部分商品的额外细节——让代理取回样例、查清差异，我就有了做决定的更好依据。
我一直在把这套流程沉淀成自己的抓取策略技能，也建议你边做边建。每当某个检查在一个站点上被证明有用，就把它加进去：找站点地图、调查备选数据源、取回样本、在推荐方案之前先比对字段覆盖。这样经验就能从一次调查带到下一次，既给代理一套可重复的流程，又允许它针对具体站点和具体数据灵活调整。当第一次尝试失败、或样本里冒出意外情况时，回头检验假设也更容易。
我要的输出是一份能直接执行的抓取计划：怎么发现相关记录、发哪些请求、各自返回什么字段、哪里还需要额外检查或额外请求。拿到它，我就能去写 Scrapy 爬虫或别的适合这项任务的采集器；因为调查就发生在同一个对话里，代理已经掌握了这些决定背后的上下文。如果要把工作挪到别处，我可以让它把策略和需求写下来。
MCP 最自然地嵌进我工作流的位置就在这里。我用它在写规模化采集代码之前先探索、采样、理解一个站点。它不替我写爬虫——parse() 方法和翻页逻辑仍然归我——它替代的是过去排在最前面的手工活：在浏览器里打开站点、东点西点看哪里会崩、翻着原始 HTML 找我需要的字段。
想试的话，从一个站点和你需要的字段开始，然后让你的代理去调查可用的路径、返回一份样本，并检查推荐方案可能漏掉什么。安装说明在 Zyte MCP 的文档里。
热门跟贴