gitai: Git hướng đến nhiều coding agent cùng một nhánh

gitai là dự án mã nguồn mở triển khai độc lập các ý tưởng từ Scion: agent chỉ lấy phần mã cần thiết, land thay đổi bằng compare-and-swap, ghi changeset log và chỉ tự land đề xuất resolve từ LLM khi xác minh đạt yêu cầu.

Một agent đổi tên hàm get thành fetch. Một agent khác gần như cùng lúc thêm tham số cho chính hàm đó. Với quy trình Git quen thuộc, hai thay đổi có thể va nhau: rebase, retry hoặc chờ merge queue.

Khi coding agent tạo ra hàng loạt tác vụ nhỏ và ngắn, nút thắt không chỉ là viết code. Vấn đề là làm sao để nhiều agent cùng đọc, sửa và land thay đổi trên một nhánh, đồng thời vẫn truy được ai đã làm gì và thay đổi nào gây lỗi.

gitai là một dự án mã nguồn mở nhắm vào bài toán này. Repository có tên git-ai, còn các extension trong mã nguồn được gọi là Graft: gồm Graft CLI, cấu hình [graft] và các thành phần server.

Mô hình Git server-centric cho agent

Theo README, gitai là triển khai độc lập các ý tưởng thiết kế của Scion mà Anthropic từng mô tả. Scion là hệ thống nội bộ của Anthropic, không công khai; gitai không liên kết hay được Anthropic chứng thực.

Ý tưởng chính là chuyển phần điều phối từ client lên server. Git hosting truyền thống phù hợp với luồng một người clone toàn bộ repository, làm việc trong thời gian dài rồi push. Trong khi đó, coding agent thường chỉ cần vài file cho một tác vụ và cần đưa kết quả lên nhanh.

gitai tổ chức luồng này qua server:

Lấy đúng dữ liệu cần dùng. graft clone và graft sparse có thể materialize — tạo workspace cục bộ — chỉ cho các path được yêu cầu. Đưa truy vấn lịch sử lên server. Blame, path history, ancestry và code search chạy phía server, được memoize thành derived data để tái sử dụng theo commit. Land không qua merge queue tuần tự. UserLand rebase thay đổi lên tip hiện tại rồi dùng compare-and-swap để cập nhật ref khi ref vẫn đúng giá trị dự kiến. Ghi changeset log. Mỗi cập nhật ref được chấp nhận là một bản ghi có thứ tự, gồm operation và actor. Kiểm soát quyền của agent. Token theo agent, RPC allowlist và branch policy được dùng để xác định agent được phép thực hiện thao tác nào.

Mô hình này đáng chú ý với đội ngũ có nhiều agent CI hoặc agent chuyên trách cùng hoạt động trên một codebase.

Quickstart: dựng server, cache và hai agent

README hiện nêu các yêu cầu: Linux hoặc macOS, Go 1.26, C toolchain, Meson và Ninja. Quá trình build sẽ biên dịch một bản Git được đóng gói kèm theo.

Luồng thử nghiệm ngắn nhất của dự án là:

shell git clone https://github.com/feder-cr/git-ai.git cd git-ai make build # server, CLI and tools into build/bin examples/graft/quickstart.sh # a server, a cache daemon, two agents and a land, in a temporary directory ./build/bin/graft # the CLI and its commands

Script quickstart được mô tả là tạo một server, một cache daemon, hai agent và một thao tác land trong thư mục tạm thời. Đây là điểm khởi đầu phù hợp để quan sát cơ chế trước khi cân nhắc đưa repository thật vào hệ thống.

Khi tự dựng server, README hướng dẫn bắt đầu từ examples/graft/config.toml:

shell build/bin/gitaly serve config.toml

Để lưu trạng thái repository trong database và object storage, cấu hình thêm [graft.storage]. Tài liệu khuyến nghị bắt đầu ở chế độ shadow, import repository rồi chuyển sang authoritative.

Sparse workspace: thu hẹp context cho agent

graft clone và graft sparse giúp agent chỉ materialize phần cây thư mục cần thiết. Đây là điểm có thể hữu ích với monorepo hoặc worker ngắn hạn.

Ví dụ, một agent sửa API có thể chỉ cần thư mục dịch vụ và phần test liên quan. Một agent theo dõi component cũng có thể dựa vào changeset stream thay vì tự đi lại toàn bộ lịch sử từ client.

README không đưa cú pháp hoàn chỉnh cho tham số path của graft clone hay graft sparse trong phần quickstart. Vì vậy, trước khi đưa vào pipeline, nên kiểm tra Quickstart và configuration reference của dự án thay vì tự suy diễn quy trình thay thế git clone.

Resolve conflict bằng AI, nhưng không cho AI tự merge vô điều kiện

Một conflict có thể được gửi đến resolver do bạn chọn: nhà cung cấp LLM bất kỳ, công cụ deterministic hoặc không dùng resolver. Theo README, server không tự gọi mô hình ngôn ngữ; lựa chọn model và provider thuộc về phía triển khai.

Nếu LLM đưa ra phương án resolve, đó chỉ là đề xuất. Đề xuất chỉ tự land khi verify.command được cấu hình chạy thành công trên đúng cây mã chuẩn bị được land. Nếu xác minh thất bại, agent nhận lại conflict package kèm proposal.

Với deterministic rules, không có điều kiện riêng như LLM proposal. Tuy nhiên, chúng vẫn có thể được verify trên đúng tree khi bật verify.enabled.

Điểm đáng chú ý ở đây là hàng rào xác minh nằm trên kết quả cuối cùng:

LLM có thể gợi ý cách nối hai thay đổi, nhưng không có quyền merge vô điều kiện. verify.command có thể là nơi đặt test, lint hoặc kiểm tra phù hợp với repository. Khi chưa có rule và verification đáng tin cậy, conflict có thể được trả lại cho agent thay vì buộc tự động hóa.

Benchmark: nhanh hơn trong bài thử của dự án, không phải cam kết chung

README công bố benchmark trên một máy 16 core, chạy hai lượt: 50 agent cùng land 250 thay đổi trên một nhánh, trong đó 20% thay đổi được cố ý tạo conflict.

So với cấu hình “classic” của cùng server nhưng tắt batching, gitai land 200 thay đổi thay vì 100–106 khi không dùng conflict resolver.

| 50 agent, 250 thay đổi, không dùng resolver | Classic | gitai | |---|---:|---:| | Thay đổi được land | 100–106 | 200 | | Lần thử trên mỗi thay đổi được land | 26,5–28,7 | 1,0 | | Lượt land mỗi phút | 264–385 | 1.487–1.944 | | Độ trễ p99 | 4,4–5,2 giây | 1,9–2,7 giây |

50 thay đổi gitai không land trong bài thử này là các conflict được tạo có chủ đích. Với deterministic resolver trong cấu hình demo, dự án báo cáo land được toàn bộ 250 thay đổi, ở mức 1.245–1.806 lượt land mỗi phút và p99 2,0–3,4 giây.

Đây là số liệu do chính dự án công bố, trên môi trường và workload cụ thể. Repository thực tế có thể có test dài, dependency phức tạp, review policy và conflict ngữ nghĩa khó hơn.

README nêu phiên bản hiện tại là 0.3.0; interface vẫn có thể thay đổi trước 1.0. Dự án dùng giấy phép MIT.

Có nên thử gitai?

gitai phù hợp để thử khi đội ngũ đang gặp đồng thời các vấn đề: nhiều agent cùng một nhánh, thay đổi nhỏ nhưng dồn dập, retry/rebase liên tục và khó truy vết agent nào vừa ảnh hưởng tip.

Checklist ban đầu:

[ ] Chạy quickstart trên Linux hoặc macOS có Go, C toolchain, Meson và Ninja. [ ] Xác định branch nào agent được phép land thay đổi. [ ] Thiết lập token và RPC allowlist theo từng agent hoặc nhóm agent. [ ] Chỉ dùng resolver LLM khi đã có verify.command phù hợp. [ ] Đánh giá chế độ storage shadow trước khi chuyển sang authoritative. [ ] Duy trì quy trình review và xử lý lỗi phù hợp với repository của bạn.

Kết lại: gitai không đánh giá chất lượng code do agent tạo ra. Dự án tập trung vào “đường băng” để nhiều thay đổi đi vào codebase: lấy ít dữ liệu hơn, land đồng thời hơn, ghi nhận actor rõ hơn và không tự chấp nhận đề xuất merge từ AI nếu chưa qua xác minh.