Orca 七個月拿下 10 萬顆星：我拆了它的 GitHub 數據，看到 agent 開發真正的瓶頸

先講我為什麼在意這個工具

今年我自己手刻過一套「讓一群 agent 同時幹活」的系統：15 個 Claude Code agent 跑 QA pipeline，用 launchd 在一台 Mac 上排兩個班，拿 Linear 當工作佇列，兩週合併了 17 個 PR。

那套東西能動，但每一塊都是膠水：bash、plist、自己寫的 CLI。所以當我看到 Orca 把「同時管很多個 agent」整個做成產品，而且七個月就在 GitHub 拿下將近 10 萬顆星，第一個反應不是「好酷」，而是「它把我手刻的哪些東西做掉了？又有哪些是它也解不了的？」

先說清楚：這篇不是使用心得。 我沒有長期用 Orca 做正式工作。這篇是把它公開的 GitHub 數據拉出來（截至 2026-10-21），配上我自己做過 agent pipeline 的經驗，看看這個專案透露了什麼。

---

Orca 是什麼

Orca 是 Stably AI 做的開源桌面應用，YC 投資，MIT 授權，免費。它管自己叫 ADE（Agent Development Environment），意思是：IDE 是給人寫 code 的環境，ADE 是給 agent 寫 code 的環境。

它本身不是一個 agent。它是一個「讓你同時開很多個 agent」的工作台：

• 每個任務一個 git worktree：同一個 repo 開好幾個獨立的工作目錄，每個 agent 各做各的，不會互相改到對方的檔案。同一個提示可以丟給好幾個 agent，再挑最好的結果合併
• 支援 27 種 CLI agent：Claude Code、Codex、Cursor CLI、Gemini、Copilot、OpenCode 等等。用你自己的訂閱，Orca 不經手模型費用
• 內建終端機、編輯器、瀏覽器：終端機用 WebGL 渲染，可以無限分割；每個 worktree 有一個內嵌的 Chromium，在 Design Mode 下點一下畫面上的元素，就能把 HTML、CSS 和截圖丟給 agent
• GitHub 和 Linear 整合：在 app 裡看 PR、審 PR、開 Linear issue
• SSH 遠端 worktree：agent 可以跑在別台機器上
• 手機 app：離開座位也能看 agent 跑到哪、切換帳號、操作終端機
• Orca CLI：反過來讓 agent 也能操作 Orca，例如自己開新的 worktree

技術上是很標準的組合：Electron、React、xterm.js、node-pty、Monaco 編輯器、ssh2。沒有什麼黑科技，價值在於把這些東西組在一起，而且組得夠快。

---

數字

指標	數字
建立日期	2026-03-17
GitHub stars	99,359
Forks	6,320
過去 52 週 commits	19,299
Release 次數	979（桌面 940、手機 39）
貢獻者	497
PR 總數	22,386（已合併 14,303）
目前開著的 PR	4,243
Issue 總數	8,543（還開著 4,358）

每週 commit 數的變化：

期間	每週 commits
3 月底（剛開源）	128
4 月	250 到 405
5 月	411 到 1,389
6 月到 9 月	大約 340 到 820
10 月	1,167、1,499

Release 的節奏也很誇張。4 月到 7 月，每個月 180 到 230 次 release，平均一天六、七次，大多是 -rc 測試版。8 月之後幾乎只發正式版，每月降到 10 到 50 次。版本號從 v1.0.12 一路跑到 v1.4.232。

---

判讀一：這是一個 agent 寫出來的 agent 工具

貢獻者有 497 人，但 commit 非常集中：

帳號	commits
nwparker	5,889
brennanb2025	2,528
Jinwoo-H	2,297
AmethystLiang	2,166
orca-ide	1,942
OrcaWin	1,092

前四個人加起來超過 12,000 個 commit。換算一下，nwparker 這個帳號七個月平均每天大約 27 個 commit。

我抽了最近的 100 個 commit 來看：這 100 個 commit 發生在大約 13 個小時內，至少 38 個在訊息裡標了 Co-Authored-By: Claude，提到 Claude 或 Codex 的有 66 個。

這個速度不是人類手打出來的。Orca 自己就是「一個人帶一群 agent 寫 code」最好的展示：少數幾個工程師，每天幾十個 commit，每週上千個。

這也是它能七個月做出 27 種 agent 支援、手機 app、SSH 遠端、Design Mode 的原因。功能清單長，不是因為團隊大，是因為產出的方式變了。

---

判讀二：瓶頸已經從「寫 code」變成「消化 code」

但另一組數字更值得看：

• 目前開著的 PR：4,243 個
• 其中建立超過一個月、到現在還開著的：2,525 個
• 10 月前 20 天：新開 4,923 個 PR，合併 3,057 個。等於每天大約有 90 個 PR 沒被合併，繼續往上堆
• Issue 還開著的有 4,358 個，我抽看的 open issue，大多連一則留言都沒有

產出的速度已經遠遠超過消化的速度。寫 code 變便宜了，但看 code、決定要不要收、回應使用者，還是要人。

這跟我自己的經驗完全一樣。我的 QA pipeline 兩週開了 17 個 PR，我每一個都看得完，所以覺得很順。但我很清楚，那是因為量小。如果 agent 一天開 90 個 PR，我會變成整條 pipeline 裡最慢的那一環。

這也是我在〈Test-driven 是錯的〉裡把 spec 當成唯一標準的原因：agent 產出越多，你越需要一個不用人逐行看也能判斷對錯的東西。沒有這個，review 就是天花板。

所以我看 Orca 的 99,359 顆星，不會覺得是「產品很健康」的證據。星數代表很多人有這個需求；2,525 個放了一個月的 PR，才代表這個需求的難處在哪。

---

判讀三：Orca 做掉了什麼，沒做掉什麼

拿我手刻的那套來對照：

需求	我手刻的做法	Orca
讓多個 agent 不互相干擾	分班次，一次只跑一條線	✅ 每個任務一個 worktree，可以真的平行
工作佇列	自己寫 Linear CLI，17 個子命令	✅ 內建 GitHub、Linear 整合
看 agent 跑到哪	看 log、等通知	✅ 桌面加手機 app
換 agent、換帳號	改腳本	✅ 27 種 agent，帳號一鍵切換，顯示用量
跑在別台機器	沒做	✅ SSH 遠端 worktree
agent 跨 session 累積經驗	learned-patterns，讓 agent 教 agent	⚠️ 有 skills 和 hooks 可以接，但要累積什麼得自己設計
判斷產出對不對	spec 當唯一標準	❌ 不是它要解的問題
決定要不要合併	我自己看	⚠️ 讓你看得比較快，但還是你看

結論很清楚：Orca 把「調度」做成了產品，但「判斷」還在你身上。

它讓你從同時管 1 個 agent 變成同時管 10 個，這很有價值；但 10 個 agent 的產出要變成能上線的東西，中間那段「這個對不對、要不要收」的工作，它幫不了你，而且 agent 越多，這段越重。Orca 自己的 PR 數字就是證明。

---

誰該用

• 同時跑 3 個以上 agent 的人：值得裝。光是 worktree 隔離和一個畫面看全部，就能省掉很多手動切換
• 只用一個 agent 的人：直接用 Claude Code 或 Codex 就夠了，多一層 Electron 不一定划算
• 想在手機上盯 agent 的人：這是目前少數做得比較完整的
• 企業：MIT 授權、程式碼都看得到，導入風險低；但要有心理準備，它的更新速度很快，4,000 多個 open issue 也代表你遇到的問題不一定很快有人回

---

判讀紀錄

照判讀紀錄的規則，押兩題，到期回來對答案：

判讀 A：到 2027-04-30 前，Orca 會推出公開標價的付費方案（個人或團隊方案，不只是「聯絡業務」的企業版）。 信心：65% 理由：YC 投資的公司，產品免費又是 MIT 授權，官網已經有 Enterprise 頁面。用戶規模到這裡，下一步就是收錢，問題只是收什麼：雲端 runtime、團隊協作，或是企業的權限與稽核。

判讀 B：到 2027-04-30 前，Orca 的 open PR 會降到 2,000 個以下（2026-10-21 是 4,243 個）。 信心：35% 理由：要做到，他們得先解決自己的「消化」瓶頸，例如用 agent 自動分類、自動關掉重複或過時的 PR。如果他們做到了，那個方法本身大概會變成 Orca 的下一個功能，也是這篇最想看到的答案。

對答案：2027-05。

---

數據來源：GitHub API（stablyai/orca，2026-10-21 抓取）、Orca 官網 orca.dev。commit 是否由 agent 協作，只根據 commit 訊息裡的標記判斷，沒標的不算，所以實際比例只會更高。