【關鍵數字】 關鍵數字：
- 5個月：Anthropic開發Scion版本控制系統所花費的時間。
- 2,500筆：今年5月平均每天合併的程式碼變更數量。
- 30,000筆：到了9月，平均每天合併的程式碼變更已超過的數量，4個月成長逾10倍。
- 100 GB：該公司主要程式庫主分支歷史資料接近的規模。
- 25 GB：壓縮後工作副本仍超過的大小。
- 2,500萬次：CI系統每天取出指定版本程式碼的次數。
- 25%：導入Scion後，CI節省的CPU容量比例。
- 數百台：Anthropic過去曾使用的Git鏡像伺服器數量。
AI代理大量參與程式開發，正在改寫軟體工程的基礎設施。Anthropic既有的Git版本控制架構面臨擴充瓶頸，因此花費5個月開發名為Scion的版本控制系統，並將內部大型單一程式碼儲存庫完整遷移至新系統，改由伺服器處理程式碼提交、合併及歷史查詢，大幅減輕開發環境與持續整合系統的負擔。
變化的速度驚人。Anthropic今年5月平均每天合併約2,500筆程式碼變更，到了9月，這個數字已超過3萬筆，短短4個月成長超過10倍。如此龐大的變更量，讓傳統版本控制工具難以招架，也促使該公司決定自行打造新的解決方案。
規模是另一個關鍵。該公司主要程式庫的主分支歷史資料接近100 GB，即使是壓縮後的工作副本，仍超過25 GB。光是CI系統，每天就要取出指定版本的程式碼約2,500萬次。在這樣的規模下，任何效率上的微小提升，都能帶來可觀的資源節省。
事實上，Anthropic開發團隊過去曾嘗試多種緩解方案，包括使用數百台Git鏡像伺服器、淺層複製，以及只在工作目錄保留所需檔案的稀疏取出等方法。但隨著程式碼變更量持續增加，這些方法的維護負擔也越來越重，最終仍無法跟上成長的速度。
問題的根源在於架構差異。Git採用分散式架構，開發者可以在本機查看版本歷史、比較程式碼差異，甚至離線作業，這是為人類開發者設計的。但在Anthropic的環境中，存取程式庫的客戶端多為保持連網的AI代理與自動化作業，根本不需要離線功能，反而被分散式架構的 overhead 拖累。
因此，Scion改由伺服器執行提交、合併及版本歷史查詢，客戶端只需保留有限的本機快取，不必下載大量歷史資料。這種集中式設計，正是針對AI代理工作型態的最佳化：代理人幾乎隨時連網，需要的是快速取得所需程式碼，而非完整的本地歷史。
在技術實作上，Scion以變更集記錄每次修改的檔案，並建立額外索引加快歷史查詢。CI工作可以直接透過API取得版本差異，不必每次都取出整個程式庫。需要讀取程式碼時，也能透過稀疏取出及按需載入機制，只取得實際需要的檔案，並利用多層快取減少重複傳輸。
成效十分顯著。根據Anthropic內部量測，Scion大幅降低版本控制基礎設施的CPU與記憶體需求，CI及研究工作取出程式碼的時間也從數分鐘縮短至數秒，CI另節省約25%的CPU容量。對於每天要執行2,500萬次取碼的系統來說，這樣的提升直接轉化為可觀的成本節省。
不過，Anthropic也強調，Scion主要針對超大型程式庫及大量AI代理的開發環境設計，並不適合一般用途。由於系統與Git差異甚大，其他組織若要採用，還必須另行建置或整合程式碼審查、搜尋與CI等配套系統，導入門檻不低。
這起案例反映了AI時代基礎設施的典範轉移。當AI代理成為程式碼的主要生產者，傳統為人類設計的工具鏈開始出現瓶頸。從版本控制到CI系統，整個開發基礎設施都可能需要重新思考。Anthropic的選擇是自行打造，而其他組織未來也可能面臨類似的抉擇。
值得關注的是，這也凸顯了AI代理對運算資源的龐大需求。每天3萬筆程式碼變更、2,500萬次取碼，這樣的規模在幾年前難以想像。隨著更多企業導入AI輔助開發，基礎設施的擴充性將成為競爭力的關鍵之一。
對台灣的軟體產業而言，這個案例提供了前瞻性的參考。當AI代理逐漸普及，現有的開發流程與工具鏈是否足以支應，值得技術主管提前評估。雖然多數團隊的規模遠不及Anthropic，但及早理解集中式與分散式版本控制的取捨，有助於未來的架構決策。
