Ngày 17 tháng 8, GitHub trải qua sự cố dịch vụ rộng rãi, cùng ngày Cursor mở bản early beta của Origin cho người dùng trả phí. Các kho mã đang được tích hợp với Agent chạy liên tục, trong khi hạ tầng hợp tác hiện tại được thiết kế để phù hợp với nhịp làm việc của con người. Nghiên cứu cho thấy 40,2% các kho mã có PR của Agent chồng lấn, tỷ lệ xung đột merge đạt 41,7%. Cursor Origin được thiết kế dành riêng cho việc ghi của Agent với tốc độ lên tới 22,6 commit/giây trên một kho mã, tích hợp kho mã, PR, checks và review. Origin được định vị là lớp điều khiển nằm trên Git, tái thiết kế quy trình hợp tác của Agent với tần suất cao. xAI, X, SpaceX và Cursor dưới quyền Musk đã hình thành chuỗi sản xuất AI hoàn chỉnh: Colossus cung cấp sức mạnh tính toán, Grok cung cấp mô hình, Cursor thực thi mã và Origin quản lý trạng thái kỹ thuật. GitHub đang mở rộng từ hợp tác của con người sang Agent, trong khi Cursor tái thiết kế forge dựa trên tải công việc của Agent — hai hướng đi này đang ngày càng cạnh tranh khốc liệt.

Tác giả bài viết, nguồn: LeFengwang

Chủ sở hữu kho mã đang chuyển từ con người thành Agent.

Ngày 17 tháng 8, GitHub trải qua sự cố dịch vụ rộng rãi. Các tuyến cốt lõi như Web, API, Actions, Pull Requests, Git Operations, Webhooks lần lượt bị ảnh hưởng, trong một số thời điểm tỷ lệ lỗi yêu cầu Web và API gần 20%.

Cùng ngày đó, Cursor bắt đầu từng bước mở rộng Origin early beta cho tất cả các gói trả phí. Các tính năng repository, PR, checks, review, merge và Automations bắt đầu được tích hợp vào cùng một hệ thống, và định vị của Cursor cũng rất rõ ràng: nền tảng lưu trữ mã nguồn bắt đầu được thiết kế cho “agent scale”.

Điều thú vị là, hai sự việc này vô tình xảy ra cùng một thời điểm, làm nổi bật rõ một sự thay đổi: kho mã nguồn đang tích hợp ngày càng nhiều Agent chạy liên tục, trong khi cơ sở hạ tầng hợp tác phần mềm hiện tại đã lâu dài thích nghi với nhịp làm việc của con người.

Con người có thể viết vài giờ mã nguồn nhưng chỉ tạo ra vài lần commit; Agent có thể liên tục sửa đổi, push, kích hoạt các kiểm tra và tiếp tục vòng tiếp theo dựa trên kết quả trong vài phút. Việc commit nhanh hơn chỉ là bề nổi, sự thay đổi sâu sắc hơn là thang thời gian của toàn bộ hệ thống sản xuất phần mềm đang được thu hẹp.

Nhiều vấn đề mới mà GitHub đang đối mặt, nhiều vấn đề Origin muốn giải quyết, có thể đều bắt đầu từ đây.

01 GitHub không đột nhiên già đi

Khi GitHub ra đời, sự hợp tác phần mềm có một đơn vị cơ bản ổn định: con người.

Kỹ sư viết vài giờ mã, gửi một commit; phát triển một tính năng trong vài ngày, tạo một PR; đánh giá có thể xuất hiện sau nửa giờ hoặc đến ngày hôm sau; CI chạy vài phút thường là chấp nhận được, xử lý xung đột merge sau một chút cũng không làm mất đi ý nghĩa của toàn bộ hệ thống.

Dựa trên nhịp điệu này, GitHub đã xây dựng hệ thống Pull Request, Issue, Review, Actions, Webhook và quyền hạn. Ngay cả với các dự án như Linux Kernel, vốn duy trì khối lượng commit cao trong thời gian dài, nhịp điệu này vẫn mang rõ nét thước đo thời gian của con người.

LWN thống kê, toàn bộ chu kỳ phát triển Linux 7.0 có 14.251 commit không phải hợp nhất, đến từ 2.362 nhà phát triển. Những commit này xảy ra trong chu kỳ phát triển kéo dài nhiều tuần, giữa chừng có các cuộc thảo luận qua email, đánh giá của người duy trì, tích hợp hệ con và chu kỳ phát hành.

Cursor đã hiển thị một dạng tải khác trong buổi trình diễn Origin vào tháng 6: 22,6 commit/s trên một kho duy nhất.

Con số này thuộc dữ liệu demo trực tiếp, không phải là benchmark sản xuất đã được tái tạo độc lập, và không thể chứng minh Origin có thể duy trì mức độ thông lượng tương đương trong môi trường thực tế. Tuy nhiên, nó đủ để cho thấy Origin hướng đến loại workload nào: nhiều Agent liên tục ghi vào cùng một trạng thái mã.

Các nhà phát triển con người tự nhiên bị giới hạn tốc độ. Việc suy nghĩ, viết mã, tham gia cuộc họp và nghỉ ngơi sẽ tạo ra nhiều khoảng trống thời gian giữa các lần gửi, do đó, các hệ thống được thiết kế xung quanh con người có thể chuyển một phần lớn áp lực hệ thống cho thời gian hấp thụ.

Agent không có giới hạn này.

Hàng chục Agent có thể đồng thời phân nhánh từ cùng một base SHA, sửa đổi các tệp liên quan trong thời gian gần nhau, sau đó cùng đẩy, tạo PR, gọi kiểm tra, đọc phản hồi, sửa mã và đẩy lại. Một commit duy nhất còn có thể tiếp tục kích hoạt cập nhật chỉ mục, kiểm tra quyền, Webhook, CI, quét mã, làm mới trạng thái phản hồi và tính toán khả năng hợp nhất.

Do đó, điều cần chịu đựng sự thay đổi không phải là mô hình đối tượng Git本身, mà quan trọng hơn là control plane forge trên Git: API, xác thực, tác vụ nền, lịch trình CI, webhook, bảo vệ nhánh, trạng thái xem xét, hàng đợi gộp, cùng với tải chuỗi được tạo thành giữa các thành phần này.

Một nghiên cứu về các PR của Agent trên GitHub được công bố vào tháng 7 đã ghi nhận kiểu đồng thời này. Nghiên cứu đã phân tích 33.596 PR của Agent trong 2.807 kho lưu trữ, và 40,2% số kho lưu trữ có các PR của Agent trùng nhau về thời gian.

Trong các lần sửa đổi đồng thời được phát lại mẫu, tỷ lệ xung đột hợp nhất văn bản giữa các PR của Agent khác nhau đạt 41,7%, trong khi tỷ lệ giữa các PR đồng thời do cùng một Agent tạo ra là 19,8%.

Sự hợp tác của nhiều agent do đó sẽ mang lại các vấn đề kiểm soát đồng thời mới. Sự cố lần này của GitHub không chứng minh được lưu lượng agent đã vượt quá cơ sở hạ tầng hiện tại, nhưng nó cung cấp một cửa sổ quan sát: khi sản xuất phần mềm chuyển từ các sự kiện con người tần suất thấp thành các sự kiện máy móc tần suất cao, quy hoạch dung lượng, thiết kế hàng đợi, truyền trạng thái và mô hình nhất quán đang đối mặt với một loại workload khác.

Thiết kế của Origin cũng bắt đầu từ đây.

02 Origin tái viết chi phí hợp tác

Nếu Origin chỉ đơn giản thêm một cổng hỗ trợ kho lưu trữ Git, thì nó khó có thể phá vỡ các mối quan hệ nhà phát triển, hệ sinh thái mã nguồn mở, hệ thống quyền doanh nghiệp và chuỗi công cụ mà GitHub đã xây dựng.

Cơ hội của nó đến từ việc Agent thay đổi chi phí hợp tác. Stacked PR là một ví dụ điển hình.

Các nhà phát triển con người thường có xu hướng tổng hợp một tính năng thành một PR tương đối hoàn chỉnh. Mỗi khi tách ra một PR, sẽ tăng thêm một ngữ cảnh, một vòng đánh giá và một nhóm phụ thuộc branch. Nếu một thay đổi được tách thành hàng chục PR, con người rất dễ tốn nhiều năng lượng để duy trì các mối quan hệ này.

Cấu trúc chi phí của Agent khác nhau. Khi một thay đổi trải rộng qua hàng chục tệp, bất kỳ bước nào thất bại đều có thể khiến Agent phải hiểu lại bối cảnh rộng lớn. Khi chia thành các tập thay đổi nhỏ hơn, các chỉnh sửa về schema, service, UI... có thể tạo thành các phụ thuộc rõ ràng, mỗi nút được xác minh riêng biệt, và khi thất bại chỉ xử lý các phần liên quan.

Do đó, PR nhỏ có thể trở thành checkpoint của Agent, giúp nhiệm vụ có khả năng xác minh cục bộ, thử lại cục bộ và theo dõi phụ thuộc.

Việc Cursor mua lại Graphite cũng có thể được hiểu theo cách này. Bản early beta hiện tại của Origin chưa hoàn toàn tích hợp quy trình stacked của Graphite, nhưng các tính năng stacked PR và stack-aware merge queue mà Graphite đã đầu tư lâu dài lại chính xác giải quyết các nút thắt sau này phát sinh sau khi Agent tăng tốc độ tạo mã.

Sau khi số lượng PR tăng lên, nhiệm vụ của hàng đợi merge cũng sẽ nặng hơn. Agent A và Agent B có thể cùng làm việc từ cùng một base SHA, cả hai bên đều vượt qua bài kiểm tra.

Sau khi A vào main, kết quả kiểm tra của B chỉ chứng minh được mã hoạt động đúng ở trạng thái cũ, không thể chứng minh rằng nó vẫn an toàn sau khi chuyển sang main mới. Do đó, queue cần dựa trên main đang thay đổi để tái xây dựng các trạng thái ứng cử, thực hiện lại các kiểm tra và xử lý các phụ thuộc giữa các PR.

Conflict cũng có thể dần trở thành trạng thái lỗi có thể khôi phục trong quy trình. Cursor đã cung cấp khả năng loại /babysit, xử lý liên tục phản hồi PR, các check thất bại và xung đột. Sau khi候选 merge gặp vấn đề, ngữ cảnh liên quan có thể được chuyển lại cho Agent để sửa chữa và xác minh lại trong môi trường cách ly.

các bản đánh giá cũng sẽ được cấu trúc hóa. Sự hợp tác của con người phụ thuộc rất nhiều vào ngôn ngữ tự nhiên và kinh nghiệm nhóm, trong khi Agent chạy trong thời gian dài cần đọc rõ ràng lỗi check nào đã xảy ra, các thread nào chưa được giải quyết, chính sách nào chưa được đáp ứng, và SHA hiện tại là gì.

Origin đã công khai các đối tượng repository, commit, checks, PR thông qua API và phân biệt giữa đánh giá chính thức và thảo luận thông thường.

Các trạng thái có cấu trúc này sau đó có thể được Automations tiêu thụ trực tiếp. push, PR opened hoặc PR pushed sẽ kích hoạt cloud agent, kết quả thực thi sẽ được ghi lại vào checks và PR, nếu thất bại sẽ chuyển vào quy trình xử lý. MCP, hooks và Agent API cho phép các công cụ bên ngoài tham gia vào cùng một chuỗi sự kiện.

“Tách khỏi GitHub” giải quyết lộ trình di chuyển. Nhóm có thể trước tiên mirror repository trên GitHub, giữ cho GitHub là nguồn sự thật, đồng thời chuyển luồng làm việc của Agent sang Origin; sau khi chạy ổn định thì ngắt kết nối đồng bộ và để Origin quản lý kho lưu trữ độc lập.

Điều này cho phép Cursor ban đầu tiếp nhận Agent, PR, review, checks và Automation, sau đó dần dần giữ lại nhiều trạng thái kỹ thuật hơn trong hệ thống của chính nó.

Do đó, logic sản phẩm của Origin rất rõ ràng: Git tiếp tục đảm nhận vai trò kiểm soát phiên bản, còn Origin muốn tái tạo lớp điều khiển phía trên Git, được xây dựng xung quanh sự hợp tác của các Agent tần suất cao.

03 Lão Mã đang thu gọn một chuỗi sản xuất AI

Trong hơn một năm qua, chuỗi hành động giữa xAI, X, SpaceX và Cursor đã dần hình thành mối quan hệ上下游 hoàn chỉnh hơn.

xAI mua lại X, sau đó gia nhập hệ thống SpaceX; Cursor nhận được nguồn tính toán Colossus, sau đó cũng gia nhập hệ thống SpaceX. Đồng thời, Grok 4.6 được phát hành, Origin bắt đầu mở cửa.

Con đường này tương tự với tư duy tích hợp dọc mà Musk từng áp dụng tại Tesla: khi các khâu bên ngoài bắt đầu gia tăng ma sát trong quá trình lặp lại, hãy tiếp tục mở rộng lên trên và xuống dưới chuỗi cung ứng, đưa các giao diện then chốt vào cùng một hệ thống.

Agent hiện đang đối mặt với vấn đề này. Mô hình có thể thực hiện suy luận, nhưng một tác vụ phần mềm còn yêu cầu truy cập kho, sửa đổi tệp, chạy kiểm thử, xử lý CI, nhận phản hồi, giải quyết xung đột và khôi phục thực thi sau khi thất bại.

Nếu các khâu này được phân tán trong nhiều hệ thống khác nhau, mỗi nhiệm vụ sẽ cần đồng bộ hóa quyền truy cập, ngữ cảnh và trạng thái lặp đi lặp lại, chi phí giao diện sẽ tích lũy liên tục trong vòng lặp Agent đang chạy.

Colossus, Grok, Cursor và Origin lần lượt tương ứng với các cấp độ khác nhau trên chuỗi này: Colossus cung cấp sức mạnh tính toán, Grok cung cấp khả năng mô hình, Cursor cung cấp Agent mã và môi trường thực thi, Origin lưu trữ trạng thái repository, PR, checks và review.

Mã được tạo ra tạo thành một chuỗi liên tục: mô hình đưa ra quyết định, Cursor chuyển đổi quyết định đó thành các thay đổi thực tế, Origin lưu trạng thái dự án và chịu trách nhiệm kiểm soát hợp tác tiếp theo.

Điều này cũng thay đổi tiêu chí đánh giá Grok 4.6. Khả năng của mô hình vẫn quan trọng, nhưng đầu ra của hệ thống Agent còn phụ thuộc vào môi trường thực thi và cơ sở hạ tầng kỹ thuật. Một đoạn mã dù có chất lượng tạo ra tốt, nhưng nếu vẫn cần con người sao chép, thực thi, kiểm tra và gửi lại, thì khả năng của mô hình khó có thể được khuếch đại liên tục.

Sau khi mô hình đã đạt đến mức độ có thể sử dụng được, tốc độ code có thể nhanh chóng đi vào quy trình thực thi, xác minh và hợp nhất sẽ ngày càng ảnh hưởng đến đầu ra của toàn bộ hệ thống.

Vị trí của X trong chuỗi này hiện vẫn còn khá mờ nhạt. Nó sở hữu nội dung thời gian thực, mối quan hệ người dùng, danh tính và mạng lưới phân phối, trong tương lai có thể trở thành nguồn nhiệm vụ và cổng phân phối; ở giai đoạn hiện tại, Grok Bot về mặt sản phẩm gần với lớp thực thi nhiệm vụ liên tục hơn là chỉ là một “trợ lý trò chuyện thụ động chờ đợi câu hỏi” như nhiều người tưởng tượng.

Cursor cần Origin, và điều này cũng giải thích: sau khi sinh mã, cần một hệ thống lưu trữ trạng thái dự án lâu dài, phối hợp các thay đổi, xác minh kết quả và kết nối các bước thực thi tiếp theo. Nếu vị trí này luôn nằm ngoài, chuỗi sản xuất phần mềm Agent sẽ tồn tại một phụ thuộc then chốt.

Và Origin lấp đầy chính lớp này.

04 Sự khác biệt giữa GitHub và Origin

GitHub đã sở hữu stacked PR, merge queue, REST API và đang liên tục tích hợp Copilot coding agent vào Issue, Actions, PR và code review. Chỉ nhìn vào danh sách tính năng, hai nền tảng này sẽ ngày càng có nhiều điểm trùng lặp trong tương lai.

Sự khác biệt chủ yếu đến từ các giả định thiết kế.

GitHub được xây dựng trên mạng lưới các nhà phát triển con người đã trưởng thành, do đó, con đường tự nhiên hơn là để Agent tham gia vào các hệ thống Issue, PR, Actions và bảo vệ branch hiện có.

Cursor có thể tái thiết kế các thành phần này dựa trên sự hợp tác mật độ cao của các Agent. Nếu một repository chạy liên tục hàng chục Agent, số lượng PR tăng lên, mức độ thay đổi trở nên tinh vi hơn và trạng thái thay đổi nhanh hơn, thì các hệ thống review, checks, merge và quyền hạn cần được tổ chức lại xung quanh hành vi của máy móc.

Vai trò của PR cũng có thể được mở rộng. Nó có thể dần trở thành một đơn vị công việc kỹ thuật bao gồm diff, mối quan hệ phụ thuộc, bằng chứng kiểm thử, nguồn gốc, mức độ rủi ro và trạng thái phê duyệt, thay vì chỉ là một bản sửa đổi mã chủ yếu dành để đọc.

Trách nhiệm của con người sẽ ngày càng tập trung vào cấp độ quy tắc: những thư mục nào được phép tự động chỉnh sửa, việc nâng cấp phụ thuộc được phép vượt qua bao nhiêu phiên bản, các bản di chuyển cơ sở dữ liệu cần những xác minh nào, mã liên quan đến xác thực và thanh toán cần trải qua những phê duyệt nào, và trong những tình huống nào Agent phải dừng hoạt động.

Tương ứng, các chỉ số của Agent-native forge cũng sẽ thay đổi. 22.6 commit/s rất nổi bật, nhưng số lượng commit bản thân không thể đại diện cho hiệu suất sản xuất phần mềm. Các chỉ số có ý nghĩa hơn sẽ là thời gian từ khi nhiệm vụ được đưa vào hệ thống đến khi merge, khả năng phục hồi cục bộ sau khi thất bại, tỷ lệ các thay đổi được tự động hoàn thành trong policy, chi phí tính toán của các change được chấp nhận, và sự chú ý nhân công tiêu tốn cho các thay đổi rủi ro cao.

Origin muốn kiểm soát chính là bề mặt kiểm soát sản xuất phần mềm được hình thành từ sự hội tụ của repository, checks, review, quyền và events.

Sự cạnh tranh giữa GitHub và Origin do đó sẽ dần tập trung vào hai hướng đi: GitHub mở rộng từ hệ thống hợp tác con người trưởng thành sang Agent, trong khi Cursor cố gắng thiết kế lại forge theo tải công việc của Agent.

05 Lão Mã đã ở tầng dưới

Nói lại thì, sau khi Grok 4.6 được ra mắt, bên ngoài dễ dàng tiếp tục thảo luận về benchmark về khả năng mã hóa, điểm suy luận và giá cả. Nhưng khi xem xét cùng lúc Colossus, Grok, Cursor và Origin, thực tế bộ bố trí này đã mở rộng sang chuỗi sản xuất phần mềm sau mô hình.

Colossus cung cấp sức mạnh tính toán, Grok phụ trách suy luận, Cursor biến khả năng mô hình thành các thay đổi mã, Origin tiếp nhận trạng thái kho, PR, checks và review tiếp theo. Khi khả năng mô hình được cải thiện, lợi ích có thể được truyền trực tiếp dọc theo chuỗi thực thi; ngay cả khi mô hình thế hệ đơn lẻ không tạo ra sự khác biệt rõ rệt, các cơ sở hạ tầng phía sau vẫn có thể tiếp tục tích lũy.

Vì vậy, vị trí của Grok 4.6 hôm nay trên một bảng xếp hạng nào đó có thể chỉ là kết quả mang tính giai đoạn. Vấn đề dài hạn hơn là ai có thể tổ chức mô hình, môi trường thực thi và trạng thái kỹ thuật phần mềm thành một hệ thống sản xuất hoạt động liên tục.

Khi mọi người vẫn đang tranh luận mô hình nào thông minh hơn trong đợt này, thì Lão Mã đã bước xuống tầng tiếp theo.