DeepSeek Fetch实测：打不破海外反爬盾，却啃下了微信这块硬骨头

10 月 17 日，DeepSeek 发布了新版本，在《DeepSeek V4.1 Flash 新版本：许愿式编程一键成真》里，除了模型自身的升级，还宣布了一个低调却很实用的变化：正式在 API 端向公众开放 Search 与 Fetch 两个工具接口。

按照官方的介绍，其底层依托的是自研搜索引擎，定价相当亲民，每次调用只需五厘钱（5 元 / 千次）。公告里还特别提到了一个细节：当前在 DeepSeek Harness、Claude Code、Codex 这类主流 Agent 环境中使用 DeepSeek API 时，服务端已经在自动调用这两个接口提供联网能力。

对于平时折腾信息流整理、用自动化脚本抓网页生成文献引用的人来说，Fetch 这个接口格外诱人：给它一个 URL，直接返回清洗好的标题和 Markdown 正文。如果好用，很多平时需要本地开无头浏览器、或者调用第三方服务才能搞定的网页抓取，就能直接收拢进大模型的工作流里。

但它到底能走多远？

今天我找了几个典型场景，把平时抓取最容易踩坑的几种页面拉出来，给 DeepSeek 的 Fetch 接口做了一次实地压力测试。

撞上反爬盾的第一道坎

测试的第一站，我挑了学术圈常用的 SSRN 论文库，拿了一篇具体的论文页面（SSRN Abstract 6276738）来试水。

读论文的人都知道，SSRN 挂在 Cloudflare 后面，反爬机制向来严格。直接用普通的 HTTP 请求访问论文详情页，服务器会毫不犹豫地甩回一个 403 拦截页。

我把论文链接送进 DeepSeek 的 Fetch 接口：

1

{"error": {"message": "failed to fetch URL", "type": "not_found_error"}}

接口直接返回了 404。

作为对照，我用专门做网页解析的 Jina Reader 抓取同样的链接。Jina 在 2 秒多返回了结果，并且在头部明确提示：页面需要人机验证（CAPTCHA），未能加载完整内容。

两相比较，结论很清楚：面对严肃的反爬防护，DeepSeek 目前完全过不去。不仅过不去，它在错误处理上也显得有些粗糙——明明是被反爬拦截，接口却报了一个容易误导人的“页面不存在”。

渲染动态页面的基本功

反爬盾过不去并不让人意外，毕竟那是专业爬虫服务才啃得动的硬骨头。对于普通的大模型应用来说，更常见的刚需是抓取那些靠 JavaScript 动态渲染的现代网页。

我找了上观新闻的一篇文化报道（《今夜无人入眠！东西和鸣“中国扇”，上海大歌剧院的“朋友圈”太精彩》）。这类门户页面的特点是：直接发请求只能拿到一个十来 KB 的空骨架，真正的正文全靠前端脚本异步拉取。

这一次，DeepSeek 的表现让人眼前一亮。

耗时 12 秒左右，接口返回了 200，并吐出了 4400 多字的完整标题与正文。随后测试的虎嗅网财经分析（《高盛与都铎·琼斯对2027年美股两个1.7万亿美元供需能否相抵判断相反》），也只用了 4 秒多就拿下了 5000 多字的内容。

这说明 DeepSeek 的后端绝非简单的文本拉取器，而是确实运行着一套能执行脚本、渲染 DOM 的无头浏览器环境。面对国内主流的内容与媒体站点，它应付动态渲染的基本功是过关的。

不过，如果把它们和 Jina 的抓取结果放在一起对比，就能看出两边在正文清洗成熟度上的差异。

Jina 抓取这两篇同样全部成功（上观耗时约 17 秒，虎嗅约 9 秒）。但在文本质量上，Jina 吐出的 Markdown 结构更规整，头部自带标题、发布时间等元信息，正文直接切入核心事实，文末还附带完整的链接汇总；而 DeepSeek 提取出来的文本，开头混进了不少“关注我们”、“加入社群”、“热搜词”等页面骨架噪音，正文也残留着 \#、\-、\*\* 这类多余转义符。如果要把 DeepSeek 的结果送进下游做深度分析，最好在本地做一层清洗。

当然，DeepSeek 的本意可能就只是喂给大模型阅读，这些就可以自动智能忽略，也不能算错。

抓自家静态博客的意外卡顿

最戏剧性的转折，发生在我拿自己的Hugo搭建的静态博客测试时。

按常理，纯静态生成的博客既没有反爬验证，也没有复杂的异步数据流，理应是最好抓的对象。然而当我把博客上刚写的一篇长文（《单图3分钱：DeepSeek新版 与公众号封面的“斩杀线”》）链接发过去时，等待 30 秒后，接口却抛出了一个 504 网关超时错误。

更奇怪的是，同样的页面偶尔重试又能成功拿到近 7000 字的完整正文，但多试几次就会发现，成功率就像抛硬币一样不稳定。换了一篇没有图片的纯文字短文（《被手机折叠的世界，与那个不问效益的银行柜台》），同样频频超时。

与之相比，同一个带图的页面，用 Jina 抓取只需要 4.4 秒，就能干脆利落地带回 8800 多字的完整 Markdown，完全没有被几张图片或脚本拖慢。

为什么 DeepSeek 会反复卡在 30 秒的超时线上？

仔细排查页面的网络请求才发现端倪。博客主题里默认带了海外第三方统计脚本。DeepSeek 后端的渲染器在等待页面加载时，似乎采用了等待所有网络请求静止的策略。由于网络连接局限，外部统计脚本的请求容易在建立连接时挂起，直接拖死整个渲染进程，直到撞上 30 秒的硬性超时上限。

Jina 显然聪明得多，大概率在抓取阶段就主动过滤掉了无关的第三方统计与分析脚本，只保留页面本体的核心资产。

这也给使用 DeepSeek Fetch 的人提了个醒：如果目标网站挂了响应缓慢的外部资源，它的稳定性会大打折扣。

公众号里的真绝活

不过，如果测试就此打住，未免太小看了 DeepSeek 的本土基因。

在中文互联网的信息流处理与知识库搭建中，有一个绕不开、也最让人头疼的抓取场景——微信公众号。微信生态对外部爬虫的风控极其严格，稍有异样就会直接弹出“环境异常，完成验证后即可继续访问”的人机验证页面。

平时大家在微信里分享文章，常见两种链接格式：一种是客户端内直接复制生成的短链接（mp.weixin.qq.com/s/...），另一种是浏览器或历史图文展开后带有一长串参数的长链接（mp.weixin.qq.com/s?__biz=...&mid=...），你从公众号后台或者只用一些抓取服务获得的，多半是这类。

后一类，是最让人头疼的，往往人工打开就会出现下图，Agent就更彻底无法抓取。

我把这两种链接分别喂给 DeepSeek 和 Jina，各跑了一轮实测：

结果形成了极其鲜明的反差。

不得不说，DeepSeek是懂中国国情的。

走国际化路线的 Jina 在微信的高墙面前全军覆没：无论短链还是长链，无一例外被微信反爬直接挡在门外，只返回了一个需要验证的空壳页面。要知道，短链手搓一个抓取脚本，都能获得的。

而 DeepSeek 的表现堪称惊艳。短链测试中，它耗时 10.5 秒完整拿下了巴伦投资的一篇市场观察（《AI仓位踩踏开始了，这轮抛售该不该接？| 巴伦投资》）；长链测试中，面对一篇包含视频占位符、图文混排、长达 9400 多字的深度技术长文（数字生命卡兹克的《分享一个最近很惊艳的开源Skill，一句话让AI搓出任何原理的科普视频。》）以及机器之心的一篇报道（《宕机数小时，DeepSeek给补钱了！》），DeepSeek 都在十几秒内把正文原原本本地扒了下来。

在 SSRN 和海外慢脚本上占尽优势的 Jina，反而在国内最大的内容孤岛前碰了壁；而 DeepSeek 凭借原生适应国内网络与生态风控的后端环境，毫不费力地啃下了这块硬骨头。

对于平时需要高频抓取、整理公众号文章的国内开发者来说，这可以说是 DeepSeek Fetch 最具杀伤力的一个绝活。

一只偏科的眼睛

把前面几轮不同场景的实测拉一张总表，两者的能力边界一目了然：

测完这一圈，两个工具的定位与生态分工其实非常清晰，各有一招不可替代的看家本领。

DeepSeek 的 Fetch 接口，更像是一副专为本土生态与 Agent 工作流定制的“破壁镜”。它最大的杀手锏是原生适应国内网络风控，能轻松穿透微信公众号这种最让爬虫头疼的围墙花园，同时胜任国内主流站点的动态渲染，调用成本也极低（5 元 / 千次）。不过它的偏科同样明显：遇到 Cloudflare 等硬核反爬直接报错，遇到外部慢资源容易超时卡死，正文提取也残留着不少页面骨架噪音。

与之相比，Jina Reader 依然是通用互联网上更成熟的专业解析底座。它主动过滤慢资源、正文清洗极为规整、元数据齐备，且个人免费额度非常充裕（根据其官方定价页面，不带 Key 每分钟 20 次，绑免费 Key 升至每分钟 500 次并赠送 1000 万 token）。它目前唯一的硬伤，恰恰是在国内公众号的反爬高墙面前全军覆没。

在实际工作流中，两者不是非此即彼的替代关系，而是分工明确的互补组合：处理微信公众号等本土高风控内容，DeepSeek 是无可替代的利器；而在开放互联网的日常网页抓取与文献归档场景下，Jina 依然是更省心、更规整的通用选择。