很多團隊看到 AI 程式代理能同時產生更多程式碼，第一個念頭可能是加快持續整合（CI）。但要先問清楚：工程師與代理是在等版本控制系統取出程式碼、等 CI 佇列，還是等編譯與測試？這些階段各有不同的瓶頸，改善其中一段不代表整條交付流程都會同步變快。Anthropic 的 Scion 案例，正是從程式碼存取與版本控制開始重新設計。
代理增加程式碼變更後，瓶頸先出現在哪裡？
先量測版本控制、代理併行、CI 佇列、編譯與測試各自耗時，再判斷等待集中在哪個階段。Anthropic 的變更量是該公司的內部工作負載，不能直接當成一般團隊的預測。
Anthropic 公布的變更量與背景
Anthropic 在 2026 年 10 月公布，該公司每天合併的程式碼變更從 2026 年 5 月平均約 2,500 件，增至 9 月超過 30,000 件。公司表示，程式撰寫速度提高後，來源控制、建置與持續整合成為開發基礎設施的壓力點，因此打造內部版本控制系統 Scion，並在五個月內將大型單一程式庫從 Git 遷移過去。
這些數字反映 Anthropic 的規模與作業方式，不表示所有使用 AI 工具的團隊都會遇到同等負載。
Anthropic 也描述其程式庫歷史近 100 GB、壓縮後工作副本超過 25 GB，每天僅 CI 就會取出程式碼約 2,500 萬次。若每次都以完整方式取得資料，網路傳輸與機器資源都會成為成本。這能說明 Scion 為何針對大型程式庫設計，卻不能證明一般規模專案需要捨棄 Git。
來源控制、建置、CI 是不同階段
「CI 很慢」可能包含多種等待：工作排入佇列、取得指定版本的檔案、設定建置環境、編譯、執行測試，以及部署前檢查。代理工作增加時，併行任務也可能爭用 CPU、磁碟或服務額度。若只看整體 CI 完成時間，就難以知道改善版本控制能否解決真正的延遲。
團隊可在 CI 工作中記錄排隊時間、檢出時間、依賴安裝、編譯、測試與部署各自的中位數及高百分位耗時，並按程式庫、工作類型與快取命中情況分類。這樣才能分辨是原始碼取用太慢，還是程式碼已取得、後續運算仍占大多數時間。若主要耗時在測試或佇列，重做版本控制系統未必會帶來相稱改善。
Scion 如何改變大型程式庫的程式碼存取？
Git 著重每份複本可獨立運作，Scion 則以常在線的客戶端搭配伺服器服務為前提，依需求取得檔案與版本資訊。這種設計減少每個工作環境都保存完整程式庫的需求，也把更多能力集中到服務端。
伺服器處理版本資訊，客戶端按需取得檔案
Git 的分散式特性讓開發者能在本機讀取歷史、比較差異，也可離線提交與檢視程式碼。Anthropic 指出，這些特點對多數程式庫仍合適；但在其大型單一程式庫裡，許多 CI 工作與代理環境短暫存在、預設連線，完整複本與離線能力未必是主要需求。
Scion 將部分工作移到伺服器端。伺服器可回應歷史、差異與檔案歸屬等查詢，也負責建立變更、合併與 rebase；客戶端保存有限的本機物件快取，需要工作副本時才把目標路徑的檔案放到磁碟。某些 CI 工作只需要詢問差異或合併基準，便可透過 API 取得資訊，不必先建立整份本機程式庫。
Scion 的 changeset 記錄相對於前一版本變更的檔案，並指向內容定址的檔案物件。由於物件建立後不可變，服務可用物件識別碼快取與重複供應。對工作只涉及部分目錄的任務，稀疏檢出只取用指定路徑；虛擬檢出則等檔案真正被讀取時才取得內容。
分層快取如何減少重複傳輸與計算
Scion 的資料流由工作節點上的 scion-daemon 開始，接著連到區域快取 scion-cache；快取缺少物件時，再向權威 scion-server 取得資料，伺服器可從資料庫或雲端儲存讀取。Anthropic 表示，各層使用相同的通訊協定，但會限制流量逐層傳遞，避免區域快取故障時大量請求直接壓垮上游服務。
物件不可變，讓節點與區域可以重複使用已取得的內容；工作只索取需要的樹與檔案，也免去傳送單一大型封裝檔的方式。這種架構將大量重複讀取轉成快取供應，並將計算與服務容量放在集中管理的基礎設施。代價是客戶端需要連線服務，且整體可用性仰賴伺服器、網路與快取層的設計。
檢出加速與 25% CPU 容量代表什麼？
不能直接這樣解讀。Anthropic 稱其 CI 與研究工作檢出從分鐘縮短到秒，CI 取得 25% CPU 容量；這些是公司內部數據，描述版本控制與檢出改善，不是編譯、測試或部署時間的保證。
Anthropic 自述的效能數字與適用範圍
Anthropic 表示 Scion 各層快取命中率超過 99%，版本控制基礎設施的 CPU 與記憶體需求約為原有 Git 鏡像架構的二百分之一，CI 與研究工作取出程式碼的時間由分鐘級降至秒級，並稱 CI 因此取得 25% CPU 容量。
這些數據比較的是 Anthropic 自身的基礎設施與工作負載，公開文章未提供跨公司對照或獨立重現結果；不同團隊的程式庫、硬體、快取與 CI 工作安排都可能不同。
「CPU 容量增加」也不等於 CI 總時間減少相同比例。檢出階段少占用 CPU，可能讓同一批執行器能處理更多工作；但單項工作仍可能受編譯、測試或依賴服務限制。若佇列時間下降，也可能是容量釋出後帶來的間接效果，需要以實際遙測判斷。
「Scion 並非適合一般用途的 Git 替代品。」— Anthropic 工程團隊（原文意譯）
「我們不認為自己的解法或考量適合每一種情況。」— Anthropic 工程團隊（原文意譯）
檢出、編譯、測試時間要分開量測
評估效能時，可將工作分成「取得來源」與「處理來源」兩類。前者包括建立工作副本、取回檔案物件、查詢版本歷史；後者包括依賴安裝、編譯、測試與部署。每個指標都要使用相同的程式版本、執行器規格、快取狀態與測試集合，並同時觀察典型值與較慢的尾端案例。
若檢出占總耗時比例很低，即使將檢出時間大幅降低，整體交付改善也有限。反之，若短命代理每次啟動都重複下載大型程式庫，且大量工作集中在同一套 CI 基礎設施，檢出與物件快取可能值得優先調校。這是待驗證的工程假設，須以本身工作負載測試。
自建版本控制系統要承擔哪些遷移成本？
要移動的不只是 Git 儲存格式，還包括依賴版本控制的整套開發流程。離線能力、權限、程式碼審查、搜尋、CI、故障復原與人員訓練都可能需要重做或整合。
離線能力、可用性與權限治理
Git 複本可在網路中斷時繼續檢視與提交，集中式服務則需要明確處理斷線時如何工作、未同步變更如何保存，以及伺服器不可用時如何復原。團隊應估算服務中斷對開發、建置與發布的影響，並確認備份、災難復原、容量擴充與版本升級程序。
權限模型也要重新檢查。Scion 的資料與操作集中在服務端，Anthropic 表示其系統支援儲存庫及目錄層級存取控制。其他團隊需先盤點機密程式碼、機器身分、權限審核、稽核紀錄與緊急撤權流程，再確認新系統能否符合組織的安全與法遵要求。
程式碼審查、搜尋及 CI 工具的整合
日常工作流程往往依賴 Git 的分支、標籤、合併請求、差異檢視與外掛。轉換系統會牽涉程式碼審查介面、搜尋索引、建置腳本、部署規則、開發者工具與供應鏈安全工具。Anthropic 在遷移期間也打造了內部程式碼審查工具、搜尋與存取控制服務，顯示版本控制與周邊工具之間有緊密依賴。
遷移期間還要考慮 Git 與新系統並行、歷史資料一致性、回退路徑、操作訓練及維護人力。Scion 是 Anthropic 內部系統，該公司也表示它與 Git 差異顯著，其他組織要採用，必須遷移整個開發生命週期。對多數團隊而言，局部調校既有 Git 流程可能比維護一套新系統更容易衡量與回退。
團隊如何判斷該調校 Git 還是重做系統？
先用代表性工作負載找出持續發生的來源控制瓶頸，再比較改造成本與可回收資源。只有在現有工具調校與局部快取仍不足以處理主要問題時，才值得把自建系統納入評估。
先定位等待時間，再比較改造方案
第一步是建立可重複的基準：記錄代理建立工作環境、檢出、版本查詢、CI 排隊、編譯與測試的時間，以及各階段資源使用量。接著依序檢查是否能透過 Git 設定、內部鏡像、預熱快取、稀疏檢出或部分複製降低等待。Git 官方文件列有部分複製與按需取得缺少物件的方式，代表不必一開始就更換整套版本控制系統。
測試要選擇足以代表日常工作的程式庫大小、變更型態與併行數，並在相同環境比較各方案。除了平均時間，也要追蹤快取冷啟動、熱門檔案集中存取、服務故障與網路不穩時的表現。只挑最有利的單一任務，無法說明系統在一般工作日的效益。
| 方案 | 適合先檢查的情況 | 主要代價 |
|---|---|---|
| 調校 Git／部分複製 | 只需減少下載量或工作副本範圍 | 仍須管理本機複本與缺少物件的取回 |
| 增加鏡像與快取 | 重複檢出造成網路或來源服務負載 | 快取更新、容量與故障復原 |
| 自建版本控制服務 | 超大型程式庫的來源控制持續成為主要瓶頸 | 遷移整套工具鏈並長期維護 |
用同一組工作負載計算效能與維運成本
比較時可列出省下的機器時間、縮短的等待與提升的執行器容量，再扣除工程開發、資料搬遷、服務維護、備援、資安審查、整合與教育成本。也要確認效益能否隨工作量持續增加；如果瓶頸只是少數專案的冷啟動，增加快取或調整建置流程可能已足夠。
實作上可先為一個非關鍵工作流程建立小規模試點，保留回到原流程的方式，設定明確的效能、可用性與維護門檻。若量測顯示來源控制長期占據顯著時間，局部改善仍無法擴展，而且團隊有能力長期維護伺服器與周邊工具，再評估更大幅度的系統改造。Anthropic 的 Scion 提供一種設計案例，不是其他團隊的採購清單。
- 先拆分檢出、CI 佇列、編譯與測試時間，找到主要等待來源。
- Anthropic 公布的檢出與 CPU 數字屬於其大型程式庫和內部基礎設施，不能直接外推。
- 先比較 Git 調校、稀疏或部分檢出與快取，再把遷移和維運成本納入自建評估。
常見問題
Q1: Scion 是否已取代所有公司的 Git？
沒有。Anthropic 將 Scion 用於自己的大型單一程式庫，並明確表示它不適合作為一般用途的 Git 替代品。該公司認為這種設計主要對極大型程式庫、眾多工程師或大量代理工作負載才可能有意義。
Q2: CI 檢出加速是否代表整體建置也變快？
不一定。檢出只涵蓋取得程式碼與版本資料的階段。編譯、測試、佇列和部署仍需分別量測，才能判斷檢出改善是否縮短整體交付時間。
Q3: 一般團隊可以直接採用 Scion 嗎？
Anthropic 表示 Scion 是內部系統，採用者還需調整程式碼審查、搜尋與 CI 等整套流程。一般團隊可先檢查 Git 的部分複製、稀疏檢出與快取選項，再以自身工作負載測試是否仍有來源控制瓶頸。
