摘要： Firecrawl 在 2026 年 8 月 20 日發表 Developer Index，為 coding agents 提供語意檢索層，收錄 README、issues、pull requests、外部文件與 OpenAPI specs，但不存放程式碼。索引宣稱有 70M+ 工件；同日 DevDex 基準收錄 1,179 個查詢，官方結果中 Firecrawl 的 Recall@10 為 0.63。
Coding agents 有很大一部分工具呼叫都耗在找資料：某個想法是哪個 repo 做出來的、哪份文件回答了手上這個問題、又是哪個 issue 或 PR 把 bug 修掉的。這些線索四散在 GitHub、文件網站與討論串裡，而目前能用的檢索工具大多只做詞彙比對，既不語意，也不完整。
Firecrawl 在 2026 年 8 月 20 日發表 Developer Index，這是一層專為 coding agents 打造、用來檢索的索引，把 README、issues、pull requests、外部文件與 OpenAPI specs 收納其中，每天更新，並支援語意檢索與 metadata 過濾。同日一同釋出的還有開放基準 DevDex，收錄 1,179 個開發者搜尋查詢，以 Recall@10 與 MRR@10 計分，讓團隊得以評估任何檢索系統在真實 coding-agent 工作流程上能支撐到什麼程度。
為何需要一個專用索引？
Firecrawl 從客戶怎麼搜尋、怎麼抓取的觀察裡，整理出三個一再重複的模式：
- Agentic 產品（如 Lovable、Replit、Bolt）替終端使用者做後端除錯。
- 知識庫建置者把內部與外部 repo 縫成單一檢索層。
- 前沿實驗室要的是開放的開發者文件、程式碼、issues 與 PR，用來訓練與評估。
這三種需求撞上的其實是同一個缺口。既有供應商並非為 agent 的世界而設計：搜尋停在詞彙層次而非語意層次，而想拿到一份完整工件（一份 README 連同它的 issues 與近期 PR），得把 50 多個 API 呼叫串起來，否則就是自己從零打造整條 pipeline。Firecrawl 自家的通用搜尋與抓取在這種題型上同樣不理想，道理很簡單——coding agent 要的不是網頁，而是工件。
索引裡收錄了什麼？
索引規模為 70M+ 工件，類型橫跨 README、issues、pull requests、OpenAPI specs、skills 與外部文件，多數來源每天更新。每一筆工件都附帶 metadata，例如 stars、license、artifact type。
有一點必須講明白：Developer Index 不存放程式碼，它也不是通用的網頁搜尋端點。這是一層針對 coding agents 所產出與取用的工件而設計的檢索層。
怎麼用，實測又如何
用法很直接：送出以自然語言描述的問題，取回排序好的開發者結果，連同命中的匹配段落，agent 據此即可行動，不必再抓一次。入口有兩個——/search/developer，或在 /search 帶上 categories: ["developer"]。每筆結果都附上穩定 ID（寫法如 issue:owner/repo#123），其前綴則代表工件類型；匹配段落以 markdown 呈現，表格與程式碼區塊都能保留下來。API 端另外接受一串過濾條件——types、repos、sources、language、topic、license、min_stars 等——用來縮小查詢範圍，但 CLI 與 MCP 並不開放這些過濾器，因為 agent 在完全不設過濾時表現最好。
起步門檻極低：直接呼叫 /search/developer 就行，不需 API key，一行 curl 即可打通：
# No API key needed to get started; add -H "Authorization: Bearer $FIRECRAWL_API_KEY" for higher rate limits:
curl -s "https://api.firecrawl.dev/v2/search/developer?query=how%20do%20I%20configure%20retries&k=10"想讓自己的 agent 直接用上這個索引，最省事的做法，是在自己的環境安裝 Firecrawl 專屬的 developer skill，它會掛進 Firecrawl CLI 或 MCP server：
npx -y firecrawl-cli@latest setup developer-index在 DevDex 基準上，Firecrawl Developer Index 的整體 Recall@10 落在 0.63，勝過 Firecrawl Search 的 0.58、Parallel 的 0.57，以及 Mintlify、Exa 的 0.54；原生網頁搜尋拿到 0.45，Context7 則是 0.17。拆到各分項，它在 issue 與 PR 解決一項居首（0.66）；文件查詢與 Context7 在統計上打成平手（兩者皆 0.47）；repo 發現一項則輸給 Parallel（0.76 vs 0.82）；Context7 的強項只集中在文件，其餘兩項分數接近零。
對產品建置者的意義
Developer Index 的價值在於補上 agent 檢索原本缺的那一塊。對產品建置者來說，可以把它接進 agent 的工具迴圈，讓 agent 一遇到錯誤就立刻去查 issues 與 PR，而不是憑空猜測；也可以用它建立開發者知識庫，無需自己維護 GitHub scraper；還能當成 RAG 訓練資料 pipeline 的檢索層，並以 DevDex 替自己打造的 retriever 打分。
有一點值得留意：Firecrawl 將 DevDex 一半的資料集與評估 harness 開源，任何團隊都能在自己的系統上重現結果。對正在評估檢索系統的團隊來說，這樣的公共標準並不多見。
目前 Developer Index 已在 API、CLI、MCP 與 SDK 上線，也能接上 Codex、Claude Code、Grok Build 等 harness。搜尋計價為每 10 個結果 2 credits；不需 API key 也能起步。
如果你手上正在做的 agent 會依賴開發者文件，這個索引值得一試，尤其是當你發現通用搜尋已經滿足不了 artifact 層級的需求時。