Context.dev 上线：Agent 抓网站不用再写解析器
YC S26 团队 Context.dev 推出网页结构化数据 API，一个 POST 请求把任意网站抓成干净 Markdown，最多 500 页。Agent 和 RAG 开发者从此不用再和 Cheerio、Playwright、反爬虫死磕。
Context.dev 把"抓网页"这件事做成了一个 POST 请求
7 月 9 日，YC S26 批次的 Context.dev 在 Hacker News 挂出 Launch 帖，正式对外开放它的网页结构化数据 API。产品定位一句话就能讲完：给一个 URL，返回干净的 Markdown、原始 HTML、图片列表，或者整站爬取结果——面向 Agent 和 RAG 开发者，OpenAI 格式的思路，一个端点搞定所有场景。
这不是又一个通用爬虫。过去两年 Firecrawl、Jina Reader、Apify 的 RAG Web Browser 已经把"网页转 Markdown"这条路踩得差不多，Context.dev 挤进来卡的位置更精准：它把整个抓取流程收敛成了几个高度对齐 LLM 消费习惯的原子端点，不再让你在"要抓一页"和"要爬一站"之间自己搭中间件。
四个端点，覆盖 Agent 抓网页的 90% 场景
翻一下它现在开放的能力列表，逻辑非常清楚：
- Extract Raw HTML：给 URL 拿到渲染后的完整 HTML，处理 SPA、无限滚动、Cookie 弹窗这些老大难；
- Extract Images：把页面上所有图片资源抽出来，返回 URL 列表；
- Discover URLs：喂一个域名，反查站点下所有可达页面的 URL——本质是站点地图重建；
- Crawl Website：从任意 URL 出发，抓最多 500 页并全部转成 Markdown，可控制爬取深度、页面上限、URL 过滤规则、是否跟随子域名。
最后一个是重头戏。以往你要做同样的事，得自己拼三层：Playwright/Puppeteer 做渲染，readability.js 或者一堆手写规则做正文抽取，再加一层 turndown 把 HTML 转 Markdown。中间还得处理并发、重试、robots.txt、代理池。整套流程写完能吃掉一个工程师两周。
Context.dev 把这一切压缩成一个 POST 请求，控制参数就那几个：
{
"url": "https://example.com/docs",
"maxPages": 500,
"maxDepth": 3,
"includePatterns": ["/docs/*"],
"followSubdomains": false
}
返回体是每一页的 Markdown 数组。这个粒度刚好卡在 Agent 消费的黄金位置——不是 Chunk 太碎需要重新组装，也不是原始 HTML 太脏需要清洗。
为什么这件事现在才成为一门生意
把"抓网页"抽象成 API 的想法并不新。真正的转折点是 Agent 生态在过去一年爆发之后，抓取需求的形态彻底变了。
聊天机器人时代，抓网页是离线任务：夜里跑一遍 Sitemap，把内容洗进向量库，白天检索。你有时间把爬虫调到完美。Agent 时代不是这样——它是在线的、按需的、随机的。用户丢一个链接进来，Agent 得在几百毫秒里判断这是文档站还是电商页，然后决定要抓一页还是要抓一整个 /docs/ 目录。整个抓取动作变成了推理链上的一个 Tool Call。
Manus 团队最近那篇《AI 代理的上下文工程》里有个观察挺扎心：一个典型 Agent 任务平均需要 50 次工具调用，输入输出 Token 比 100:1。这意味着抓取工具的每一次延迟和每一次失败，都会被 Agent 循环乘以几十倍放大。你的爬虫不能是那种"偶尔挂一下用户也能接受"的东西，它必须像调用一个云函数一样稳定。
自己搭这样一套基础设施，代价越来越不划算：
- 反爬对抗越来越贵。Cloudflare、Datadome、Akamai 都在升级 Bot 检测，指纹伪装、住宅代理、TLS 指纹这些活儿现在是一个专门赛道；
- JavaScript 渲染成本高。跑一个 Chrome headless 内存就 200MB 起步，规模化跑起来 GPU 都不够用；
- Markdown 化质量不稳定。readability.js 十年没更新了，面对现代前端框架经常抽出一堆导航栏和 footer。
所以哪怕是有工程能力的团队，也越来越愿意把这层外包出去。这是 Firecrawl 一年多做到年营收数百万美元的底层逻辑，也是 Context.dev 敢在这个赛道上再插一脚的原因。
和 Firecrawl、Jina Reader 比，Context.dev 的差异化在哪
直接对比一下：
| 产品 | 核心定位 | 计费单位 | 特色 |
|------|----------|----------|------|
| Firecrawl | 全能爬取 + 抽取 | 页面/API 调用 | JSON schema 结构化抽取、批量任务队列 |
| Jina Reader | URL → Markdown | 免费 + Rerank 增值 | 反爬能力强、可直接 r.jina.ai/URL 拼 URL 用 |
| Apify RAG Web Browser | Google 搜索 + 抓取一体 | Actor 运行时 | 集成搜索、MCP 友好 |
| Context.dev | Agent 原子端点 | 未公开定价 | 端点粒度更细、URL 发现独立成一个 API |
Context.dev 把 Discover URLs 独立成一个端点 是我觉得最有意思的设计。这个能力其他家或多或少都有，但一般埋在整站爬取里面。独立出来意味着 Agent 可以先做一次"侦查"再决定要不要真爬——这在 Token 成本敏感的场景下很重要。你先花几毛钱看清楚这个站长什么样，再决定要不要花几十块钱把它全抓下来。
它的 case study 列表里已经能看到一些眼熟的名字：Mintlify（文档托管）、Chatwoot（客服）、Daily.dev（开发者社区）、Sunrun（太阳能能源公司）。前三个都是明摆着的 Agent/RAG 用户，Sunrun 出现在里面挺有意思——传统行业开始为 AI 应用改造自己的知识分发方式了。
但也不是没有隐患
泼一盆冷水。这类 API 有几个绕不开的结构性问题：
第一，法律和伦理边界越来越紧。Reddit 起诉 Anthropic、纽约时报起诉 OpenAI、Perplexity 被 Forbes 点名，整个行业对"抓公开网页拿去训练/服务 AI"的容忍度在快速下降。作为 API 提供方，Context.dev 相当于把这个风险中心化了——某天出一个大案子，整条链上的 SaaS 都得跟着抖。
第二，动态内容的抓取质量瓶颈还在。文档站、博客这些静态内容 Markdown 化没问题，但涉及登录、动态加载、复杂交互（比如 SPA 的 tab 切换）的场景，任何通用爬虫都得对着具体网站调优。Context.dev 目前的 API 看不出对这类场景的特别处理。
第三，价格模型是硬仗。Firecrawl 的定价策略已经改过好几轮，因为爬取的边际成本很难压。Context.dev 官网现在还没挂出明确的定价页面，等公开定价出来才好判断它到底是走开发者友好路线还是走企业单路线。
对开发者意味着什么
如果你现在正在搭 Agent 或者 RAG 系统，我的建议是：别再手写解析器了。这个赛道已经过了自建的性价比拐点，除非你有非常特殊的抓取需求，否则调 API 是更理性的选择。
选型上：
- 只要抓单页 Markdown，Jina Reader 免费额度够用，甚至可以直接拼 URL；
- 需要按 Schema 抽结构化字段，Firecrawl 的 Extract 更成熟；
- 需要"搜索 + 抓取"一步到位，Apify 的 RAG Web Browser 更合适；
- 需要精细控制爬取范围、要独立的 URL 发现能力，Context.dev 值得试。
再往上一层的问题是抓下来的 Markdown 交给谁处理。抓取只是 RAG 流水线的第一步，后面还有分块、Embedding、检索、重排、合成——每一步都有模型选择的空间。开发者现在越来越倾向于一个 Key 调多家模型这种模式来避免锁死。像 OpenAI Hub 这类聚合平台的价值也在这里，抓取端选 Context.dev、Embedding 端选 Voyage、合成端切换 Claude 或 GPT，中间不用维护三套鉴权。
结语：Agent 时代的"卖水人"
淘金热里赚钱的是卖铲子的。Agent 这波浪潮里，模型公司在最前面吸引所有注意力，但底下已经形成了一层稳定的"卖水人"：向量数据库、检索服务、评估平台、Prompt 管理、抓取 API。
Context.dev 属于这层里最基础但也最刚需的一环。它不性感，但每一个严肃的 Agent 项目都得用。YC 把它录进 S26 是有道理的——这个位置在未来两三年会长出至少一家独立的中等规模公司，问题只是谁跑得出来。
从目前的产品完成度和端点设计来看，Context.dev 至少值得进入你的 shortlist。
参考来源
- Firecrawl 开源仓库 · GitHub：目前最活跃的开源网页转 Markdown 爬取工具，可以作为 Context.dev 的对照参考。
- Crawl4AI · GitHub：面向 LLM 的开源爬虫框架，社区活跃度高，适合自建方案。
- RAG 抓取网页方案讨论 · 知乎：中文社区关于 RAG 场景下网页抓取工具选型的讨论。
- YC S26 Batch 相关讨论 · Reddit：Y Combinator 最新一批创业公司的社区讨论。
- Playwright · GitHub：如果你打算自建抓取方案，Playwright 仍然是浏览器自动化的事实标准。
