Reader：把任意 URL 变成 LLM 能直接吃的 Markdown，但自托管有代价
Convert any URL to an LLM-friendly input with a simple prefix https://r.jina.ai/
秒懂
- 它是什么？
- Jina AI 的 Reader 用 URL 前缀把网页、PDF 和 Office 文档转成 LLM 友好的 Markdown，并提供搜索接口。开源版去掉了 MongoDB 存储层，跑在无状态模式，适合想自己控制抓取管线的团队，但别指望它有 SaaS 版的全部能力。
- 适合谁用？
- Reader 适合两类人：一是想在 agent 或 RAG 系统里快速把 URL 内容喂给 LLM 的开发者，直接调用 r.jina.ai 和 s.jina.ai 免费服务即可，无需自己部署；二是需要内部抓取能力、对数据隐私敏感或想定制抓取策略的团队，可以用 docker compose 跑开源版，但必须接受它默认无状态、没有 MongoDB 存储层的事实。不建议把开源版当成 SaaS 的完整替代品，因为 README 明确说了 SaaS 的存储层不在仓库里，你拿到的只是一个抓取和转换的引擎。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 117 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 LLM 输入侧的脏活
LLM 和 RAG 系统最头疼的不是模型能力，而是喂进去的内容质量。直接丢一个 URL 给模型，它拿到的是 HTML 标签、脚本噪声和导航菜单，token 浪费在无用信息上。Reader 的思路很直接：在 URL 前面加一个前缀 https://r.jina.ai/，服务端帮你把网页抓下来，去掉样板内容，转成干净的 Markdown 再返回。这个项目是 Jina AI 的 SaaS 服务 r.jina.ai 和 s.jina.ai 的开源分支，代码用 TypeScript 写的，许可证是 Apache-2.0。它面向的是构建 agent、RAG 管道或者任何需要把网页内容结构化喂给 LLM 的开发者。你不需要自己维护浏览器渲染、PDF 解析或者反爬绕过，这些都被封装在了一个 URL 前缀后面。
两条路径：读 URL 和搜全网
Reader 的核心是两个端点。r.jina.ai 负责把单个 URL 转成 Markdown，你只要把目标 URL 拼在域名后面就行，比如 https://r.jina.ai/https://en.wikipedia.org/wiki/Artificial_intelligence。s.jina.ai 则处理搜索，你把查询词编码后拼上去，比如 https://s.jina.ai/Who%20will%20win%202024%20US%20presidential%20election%3F。搜索的工作方式值得注意：它先搜索网页，取前 5 个结果，然后逐个访问这些 URL，再用 r.jina.ai 的技术栈把每个页面转成 Markdown。这和很多 agent 框架里的 web search function-calling 不一样，那些通常只返回标题、URL 和搜索引擎给的描述，你要深入读某个结果还得自己再抓一次。Reader 直接把内容拉回来了，省掉了二次请求。s.jina.ai 还支持 site 参数做站内搜索，比如 curl 'https://s.jina.ai/When%20was%20Jina%20AI%20founded%3F?site=jina.ai&site=github.com'，可以限定在特定域名里搜。
抓取机制：headless Chrome 和 curl-impersonate 的二选一
Reader 处理网页时有两种抓取方式。一种是 headless Chrome，完整渲染页面，适合 JavaScript 重的站点；另一种是 curl-impersonate，轻量抓取，速度快但拿不到动态内容。README 说 Reader 会在这两者之间智能选择，但没细说判断标准是什么。对 PDF 文件，它用 PDF.js 解析成 Markdown，README 里给了一个 NASA PDF 的对比链接。Office 文档走的是 LibreOffice 转换，先转成 HTML 或 PDF 再处理。图片则由视觉语言模型生成标题，让纯文本 LLM 能获得一点关于图片内容的提示。这套机制意味着你得到的 Markdown 不是简单的 HTML 转文本，而是经过了可读性提取和格式整理。但智能选择也带来不确定性，你没法控制它到底走哪条路径，只能通过请求头调整输出格式。
请求头控制输出，frontmatter 是亮点
Reader 的行为可以通过请求头调节。x-respond-with 是核心的一个，它决定返回格式。默认返回的是带 Title 和 URL Source 自定义头部的纯文本，如果你想要 YAML frontmatter，就设置 x-respond-with: frontmatter，返回的 Markdown 会带上 title、description、url 字段。还有 markdown 选项，跳过 readability 直接返回原始 Markdown，html 返回 documentElement.outerHTML，text 返回 body.innerText，screenshot 和 pageshot 则返回截图 URL，区别是 pageshot 尝试截整页。这些选项让 Reader 不只是一个 Markdown 转换器，还能当网页截图服务或者 HTML 抓取器用。但完整参数列表和默认值不在 README 里，文档指向 live API 文档和源码里的 src/dto/crawler-options.ts。如果你要深入用，得自己去翻那个文件。
部署方式：无状态是默认，缓存要自己接
开源版和 SaaS 版有一个关键差异。README 在更新日志里说得很清楚，2026 年 4 月重新同步了开源分支和 SaaS 代码，但 MongoDB 存储层被剥离了，开源版默认以无状态模式运行。这意味着你部署的 Reader 不保存任何抓取结果，每次请求都重新抓取。如果你想要缓存，得用 docker compose 启动 MinIO 或 S3 兼容的 bucket 缓存。仓库里没有提供完整的部署步骤，只提到 Local development 一节有说明。这个设计选择有实际影响：无状态模式适合测试和低流量场景，但生产环境里重复抓取同一 URL 会浪费带宽和时间。你需要自己搭缓存层，而且 README 没给出具体的 MinIO 配置示例，得看仓库里的 docker-compose 文件。
它能读什么，不能读什么
Reader 支持的范围挺广：网页、PDF、Word、Excel、PowerPoint，还有图片。PDF 和 Office 文档还支持直接 POST 二进制文件，通过 file body 字段上传，不用先托管到公网 URL。这个功能是 2025 年 12 月加的。但限制也很明显。首先，它依赖外部服务，如果目标网站有严格的反爬机制，curl-impersonate 可能被识别，headless Chrome 也可能被检测。其次，图片只生成标题级别的描述，对需要详细视觉信息的任务不够用。第三，s.jina.ai 的搜索深度固定在前 5 个结果，你没法调这个数字。如果你需要抓取登录后的页面或者需要自定义抓取频率，Reader 不是合适的工具，它更像一个即插即用的转换器，而不是一个完整的爬虫框架。
和自建抓取管线的对比
Reader 的替代方案不是某个具体产品，而是你自己用 Playwright、Puppeteer 加 readability 搭一套抓取转 Markdown 的管道。区别在于控制粒度。自建方案里你能决定何时用无头浏览器、何时用普通 HTTP 请求、怎么处理重试和限速。Reader 把这一切封装成黑盒，你只能通过请求头做有限的调节。好处是省事，一个 URL 前缀就搞定，坏处是出了问题你没法排查，比如某个网站返回了空内容，你只能猜是渲染失败了还是被反爬了。另一个替代是直接用 Jina AI 的 SaaS 服务，如果你不在乎数据经过第三方，开源版的意义就只剩下自托管这一条。但自托管意味着你要负责 Chrome 实例的资源消耗、curl-impersonate 的维护，以及缓存层的搭建。开源版不是免费的 SaaS，它是把 SaaS 的复杂度搬到了你自己服务器上。
维护成本和许可证的实际情况
这个仓库的维护节奏看起来是跟着 SaaS 走的。更新日志显示 2024 年发布，2025 年 3 月做过一次大重构，从 Firebase 迁移到 Cloud Run 加 MongoDB，2025 年 12 月加了文件上传，2026 年 4 月重新同步了开源分支。说明开源版不是被遗忘的玩具，而是 SaaS 的一个镜像，只是少了一层存储。但这也意味着你升级时要留意，SaaS 的新功能可能不会立刻出现在开源版里，比如 MongoDB 存储层被剥离后，某些依赖存储的功能在本地跑不起来。许可证是 Apache-2.0，允许商用和修改，但如果你改了自己的版本，要注意保留版权声明。代码里用到的 headless Chrome、PDF.js、LibreOffice 都是外部组件，各自的许可证你得自己查。维护成本主要来自跟进上游更新，每次 SaaS 大改，开源分支都可能需要重新同步，你要么自己合并，要么等 Jina AI 推送。
编辑结论
Reader 适合两类人：一是想在 agent 或 RAG 系统里快速把 URL 内容喂给 LLM 的开发者，直接调用 r.jina.ai 和 s.jina.ai 免费服务即可，无需自己部署；二是需要内部抓取能力、对数据隐私敏感或想定制抓取策略的团队，可以用 docker compose 跑开源版，但必须接受它默认无状态、没有 MongoDB 存储层的事实。不建议把开源版当成 SaaS 的完整替代品，因为 README 明确说了 SaaS 的存储层不在仓库里，你拿到的只是一个抓取和转换的引擎。在决定采用前，先验证三件事：第一，检查 r.jina.ai 的限流策略是否满足你的调用量，README 说免费稳定可扩展，但没给具体数字；第二，确认你要抓的网站是否允许这种代理访问，Reader 用 headless Chrome 或 curl-impersonate 绕过一些反爬，但可能违反目标站点的服务条款；第三，如果你需要缓存或持久化，得自己接 S3 兼容存储，因为开源版默认不存任何东西。
社区笔记