Cursor公開程式碼託管服務Origin所採用的底層Git儲存系統Continuity Git 儲存系統。這套架構以S3相容物件儲存中的預寫日誌（Write-Ahead Log，WAL）保存每次推送的資料，並將伺服器本機Git儲存庫定位為可隨時重建的高速快取。
Cursor表示，新架構主要針對兩類日益明顯的負載：企業持續擴大的大型單一儲存庫，以及由AI代理大量建立、但實際使用頻率偏低的小型儲存庫。隨著AI代理開始大規模操作Git，傳統儲存架構在寫入效能、運算資源與儲存成本上的擴充問題更加突出。
以S3預寫日誌作為資料最終依據
傳統Git託管服務通常會將同一個儲存庫複製到多部伺服器，以提高可用性並分擔讀取流量。不過，當副本數量增加，開發者推送程式碼時就需要同步更多伺服器，可能影響寫入速度；對於使用量很低的小型儲存庫，固定維持多份副本也會占用不必要的運算與儲存資源。
Continuity的做法是將S3上的預寫日誌視為資料的最終來源。當開發者推送程式碼後，系統會先把資料完整寫入S3，再回覆推送成功。本機則繼續使用標準Git儲存庫及高速NVMe儲存裝置，處理日常讀寫與其他Git操作。
在這套設計下，伺服器上的Git副本不再是不可替代的資料來源。即使某個副本遺失，系統仍可從S3重新建立儲存庫，無須長期追蹤每個儲存庫目前分布在哪些伺服器。
副本數量可依使用量調整
Continuity也讓儲存庫副本數量能隨實際使用情況調整。大型單一儲存庫可增加副本，以分擔大量讀取需求；由AI代理建立、但很少被存取的小型儲存庫，則可只保留一份副本。若儲存庫閒置一段時間，系統甚至可以將其從伺服器磁碟移除，待有需要時再由S3重建。
這種設計將儲存庫的資料持久性與本機副本分離：S3負責保存可重建的完整資料，本機NVMe則提供低延遲的日常操作。對於讀取需求差異很大的AI代理工作負載，副本策略因此不必採取一體適用的方式。
Cursor測試：最多每秒300次以上推送
Cursor公布的合成壓力測試顯示，當Continuity增加至100個副本時，唯讀Git操作仍可隨副本數增加而擴充，測試期間未觀察到程式碼推送速度下降。
| 儲存配置 | 測試結果 |
|---|---|
| S3 Standard | 每秒最多處理120次推送 |
| S3 Express One Zone | 每秒超過300次推送 |
上述數字均為Cursor自行進行的測試結果，並非獨立第三方基準測試。實際表現仍可能受到儲存服務配置、網路環境、儲存庫大小與操作類型影響，因此不能直接視為所有生產環境的固定效能。
Git託管服務面臨容量與流量成長
GitHub近期也面臨程式碼託管容量快速成長帶來的基礎架構壓力。8月17日，GitHub因美國中部資料中心的關鍵元件無法隨流量擴充，發生持續7小時47分鐘的服務中斷。
GitHub官方表示，今年4月至今，每月程式碼提交數已由14億次增加至29億次。目前Azure約承擔GitHub 58%的平台負載，以及一半的Git操作。GitHub後續將先從大型單一儲存庫著手，導入可隨讀取端數量增加而擴充處理能力的新架構。
架構轉向的影響與限制
Cursor的Continuity顯示，AI代理帶來的Git工作負載不只是傳統開發團隊的儲存庫規模變大，也包括大量建立、低頻使用的短生命週期儲存庫。將持久資料集中保存於物件儲存，再以可重建副本服務讀取需求，能讓系統更容易依照使用量調整資源。
不過，這種架構的效益仍取決於物件儲存的寫入延遲、成本、可用性與重建流程。Cursor目前公開的資料主要來自自家合成壓力測試，尚未提供更多長期生產環境數據，因此其對不同規模企業與不同AI代理工作負載的實際適用程度，仍有待持續驗證。
Reference Link : ithome.com.tw
