Claude寫代碼太快，Anthropic先扛不住了：連Git都要重做

編譯 | 程茜 編輯 | 李水青 10月14日消息，今日，Anthropic發佈一套對標Git的源碼控制系統Scion，並已在單體倉庫中用Scion取代了Git。一個7人團隊在5個月內構建了Scion和代碼審查工具Antique以及六個相關的系統，並完成所有遷移。長期以來，Git已成為現代軟件工程的重要協作基石與事實標準，是絕大多數軟件團隊管理代碼、留存變更歷史、多人協同的必備基礎工具。它就像一個軟件世界的“時光相冊”和多人協作工作臺，讓開發者看清代碼的修改脈絡。

Anthropic做這件事的背景是，在其內部，2026年5月平均每天合併約2500處代碼變更，到9月日均合併量已經突破3萬筆，4個月暴漲12倍，且這一增長勢頭短期內不會放緩。代碼合併的潛在需求幾乎無限，研究人員每消除一個瓶頸，代碼產量就會立即進一步增加。如今，Claude能夠自主迭代研究流程，對複雜程序做精細化優化，還可以從零搭建全新服務，其執行速度與規模前所未有。當下真正的瓶頸，是原本面向人類開發者打造的基礎設施正不堪重負，如版本控制、構建流程與持續集成（CI）。Scion系統中，每一層都保持著超過99%的緩存命中率，並且不需要長期狀態。

就CPU和內存需求而言，Scion基礎設施佔用空間為Git鏡像基礎設施的1/200。CI和研究作業檢出代碼的速度提高了兩個數量級，從幾分鐘縮短到幾秒鐘；僅CI一項就實現了25%的CPU容量提升。同時，客戶端和緩存都不需要執行代碼庫維護，可以簡化作業的生命週期管理。▲原生Scion倉庫實測性能提升 這一七人團隊還構建併發布了代碼審查平臺Antique、代碼搜索、功能強大的源代碼控制身份和訪問管理系統、管理和提交大量已審查代碼的新方法等。Anthropic也特別提到，Scion絕非Git的通用替代品。

Scion只適用於真正龐大的單體倉庫，這類倉庫要麼有數萬名工程師，要麼有大量智能體在高效地編寫代碼。不過，因為很多組件需要根據公司情況高度定製，因此Anthropic不會推出通用的Scion版本，只是向業界提供一種思路。一、日均千萬級檢出、數百PB流量，Git難以應對AI智能體負載 Anthropic使用Claude編寫軟件的頻率遠超其他公司，這也使得其更快發現那些為人類設計的工具早已不堪重負。隨著單體倉庫不斷增長，Git已不再適用。僅主分支的歷史記錄就接近100GB，壓縮後的工作副本也超過25GB。

不包括開發環境、代理沙箱和研究任務，Anthropic每天也需要在CI環境中執行約2500萬次代碼檢出，簡單估算，每天Git流量將超過600PB。Git本身支持部分拉取倉庫能力，如淺克隆、稀疏檢出、承諾遠端（promisor remotes）。除此之外，業內也有內部Git鏡像、存放在對象存儲裡的倉庫快照（seed）等適配巨型單體倉庫的常規方案。基於這些方案，Anthropic在峰值時期維護了幾百個內部Git鏡像來應對負載。但即便如此，隨著合併量上漲，其運維壓力越來越大。快照每次更新後，和主線最新提交的差距越拉越大；而且要保證依賴提交歷史的操作在部分克隆上正常運行。

▲擴展Git檢出範圍的典型設置 在這樣的背景下，Anthropic的研究人員開始思考，多數公司此前只是將Git當作集中式系統來用，只維護一個權威倉庫。但實際上其絕大多數訪問方都是一直在線的智能體、自動化任務。Git那些適合分佈式離線工作的特性，反倒成了倉庫擴容的阻礙。那如果從頭設計一套源碼控制系統，原生就考慮智能體永遠在線這個前提會是什麼樣？二、六大設計原則，部分思路與Git截然不同 基於上述現狀，他們在構建Scion時在幾個核心原則上採取了與Git截然不同的方法，同時其借鑑了大型單體倉庫成熟的源代碼控制技術，如谷歌的Piper和Meta的Sapling。

其構建Scion的幾個核心原則是： 客戶端始終在線：Git默認客戶端離線工作並且需要倉庫的完整副本。由於Anthropic幾乎所有的客戶端都是智能體和自動化作業，他們圍繞一個始終可訪問的服務器設計了Scion的客戶端和協議，讓客戶端在需要時獲取數據。客戶端-服務器不對稱：在Git中，每個客戶端都能夠充當功能齊全的服務器。在Scion中，服務器負責回答有關文件歷史記錄和blame的問題，創建提交，執行合併和變基等操作。客戶端維護一個有界本地對象緩存，在磁盤上佈局工作副本文件，監控文件系統變更，併為用戶提供符合人體工程學的服務器交互方式。

客戶端自身計算能力有限，但作為交換，它所需的本地數據量也少得多。一套全面的源代碼控制服務可以為許多創新應用提供支持：使用Git時，CI作業或工具如果需要查詢代碼庫信息，例如誰最後修改了某一行代碼或兩個提交之間的關係，就必須維護一份本地代碼庫副本，或者寄希望於特定廠商的API能夠提供答案。而使用Scion，客戶端使用的所有源代碼控制查詢都通過API公開，因此很多情況下作業根本不需要本地代碼庫。如果沒有這種低成本、程序化的源代碼控制訪問方式，許多內部工具將無法大規模應用。

一切都必須具備水平擴展能力：在高峰時期，Anthropic運行了數百個Git鏡像，這會限制服務器容量，一旦倉庫規模超過鏡像的磁盤或內存限制，就無法繼續擴展。在Scion中，倉庫數據是分佈式存儲的，每個組件都可以獨立擴展，即使在服務器上也沒有倉庫的完整實例。Scion沒有類似Git的對象壓縮包的概念，因此無需維護倉庫。提交必須成本低廉、增量式且無鎖：在Git中，開發者要先在本地提交，然後推送以共享工作。在Scion中，每次提交、變基或合併都在服務器端進行，因此無需推送任何內容。創建提交併更新其下游數據結構的成本必須與變更的大小成正比，而不是與倉庫的整體大小成正比，否則服務器會跟不上。

Scion的開發生命週期不鼓勵使用引用，除了主引用或發佈分支之外，因為所有服務器都必須達成一致的全局狀態會帶來潛在的擴展性問題。工作副本可選，設計精簡：由於Anthropic的單體倉庫龐大，並且每天要為了CI而檢出數千萬次代碼，因此他們希望儘可能避免檢出操作。使用Scion，開發者需要比較某個提交與其合併基礎版本差異的CI作業時，可以直接向服務器請求。寫入操作也是如此，許多寫入工作負載也可以跳過檢出，完全通過API執行。Scion的協議以僅包含客戶端請求目錄的稀疏檢出和按需實例化文件的虛擬化檢出為核心，因此當作業確實需要磁盤上的文件時，客戶端只需為實際讀取的文件付費。

三、專為AI智能體負載打造，Scion如何解決巨型倉庫痛點？Scion中的工作單元是“變更集”（changeset），它是預寫式日誌（Write-ahead Log）中的一個條目。變更集存儲的內容與Git提交（commit）類似。但Git提交存儲的是指向代碼樹的指針，而變更集存儲的是相對於其第一個父級發生更改的文件列表，以及指向Blob存儲中壓縮文件內容的指針。變更集在服務器端創建，並可立即在任何位置訪問。▲Scion中變更集的架構 這種架構的好處是可以極高吞吐地接收變更集，不用處理打包文件、無需加鎖或跨服務協同，也不用操作引用。

Scion理論上支持引用，但由於創建、拉取提交都不依賴引用，因此引用的變更只是對單條Spanner記錄執行一次比較交換，和變更集的提交相互獨立。此外變更集僅記錄更改的內容，因此它本身無法快速回答諸如“誰最後編輯了某一行”或“哪些提交影響了某個文件”之類的問題。為了回答這些問題，Scion會基於變更集構建額外的數據結構，包括用於文件錯誤信息和路徑歷史記錄的專用結構，以及用於提交圖的跳過列表。研究人員將所有不直接屬於變更集的數據稱為“派生數據”，並通過一個通用機制計算所有這些數據。每種派生數據都是遞歸定義的，因此它在某個變更集中的值是根據其在該變更集父級變更集中的值計算得出的。

這種機制有三大優點：當新的數據結構能夠加快某些操作的速度時，Anthropic可以快速添加新的派生數據類型；對於每種數據類型，其可以選擇立即計算或延遲計算，從而避免實例化不需要的數據；由於客戶端永遠不會看到這些數據結構的內部細節，研究人員可以在不更改客戶端的情況下對其進行優化。少量Scion服務器即可對外提供源碼控制接口，支持各類客戶端操作，如獲取變更集、計算差異、查找合併基、拉取文件對象。所有源碼數據都採用內容尋址，數據一旦寫入就不會變更，任意服務器都可以緩存，無需和其他節點協商。因此服務器支持水平擴容，節點間協同開銷極低。

它們本質上就是大容量緩存，還能實時計算派生數據，並回寫至Spanner。此外，Scion的眾多用戶不再需要維護自己的本地代碼庫。過去，獲取和維護代碼庫對於CI作業或需要查詢源代碼控制問題的工具來說是一項繁重的維護負擔。在遷移初期，Scion僅負責處理“元數據”查詢，而獲取文件內容和實例化工作副本等操作則需要處理更多的數據，因此需要專門的設計。Scion的scn客戶端和Git的拉取協議有幾點核心差異，由此可以搭建高可擴展架構，CPU開銷遠低於Git服務。在集群裡，客戶端通過套接字和守護進程scion-daemon通信，這個守護進程為本節點統一緩存對象。

Scion大部分節點都需要訪問單體大倉庫，同一節點上的任務會複用絕大多數對象。每個守護進程都從一個定期刷新的快照啟動，然後僅與其所在區域的樹形緩存服務器和Blob緩存服務器（scion-cache）通信。這些緩存服務器直接從內存中以守護進程將要使用的磁盤格式流式傳輸對象，因此它們無需花費時間計算客戶端缺失的對象或執行增量壓縮。當緩存缺少某個對象時，它會向scion-server發出請求，後者會根據需要從Spanner或雲存儲中讀取數據。scion-daemon、scion-cache和scion-server都支持同一套協議RPC，客戶端無需感知緩存的層級拓撲。

▲Scion的檢出架構 在創建Scion的過程中，Claude Mythos Preview的早期內部快照版本重寫了Git到Scion的數據導入管道，在沒有任何進一步指示的情況下，它生成了一個內存佔用減少至1/20、速度提升4倍的版本，同時保留了所有關於數據導入順序和數據結構的隱式不變性。▲2026年1–9月，Scion與Antique代碼庫每週合併變更量 結語：AI編程，正倒逼專為人開發的研發鏈路重構 AI自主編程浪潮下，面向人類開發者設計的基礎設施正面臨挑戰。在Git裡，開發者手動提交、按需拉取、低併發操作，離線可用性是核心訴求。

但當編程主體變成7×24小時在線、高頻批量迭代的AI智能體，就需要重新設計，Anthropic此次推出的Scion面向的就是版本控制環節。未來伴隨AI生成的代碼量飛速增長，構建系統、緩存調度、代碼評審、測試沙箱、權限審計等都需要重新適配AI的併發模式。來源：Anthropic