Anthropic 的 Scion 版本控制系統：每天超過 3 萬次合併，但無法下載安裝

重點先看： Anthropic 介紹 Scion 的工程文章指出，每日合併次數從 5 月約 2,500 次增加到 2026 年 9 月超過 3 萬次，文中另外也提到 10 倍成長。Scion 是內部系統，無法下載或安裝。

合併速率和下載頁不是同一個東西。Anthropic 的工程文〈Redesigning source control at Anthropic〉寫，2026 年 5 月平均每天合併大約 2,500 筆程式變更，到 9 月每天超過 30,000 筆。同一篇後段又寫，七個人在五個月裡把 monorepo 遷完，這段期間每天合併量增加了 10 倍。2,500 乘 10 是 25,000。超過 30,000 不是 25,000。工具頁若只印一個倍數，已經改過原文。

這個站寫過本機模型旗標，不是離線模式。/model 找得到 Ollama，離線不是它。也寫過安裝只有兩行，第二個系統不是第二步。OpenShell 的安裝不是 Sentry。也寫過知識 API 要先搜片段，不要先倒全文。先搜片段。Scion 是同一種錯法：實驗室做了一套版本控制，公開了規模，沒有公開可安裝的東西。

2,500 和 30,000 是圖。10 倍是後段那句。

5 月和 9 月的數字在工程文開頭。2026 年 5 月每天大約 2,500 筆。截至 9 月，每天超過 30,000 筆。Anthropic 寫，不預期這成長會慢下來。合併程式碼的潛在需求「實際上無限」，每拿掉一個瓶頸，產出的程式碼就再增加，不是停在高原。Simon Willison 10 月 13 日的連結文引了這段。他沒有加第三個速率。轉述若寫「大約 12 倍」，那個 12 是轉述者除的。原文沒印 12。

10 倍在後面的教訓段。七個人做了 Scion 和程式碼審查工具 Antique，再加上大約半打相關系統，五個月內完成遷移，「同時每天合併的程式碼量增加了 10 倍」。那個「同時」綁的是五個月的建造期，不是一張標好 5 月對 9 月的比率。10 乘 2,500 是 25,000。9 月的數字是超過 30,000。若 10 倍的窗口不是 5 月對 9 月，或 10 倍是約數、超過 30,000 是圖上的讀數，兩句可以同時成立。它們不能當成一個等式。投影片寫「10 倍，從 2,500 到 30,000」，是把兩句黏成一個假等式。

能用的是水位，不是口號。一天大約 3 萬筆合併的 monorepo，已經不適合「複製一份就能離線」的假設。那是同一篇的下一段。

他們說 git 不再適合的，是尺寸，不是語氣。

Anthropic 沒有說 git 是錯的。文中寫，git 是分散式的，每個 clone 都是完整倉庫，可以離線做 diff、讀歷史、blame、檢出任何版本。對絕大多數倉庫，這是對的設計，也是 git 成為標準的一大部分。斷掉的是他們的 monorepo。主分支歷史將近 100 GB。壓縮後的工作複本超過 25 GB。光是 CI，每天檢出大約 2,500 萬次，這還沒算開發環境、agent sandbox 和研究工作。若天真地每次都整份抓，一天會超過 600 PB 的 git 流量。

這四個數字是一個論證。100 GB 是歷史。25 GB 是工作複本。2,500 萬是檢出次數，而且只算 CI。600 PB 是天真算法的乘積，不是他們說已經付過的帳單。原文說的是 naive fetch 會變成那樣。容量計畫把 600 PB 當成實測流量，就刪掉了 naively 那個詞。

The New Stack 10 月 15 日的報導轉述同一類說法：寫程式不再是瓶頸，瓶頸是為人類規模做的開發基礎設施，包括版本控制、建置和 CI。那是 TNS 呈現的 Anthropic 句子，不是對另一家實驗室的基準。Simon 猜測 Fable 和 Mythos 級模型推高了那張圖。那是他的猜測。猜測不進事實表。

若你是 Anthropic，Scion 改了什麼。

文中點名先例：Google 的 Piper，Meta 的 Sapling。Scion 不是被寫成第一套集中式 monorepo 系統。能拿來評的是他們列的原則。

客戶端永遠在線。git 假設客戶端可以帶完整副本離線工作。Scion 假設伺服器一直可達，因為他們幾乎所有客戶端都是 agent 和工作，需要時才抓資料。Simon 記了 Hacker News 上 Scion 工程師 Nick G 的回覆。Nick G 也是工程文的署名。他說離線支援不值得做，因為 Claude 是遠遠最重的使用者，而且必然在線。工程文的原則和 HN 回覆方向相同。文本不同。一個是給 agent 和工作的設計規則。另一個是人在說，最重的使用者反正不能離線。

提交在伺服器上。git 是本機提交再 push。Scion 的每次 commit、rebase、merge 都在伺服器發生，所以沒有東西要 push，但每一次都得快。建立一次 commit 的成本必須跟著變更的大小走，不能跟著整個倉庫的大小走。文中還說，開發流程不鼓勵 refs，也就是每個伺服器都得同意的分支和標籤指標，主 ref 或發行分支除外。全域一致是他們拒絕的那個擴展問題。

客戶端叫 scn。它不告訴伺服器客戶端已經有什麼。從根 tree 開始，要缺少的 tree，再要 blob。每個請求都是一個不會變的物件，所以快取可以回答。沒有單一的、數 GB 的 packfile。文中說每一層快取命中率超過 99%，而且不需要長生命週期的狀態。基礎設施的 CPU 和記憶體足跡，現在比先前的 git 鏡像小 200 倍。CI 和研究工作的檢出快了兩個數量級，原文括註是秒，不是分鐘。光是 CI，CPU 容量就多出 25%。

200 倍、兩個數量級、25%，是三種量。200 倍是足跡對上舊鏡像機群。兩個數量級是檢出時間。25% 是 CI 的 CPU 容量，不是全公司，也不是檢出快 25%。廠商投影片寫「快 200 倍、便宜 25%」，名詞換過了。TNS 重複了 200 倍足跡和兩個數量級的檢出。25% 留在工程文上。

不能裝。兩頁的拒絕不是同一句。

工具評測的結論是拒絕。工程文說，實務上很難把 Scion 做成對其他組織廣泛有用的形式。它和 git 差很多，公司得遷移整個開發生命週期。它需要自己的程式碼審查、程式碼搜尋和 CI。Anthropic 內部這些元件高度特製。他們擔心，一個想討好所有人的公開版本不會真的有用。他們願意給的比較窄：agent 開發怎麼撞上這些系統的早期看法，以及想跟 GitHub、GitLab 和開源社群合作。

TNS 10 月 15 日那篇更硬。它寫 Anthropic 沒有計畫發布 Scion，也不會在短期內做公開版本，系統太專門，其他碰到同一面牆的公司得到的是啟發，不是倉庫。它也寫 Anthropic 想跟 GitHub、GitLab 和開源社群合作，這句和工程文的合作句對得上。「短期內沒有計畫」是 TNS 的用詞。「困難」和「不會很有用」是工程文的用詞。

Simon 說 Scion 聽起來像沿著 Subversion 那條線重做集中式版本控制。那是他的比較。工程文引的是 Piper 和 Sapling，不是 Subversion。評設計，用他們點名的先例。評這個季度能不能 vendor 進來，兩頁的實務答案一致。不能。

倉庫只是大，不是這個尺寸，怎麼辦。

大多數倉庫仍在 Anthropic 說的「絕大多數」裡，完整 clone 是對的設計。2 GB 的倉庫和一次慢 CI 抓取，不是 100 GB 歷史加一天 2,500 萬次 CI 檢出。把 Scion 的結論抄到普通 monorepo 上，是這篇文會被誤用的方式。證明他們設計的數字印在文裡。你沒有那個量級的數字，這篇是對 agent 規模檢出的警告，不是遷移令。

若你確實有 agent sandbox 整天在檢出同一棵樹，能搬走的不是 scn 二進位。是診斷。一次檢出把完整歷史送給只需要一棵 tree 的客戶端，就是那個天真的 600 PB 形狀，只是你的尺寸比較小。sparse checkout、不含 blob 的 clone、或不要每次重抓全世界的 CI 快取，是 git 的功能。它們不是 Scion。文中自己的檢出故事是依 id 要物件、不要一份倉庫那麼大的 packfile。他們說想讓 git 託管方吸收的是這個想法。在 GitHub 或 GitLab 放出你可以指一個 remote 的東西之前，要做的是量自己的檢出次數和工作複本大小，並且別把一天 3 萬筆合併的部落格文當成套件名。

10 月的頁面給了速率、尺寸、足跡，和一次拒絕。評測是：Scion 是一套印了規模的內部系統，這週不能寫進 Dockerfile。

對讀者的意義

對大多數團隊來說，重點不是換掉 git，而是留意同樣的壓力點：合併佇列的處理量、儲存庫大小，以及 CI 負載。面對大型儲存庫，標準的 git 擴充手段仍是應該先嘗試的工具。