剛剛，Anthropic 在工程部落格上發了一篇長文，講他們為什麼、又是怎麼把整個 monorepo 從 git 上遷走的。

原因在於這樣的一組數字：今年 5 月，Anthropic 平均每天合併約 2500 次程式碼變更；到了 9 月，這個數字已經超過了每天 3 萬次。

9 月 9 日這一天，單日合併了 30401 次。

按 24 小時平均下來，差不多每 3 秒就有一次程式碼合進主幹……

而這條曲線的推手，正是 Claude。Anthropic 在文章開頭寫道：

在 Anthropic，寫程式碼已經不再是建構系統和做研究的瓶頸。Claude 能夠自主迭代研究循環、對複雜程序做微觀最佳化、從零建構新服務，速度和規模都是我們前所未見的。現在的瓶頸，是所有那些為人類規模建構的開發者基礎設施：原始碼控制、建構和 CI。

其中的原始碼控制，用的正是 git。

於是 Anthropic 花了五個月，自研了一套版本控制系統 Scion，並把整個 monorepo 從 git 完整遷移了過去。

同一時間段裡，他們還做了程式碼評審工具 Antique、程式碼搜尋、一套細粒度的原始碼權限系統，以及一批管理和合入大量已評審程式碼的新辦法。

做完這些的，一共只有 7 個人。

回到上面那張圖，從 1 月到 4 月，曲線一直在緩慢爬升，從每天幾百次漲到了兩千來次。

從 6 月開始，圖裡藍色的 Pull requests 迅速被橙色的 Antique change requests 取代，到了 7 月幾乎全是橙色，說明程式碼評審那時基本已經整體搬到了自研的 Antique 上。

7 月底、8 月初還有一周明顯的低谷，圖上標的是「Quiet week」，原文沒有多做解釋（大概是全員放假了？）。

而低谷過後，曲線幾乎是垂直往上衝的。

Anthropic 預計這個增速短期內不會放緩，因為合併程式碼的潛在需求幾乎是無限的，每移除一個瓶頸，程式碼產量就會立刻再往上漲一截。

他們也承認，這種負載非常特殊。

Anthropic 用 Claude 寫程式碼的程度幾乎超過任何一家公司，所以常常是第一個撞上「工具開始吃力」的地方，原始碼控制只是其中一個例子。

短期內不會有太多組織遇到同樣的問題，但他們認為，其他用 AI 寫程式碼的團隊用不了多久也會碰上。

git 是一個分佈式系統，每一份 clone 都是一個完整、獨立的倉庫，離線也能算 diff、看歷史和 blame、checkout 任意版本。

對絕大多數倉庫來說，這個設計是對的，也是 git 能成為行業標準的重要原因。

但 Anthropic 的 monorepo 已經越來越不適合這個設計了。僅 main 分支的歷史就接近 100 GB，壓縮後的工作副本超過 25 GB。

光 CI 每天就要 checkout 程式碼約 2500 萬次，這還沒算開發環境、Agent 沙箱和研究任務。

如果每次都老老實實全量拉取，每天的 git 流量會超過 600 PB。

git 本身有 shallow clone、sparse checkout、promisor remote 這些只取倉庫一部分的手段，業內對付大型 monorepo 也有成熟的套路，比如內部 git 鏡像，以及放在 blob 記憶體裡的倉庫快照（seed）。

Anthropic 把這些全都用上了，高峰時營運著幾百台內部 git 鏡像來扛負載。

這些辦法確實爭取到了一些時間，但合併速度越漲，維護起來就越難。

兩次刷新之間，seed 離 main 的最新提交越來越遠；diff、blame 這類依賴歷史的操作，要在 partial clone 上保持正常工作，也越來越費勁。

後來他們退一步看，才發現自己和大多數公司一樣，其實是把 git 當成「只有一份權威副本」的中心化系統在用，而幾乎所有客戶端都是 Agent 和各種任務，天然就是線上的。

git 最擅長的分佈式、離線工作，在倉庫變大之後，反倒成了擴展的阻礙。

那麼問題就變成了：如果從一開始就假設 Agent 永遠線上，原始碼控制應該是什麼樣子呢？

超大 monorepo 的原始碼控制是有先例的，比較有名的是 Google 的 Piper 和 Meta 的 Sapling，Scion 也借鑑了它們用大量踩坑換來的經驗。

在此基礎上，Anthropic 定下了幾條和 git 截然不同的原則。

這幾條原則都從同一個前提出發：客戶端永遠線上。

git 假設客戶端要離線工作，所以每個人手裡都得有一份完整的倉庫；Scion 則圍繞一個始終可達的伺服器端來設計，需要什麼資料，客戶端再去取什麼。

這也就帶來了客戶端和伺服器端的不對稱。

在 git 裡，每個客戶端都有能力當一台完整的伺服器；而在 Scion 裡，查歷史和 blame、建立提交、做 merge 和 rebase，統統由伺服器端完成。

客戶端只維護一個有上限的本地對象快取，把工作副本的檔案放到磁碟上，監聽檔案系統的變化，再給使用者提供一套好用的操作方式。它自己幾乎算不了什麼，換來的是本地需要的資料少得多。

伺服器端既然什麼都能回答，也就可以直接開放成 API。

用 git 的時候，CI 任務或工具想知道「這行程式碼最後是誰改的」「這兩個提交是什麼關係」，要麼自己維護一份本地倉庫，要麼指望託管平台剛好提供了對應的 API。

在 Scion 裡，客戶端用到的所有查詢都以 API 形式開放，很多任務根本不需要本地倉庫。

Anthropic 內部的自動 bisect 和自動 revert 流水線，沒有這種低成本、可程式設計的訪問方式，規模一大就不現實了。

所有元件也都必須能水平擴展。

前面那幾百台 git 鏡像，一旦倉庫大小超過鏡像的磁碟或記憶體上限，就再也擴不動了。

Scion 的倉庫資料是分佈式記憶體的，每個元件都能獨立擴展，任何地方都不存在一份完整的倉庫，伺服器端上也沒有。

Scion 裡也沒有 packfile 這類東西，所以不需要做倉庫維護。

git 是先在本地 commit 再 push；Scion 的每次 commit、rebase、merge 都發生在伺服器端，沒有什麼需要 push 的，但每個操作都必須夠快。

建立一個提交、更新它下游資料結構的開銷，必須跟改動的大小成正比，而跟整個倉庫的大小無關，否則伺服器端就跟不上。

也因此，Scion 的開發流程不鼓勵使用 ref（main 和發佈分支除外），因為需要所有伺服器達成一致的全域狀態，遲早會成為擴展上的隱患。

最後，工作副本是可選的，而且天生稀疏。

每天幾千萬次 checkout，能省則省：CI 想要某個提交和它 merge base 之間的 diff，直接問伺服器端就行，很多寫操作也可以跳過 checkout，全程走 API。

真需要把檔案放到磁碟上時，Scion 的協議以 sparse checkout 和虛擬化 checkout 為核心，前者只包含客戶端要的目錄，後者在檔案被讀到時才落盤，客戶端只為它真正讀到的內容付出成本。

Scion 裡的基本單位叫 changeset，是預寫日誌裡的一條記錄，存的東西和 git 的 commit 大體相同。

只不過 git commit 存的是指向整棵樹的指針，而 changeset 存的則是相對於第一個父提交改了那些檔案，以及指向 blob 記憶體中壓縮檔案內容的內容定址指針。changeset 在伺服器端建立，建立好之後立刻處處可用。

（示例裡這條 changeset 的 author 一欄，寫的正是 Claude……）

沒有 packfile 要接收，沒有鎖和跨伺服器協調，也沒有 ref 要移動，所以 Scion 接收 changeset 的吞吐量可以做得非常高。

Scion 技術上也支援 ref，但建立和獲取提交都不涉及 ref。

移動一個 ref，只是對 Spanner 裡的單行資料做一次 compare-and-swap，跟建立 changeset 是分開進行的。

只記錄改動，也就意味著單靠 changeset 本身，沒法快速回答「這一行最後是誰改的」「那些提交動過這個檔案」這類問題。

為此，Scion 會在 changeset 之上再建構一批資料結構，比如專門用於 blame 和路徑歷史的結構，以及提交圖的跳錶。

凡是不直接屬於 changeset 的，都叫「派生資料」，統一由一套通用機制來計算。

每種派生資料都是遞迴定義的，某個 changeset 上的值，由它的父提交上的值算出來。

這樣做有三個好處。想讓某個操作更快，加一種新的派生資料就行；每一種都可以選擇立即計算還是推遲計算，不需要的資料就不去物化；而客戶端看不到這些資料結構的內部，最佳化它們也不用改客戶端。

隨著系統增長，他們已經加過很多次新類型，比如用來做複製檢測、按路徑搜尋檔案的新索引。

一小組 Scion 伺服器對外提供客戶端需要的所有原始碼控制 API，比如獲取 changeset、計算 diff、尋找 merge base、獲取 blob。

所有資料都是內容定址的，存進去就不會再變，任何一台伺服器都能快取，不用和其他伺服器核對。

所以這些伺服器可以水平擴展，幾乎不需要協調，說到底就是一組大快取，同時還能現場計算派生資料，再寫回 Spanner。

遷移早期，在還沒有自己的客戶端、倉庫格式和協議的時候，Scion 只回答提交祖先關係、blame 這類「中繼資料」查詢，這已經幫 CI 和各種工具省掉了自己拉取、維護倉庫的大量負擔。

而獲取檔案內容、生成工作副本，資料量要大得多，需要單獨設計。

Scion 的客戶端叫 scn，它的拉取協議和 git 有幾處關鍵的不同，伺服器端因此比 git 伺服器省下了大量 CPU。

git 協商時，客戶端要告訴伺服器端自己已經有了什麼；scn 則只說自己要什麼。

它從根樹開始，檢查本地缺了那些 tree 並遞迴請求，再對 blob 重複一遍。

每個請求都對應一個永遠不會變的具體對象，任何一層快取都能應答，整個架構和傳統的分層快取非常相似。

沒有動輒幾個 GB 的單個 packfile 響應，過程高效，也能斷點續傳。sparse 乃至虛擬化 checkout 也不需要特殊支援，客戶端不請求它不要的樹就行了。

在叢集裡，客戶端通過 socket 和一個叫 scion-daemon 的守護處理程序通訊，由它為整個節點記憶體對象，畢竟同一節點上的任務大多會復用相同的對象。

每個 daemon 從一份定期刷新的快照啟動，之後只和所在區域的快取伺服器 scion-cache 通訊。

scion-cache 直接從記憶體裡以 daemon 可以直接使用的磁碟格式流式傳送對象，不用計算客戶端缺什麼，也不用做 delta 壓縮。

快取裡缺了某個對象，才去問權威的 scion-server，後者再按需讀取 Spanner 或雲端記憶體。

三層都響應同一套 RPC，客戶端不需要知道快取的拓撲結構。

理論上任意兩層都能直接通訊，但他們嚴格執行分層，用來隔離故障域，避免某個區域的 scion-cache 出了故障，把上游的 scion-server 沖垮，進而拖垮整個系統。

最終，每一層的快取命中率都在 99% 以上，而且不需要長期保存狀態，擴容很容易。

Scion 基礎設施的 CPU 和記憶體佔用，只有之前 git 鏡像方案的 1/200。

CI 和研究任務的 checkout 快了兩個數量級，從分鐘級變成了秒級，整個叢集因此空出了一大塊算力，光 CI 就拿回了 25% 的 CPU 容量。

客戶端和快取都不需要做倉庫維護，任務的生命周期管理也簡單了不少。

落到日常命令上，對比是這樣的：

開發環境裡，status 從 3.9 秒降到 19 毫秒，快了 207 倍，拉取最新程式碼則從 87 秒降到 3.5 秒（開發機上的 commit 倒是沒怎麼變，1.4 秒到 1.1 秒……）。

Agent 環境裡，新建一個 worktree 從 7.1 分鐘降到了 5.1 秒。

彙整鉅亨號中所有使用「Scion系統」關鍵字，所發布的內容 (依照時間排序，最新在前，舊的在後)`

剛剛，Anthropic 重新發明了 git