Lần đầu tiên bạn chạy ba coding agent cùng lúc, khâu thực thi không còn là phần chậm nhất nữa. Bạn giao một bug cho Claude Code, một refactor cho Codex, và một lỗ hổng test coverage cho Runtime thứ ba; bốn mươi phút sau, ba branch đã sẵn sàng. Nhưng đó cũng là lúc bắt đầu chờ thật sự, vì cả ba đang chờ bạn. Bạn đọc diff đầu tiên, duyệt nó, còn hai cái kia thì ngồi không. Bạn có thực thi song song nhưng review tuần tự, nên tính song song gần như chẳng mang lại gì.
Đây là cái bẫy mà mọi đội ngũ giỏi chạy agent song song đều dính phải. Điểm nghẽn không biến mất; nó dịch chuyển, từ “agent viết code nhanh đến đâu” sang “một người đọc, đánh giá và chấp nhận kết quả nhanh đến đâu”. Thêm một agent thứ tư chỉ làm mọi thứ tệ hơn: hàng đợi công việc đã xong dài hơn, mà vẫn chỉ một người review.
Cách giải quyết không phải là review nhanh hơn hay tin tưởng nhiều hơn, mà là thiết kế khâu review thành một phần rõ ràng của quy trình, thay vì để nó là việc nghĩ đến sau, nằm trong đầu bạn. Đó là quy trình mà bài viết này sẽ đi qua, và cũng là bài toán mà Sharkly được xây dựng để giải: giữ mục tiêu, diff, bằng chứng và phần review của mọi lượt agent chạy trong cùng một Task, để hàng đợi review trở thành thứ bạn nhìn thấy và quản lý được, thay vì một đống tab trình duyệt đang mở.
Vì sao chạy agent song song lại đẩy điểm nghẽn sang khâu review
Review là một hàng đợi. Các lượt agent chạy xong đến với một tốc độ nào đó, một người xử lý chúng với một tốc độ nào đó, và nếu tốc độ đến vượt tốc độ xử lý thì hàng đợi sẽ dài ra vô hạn. Toàn bộ câu chuyện chỉ có vậy, và đó là lý do thông lượng agent thô là con số sai để tối ưu. Nếu mười agent hoàn thành trong một giờ mà bạn chỉ có thể cẩn thận nghiệm thu ba thay đổi mỗi giờ, thì bạn đã xây một nhà máy mà bến bốc hàng chỉ có một người cầm bảng kẹp giấy.
Phần lớn công cụ che giấu điều này. Một chồng pull request cho bạn thấy công việc, nhưng không cho biết mục nào thật sự đang chờ quyết định, mục nào vẫn đang chạy, mục nào đã merge. Hàng đợi là có thật, nhưng nó nằm rải rác khắp các tab, thông báo và trong trí nhớ bạn. Mục tiêu thiết kế đầu tiên là làm cho nó hiện ra, vì bạn không thể quản lý một điểm nghẽn mà mình không nhìn thấy. Một bài viết đồng hành về phép toán năng lực review sẽ phân tích điều gì xảy ra khi mức độ song song tăng lên.
Mô hình vận hành: ai giao việc, ai chạy, ai review, ai nghiệm thu
Trước khi động đến các trạng thái, hãy gọi tên bốn công việc. Chúng là những công việc khác nhau, và chính việc lẫn lộn chúng khiến khâu review trở nên hỗn loạn.
Ai đó giao việc: biến một ý định thành một Task có phạm vi rõ ràng kèm tiêu chí nghiệm thu. Một thứ gì đó chạy nó: một Agent, trên một Computer, thực thi trong một Runtime, tạo ra thay đổi và bản ghi về những gì nó đã làm. Ai đó review kết quả: đọc diff và bằng chứng, quyết định xem kết quả có đáp ứng tiêu chí hay không. Ai đó nghiệm thu nó: đưa ra quyết định merge và release, một quyết định khác với “code trông ổn đấy”.
Sharkly phát biểu giao kèo này trong một câu đáng dán lên giấy nhớ: agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người định hướng, trao quyền và nghiệm thu kết quả. Tự động hóa dừng lại đúng ở chỗ cần đến phán đoán của đội ngũ. Giao việc và nghiệm thu mặc định là việc của con người. Chạy là việc của Agent. Review là công việc phải được thiết kế kỹ càng, vì đó là nơi hàng đợi hình thành.
Một ranh giới hữu ích: PR đã merge không đồng nghĩa với kết quả đã được nghiệm thu. Merge là một thao tác git. Nghiệm thu là việc một người quyết định rằng thay đổi đó làm đúng điều Task yêu cầu. Khi hai việc này gộp thành một cú click, chất lượng review sẽ tụt xuống đúng mức năng lượng mà người review có được trong phút đó.
Vai trò, trạng thái và các cổng review
Hãy tạo hình dạng cho hàng đợi bằng cách cho mỗi Task một tập trạng thái nhỏ mà agent và con người di chuyển qua lại. Task là đơn vị công việc chính: nó chứa mục tiêu, cuộc trao đổi và lượt chạy. Ý nghĩa của các trạng thái nằm ở chỗ agent có thể đẩy một Task đi cho tới sát cổng review, và chỉ con người mới có thể đưa nó qua cổng đó.
| Trạng thái | Ai chuyển nó tới đây | Ý nghĩa |
|---|---|---|
| Backlog | Con người | Đã xác định phạm vi, chưa bắt đầu. Không có lượt chạy nào ở đây. |
| Ready | Con người | Đã cho phép chạy; một Agent có thể nhận nó. |
| In progress | Agent | Một lượt chạy đang thực thi trong một worktree tách biệt. |
| Ready for review | Agent | Lượt chạy đã xong, thay đổi và bằng chứng đã được đính kèm, đang chờ con người. |
| Changes requested | Con người | Bị trả lại kèm bình luận; một lượt chạy tiếp theo sẽ tiếp tục trên chính Task đó. |
| Done | Con người | Đã nghiệm thu, đã merge, đã release. |
Cổng review là bước chuyển vào Ready for review và bước chuyển ra Done. Agent có thể tự mình tới cổng; nhưng không thể đi qua. Chính quy tắc duy nhất đó cho phép bạn chạy mười agent một cách an toàn: chúng lấp đầy cột Ready for review song song, còn bạn xử lý cột đó với tốc độ sao cho chất lượng vẫn được giữ đúng. Độ dài của cột chính là điểm nghẽn của bạn, được phơi bày rõ ràng.
Đây là cặp quyết định trung thực. Hãy đặt cổng cho mọi thay đổi được phát hành tới người dùng hoặc đụng tới tiền, auth, migration dữ liệu hay API công khai. Đừng đặt cổng cho những spike làm rồi bỏ, boilerplate sinh tự động mà kiểu gì bạn cũng tạo lại, hay công việc nằm sau một feature flag chưa ai chạm tới. Đặt cổng cho tất cả chỉ đẩy điểm nghẽn trở lại người review, cho những thay đổi vốn chẳng cần đến con người. Các cổng phê duyệt sẽ nói về việc nên đặt điểm dừng ở đâu cho công việc có rủi ro cao hơn.
Thiết kế khâu review để có thể mở rộng
Review kết quả của các agent chạy song song không giống review PR của đồng nghiệp. Bạn có nhiều thứ để review hơn, chúng ập đến thành từng đợt, và bạn thường biết ít hơn về cách chúng được tạo ra. Ba động thái sau giúp giảm chi phí review cho mỗi mục.
Đính bằng chứng vào Task, chứ không phải vào trí nhớ của bạn. Một lượt chạy nên trả về bản tóm tắt thay đổi, kết quả typecheck và test, kết quả build, cùng những giới hạn đã biết — tất cả đều được ghi lại. Khi bạn mở một mục Ready for review, bạn đang đọc một hồ sơ vụ việc, chứ không phải dựng lại xem chuyện gì đã xảy ra. Đó là khác biệt giữa review với bằng chứng ở cấp Task và việc tự chạy lại mọi thứ để lấy lại niềm tin.
Review quyết định, không review từng phím gõ. Những thuộc tính máy kiểm được — định dạng, an toàn kiểu, test có pass hay không — nên được máy chặn lại trước khi Task tới tay bạn. Hướng dẫn review code của Google cũng đưa ra cách phân chia tương tự: tự động hóa những gì công cụ kiểm tra được để con người dành sự chú ý cho thiết kế và độ phù hợp. Phán đoán quý giá của bạn nên dành cho câu hỏi “đây có phải thay đổi đúng không”, chứ không phải “nó có compile không”.
Giới hạn số việc đang làm. Một mức trần cứng cho số Task cùng nằm ở In progress sẽ giữ cho cột Ready for review không biến thành bức tường mà bạn mãi không vượt qua được. Đây chính là ý tưởng giới hạn WIP của kanban áp dụng cho agent: bắt đầu lượt chạy thứ sáu khi đã có năm lượt đang chờ bạn không làm tăng thông lượng, mà chỉ che giấu hàng đợi. Việc theo dõi các agent đang chạy cũng hữu ích, để bạn phân biệt được một lượt chạy bị kẹt với một lượt chạy chậm trước khi nó tới cổng review.
Một ví dụ cụ thể, từ ticket đến PR đã merge
Lấy một Task trông có vẻ thật, SH-312: “Giới hạn tần suất cho endpoint tìm kiếm công khai.” Một người định hình nó trong Backlog với các tiêu chí nghiệm thu (trả 429 sau N request mỗi phút cho mỗi key, có header được ghi trong tài liệu, có một test) rồi chuyển nó sang Ready.
Ba Agent đang làm việc song song trong Space. Một agent nhận SH-312, clone repository đã cấu hình lên một Computer, và chạy trong một worktree tách biệt để branch của nó không bao giờ đụng với hai lượt chạy đang diễn ra. Nó viết bộ giới hạn tần suất, thêm test, chạy typecheck và toàn bộ test suite, mở một PR có tiêu đề mang Task ID, rồi chuyển SH-312 sang Ready for review kèm bản tóm tắt thay đổi, kết quả test đã pass, và ghi chú một giới hạn đã biết: bộ đếm nằm trong tiến trình, không được chia sẻ giữa các instance.
Bạn mở Task, chứ không phải mười lăm cái tab. Bằng chứng nằm ngay đó, và phần hữu ích nhất là ghi chú về giới hạn đã biết: test pass, nhưng trạng thái chia sẻ giữa các instance là một quyết định thiết kế mà bạn phải đưa ra. Bạn để lại một bình luận và chuyển nó sang Changes requested. Bình luận đó khởi động một lượt chạy tiếp theo trên chính Task ấy; Agent chuyển bộ đếm sang một store chia sẻ và trả về bằng chứng đã cập nhật. Lần này bạn nghiệm thu. Việc chuyển SH-312 sang Done là quyết định của bạn, được ghi lại thành một thay đổi trạng thái mang tên bạn, chứ không phải một hệ quả âm thầm của một lệnh merge git.
Trong lúc đó, hai Agent còn lại đang nằm ở Ready for review. Vì hàng đợi là một cột chứ không phải hộp thư đến của bạn, bạn xử lý chúng tiếp theo, theo đúng thứ tự, mà không bị mất mạch.
Vạch ranh giới bạn giữ cho con người
Agent song song là câu chuyện về thông lượng, cho tới khi review trở thành điểm hạn chế — và khi đó nó thành câu chuyện về hàng đợi. Những đội ngũ thu được giá trị từ nhiều agent coi review là hạ tầng được thiết kế bài bản: trạng thái rõ ràng, một cổng mà agent tới được nhưng không qua được, bằng chứng gắn với Task, kiểm tra bằng máy trước khi tới con người, và một giới hạn cho số việc đang chạy.
Bạn có thể tự dựng cơ chế này bằng worktree, một quy ước đặt tên branch và tính kỷ luật. Hoặc để Sharkly quản lý quy trình: Agents có thể giao việc, Tasks mang theo lượt chạy và bằng chứng của nó, cùng một board nơi Ready for review là một cột bạn xử lý dần, để agent nghiên cứu, thực thi, kiểm thử và báo cáo trong khi con người giữ quyết định cuối cùng. Nếu bạn đã chạy nhiều agent, đây là một nơi để quản lý công việc và kết quả của chúng, thay vì trông cậy vào trí nhớ.
Câu hỏi thường gặp
Chạy agent song song có tiết kiệm thời gian khi khâu review vẫn tuần tự không? Chỉ đến mức mà các lượt chạy đã xong đến nhanh hơn khả năng nghiệm thu của bạn. Vượt qua mức đó, thêm agent chỉ làm hàng đợi review dài ra mà không đưa được gì ra sớm hơn. Lợi ích đến từ việc làm cho khâu review hiện rõ và chỉ đặt cổng cho những gì thật sự cần con người.
Có phải mọi thay đổi của agent đều cần con người review không? Không. Hãy đặt cổng cho những thay đổi được phát hành tới người dùng hoặc đụng tới auth, dữ liệu, tiền hay API công khai. Hãy để công việc rủi ro thấp hoặc có thể tạo lại đi qua chỉ với kiểm tra bằng máy. Đặt cổng cho tất cả sẽ đẩy điểm nghẽn trở lại người review, cho những thay đổi vốn không cần ai review.
Merge PR có phải là nghiệm thu công việc không? Không. Merge là một thao tác git; nghiệm thu là việc một người quyết định rằng thay đổi đáp ứng tiêu chí của Task. Giữ hai việc này tách biệt sẽ bảo toàn chất lượng review khi khối lượng công việc lớn. Xem human-in-the-loop coding agents để biết nên giữ quyết định của con người ở đâu.
