Anthropic 用 Scion 重整 AI coding 下的版本控制
Anthropic 為內部大型單一程式碼庫開發並遷移至 Scion 版本控制系統，將提交、合併及歷史查詢等重工序交由 server 處理。iThome 報道指出，該公司面對大量 AI coding agents 參與開發後，原有 Git 架構的擴充成本上升；其內部量測稱，CI 及研究工作取出程式碼所需時間由數分鐘降至數秒，CI 的 CPU 容量需求亦減少約 25%。
不過，Scion 是為超大型程式碼庫及高密度自動化工作流而設。Anthropic 已明言它不適合一般用途；其他團隊即使想借鑑，也不能把它理解為可直接安裝、取代 Git 的通用產品，因為程式碼審查、搜尋和 CI 等周邊系統都要重新整合。
AI coding 將瓶頸推向版本控制與 CI
iThome 指出，Anthropic 在 5 月平均每日合併約 2,500 項程式碼變更，到 9 月已逾 3 萬項。其主要程式碼庫主分支歷史接近 100GB，壓縮後的工作副本仍超過 25GB；CI 每日則要取得指定版本程式碼約 2,500 萬次。
這組數字反映，當自動化 agents 提高提交與測試頻率，版本控制的壓力不只在儲存空間，更在於反覆複製、解壓、比對和傳輸程式碼。Anthropic 過去曾以數百台 Git mirror server、shallow clone 及 sparse checkout 應對，但隨變更量增加，維護成本同樣累積。
Scion 的取捨：把資料與運算集中在 server
Git 的分散式特性讓開發者可在本機保留完整歷史、比較差異，甚至離線工作。Scion 的設計假設卻不同：iThome 報道稱，Anthropic 的主要客戶端是持續連線的 AI agents 和自動化作業。因此，它讓 client 僅保留有限本機快取，將提交、合併和歷史查詢移至 server。
為減少 CI 每次取得整個程式碼庫，Scion 以變更集記錄受影響檔案，另建索引加速歷史查詢；CI 可經 API 直接取得版本差異。真正需要讀取程式碼時，系統會以稀疏取出、按需載入及多層快取，只傳送所需檔案並避免重複傳輸。
這代表一項明顯取捨：以 server 端能力、網絡可用性及配套整合，換取大規模自動化下較小的 client 資料負擔和更快的 CI 啟動。對需要離線操作、倚重本機完整歷史的團隊，這種架構未必合適。
一般團隊可借鑑的，是工作流而非系統本身
從這個案例可作出的合理推論是，使用 monorepo 或高頻 CI 的團隊，應先量度「完整取碼」是否已成為 pipeline 的主因，而非急於更換版本控制工具。若重複建置工作只需部分檔案或兩個版本之間的差異，可優先檢視 sparse checkout、按需載入、版本差異 API，以及分層快取能否減少不必要傳輸。
對採用 AI coding agents 的企業，另一個要觀察的指標是變更量與 CI 觸發次數是否同步飆升。當 agents 將產碼速度推高，程式碼審查、測試隔離、快取命中率和 server 端查詢容量，都可能比編輯器內的產碼速度更早成為限制。
Scion 的成效目前主要來自 Anthropic 自述，且 iThome 所載資訊沒有交代其授權或開源安排。下一步值得關注的是，這類 server 端版本控制模式能否在不犧牲開發者既有工具鏈的情況下，支援更多程式碼審查、搜尋與 CI 工作流。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — Anthropic自建Scion取代Git，CI取出程式碼時間從數分鐘縮至數秒 — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
