Anthropic thiết kế lại source control cho monorepo có agent
Anthropic xây Scion và chuyển monorepo khỏi Git khi số thay đổi merge mỗi ngày tăng mạnh. Case study này cho thấy source control, checkout và CI chịu áp lực ra sao khi client chủ yếu là agent và job luôn online.
Khi agent và CI tạo thay đổi nhanh hơn tốc độ hạ tầng phát triển có thể hấp thụ, nút thắt không còn chỉ là viết code. Nó có thể nằm ở clone repository, truy vấn history, checkout cho CI hay các trạng thái dùng chung như branch.
Anthropic mô tả bài toán này qua Scion, hệ thống quản lý phiên bản nội bộ của họ. Theo công ty, số thay đổi được merge vào monorepo tăng từ trung bình khoảng 2.500 thay đổi mỗi ngày vào tháng 5/2026 lên hơn 30.000 thay đổi mỗi ngày vào tháng 9/2026.
Anthropic cho biết đã chuyển toàn bộ monorepo từ Git sang Scion trong năm tháng. Cùng giai đoạn đó, họ xây giao diện review mã nguồn mang tên Antique, code search, hệ thống IAM cho source control và các cơ chế quản lý lượng code đã review.
Đây không phải thông báo về một sản phẩm công khai hay một công cụ thay thế Git cho bên ngoài. Scion là kiến trúc nội bộ được xây cho workload rất đặc thù của Anthropic. Nhưng với DevOps, SRE và platform engineer, đây là một case study đáng chú ý: khi phần lớn client là agent, CI job và sandbox luôn trực tuyến, source control có thể cần được vận hành như một dịch vụ nền tảng thay vì chỉ là repository để clone.
Vì sao Git chịu áp lực ở quy mô này?
Git là hệ thống phân tán: một clone đầy đủ có thể làm việc offline, tính diff, đọc history, chạy blame và checkout revision mà không cần server. Anthropic nhấn mạnh đây vẫn là thiết kế phù hợp với phần lớn repository.
Tuy nhiên, monorepo của họ đã vượt xa mô hình sử dụng đó:
History riêng của nhánh chính gần 100 GB.
Working copy đã nén lớn hơn 25 GB.
CI thực hiện khoảng 25 triệu lượt checkout mỗi ngày, chưa tính môi trường developer, agent sandbox và research job.
Nếu fetch theo cách đơn giản, lưu lượng Git có thể vượt 600 PB mỗi ngày.
Anthropic từng dùng shallow clone, sparse checkout, promisor remote, Git mirror nội bộ và snapshot repository trong blob storage. Ở đỉnh điểm, họ vận hành vài trăm Git mirror nội bộ.
Các biện pháp này giúp kéo dài khả năng vận hành, nhưng ngày càng khó quản lý khi tốc độ merge tăng. Snapshot ngày càng xa đầu main giữa các lần làm mới; còn các thao tác phụ thuộc history như diff và blame đòi hỏi nhiều xử lý hơn với clone không đầy đủ.
Từ repository cục bộ sang dịch vụ source control
Điểm xuất phát của Scion là một giả định khác: phần lớn client của Anthropic là agent và job, vốn online theo mặc định.
Thay vì để mỗi client giữ đầy đủ năng lực của một repository, Scion đưa nhiều thao tác lên server. Theo Anthropic, server trả lời truy vấn history và blame, đồng thời tạo commit, thực hiện merge và rebase.
Client giữ một object cache có giới hạn, materialize working copy ra đĩa, theo dõi thay đổi hệ thống tệp và cung cấp giao diện làm việc với server. Đổi lại, client không cần giữ lượng dữ liệu và năng lực xử lý tương đương một repository hoàn chỉnh.
Điều này thay đổi cách CI tương tác với source control. Chẳng hạn, job chỉ cần diff giữa một commit và merge base có thể hỏi server thay vì checkout repository. Các truy vấn mà client sử dụng cũng được mở qua API, giúp những công cụ nội bộ như pipeline bisect và revert tự động truy cập source control theo cách lập trình được.
Sáu nguyên tắc Scion nhấn mạnh
1. Client luôn online
Scion được thiết kế quanh giả định server luôn có thể truy cập, còn client chỉ lấy dữ liệu khi cần. Đây là đánh đổi trực tiếp với ưu thế làm việc offline của Git.
Với runner tạm thời, sandbox và agent trong hạ tầng tập trung, giả định này có thể phù hợp hơn mô hình mỗi client mang theo một bản sao repository hoàn chỉnh.
2. Client và server không đối xứng
Trong Git, mỗi client có thể là một repository hoàn chỉnh. Với Scion, phần lớn công việc source control nằm ở server, còn client được giữ gọn hơn.
Mục tiêu là giảm lượng dữ liệu phải có tại client, thay vì yêu cầu mọi job duy trì bản sao có thể tự xử lý toàn bộ history của monorepo.
3. Source control là API cho các công cụ khác
Một job không nhất thiết cần repository cục bộ chỉ để trả lời các câu hỏi như:
Dòng này được thay đổi lần cuối khi nào?
Hai commit có quan hệ thế nào?
Diff giữa một thay đổi và merge base là gì?
Theo Anthropic, các truy vấn source control mà client dùng đều được cung cấp qua API. Đây là góc nhìn hữu ích cho platform team: phân biệt rõ workload nào cần source tree trên đĩa và workload nào chỉ cần metadata.
4. Mọi thành phần phải mở rộng theo chiều ngang
Anthropic cho biết Git mirror từng gây áp lực đáng kể lên năng lực vận hành, nhất là khi repository phát triển vượt giới hạn đĩa hoặc bộ nhớ của mirror.
Scion phân phối dữ liệu repository và cho phép các thành phần mở rộng độc lập. Theo mô tả của Anthropic, không có bản sao đầy đủ của repository được materialize ở bất kỳ đâu, kể cả phía server.
Hệ thống cũng không có thành phần tương đương trực tiếp với packfile của Git, nên không cần bảo trì repository theo kiểu đó.
5. Commit phải rẻ, tăng dần và không khóa
Trong Git, developer thường commit cục bộ rồi push để chia sẻ. Với Scion, commit, rebase và merge diễn ra trên server, nên các thao tác này phải đủ nhanh để theo kịp tốc độ thay đổi.
Anthropic mô tả đơn vị công việc của Scion là changeset — một entry trong write-ahead log. Changeset chứa danh sách file thay đổi so với parent đầu tiên, cùng các con trỏ content-addressed tới nội dung file đã nén trong blob storage.
Khác với Git commit trỏ tới một cây thư mục, changeset chỉ ghi phần thay đổi. Theo Anthropic, thiết kế này không cần tiếp nhận packfile, không cần lock hoặc điều phối liên server khi tạo changeset.
6. Working copy là tùy chọn và sparse theo thiết kế
Vì monorepo lớn và số lượt checkout cho CI rất cao, Scion cố gắng tránh checkout khi không cần thiết.
Giao thức của Scion được xây quanh hai mô hình:
Sparse checkout chỉ chứa các thư mục client yêu cầu.
Virtualized checkout chỉ materialize file khi thực sự cần đọc.
Một số workload đọc hoặc ghi có thể làm việc hoàn toàn qua API mà không cần working copy. Khi cần file trên đĩa, client chỉ phải trả giá cho dữ liệu thực sự được đọc.
Vì sao Scion hạn chế refs?
Scion vẫn hỗ trợ refs, tức các con trỏ như branch và tag. Tuy nhiên, Anthropic cho biết vòng đời phát triển trong Scion hạn chế dùng refs, ngoại trừ các ref như main hoặc release branch.
Lý do là refs là trạng thái toàn cục: một thay đổi ref đòi hỏi sự thống nhất giữa các server. Ở quy mô thay đổi rất lớn, trạng thái toàn cục có thể trở thành vấn đề cần kiểm soát.
Việc tạo changeset được tách khỏi việc di chuyển ref. Theo Anthropic, di chuyển ref là thao tác compare-and-swap trên một hàng Spanner riêng, thực hiện độc lập với việc tạo changeset.
Với đội vận hành CI/CD, đây là câu hỏi đáng cân nhắc: trạng thái nào thực sự cần đồng bộ toàn cục, và trạng thái nào có thể được biểu diễn bằng thay đổi bất biến hoặc truy vấn qua API?
Bài học cho đội platform
Scion được xây cho áp lực đặc thù của Anthropic, không phải công thức thay thế Git phổ quát. Dù vậy, case study này đưa ra một số câu hỏi hữu ích:
Pipeline nào thực sự cần working copy?
Phân biệt job cần build hoặc test với job chỉ cần metadata source control.
Dịch vụ source control có đang trở thành dependency vận hành?
Khi workflow dựa vào truy vấn tập trung, availability, độ trễ và năng lực phục vụ của dịch vụ này trở nên quan trọng.
Trạng thái toàn cục nào đang giới hạn tốc độ?
Branch, tag, merge queue hoặc các cơ chế đồng bộ khác có thể thành điểm nghẽn khi số thay đổi tăng mạnh.
Automation có phải chuẩn bị repository cục bộ cho mọi lần chạy?
Các tác vụ như phân tích diff, bisect hoặc revert có thể hưởng lợi từ API source control thay vì luôn bắt đầu bằng checkout.
Hạ tầng phát triển có theo kịp tốc độ tạo code không?
Khi agent tăng số lượng thay đổi, bottleneck có thể chuyển sang source control, build, CI và quy trình merge.
Git vẫn phù hợp với phần lớn repository, đặc biệt khi khả năng làm việc offline và tính độc lập của client quan trọng. Nhưng bài viết của Anthropic chỉ ra một giới hạn đáng chú ý: khi agent và job luôn online trở thành client chính, các giả định tối ưu cho developer có thể không còn tối ưu cho hạ tầng phát triển ở quy mô cực lớn.
Agent có thể tăng tốc tạo code. Câu hỏi tiếp theo là source control, build và CI có hấp thụ được tốc độ đó hay không.