AI代理（AI Agent，能自主决策并执行任务的智能程序）要干活，第一步是拿到干净的网页数据。但网页不是为机器设计的——JavaScript动态加载、反爬机制、格式混乱，每一样都能让代理卡死。
Firecrawl、ScraperAPI、Apify三家，代表了三种解题思路。Rhumb的AN评分专门针对"代理就绪度"：执行可靠性、结构化提取、复杂JavaScript处理、失败时的容错能力。分数不是拍脑袋，是代理实际跑出来的。
Firecrawl：给代理喂Markdown，别的不管
执行评分7.8，三家里最高。它的设计哲学像快餐店的标准化流程：URL进去，Markdown出来，零配置。
REST API干净，JavaScript重站默认处理，错误信息能让代理直接决策下一步。对需要快速把网页塞进上下文的代理来说，这是最短路径。
但问题也在这：Markdown会丢结构。
表格、嵌套列表这些HTML能保住的层级关系，转成Markdown后可能变平。如果你的代理要处理财务数据、产品规格这类强结构化内容，Firecrawl的"简单"就成了负担。需要原始HTML或API响应时，它过度拟合了Markdown场景。
选它的情况很具体：代理消费Markdown，且你想最小化设置时间。
ScraperAPI：瑞士军刀，但得自己磨
灵活性评分7.8，和Firecrawl的执行分打平，但维度不同。它覆盖HTML解析、结构化提取、代理轮换、JavaScript渲染、自定义渲染——你能想到的需求，它都有开关。
代价是配置量。JavaScript渲染增加延迟，结构化提取要手写CSS选择器或正则，不像Firecrawl那样"给代理直接可用的文本"。
CAPTCHA解决和代理轮换对难缠站点有效，但这更像工具箱，而非现成答案。
如果你只需要"URL变Markdown"，ScraperAPI的大炮打蚊子了。多样化站点结构、不同策略切换，才是它的主场。
Apify：云原生流水线，单请求别来
执行评分7.4，略低于前两家，但能力边界完全不同。多步导航、认证爬取、数据转换流水线、定时监控数百站点——这些是它的设计目标。
问题同样明显：单URL提取太重。云原生架构假设你在建数据管道，不是做一次请求。定价也复杂，计算单元、存储、请求数分开算，小团队算账头疼。
代理只需要抓一个页面时，Apify的动力过剩。
复杂编排、定时任务、大规模监控，才是它该出现的地方。
选型决策：代理的胃口决定工具
三家的分化很清晰。Firecrawl赌的是"代理要的是干净文本，格式我帮你定"；ScraperAPI赌的是"代理场景多变，灵活比省事重要"；Apify赌的是"代理只是数据流水线的一环，要的是工程化"。
Rhumb的评分体系有意思：它不评"哪个爬虫更强"，而是评"哪个对代理更友好"。这个视角转换，把技术选型从功能清单变成了场景匹配。
一个细节：Firecrawl的LLM原生设计，意味着它的输出格式是替代理"预消化"过的。这和传统爬虫"给你原始数据，你自己洗"的逻辑相反。代理越智能，这种预消化越有价值；代理越需要精细控制，这种预消化越碍事。
你的代理属于哪一类？
热门跟贴