挑战
你正在构建一款 B2B SaaS 产品。你的客户上传了一份公司名称列表。他们期望返回干净的记录：营收区间、员工人数、技术栈、融资轮次、关键联系人、最新动态。他们期望在几分钟内而不是几天内拿到数据。而且他们期望数据是准确的。
这些数据确实存在。它们分布在 Crunchbase、公司官网的“关于我们”页面、LinkedIn 公司主页、Google Maps、Glassdoor、地区商业登记处以及 TechCrunch 归档中。问题在于如何可靠地获取这些数据。
每个数据源的失效方式都不同。Crunchbase 运行着一个庞大的客户端应用，一旦怀疑有机器人访问就会重新渲染。LinkedIn 实行严格的 rate limit，并且其 DOM 变化速度比你修补选择器的速度还要快（一篇热门社区文章对原生 Python 爬虫进行了基准测试，发现在遭遇反爬墙之前只能抓取大约 50 个 profile）。公司网站的类型多种多样，从静态 HTML 到需要完整浏览器才能显示内容的单页应用。地区登记处每季度都会轮换布局，并设置特定国家/地区的封锁。根据 GroupBWT 的 2026 年行业报告，某些垂直领域的爬虫中有 10% 到 15% 每周都需要修复，才能跟上反爬更新和 DOM 漂移的速度。
因此，你的富化管道最初是一个干净的五数据源设计。六个月后，它变成了一团乱麻，充斥着半损坏的爬虫、重试队列，以及一个名为 #scraper-alerts 且再也没人打开的 Slack 频道（我们之前写过关于维护自研爬虫的隐性成本的文章）。数据质量投诉在你的支持队列中堆积如山。你的团队开始开玩笑说，公司名字应该改叫“五个爬虫和一个祈祷”。
解决方案
先别管爬虫了。富化最难的部分不是提取，而是路由：决定哪个数据源需要哪个工具、哪个 proxy、哪种重试策略，以及什么才算作“好”的 response。
像 FourA 这样的平台为你提供了三个产品，直接映射到你将要面对的三类数据源。
静态 HTML 目录和登记处。 大多数地区商业登记处和许多较旧的 B2B 目录都是服务端渲染的。它们需要来自干净 IP 的快速、低开销的 HTTP request。这就是 Single：输入一个 URL，输出一个 response。加上 unblocker: true，它就能穿透那些让原生 HTTP 客户端束手无策的握手级封锁。Single 会自动通过 Proxy Finder 进行路由，并在 response 的顶层返回 proxy id（r.proxy），以便你的后续调用可以将其作为 proxy:"<id>" 传回，在需要保持会话连续性时锁定同一个出口。
重度依赖 JavaScript 的单页应用（SPA）。 Crunchbase、类似 LinkedIn 的应用，甚至中等规模的公司网站，都无法通过简单的 HTTP response 返回你想要的数据。它们在客户端进行渲染。这就是 Browser：一个完整的浏览器执行页面、运行 JS，并将渲染后的 HTML、cookie 和截图返回给你。与 Single 一样，它在底层通过 Proxy Finder 进行路由，无需你在本地进行单独的选择步骤。
带验证的混合数据源。 发送到 FourA API 的每个 request 都接受一个 validate 块。你可以要求特定的状态码、header 匹配或 body 中的子字符串匹配。如果 response 是软失败（带有 CAPTCHA 的 200 页面、空的数据外壳，或“抱歉”之类的过渡页面），验证器就会拒绝它。然后，你的管道可以改用 Browser 路由相同的 URL。仅这一个功能就消除了富化中最昂贵的一类 bug：将垃圾数据写入数据库的静默失败。
以下是单数据源调用的形式：
curl -X POST https://api.foura.ai/api/single \
-H "Authorization: Bearer pk_live_..." \
-d '{
"url": "https://registry.example.com/company/123",
"unblocker": true,
"followRedirects": 5,
"validate": {
"status": { "accept": [200] },
"data": { "fail": ["captcha", "blocked", "access denied"] }
}
}'
以及针对重度依赖 JavaScript 的公司网站的 Browser 等效调用：
curl -X POST https://api.foura.ai/api/browser \
-H "Authorization: Bearer pk_live_..." \
-d '{
"url": "https://www.example-saas.com/about",
"unblocker": true
}'
路由逻辑存在于你自己的管道中。可靠性则由我们来保证。你决定你的哪个数据源使用哪个工具。We make sure the tool actually gets through.
效果
在公测期间，我们见证了少数团队从自研爬虫切换到基于 FourA 路由的管道。其模式是高度一致的（以下说明性数字基于我们在公测群体中观察到的情况）：
- 富化延迟在缓存住宅路由上从每家公司 3 至 6 秒降至中位数 1.5 秒以下
- 静默失败率（返回 200 但数据为空的 response）在
validate块于软失败进入数据库之前将其捕获后，从 8% 左右降至 1% 以下 - 用于爬虫维护的工程时间从 1 到 2 名全职工程师减少到一个基本保持安静的 Slack 频道
- 首访成功率在受保护目录上，当
unblocker: true与干净的 proxy id 配合使用时，将攀升至 90% 以上
还有一个值得关注的数字：我们发现，首次访问的正确率（正确的数据，正确的公司）比首次访问的成功率落后大约四个百分点。这给我们的启示不是抓取有多难，而是你仍然需要根据你实际请求的公司来验证记录（我们在为什么你的网页爬虫总是失效中讨论过这种模式）。
真正重要的数字不是 proxy 池的大小或 request 数量。而是你的富化 endpoint 在第一次尝试时返回正确数据的概率，以及未来六个月内你的爬虫维护曲线的斜率。
核心要点
富化管道的失效是一个缓慢的过程。你写的第一个爬虫在周二看起来运行良好。到了第三个数据源，你会在晚上 11 点修补选择器。到了第十个，你背负的维护债务将随着客户群的扩大而增加。到了第二十个，你已经悄悄停止引入新的数据源，因为团队中没有人愿意接手下一个。
瓶颈从来都不在数据源。而是在于路由：每一次、为每一个 URL 选择正确的工具、正确的 proxy、正确的验证规则。只需构建一次该层，将其交给已经实现该功能的系统，你的团队就可以在周二专注于产品，而不是去排查选择器损坏的问题。