Anthropic 每天合併 3 萬筆變更後換掉 Git：自建版本控制系統 Scion，七人五個月完成遷移，CI 取出程式碼從數分鐘縮到數秒

趨勢新聞2026 年 10 月 18 日

Anthropic 10 月 13 日在工程部落格發表〈重新設計 Anthropic 的原始碼控管〉，說公司每天合併進單一大型程式庫（monorepo）的變更，從 2026 年 5 月平均約 2,500 筆增加到 9 月超過 3 萬筆，版本控制成了開發最大的瓶頸。Anthropic 為此自建版本控制系統 Scion，用五個月把程式庫完全遷離 Git。新系統的 CPU 與記憶體需求，是原本 Git 鏡像基礎設施的兩百分之一；CI 與研究工作取出程式碼的速度快了兩個數量級，從數分鐘降到數秒，光是 CI 就省下 25% 的 CPU 容量。

文章給的規模數字：主分支歷史將近 100 GB，壓縮後的工作副本超過 25 GB；光是 CI 每天就要取出程式碼約 2,500 萬次，還不算開發環境、代理人沙箱與研究工作，若照一般方式抓，每天會產生超過 600 PB 的 Git 流量。Anthropic 用過淺層複製、稀疏取出、內部 Git 鏡像、存在物件儲存裡的程式庫快照等做法，高峰時養了數百台內部 Git 鏡像，合併速度一快，這些方法越來越難維運。文章的判斷是，公司實際上把 Git 當成只有一份權威副本的集中式系統在用，而用戶端幾乎都是本來就一直連線的代理人與工作排程，Git 為離線、分散式協作設計的特性反而卡住擴充。

Scion 怎麼做

Scion 假設用戶端永遠在線。查檔案歷史、追溯每一行是誰改的、建立提交、合併、重定基底（rebase），都在伺服器端完成；用戶端只保留有上限的本機快取，按需要抓資料。所有查詢都開放成 API，很多 CI 工作不必在本機放一份程式庫，例如只要差異內容的工作直接向伺服器要。基本單位叫「變更集」，只記錄相對上一個版本改了哪些檔案，再指向物件儲存裡壓縮過的內容；伺服器端資料放在 Spanner 資料庫與雲端儲存。取檔走三層快取：每個節點一個常駐程式、每個區域一組快取伺服器、最後才是權威伺服器，Anthropic 說每一層的快取命中率都在 99% 以上。

團隊七個人，五個月內除了 Scion，還做了程式碼審查工具 Antique、程式碼搜尋與權限系統，期間每天合併的程式量增加了十倍。文章說參與的工程師都認為 Claude 寫程式比自己強，工程師的工作變成在系統設計上做取捨，並且常常對 Claude 說「不」，因為代理人有時會為了套用某個模式而違反系統的核心限制。文章也說，Anthropic 用早期內部版的 Claude Mythos Preview 重寫原本手寫的 Git 轉 Scion 匯入程式，記憶體用量少了 20 倍、速度快 4 倍。

Anthropic 寫明 Scion「絕不適合拿來取代一般用途的 Git」，只對有數萬名工程師、或有大批代理人在寫程式的超大型程式庫才有意義；它和 Git 差異很大，要用就得連程式碼審查、搜尋、CI 一起換掉，Anthropic 說很難做成對其他組織有用的形式，也擔心一個想討好所有人的公開版本不會真的好用。Anthropic 預估這類問題會在未來 6 到 12 個月變得常見，希望 GitHub、GitLab 與開源社群把伺服器端查詢 API、更好的取檔協定這些做法帶進 Git。文章提到 Google 的 Piper 與 Meta 的 Sapling 是前例，10 月 15 日的更新補充，Scion 用的許多技術最早出自 Sapling 的伺服器端 Mononoke。