Trả lời nhanh: Chạy nhiều subagent song song chỉ có lợi khi bạn giải quyết trước một chuyện: ai được sửa file nào. Hai phiên cùng sửa một file thì phiên chạy sau ghi đè công của phiên trước, và không ai báo cho bạn biết. Vì vậy thiết kế đội agent thực chất là thiết kế ranh giới quyền sở hữu, giống hệt cách chia việc cho người thật. Thêm hai thứ nữa là đủ dùng: mỗi phiên có tiêu chí hoàn thành rõ ràng và một bước gộp do bạn kiểm soát.
Khi đã quen giao một việc cho một phiên phụ, ai cũng nghĩ tới bước tiếp theo: cho năm phiên chạy cùng lúc để xong nhanh gấp năm. Thực tế thì tăng tốc có thật, nhưng kèm một loại lỗi mới mà làm tuần tự không bao giờ gặp. Bài này nói về cách tổ chức để hưởng phần tăng tốc mà không dính phần lỗi.
Quyền sở hữu file là luật số một
Nguyên tắc duy nhất không được phá: tại một thời điểm, mỗi file chỉ có đúng một phiên được quyền sửa. Nếu hai phiên cùng sửa, phiên xong sau đọc file trong bộ nhớ của nó rồi ghi đè, và thay đổi của phiên kia biến mất im lặng.
Cách chia thực dụng theo lớp của dự án:
- Phiên A sở hữu thư mục giao diện.
- Phiên B sở hữu thư mục API và tầng dịch vụ.
- Phiên C sở hữu thư mục kiểm thử.
Ghi ranh giới đó thẳng vào prompt giao việc, kèm câu cấm rõ ràng: chỉ sửa trong thư mục được giao, gặp việc cần sửa chỗ khác thì dừng lại và báo cáo chứ không tự làm. Câu cấm này quan trọng vì mô hình luôn có xu hướng làm nhiều hơn phạm vi được giao.
Với việc chỉ đọc, ví dụ rà soát bảo mật hoặc dò tìm chỗ dùng một hàm, bạn chạy bao nhiêu phiên song song cũng được vì không có xung đột. Đây là loại việc hưởng lợi nhiều nhất từ song song, như đã nói ở bài khi nào nên tách việc.
Ba mô hình chia việc hay dùng
Chia theo lớp kiến trúc. Mỗi phiên một tầng: giao diện, nghiệp vụ, dữ liệu. Hợp khi tính năng mới đụng nhiều tầng nhưng ranh giới giữa các tầng đã rõ. Rủi ro là hợp đồng giữa các tầng, nên hãy chốt trước định dạng dữ liệu trao đổi rồi mới giao việc.
Chia theo tính năng. Mỗi phiên làm trọn một tính năng nhỏ từ đầu tới cuối. Hợp khi các tính năng độc lập, ví dụ ba trang quản trị khác nhau. Ít xung đột nhất trong ba mô hình.
Chia theo vai trò. Một phiên viết code, một phiên viết kiểm thử, một phiên rà soát. Hợp với việc cần nhiều góc nhìn hơn là cần nhanh. Lưu ý phiên rà soát nên chạy sau chứ không cùng lúc, vì rà soát code đang thay đổi là vô nghĩa.
Với mô hình đầu tiên, nhiều người dùng thêm nhánh Git riêng cho mỗi phiên để cách ly hoàn toàn, cách làm nằm ở bài Git worktree.
Viết prompt giao việc cho từng phiên
Phiên con không thấy gì ngoài prompt bạn đưa. Một prompt đủ dùng gồm sáu phần:
- Việc cần làm, một câu.
- Bối cảnh tối thiểu, chỉ những quyết định phiên đó cần biết, không kể lể toàn bộ dự án.
- File được đọc, ghi đường dẫn cụ thể.
- File được sửa, ghi rõ, kèm câu cấm sửa ngoài phạm vi.
- Tiêu chí hoàn thành, kiểm chứng được, ví dụ lệnh kiểm thử nào phải chạy qua.
- Định dạng báo cáo, thường là danh sách ngắn kèm đường dẫn và số dòng.
Phần cuối hay bị bỏ và hậu quả là mỗi phiên trả về mấy trang văn xuôi, khiến bước gộp của bạn nặng hơn cả việc tự làm. Hãy nói thẳng số dòng tối đa.
Nếu bạn giao cùng một dạng việc nhiều lần, đóng gói prompt đó thành skill theo bài viết skill đầu tiên, khỏi phải gõ lại và tránh sót phần cấm.
Bước gộp phải do bạn kiểm soát
Sai lầm phổ biến là để một phiên khác đứng ra ghép kết quả của các phiên còn lại. Nghe hợp lý nhưng thực tế phiên gộp không đủ bối cảnh để phán xét, và nó có xu hướng chấp nhận mọi thứ được đưa cho.
Quy trình gộp an toàn:
- Đọc báo cáo ngắn của từng phiên, chưa xem code vội.
- Xem thay đổi thật bằng công cụ so sánh, từng phiên một.
- Chạy toàn bộ kiểm thử sau khi ghép, không phải sau từng phần.
- Chỉ khi tất cả đã xanh mới ghi nhận vào nhánh chính.
Với thay đổi động tới database hoặc cấu hình máy chủ, hãy giữ nguyên tắc cứng: không bao giờ cho phiên song song đụng vào những thứ đó. Chuỗi migration là tài nguyên có thứ tự, hai phiên cùng thêm sẽ tạo ra hai bản ghi tranh nhau và bạn sẽ gỡ rất lâu.
Chi phí thật và giới hạn máy
Ba loại chi phí cần tính trước khi mở rộng số phiên:
Chi phí gọi mô hình. Mỗi phiên có ngữ cảnh riêng nên năm phiên nghĩa là năm lần dựng bối cảnh. Với việc đọc nhiều thì vẫn lời, với việc nhỏ thì lỗ.
Chi phí máy. Mỗi phiên chạy lệnh thật: cài gói, biên dịch, chạy kiểm thử. Năm phiên cùng chạy kiểm thử trên một laptop 16GB là công thức của quạt kêu và mọi thứ chậm đều. Đây là lý do nhiều người chuyển phần này lên máy chủ theo bài chạy Claude Code trên VPS.
Chi phí chú ý của bạn. Ba phiên là mức phần lớn người theo dõi nổi. Vượt lên năm thì bạn bắt đầu duyệt qua loa, và duyệt qua loa thì mất luôn lý do dùng agent.
Lời khuyên thực tế: bắt đầu với hai phiên song song cho một tính năng, chỉ tăng khi bạn thấy bước gộp vẫn nhẹ nhàng.
Quyền sở hữu tệp là luật số một
| Cách chia | Có an toàn không | Ghi chú |
|---|---|---|
| Mỗi phiên một thư mục riêng, không chồng lấn | An toàn | Đây là cách đúng |
| Mỗi phiên một nhánh mã riêng | An toàn | Gộp về sau, do bạn kiểm soát |
| Nhiều phiên cùng sửa một tệp | Không an toàn | Ghi đè lẫn nhau, mất công việc |
| Nhiều phiên cùng chạy lệnh cài thư viện | Không an toàn | Xung đột tệp khóa phiên bản |
| Nhiều phiên cùng sửa cấu hình chung | Không an toàn | Cùng lý do |
Quy tắc đơn giản để nhớ: hai phiên không bao giờ được ghi vào cùng một tệp. Vi phạm quy tắc này là mất công việc, và mất theo cách khó phát hiện vì không có báo lỗi nào.
Chia việc theo tầng, theo tệp hay theo giai đoạn
- Chia theo tầng: một phiên làm phần giao diện, một phiên làm phần máy chủ, một phiên làm phần cơ sở dữ liệu. Ranh giới tệp rõ ràng nhất.
- Chia theo tính năng: mỗi phiên một tính năng độc lập, mỗi tính năng một thư mục riêng.
- Chia theo vai trò rà soát: nhiều phiên cùng đọc một đoạn mã nhưng theo các tiêu chí khác nhau, và không phiên nào được sửa. An toàn nhất vì chỉ đọc.
Mỗi phiên một nhánh, người gộp là bạn
# Khong bao gio de cac phien tu gop viec cua nhau # Quy trinh dung:# 1. Moi phien lam trong nhanh rieng, hoac thu muc rieng# 2. Ban doc ket qua tung phien# 3. Ban gop, hoac giao viec gop cho MOT phien duy nhat# 4. Chay bo kiem thu day du sau khi gop# 5. Doc lai phan gop truoc khi dua len # Kiem xung dot truoc khi gopgit statusgit diff --stat # Neu hai phien cung sua mot file: dau hieu chia viec sai tu dauBốn phiên song song là tốn gấp bốn
- Mỗi phiên tốn riêng. Bốn phiên song song là tốn gấp bốn. Chỉ dùng khi việc thật sự tách được và thật sự gấp.
- Bộ nhớ là thứ chạm trần trước: mỗi phiên giữ ngữ cảnh riêng. Xem cấu hình theo số phiên ở bài chạy nhiều phiên song song.
- Ổ đĩa cũng chạm trần: nhiều phiên cùng quét dự án là nhiều lần đọc cùng một tập tệp. Loại thư mục thư viện khỏi phạm vi quét trước khi chạy song song.
Câu hỏi thường gặp
Bao nhiêu subagent song song là hợp lý?
Hai tới ba cho việc có sửa code, vì bạn còn phải xem lại từng phần. Việc chỉ đọc như dò tìm hay rà soát thì nhiều hơn vẫn được, giới hạn khi đó nằm ở hạn mức gọi của gói và sức máy chứ không ở khả năng theo dõi.
Làm sao tránh hai phiên sửa cùng một file?
Ghi ranh giới file vào prompt của từng phiên kèm câu cấm sửa ngoài phạm vi, và chọn cách chia việc sao cho ranh giới trùng với ranh giới thư mục. Khi việc buộc phải chạm chung, hãy tự làm phần chung trước rồi mới giao phần còn lại.
Có nên cho mỗi phiên một nhánh Git riêng không?
Nên khi các phiên sửa nhiều file và bạn muốn cách ly tuyệt đối. Cách này tốn thêm bước gộp nhánh nhưng đổi lại không bao giờ có chuyện ghi đè. Với việc nhỏ trong hai thư mục tách biệt thì chia theo thư mục là đủ.
Máy chủ cấu hình bao nhiêu để chạy nhiều phiên?
Tính theo việc mà các phiên chạy chứ không theo số phiên. Nếu mỗi phiên chỉ đọc và sửa file thì nhẹ. Nếu chúng cùng biên dịch hoặc chạy kiểm thử thì nên từ 4 vCPU và 8GB, và ổ đĩa nhanh giúp rõ vì nhiều tiến trình cùng đọc ghi.