一天三萬件合併之後，Git 先撐不住：Anthropic 自建 Scion，改寫的是程式碼的取用方式

2026 年 10 月 16 日，一篇關於 Anthropic 內部工具 Scion 的報導引起工程圈討論。重點不在 Anthropic 又出了什麼模型，而在一家重度使用 AI 程式代理的公司，把開發流程裡最老牌的基礎設施之一，版本控制，拿回去重做了一遍。

先看數字。Anthropic 公布，每天合併的程式碼變更從 2026 年 5 月的約 2,500 件，成長到 9 月的超過 30,000 件，十二倍的增加發生在四個月內。該公司的單一程式庫歷史近 100 GB、壓縮後工作副本超過 25 GB，而且光 CI 每天就取出程式碼約 2,500 萬次。在這個規模下，取出程式碼本身就是成本，於是 Scion 誕生，五個月內完成遷移。Anthropic 稱 CI 檢出更快，並釋出約 25% 的 CPU 容量。

這組數字是 Anthropic 的內部工作負載，不是任何團隊用了 AI 工具就會遇到的情境。但它指出一個正在成形的問題：當程式碼的產出速度被代理拉高，瓶頸會往基礎設施移動。

「CI 很慢」其實是好幾種等待

報導裡最值得一般團隊留下的一段，是把「CI 很慢」拆開來看。整體完成時間裡混著好幾種等待：工作排入佇列、取得指定版本檔案、安裝依賴、編譯、跑測試。代理併行任務一多，CPU、磁碟與服務額度也可能互相爭用。

如果不去分項量測排隊時間、檢出時間、編譯與測試各自的中位數與高百分位耗時，就無法判斷延遲到底出在哪一段。多數耗時在測試或佇列的團隊，重做版本控制不會帶來相稱的回報。這和判斷 API 成本該不該重構是同一套邏輯：折扣寫在公告上，實際省多少要從自己的日誌算起，GPT-6 提示快取的重構判斷就是這個思路的近例。

Scion 改了什麼：從「人人有全份」到「中央廚房」

Git 的核心假設是每份複本都能獨立運作：本機讀歷史、看差異、離線提交。Scion 反過來，以常在線的客戶端搭配伺服器為前提。伺服器負責回應歷史查詢、diff、合併與 rebase；客戶端只保留有限的本機物件快取，需要工作副本時才把目標路徑的檔案放到磁碟。

用日常比喻，Git 像每個人都拿到一本完整的食譜大全，Scion 則是中央廚房：你點哪道菜，端出哪道，食材以內容定址的方式存放、建立後不可變，所以各層可以放心重複供應。某些 CI 工作只需要問差異或合併基準，透過 API 就能拿到答案，根本不必先建一份完整本機程式庫。

快取是分層的：工作節點上的 scion-daemon、區域快取 scion-cache、權威 scion-server，各層用同一套通訊協定，流量被逐層限制，避免區域快取故障時請求直接沖垮上遊。對每天 2,500 萬次檢出的場景，這把大量重複讀取轉成快取供應，也把計算與服務容量集中管理。

所以呢

Scion 的代價很明確：客戶端必須連線，整體可用性仰賴伺服器、網路與快取層。Anthropic 自己也說，Git 的分散式特性對多數程式庫仍然合適。對一般團隊，這篇報導的用法不是「該換掉 Git」，而是當代理讓程式碼變更量往上跳時，先量測，再決定瓶頸在哪。基礎設施的準備清單也不只版本控制一項，AI 代理沙箱的評估重點同樣是代理大規模上工前該想清楚的事。規模沒到位之前，知道別人在哪個規模做了什麼取捨，比急著跟進更有價值。