OpenResearcher：把長程 deep research 的軌跡合成流程整套開源
OpenResearcher: A Fully Open Pipeline for Long-Horizon Deep Research Trajectory Synthesis
秒懂
- 它是什麼？
- TIGER-AI-Lab 把 96K 軌跡資料集、30B-A3B 模型、蒸餾配方與評測框架一起放出來，並用自建 retriever 取代外部 Search API。對想自己造 deep research 資料的人，這是一份可拆解的配方；對只想找一個現成研究助理的人，它給的東西比想像中少。
- 適合誰用？
- 如果你要的是可重跑、可拆解的 deep research 軌跡合成配方，OpenResearcher 值得先讀它的資料集格式與評測框架，再決定要不要動 30B-A3B 模型。若你只需要一個能回答問題的研究助理，這個專案的成本結構不對：你得先備好 ~11B-token 語料與本地檢索，GAIA 那條路雖然可以用 Serper API 省掉本地搜尋，但那就脫離了它省錢的設計前提。
- 可以商用嗎？
- 未經許可不行。GitHub 在這個儲存庫中沒有找到授權檔案；沒有授權，預設即「保留所有權利」：你可以閱讀程式碼，但不能重複使用。使用前請看看 README，或先取得作者同意。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 97 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
OpenResearcher 想解決的是軌跡從哪裡來
長程 deep research 的訓練資料很難自己生。一次完整的搜尋行為可能橫跨 100 多輪工具呼叫，中間夾著檢索、閱讀、放棄、改寫查詢。這種軌跡既貴又慢，而且一旦檢索走外部 API，每一輪都要付費，資料量一大成本就失控。OpenResearcher 的定位就是把這條生產線開源出來：README 說它開源的是「訓練與評測配方」，涵蓋資料、模型、訓練方法與評測框架。它的目標讀者不是終端使用者，而是想自己合成軌跡、或想復現蒸餾流程的研究與工程團隊。專案描述裡寫得很直白：A Fully Open Pipeline for Long-Horizon Deep Research Trajectory Synthesis。重點在 synthesis，不在 chat。
資料流：96K 軌跡、自建 retriever、~11B-token 語料
根據 README，軌跡由 GPT-OSS-120B 搭配 vLLM 的 native browser tools 產生，規模是 96K 筆、單筆可達 100 多輪。這裡的關鍵設計是檢索不走外部 Search API，而是用專案自建的 retriever 跑在一份約 11B token 的語料上，語料以 OpenResearcher-Corpus 的名義發布。把檢索拉回本地，換來的是可重跑與邊際成本下降，代價是你得自己把語料與檢索服務準備好。模型端是一個 30B-A3B 的 MoE 架構，在 BrowseComp-Plus 上 README 給出的數字是 54.8%。這個數字要連著檢索設定一起看：換掉 retriever，答案分佈就會變，分數不具備跨設定的可比性。README 沒有在可見範圍內交代這 54.8% 對應的 top-k、語料切法或工具預算，這是採用前必須向作者確認的地方。
安裝與設定：從 requirements 到 config
README 的目錄把流程切成 Environment Setup、Configuration、Quick Start、Benchmark、Optional Train 幾段。安裝章節的具體指令在提供的內容中已被截斷，只能確定它存在於 Installation 小節之下，實際的 pip 或 conda 命令請以 repo 為準。設定集中在 Configuration 一節，但可見內容沒有列出 config key 的完整清單。能從 README 確認的兩條執行路徑是：Example 1 用 BrowseComp-Plus 搭配 Local Search Engine，Example 2 用 GAIA 搭配 Serper API 且不需要本地搜尋。這個二分很重要，它等於專案自己承認了兩種部署形態：一種是昂貴但自足的本地檢索，一種是便宜但依賴外部服務的 API 檢索。訓練路徑另外放在 Optional Train Your Own OpenResearcher，README 在 2026.2.18 的公告裡說訓練程式碼已釋出。
授權狀態不明是這個專案最硬的風險
提供的資料裡 License 欄位是 unknown，README 也沒有可見的 License 章節。這不是可以事後補救的小事。它同時牽涉三層：repo 程式碼本身的授權、Hugging Face 上資料集與模型的授權、以及那份 ~11B-token 語料的來源與再散布條件。三者可能不同。在條款確認之前，把 OpenResearcher 用於商用產品的資料管線，風險無法評估。同樣要留意的是 README 大量引用外部成績與採用情況（例如 NVIDIA Nemotron 系列採用其資料），這些是專案方的陳述，不構成對授權或品質的保證。要判斷能不能用，去看 repo 根目錄有沒有 LICENSE 檔、Hugging Face 頁面上的 license 標籤寫什麼，這比讀公告有效。
什麼時候它會是錯的工具
如果你的需求是「給定一個問題，拿到一份附引用的答案」，OpenResearcher 的成本結構不對。你得先有本地檢索與那份語料，才有辦法跑 Example 1；若改用 Example 2 的 Serper API 路線，省下的正是這個專案最主要的賣點，等於用一個為合成軌跡設計的框架去做單次推論。另一個失敗模式在於資料規模的假設：96K 軌跡、100+ 輪、11B token 語料，這組數字對單機研究者並不友善，README 也沒有提供小規模起步的替代設定。還有一種情況是當你需要的是穩定的 SaaS 行為：這個專案沒有檢索服務的 SLA，也沒有快取層的描述，檢索品質完全取決於你自己怎麼把語料餵進 retriever。
替代路線：外接搜尋 API 的 agent 框架差在哪
常見的替代做法是用既有的 agent 框架接外部搜尋 API，例如以 ReAct 風格迴圈呼叫商用搜尋端點。差別在資料流的起點。那類框架把檢索外包給服務商，你拿到的是當下的網頁結果，成本隨呼叫次數線性上升，且結果不可重現，因為索引每天都在變。OpenResearcher 把檢索換成對固定語料的查詢，同一條軌跡可以重跑出相同的檢索結果，這對合成訓練資料是必要條件，對單次問答則沒有價值。反過來說，外部 API 路線不需要你維護語料與索引，起步快得多。兩者的分野不是效能高低，而是你要的是可重現的資料生產，還是即時的外部知識。README 自己用 Example 1 與 Example 2 把這條界線畫了出來。
維護成本與版本節奏
提供的資料顯示最近一次 push 是 2026-06-10，且沒有任何 release。這意味著沒有版本號可鎖，升級只能跟 main 分支走，對需要可重現建置的團隊是實質負擔。公告的節奏倒是密集：2026 年 2 月到 6 月之間有多筆更新，包含訓練程式碼釋出、資料集被外部採用、評測日誌公開。評測日誌放在 Hugging Face 的 OpenResearcher-Eval-Logs，這是少見的加分項，因為它讓分數可以被逐筆檢視，而不是只看到一個總表數字。但沒有 release 也代表 API 與資料格式可能隨時變動，任何寫死的解析邏輯都要預期會壞。若你要長期依賴，先把資料集與模型快照到自己的儲存，別讓建置直接指向會變動的遠端。
編輯結論
如果你要的是可重跑、可拆解的 deep research 軌跡合成配方，OpenResearcher 值得先讀它的資料集格式與評測框架，再決定要不要動 30B-A3B 模型。若你只需要一個能回答問題的研究助理，這個專案的成本結構不對：你得先備好 ~11B-token 語料與本地檢索，GAIA 那條路雖然可以用 Serper API 省掉本地搜尋，但那就脫離了它省錢的設計前提。動手前先確認三件事：repo 內 LICENSE 檔的實際條款、BrowseComp-Plus 的 54.8% 是在哪個檢索設定下量出來的、以及 96K 軌跡的授權是否允許你的商用情境。
社群筆記