你電腦裡那個寫程式的 AI，可以直接變成一個會自己跑實驗的研究員。不用把程式碼傳上任何雲端。
一句話結論：OpenResearch 是一個本地優先的研究工作台，把 Claude Code、Codex、OpenCode、Cursor 變成能做文獻回顧、跑實驗的研究 agent。4,137 星、MIT 授權，但它的提示詞層只佔全庫 3％，而且 101 天發了 125 個版本、一份 changelog 都沒有。
以下所有數字都是 2026 年 9 月 17 日我自己打 GitHub API 實查的，不是抄 trending 表格。
OpenResearch 到底是什麼？
它是 alphaXiv 團隊做的一個本地研究工作台。裝好之後跑一行 orx up，瀏覽器開 http://127.0.0.1:4791，你就有一個儀表板，可以把你已經在用的 coding agent 掛上去當研究員。
官方 README 的自我定位是一句話：
The local-first workspace for research agents and autoresearch.（給研究 agent 和自動研究用的本地優先工作台。）
重點在 local-first（本地優先）：專案、對話、實驗、紀錄、程式碼、產出全部留在你自己的機器，資料庫是一個本地 SQLite。建立專案或跑一次實驗，都不會把你的程式碼公開出去。這條路線和我們之前寫過的本地優先 AI agent是同一個方向。
它支援的 agent 有四個：Claude Code、Codex、OpenCode、Cursor。每個 session 可以各自選 harness 和模型。
實查基本資料（2026-09-17）
| 項目 | 實查值 |
|---|---|
| 星數 | 4,137★ |
| Fork / Watch | 261 / 17 |
| 建立日 | 2026-06-07 |
| 最後推送 | 2026-09-16 |
| 主語言 | Rust（68.7％）＋ TypeScript（25.8％） |
| 授權 | MIT |
| 開放 issue | 8 個真 issue ＋ 24 個 PR |
最後一行要特別說：GitHub API 的 open_issues_count 回傳 32，但那個欄位把 PR 一起算進去。我逐筆拆開數，真正的開放 issue 只有 8 個，另外 24 個是 PR。這個倉庫從開站到現在總共只開過 23 個 issue，關掉 15 個。看到「32 個未解 issue」就下結論的話，會判錯這個專案的維護狀況。同一類陷阱我們在星數和真實下載量對不上那篇也踩過一次。
我數完 513 個檔案，提示詞只佔 3％？
對。這是本篇唯一一組中文圈沒有第二份的數據。
我拉了 GitHub 的 Git Trees API，把整個倉庫 513 個檔案的 byte 數逐個抓下來，然後分兩堆：一堆是「提示詞層」（12 個內建 agent-skills 資料夾，加上根目錄的 SKILL.md、SYSTEM_PROMPT.md、AGENTS.md、CLAUDE.md），另一堆是「引擎層」（Rust 原始碼加前端原始碼）。
| 層 | 檔案數 | 體積 | 佔比 |
|---|---|---|---|
| 提示詞層 · agent-skills/ | 29 | 141,006 B | 2.70％ |
| 提示詞層 · 根目錄四個 md | 4 | 16,248 B | 0.31％ |
| 提示詞層合計 | 33 | 157,254 B | 3.01％ |
| 引擎層 · src/*.rs（Rust） | 114 | 3,615,906 B | 69.29％ |
| 引擎層 · ui/src/（前端） | 146 | 1,445,493 B | 27.70％ |
| 引擎層合計 | 260 | 5,061,399 B | 96.99％ |
換句話說：你安裝的東西裡面，97％ 是一個編譯出來的工作台，3％ 才是拿來指揮 AI 的文字。
這個比例本身不是缺點。它是在告訴你這個工具的重心在哪。如果你以為裝的是「一包提示詞」，那你會低估它；它真正做的事情在那 3.6 MB Rust 裡面：git worktree 管理、實驗樹、多後端排程、SQLite 儲存。
同樣叫 Agent Skill，為什麼差了 19 倍？
因為「Agent Skill」這四個字現在指的東西，範圍已經大到沒有共同定義了。
我們昨天才量過另一個極端。Cloudflare 開源的 security-audit skill，我們數完它 22 個檔案發現42％ 根本不是提示詞—— 它 58.2％ 是提示詞 markdown，41.8％ 是驗證器程式碼和測試。那是一個「提示詞為主體、拿程式碼去接住 AI 幻覺」的設計。
OpenResearch 剛好相反：提示詞只有 3.01％。兩邊的提示詞佔比差了 19.3 倍。
| Cloudflare security-audit | OpenResearch | |
|---|---|---|
| 提示詞佔比 | 58.2％ | 3.01％ |
| 非提示詞佔比 | 41.8％ | 96.99％ |
| 非提示詞是什麼 | JS 驗證器 ＋ 測試 ＋ schema | Rust 工作台 ＋ 前端 |
| skill 的角色 | 主體 | 方向盤 |
| 你裝的時候拿到什麼 | 一包會自我檢查的提示詞 | 一個編譯好的程式 ＋ 一包提示詞 |
這件事對讀者的實際意義是：看到「某某開源了一個 skill」的新聞，不要只看星數。先問一句「它的提示詞佔多少」。這個比例決定了三件事：你能不能看懂它、你改不改得動它、它壞掉的時候你 debug 的是文字還是程式。
我們這一個月寫過的同類題材可以排成一條光譜：從190 萬個 Agent Skills 平均只有 6.2 分、Agent Skills 生態盤點、SKILL.md 有兩種數法、跨平台可攜性實測到一次裝 215 個 skill。OpenResearch 是目前量過的最右端。
12 個內建 skill 各自在做什麼？
跑 orx install-skills，它會把這 12 個 skill 裝進你支援的 coding agent。以下是逐個實測的體積：
| skill | 檔案數 | 體積 | 做什麼 |
|---|---|---|---|
| orx-figures | 9 | 80,426 B | 產研究圖表，附 TikZ 範本和繪圖樣式 |
| orx-compute | 10 | 15,698 B | 接 9 種算力後端（SSH／Slurm／K8s／Ray／HF／Modal…） |
| orx-experiment-tree | 1 | 13,246 B | 實驗樹與變體追蹤 |
| orx-lit-review | 1 | 10,692 B | 文獻回顧 |
| orx-paper | 1 | 7,565 B | 讀論文（吃 arXiv ID 或 DOI） |
| orx-agent-delegation | 1 | 2,367 B | 分派子 agent |
| orx-git | 1 | 2,328 B | git 操作 |
| orx-evidence | 1 | 2,196 B | 把證據綁回產生它的那次執行 |
| orx-create | 1 | 2,034 B | 建專案 |
| orx-reports | 1 | 1,977 B | 產報告 |
| orx-customize | 1 | 1,520 B | 自訂 |
| orx-instances | 1 | 957 B | 執行個體管理 |
有兩個地方值得注意。第一，orx-figures 一個人就吃掉整個提示詞層的 57％，畫圖這件事的規格描述遠比想像中長。第二，orx-instances 只有 957 B，大約是一頁紙，這種體積基本上就是一段路由指令。
對投資和研究受眾最直接可用的是 orx-lit-review 和 orx-paper：orx paper <arxiv-id-or-doi> 可以直接餵一篇論文進去，orx discover keyword <query> 做關鍵字探索。讀白皮書、讀研報、同時平行跑幾條研究線，這是它少數對非工程師也成立的用法。
101 天發了 125 個版本，為什麼一份 changelog 都沒有？
這是本篇第二個一手發現，而且我認為它比 3％ 更重要。
我把 releases API 兩頁翻完，逐筆數：
| 指標 | 實測值 |
|---|---|
| 總 release 數 | 125（0 個 prerelease、0 個 draft） |
| 首末版本 | v0.1.1（06-07）→ v0.2.3（09-16） |
| 跨度 | 101 天 |
| 平均節奏 | 1.24 個版本／天 |
| 有發版的日子 | 68 天，佔全期 67％ |
| 逐月 | 6 月 29／7 月 57／8 月 30／9 月 9 |
| main 分支 commit 總數 | 344 |
| 平均幾個 commit 發一版 | 2.75 |
每 2.75 個 commit 就發一個版本。7 月最瘋的時候是每天 1.84 版。
然後是那個洞：125 個 release，沒有任何一份寫了改了什麼。
我逐筆比對 release 的內文，v0.2.0 到 v0.2.3 四個版本的 body 長度一模一樣，都是 2,133 字元；v0.1.120 到 v0.1.122 都是 1,638 字元。全部是 cargo-dist 0.32.0 自動生成的安裝指令和下載表格。搜尋 What's Changed 和 Changelog，兩個字串在最新版的 release 內文裡都是零命中。
這不是隨便亂發。我去讀了 release-on-bump.yml 的註解，他們寫得很清楚：
This never increments a version: the version is always a human decision made in a reviewed PR, and “merge a PR that bumps Cargo.toml” is the release act.（版本號永遠是人在一個被審查過的 PR 裡做的決定，「合併一個把 Cargo.toml 版本推上去的 PR」就是發版這個動作本身。）
所以每一次發版都是有人刻意決定的，但決定完之後，沒有人告訴使用者改了什麼。要知道 v0.2.2 和 v0.2.3 差在哪，你只能自己去讀 commit。
那「可重現實驗」還算不算數？
算，但鎖住的範圍比你以為的窄。
OpenResearch 官方賣點表的第二列寫的是 Reproducible experiments：實驗變體記在 git 原生的實驗樹裡，每次執行都會拿到一份「所記錄那個 commit 的不可變封存」。
這句話是真的，但它鎖住的是你的程式碼 commit。它沒有鎖住兩樣東西：
- 跑這次實驗的那個
orx版本 —— 而這個版本平均每天換 1.24 次。 - 那 141 KB、12 個內建 skill 的內容 —— 它們跟著版本走，換版本就是換提示詞。
結果就是一個很實際的問題：同一個 commit，你六月跑和九月跑，中間隔了一百多個版本和一整輪提示詞改動，出來的東西不一定一樣。而因為沒有 changelog，你連「中間改過什麼」都查不到。
這不是在說這個工具不能用。這是在說，它的可重現性保證需要你自己補上最後一哩：
- 每次記錄實驗的時候，順手把
orx --version的輸出寫進筆記。這是零成本的，而且是目前唯一能還原當時環境的憑據。 - 重要的實驗做完之前，不要跑自動更新。
- 如果一篇研究要寫進正式產出，把當時的 skill 資料夾一起封存 —— 那 141 KB 是你的實驗條件的一部分。
我們在AI 數學證明倉庫實查那篇也遇過類似的狀況：工具本身在動的時候，「同一份程式碼」不等於「同一個結果」。
你的實驗中間漂了幾個版本？
下面這個試算機用我實測的兩個速率算：全期平均 1.24 版／天，以及 2026 年 9 月實測的 0.56 版／天（9 個版本除以 16 天，節奏已經在放慢）。填進你上次跑實驗到現在隔了幾天：
| 以全期均速 1.24 版／天估算 | — |
| 以近期 0.56 版／天（保守）估算 | — |
| 這期間你查得到的 changelog 份數 | — |
| 提示詞層可能已改動 | — |
估算基準：2026-09-17 實查 125 個 release ／ 101 天。實際版本數以官方 releases 頁為準。
這個試算機是外推，不是官方數字。它的用途只有一個：提醒你在筆記裡多寫一行版本號。
怎麼裝？
macOS 或 Linux 三步就跑得起來，Windows 目前還是 beta，而且要先裝 Git for Windows。
- 裝 CLI：終端機跑
curl -LsSf https://openresearch.sh/install.sh | sh。macOS 需要 11 以上。 - 啟動工作台：跑
orx up，瀏覽器會開http://127.0.0.1:4791的本地儀表板。 - 把 skill 裝進你的 agent：跑
orx install-skills，那 12 個 skill 就會進到 Claude Code、Codex、OpenCode 或 Cursor。
想完全離線跑，可以接 LM Studio、oMLX、Ollama 或自訂端點，走 OpenCode 那條路。要評估自己的機器跑不跑得動本地模型，可以看本地模型跑不跑得動那篇。
哪些人現在不該裝？
這一段是我認為在中文介紹裡最常被跳過、但最該寫的部分。六個實查到的問題：
| 問題 | 實查到的狀況 |
|---|---|
| 遠端服務沒有應用層驗證 | README 自己寫明：orx up --remote 的遠端服務綁在 loopback、沒有應用層驗證，同一台主機上的其他使用者可以直接連進來。共用工作站或共用 GPU 機請先想清楚。 |
| 遙測是預設開、不是預設關 | 官方 release build 會送出「可退出」的粗略使用事件，綁一個隨機安裝 ID。要關要自己跑 orx telemetry off。持平講：README 明列不含程式碼、提示詞、檔案內容與路徑、倉庫名、token、email、專案與實驗 ID；原始碼自行編譯的版本則完全不送。 |
| Windows 還是 beta | 官方標示 beta，而且要另外裝 Git for Windows。 |
| Claude Code harness 有已知缺陷 | issue #337（2026-09-14 開，至今未關）回報 /compact、/export、/copy 三個斜線指令會被當成一般訊息送進聊天，而且沒有 /resume，session 兩邊接不回去。 |
| 零 changelog | 125 個 release 沒有一份說明改了什麼，出問題要自己翻 commit。 |
| 三個人寫了 96.8％ | 12 位貢獻者裡，前三名（sox8502 201、myles332 67、rehaanahmad2013 65）合計 333 次，佔 344 次 commit 的 96.8％。這是典型的早期專案結構，人一走節奏就會變。 |
另外提醒一個大家常忽略的點：這個倉庫的 README 掛著 Trendshift「當日第一倉庫」徽章。衝榜和長期可用是兩件事，我們在衝上 GitHub 日榜第一之後寫過一次完整的反例。
常見問題
OpenResearch 要付費嗎？
本體是 MIT 授權的開源軟體，本地跑不用錢。openresearch.sh 的帳號只用在組織功能和託管算力這類服務端能力上，不建帳號一樣能在本地用。真正的成本是模型的 token，它會平行跑多個 agent session，燒得比單線快。
我不會寫程式，用得上嗎？
有限度地用得上。orx paper 讀論文和 orx lit-review 文獻回顧這兩塊，非工程師也能操作，拿來讀白皮書和研報是成立的。但整套安裝走終端機，實驗樹的概念建立在 git worktree 上，完全不碰命令列的話門檻還是偏高。
它和一般的 AI agent 管理工具差在哪？
差在它的核心資料結構是實驗，不是任務。它要解的是「這條研究方向試過什麼、證據在哪、怎麼回溯」，所以重心放在 git 原生的實驗樹和證據綁定上，而不是排程一堆 agent 幫你寫程式。
提示詞只佔 3％，代表它品質比較差嗎？
不代表。比例只說明重心在哪，不說明好壞。提示詞佔比高的工具（例如 Cloudflare 那個 58.2％ 的 skill）容易讀、容易改；佔比低的工具功能更硬，但你能調的旋鈕比較少。兩種設計要解的問題本來就不同。
結論
OpenResearch 是我這段時間量過最「不像 skill 的 skill 專案」—— 97％ 是編譯出來的工作台，3％ 才是提示詞。如果你已經在用 Claude Code 或 Cursor，而且手上有需要平行試好幾條路的研究工作，它值得裝一次試。本地優先這件事它做得是真的，資料不出機器。
但請帶著兩個動作用它：把 orx telemetry off 跑掉（如果你介意），以及每次記實驗的時候順手寫下 orx --version。第二個尤其重要 —— 在一個 101 天發 125 版、零份 changelog 的專案上，版本號就是你唯一的時間戳。
資料來源：alphaXiv/OpenResearch GitHub 倉庫、OpenResearch 官方文件，全部數據為 2026-09-17 經 GitHub API 實查。
本文為工具測評與資訊整理，不構成任何投資建議。開源專案版本更新快速，文中數據為 2026 年 9 月 17 日實查值，實際情況請以官方倉庫為準。安裝任何第三方工具前請自行評估安全性。
發表迴響