Reader：把網頁變成 LLM 能讀的 Markdown，但開源版與 SaaS 的界線要看清
Convert any URL to an LLM-friendly input with a simple prefix https://r.jina.ai/
秒懂
- 它是什麼？
- Jina AI 的 Reader 以 URL 前綴或搜尋前綴，把網頁、PDF、Office 文件轉成 LLM 友善的 Markdown。本文拆解它的運作機制、自架方式，以及開源分支與商業版之間的落差。
- 適合誰用？
- 建議需要把大量網頁內容餵給 LLM 或 RAG 管線的開發者採用 Reader，尤其是那些不想自己處理瀏覽器渲染、PDF 解析或反爬蟲的團隊。不建議的人包括：需要完整 SaaS 儲存與 API 金鑰管理的人，因為開源版刻意移除了 MongoDB 層，無法直接複製線上服務的全部行為。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 117 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的問題：LLM 吃不下原始網頁
LLM 的輸入格式終究是文字，而網頁是 HTML、CSS 與 JavaScript 的混合體。直接丟一串原始 HTML 給模型，token 浪費在標籤與腳本上，內容卻常常被廣告或導覽列淹沒。Reader 的切入點很直接：在目標 URL 前面加上 https://r.jina.ai/，它就回傳一份乾淨的 Markdown。這個設計把複雜的網頁清理工作變成一個 URL 前綴，任何會發 HTTP 請求的程式都能用。它的搜尋端 s.jina.ai 也一樣，把查詢字串編碼後丟過去，它會自己搜尋、抓取前五筆結果、逐頁套用讀取邏輯，最後回傳合併的 Markdown。這對 agent 或 RAG 系統特別有用，因為傳統的搜尋 API 只回傳標題、URL 和描述，想讀內文還得自己再抓一次。Reader 把兩步併成一步。
內部機制：兩種抓取路徑與多格式輸出
根據 README，Reader 對網頁有兩種抓取方式：用 headless Chrome 完整渲染，或用 curl-impersonate 做輕量請求。它會「聰明地選擇」用哪一種，但文件沒有說明判斷條件，這是一個需要實測才知道的細節。PDF 則固定用 PDF.js 解析，Office 文件先經 LibreOffice 轉成 HTML 或 PDF 再處理。圖片會由 vision-language model 產生說明文字，讓純文字的 LLM 也能獲得線索。輸出格式由 x-respond-with 標頭控制，可選 markdown、html、text、screenshot、pageshot、frontmatter 或 markdown+frontmatter。其中 frontmatter 會把預設的 Title: 與 URL Source: 自訂標頭換成標準的 YAML 區塊，便於後續處理。預設的純文字回應用的是自訂格式，這點在整合既有工具時要注意，不是標準的 front matter。
兩種使用方式：讀取與搜尋的實際請求
讀取單一網頁最簡單，直接把目標 URL 接在 r.jina.ai 後面即可，例如 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。搜尋也支援 site 參數，可以限定來源網域，curl 的範例是這樣：curl 'https://s.jina.ai/When%20was%20Jina%20AI%20founded%3F?site=jina.ai&site=github.com'。這個 site 參數可以重複出現，對需要鎖定特定網站內容的檢索很有用。若要在程式裡控制輸出，就用請求標頭，例如 curl -H 'X-Respond-With: frontmatter' 'https://r.jina.ai/https://example.com'，回應會是帶 YAML front matter 的 Markdown。這些指令都來自 README，實際行為以線上文件為準。
自架開源版：stateless 模式與可選的 S3 快取
這個儲存庫是 r.jina.ai 與 s.jina.ai 背後的開源分支，但 README 說得很清楚：它跑在 stateless 或 bucket-cached 模式，MongoDB 支撐的 SaaS 儲存層沒有包含在內。2026 年 4 月的更新提到，開源分支已與 SaaS 程式碼重新同步，移除了 MongoDB 層，預設以 stateless 模式執行，可選用 docker compose 搭配 MinIO 或 S3 相容的 bucket 快取。這代表你若想自架，得自己處理快取與狀態管理，線上服務的某些依賴儲存的功能在這裡不會出現。README 沒有提供完整的 docker compose 指令，只說「See Local development」，實際步驟需要進儲存庫看文件。對於只想快速試用的人，直接呼叫公有的 r.jina.ai 會比自架簡單得多。
真正的限制：開源版不是 SaaS 的完整鏡像
最大的限制在於開源版與 SaaS 的差異。README 明確指出 MongoDB-backed SaaS storage layer 不在這裡，這表示任何依賴儲存的功能，例如跨請求的爬蟲狀態、去重或佇列管理，都必須自己建。另外，Reader 的 SaaS 版本有 rate limit 與商業支援，而自架版本沒有這些，你得自己監控用量。文件也提到「It is free, stable and scalable」，但那是針對公有 API 的宣傳，不是對開源版的保證。若你的使用情境需要大量並發請求，stateless 模式可能很快碰到上游網站的反爬蟲限制，因為沒有分散式快取分擔負載。curl-impersonate 能模仿瀏覽器指紋，但這不代表它能繞過所有封鎖，遇到嚴格防護的網站，Reader 可能回傳不完整的內容，這點文件沒有提供保證。
替代方案：Firecrawl 與自建爬蟲管線的差異
市場上最接近的替代品是 Firecrawl，它同樣把網頁轉成 LLM 可用的 Markdown，也提供 API 與自架選項。但兩者的切入點不同：Reader 用 URL 前綴與搜尋前綴，把整個操作壓縮成單一 HTTP 請求，使用者不需要自己組合多個 API 呼叫。Firecrawl 則提供更細緻的爬蟲控制，例如網址白名單、表單填寫與 JavaScript 等待條件，這些在 Reader 的 README 中沒有對應功能。若你的需求是深度爬取整個網站並處理動態互動，Firecrawl 的架構比較適合。若你只需要把單一 URL 或搜尋結果快速轉成文字，Reader 的前綴設計更輕量。另一個替代方案是自己用 Playwright 或 Puppeteer 寫爬蟲，但那就得自己處理 PDF 解析、Office 轉檔與圖片說明，Reader 把這些整合好了，這是它的主要價值。
維護與授權：Apache-2.0 下的實際考量
專案使用 Apache-2.0 授權，這對商業使用相對友善，允許修改與再發布，但要保留原始著作權聲明。README 顯示最後一次 push 是 2026 年 5 月，且沒有 archived，代表專案仍在維護。2026 年 4 月的更新把開源分支與 SaaS 重新同步，這是個正面訊號，表示開源版不會長期落後於商業版。但要注意，Jina AI 把 Reader 視為核心產品，他們有動機讓開源版保持可用，卻不一定會把完整的 SaaS 功能都放進來。升級成本方面，由於沒有 release 標籤，你只能追蹤 main 分支的變動，這對需要穩定版本的生產環境是個風險。建議在部署前固定 commit hash，並定期檢查 upstream 是否有安全更新。授權條款本身不構成法律建議，若你打算把 Reader 改名後當作商業服務，最好諮詢律師關於商標與名稱使用的限制。
編輯結論
建議需要把大量網頁內容餵給 LLM 或 RAG 管線的開發者採用 Reader，尤其是那些不想自己處理瀏覽器渲染、PDF 解析或反爬蟲的團隊。不建議的人包括：需要完整 SaaS 儲存與 API 金鑰管理的人，因為開源版刻意移除了 MongoDB 層，無法直接複製線上服務的全部行為。導入前應先驗證三件事：查閱 src/dto/crawler-options.ts 確認目前支援的請求標頭與預設值，因為 README 只列了部分；用 docker compose 啟動後測試 x-respond-with 的各種輸出格式是否如文件所述；最後確認你對 Apache-2.0 的授權理解，特別是你若打算修改後再以 SaaS 形式提供服務，需注意商標與名稱使用上的限制。開源版是一個可以自行掌控的閹割版，它的價值在於讓你把 r.jina.ai 的核心邏輯跑在自己的基礎設施上，而不是複製一個 Jina AI 的付費服務。
社群筆記