重點
- Anthropic 的 monorepo 在 2026 年 5 月平均每天合併約 2,500 次變更，9 月超過每天 30,000 次。大部分程式碼由 Claude 撰寫，版本控制、建置與 CI 成了開發瓶頸。
- 一個七人團隊用五個月做出自家版本控制系統 Scion、code review 工具 Antique 等周邊系統，並把整個 monorepo 從 git 遷移過去。
- Scion 的前提是客戶端幾乎都是隨時在線的 agent 與 job：歷史、blame、commit、merge、rebase 都在伺服器端做，客戶端只保留有上限的物件快取，工作副本可以是稀疏或虛擬化的。
- 跟過去的 git mirror 架構相比，基礎設施的 CPU 與記憶體用量小 200 倍，CI 與研究 job 的 checkout 從幾分鐘縮到幾秒，CI 光這一項就省下 25% 的 CPU 容量。
- Anthropic 明說 Scion 不適合拿來取代一般的 git，也不打算做成通用產品，希望把有效的部分帶回 git 生態系。
問題有多大
Anthropic 工程部落格在 10 月 13 日（美國時間）發表這篇文章，作者是 Nick G. 與 source control 團隊。文章開頭的判斷是：寫程式已經不是瓶頸，Claude 能自己跑研究迴圈、做程式微最佳化、從零建服務，卡住的是為人類規模設計的開發基礎設施。
合併量的變化：
| 時間 | 每天合併到 monorepo 的變更 |
|---|---|
| 2026 年 5 月 | 約 2,500 次 |
| 2026 年 9 月 | 超過 30,000 次 |
作者認為合併需求幾乎沒有上限，每拿掉一個瓶頸，產出的程式碼量就會再往上跳。
repo 本身的規模：
- 主線（main）歷史將近 100 GB
- 壓縮後的工作副本超過 25 GB
- CI 每天約 2,500 萬次 checkout，還沒算開發環境、agent sandbox 與研究 job
- 照一般方式抓取，每天會產生超過 600 PB 的 git 流量
git 的擴充手段為什麼不夠
git 是分散式設計，每份 clone 都是完整的 repo，離線也能算 diff、看歷史、跑 blame、切換任何版本。對絕大多數 repo 來說這是對的設計。
大型 monorepo 常用的補救方法，Anthropic 都用過：
- shallow clone、sparse checkout、promisor remote
- 內部 git mirror：高峰時跑了幾百台
- 存放在 blob storage 的 repo 快照（seed）
合併速度上升後，這些方法越來越難維運。seed 每次刷新之間離 main 的最新版本越來越遠；在 partial clone 上要讓 diff、blame 這類依賴歷史的操作維持正常，也需要越來越多心力。mirror 最後碰到磁碟與記憶體上限，無法再擴充。
團隊注意到，他們實際上把 git 當成集中式系統在用，只有一份權威副本，客戶端又幾乎都是本來就在線的 agent 與 job。git 適合離線分散工作的特性，反而妨礙了擴充。於是他們問：如果從一開始就假設 agent 永遠在線，版本控制該長什麼樣子？
六條設計原則
大型 monorepo 的版本控制有前例，例如 Google 的 Piper 與 Meta 的 Sapling，Scion 參考了它們的經驗。文章列出的原則：
- 客戶端永遠在線：協定圍繞一台隨時連得到的伺服器設計，客戶端需要什麼資料再去抓。
- 客戶端與伺服器不對稱：檔案歷史、blame、建立 commit、merge、rebase 都由伺服器做。客戶端維護有上限的本地物件快取、把檔案放到磁碟上、監看檔案系統變化，自己能算的東西很少，相對地只需要很少的本地資料。
- 完整的版本控制服務 API：客戶端用到的查詢都開放成 API，例如「這行最後是誰改的」「兩個 commit 是什麼關係」。很多 CI job 不需要本地 repo；自動 bisect、自動 revert 這類內部工具，沒有便宜的程式化存取就無法大規模運作。
- 所有元件都能水平擴充：資料分散存放，各元件獨立擴充，連伺服器上都沒有一份完整展開的 repo。沒有 packfile，所以也不需要 repo 維護作業。
- commit 要便宜、增量、無鎖：每次 commit、rebase、merge 都在伺服器上發生，沒有 push 這一步。建立 commit 與更新下游資料結構的成本要跟變更大小成比例，跟整個 repo 的大小無關。除了 main 與 release branch，盡量不用 ref，因為所有伺服器都得同意的全域狀態遲早會變成擴充問題。
- 工作副本可有可無，而且預設稀疏：CI job 要某個 commit 跟 merge base 的 diff，可以直接問伺服器；很多寫入也能完全透過 API 完成。真的要在磁碟上放檔案時，協定以 sparse checkout（只放要求的目錄）與 virtualized checkout（讀到才展開檔案）為核心。
資料結構：changeset 與 derived data
Scion 的基本單位是 changeset，也就是 write-ahead log 裡的一筆紀錄。它跟 git commit 的差別在於存什麼：
| git commit | Scion changeset | |
|---|---|---|
| 內容 | 指向整棵 tree 的指標 | 相對於第一個 parent 有變動的檔案清單，加上指向 blob storage 中壓縮檔案內容的 content-addressed 指標 |
| 建立位置 | 本地，之後 push | 伺服器端，建立後各處立即可用 |
只記錄第一個 parent 的變動是刻意的選擇。文章的註腳說，在 trunk-based 開發的 monorepo 裡，大家只關心主線上 commit 的歷史與 blame。
這個結構讓伺服器能以很高的吞吐量接收 changeset：沒有 packfile 要收、不需要鎖或跨伺服器協調、也不用移動 ref。Scion 技術上支援 ref，但建立與抓取 commit 都用不到它；移動一個 ref 是對 Spanner 單一資料列做 compare-and-swap，跟建立 changeset 分開進行。
changeset 只記錄變動，沒辦法直接回答「誰最後改了這行」「哪些 commit 動過這個檔案」。Scion 另外從 changeset 建出 file blame、path history 等資料結構，以及 commit graph 的 skip list，統稱 derived data。所有 derived data 都走同一種機制：每種資料遞迴定義，某個 changeset 的值由它的 parent 的值算出來。
這個機制的好處：
- 要讓某個操作變快時，加一種新的 derived data 很容易。之後陸續加過 copy detection、依路徑搜尋檔案的索引。
- 每一種都可以選擇事先計算或延後計算，不用展開用不到的資料。
- 客戶端看不到這些內部結構，最佳化時不必改客戶端。
Checkout：只要缺的物件
一小群 Scion server 提供客戶端需要的 API：取得 changeset、算 diff、找 merge base、抓 blob。所有資料都是 content-addressed，存進去之後就不會變，任何伺服器都能直接快取，不必跟其他伺服器確認。伺服器因此可以水平擴充，本質上是會即時計算 derived data、再把結果寫回 Spanner 的大型快取。
遷移初期還沒有自己的客戶端與協定時，Scion 只回答 metadata 查詢（ancestry、blame 等）。抓檔案內容、展開工作副本的資料量大得多，另外設計了 scn 客戶端與協定。
跟 git fetch 協定的差異：
- git 的協商（negotiation）要告訴伺服器客戶端已經有什麼，由伺服器算出缺的部分。
scn只要求它想要的 tree 與 blob：從 root tree 開始檢查本地缺哪些 tree，遞迴請求，再對 blob 做同樣的事。 - 每個請求都指向一個不會變的特定物件，任何一層快取都能回答，架構跟傳統的分層快取很像。
- 沒有單一個好幾 GB 的 packfile 回應，傳輸可以中斷後接續。
- sparse 與 virtualized checkout 不需要特別支援，不想要的 tree 不去要就好。
分層架構：
- scion-daemon：每台節點一個，客戶端經 socket 跟它溝通。同一台節點上的 job 大多共用相同物件。daemon 從定期刷新的快照起步。
- scion-cache：每個區域的 tree 與 blob 快取伺服器。直接從記憶體串流 daemon 能直接使用的磁碟格式，不用計算缺漏物件或做 delta 壓縮。
- scion-server：快取沒有的物件才往這層要，再從 Spanner 或雲端儲存讀取。
三層回應同一組 RPC，客戶端不需要知道快取拓撲。理論上任何一層都能跟任何一層溝通，但團隊嚴格規定只能逐層往上，用來隔離故障範圍，避免一個區域的 scion-cache 故障時把上游 scion-server 壓垮、拖垮整個系統。
實測效益
- 每一層快取的命中率都超過 99%，而且不需要長期保存的狀態，要擴充很容易。
- 基礎設施的 CPU 與記憶體需求比過去的 git mirror 架構小 200 倍。
- CI 與研究 job 的 checkout 快兩個數量級，從幾分鐘變成幾秒。
- CI 一項就省下 25% 的 CPU 容量。
- 客戶端與快取都不需要做 repo 維護，job 的生命週期管理比較單純。
開發過程的經驗
Scion 開工的時間，跟 Claude Mythos Preview、Claude Tag 在內部開放的時間差不多。文章說這兩者同時放大了對 Scion 的需求，也加快了開發速度。
模型重寫既有元件。 git 到 Scion 的資料匯入管線，第一版是團隊年初手寫的原型。拿到 Claude Mythos Preview 的早期內部快照後，他們請它整個重寫，沒有給其他指示。新版本記憶體用量少 20 倍、速度快 4 倍，而且保留了匯入順序與資料結構相關的隱含不變量。
小團隊、短時程。 七個人在五個月內做出 Scion、Antique，以及大約六個相關系統，同時期每天的合併量成長了 10 倍。作者認為這類工作過去需要多年的漸進遷移與多得多的工程師。
工程師的工作內容改變。 參與的工程師都認為 Claude 寫程式比自己好，但系統間的整體結構、設計取捨與規模目標仍由工程師決定。文章說工程師很多時候是在對 Claude 說「不」：
- agent 有時會為了配合一個本來就不該允許的模式，違反核心系統限制。遷移期間有好幾個系統想靠線性讀取 commit log，找出某個變更何時合併到 main，正確做法是去問 code review 工具。
- Anthropic 大量使用對抗式審查，效果很好，但視野可能太窄。有一次審查對信任另一個內部服務過度防衛，Claude 因此加了過多驗證與複雜度，需要工程師拉回來。
- 團隊仍審查每一個變更請求，重點放在變更的意圖，不再逐行閱讀程式碼。
測試與防護。 因為 Claude 產出程式碼的速度快，即使時程很緊，團隊仍為每一種遇過的非平凡基礎設施與版本控制互動建了 hermetic simulation，另外有 fuzzing 與細緻的 rate limiting。Claude 也找到過 ancestry 查詢的演算法最佳化，起因是查詢漏用了一個索引。
權限控管。 Scion 支援 repo 層級的存取控制，也能對個別目錄設權限，保護最敏感的程式碼又保留 monorepo 的好處。Antique 能表達複雜的核准條件，例如區分只改註解的變更與敏感的邏輯變更，讓人類審查者專注在影響最大的變更。
監控。 團隊在 Slack 頻道裡讓 Claude 各自專注監看單一元件，稱為「superfan」，例如 scion-daemon superfan、scion-cache superfan、Antique merge queue superfan。它們能讀遙測與 log，能抓到傳統告警看不出的細微新問題。傳統告警仍然保留。
merge queue 要重想。 測試還在跑的時候，可能已經有幾百甚至幾千個變更合併進去。團隊沒辦法有效複製業界常見的 merge queue 全域 repo 鎖，改投資在合併後與部署前的自動化測試。代價是同時進行的變更可能互相衝突，文章說 Claude 修這些衝突通常比人類發現它們還快。
跟 git 生態系的關係
文章對適用範圍講得很直接：
- Scion 不適合拿來取代一般的 git。這些概念只對極大的 monorepo 有意義，也就是有上萬名工程師，或有大批 agent 大量寫程式的組織。
- Anthropic 內部能花的 token 遠超過一般企業願意花的量，這也是工作負載特殊的原因之一。
- Scion 跟 git 差異很大，採用它等於要遷移整個開發生命週期，還需要配套的 code review、code search 與 CI。這些內部元件高度客製化，Anthropic 認為硬做一個想滿足所有人的公開版本，實際上不會太有用。
作者預估這類問題會在未來 6 到 12 個月變得常見，所以選擇公開設計思路，讓 git 平台在不脫離 git 模型的前提下借用：
- git 伺服器不必跟 git 客戶端用同樣方式運作，已有能大幅擴充的新伺服器架構。
- git 平台可以提供像 Scion 一樣完整的伺服器端 RPC，最好能跨 forge 標準化，讓 git 客戶端學會使用。
- 協商協定可以改，git 現有的 sparse 與 shallow 功能也可以做得更好組合。
文章最後提到想跟 GitHub、GitLab 與開源社群合作。
限制與待觀察
- 所有數字都是 Anthropic 自己的內部量測，沒有公開的基準或可重現的程式碼。200 倍、兩個數量級這類比較的對象，是他們自己原本的 git mirror 架構。
- 合併量從 2,500 到 30,000 的成長，大多來自 Claude 產出的程式碼。其他組織要多久碰到同樣規模，取決於 agent 的使用量。
- 改用合併後測試會讓同時進行的變更互相衝突，文章沒有提供衝突頻率或因此造成的事故數據。
- 「工程師只審意圖、不逐行讀程式碼」是這個團隊的做法。這樣做對長期品質與安全的影響，文章沒有量化。