Khi nào nên dùng nhiều coding agent?

Ở cuối bài trước, mình nói rằng một bản bàn giao tốt giúp agent mới tiếp tục task mà không cần đọc lại toàn bộ đoạn chat.

Từ đó có một câu hỏi khá tự nhiên: nếu nhiều agent đều có thể nhận việc từ cùng một nguồn chuẩn, tại sao không cho chúng làm song song?

Một agent tìm hiểu API. Một agent làm giao diện. Một agent viết test. Thêm một agent rà bảo mật. Nghe giống như mình vừa có nguyên team chỉ sau một prompt, quá hời.

Mình cũng từng nghĩ vậy.

Nhưng kịch bản rất dễ xảy ra là ba agent cùng sửa một file schema, hai agent tự chọn hai thoả thuận API khác nhau, còn agent thứ tư review một diff đã hết hạn. Lúc đó “nguyên team” vẫn còn, chỉ có mình thành người đi dọn hiện trường.

Nhiều agent có thể giúp công việc nhanh hơn. Nhưng chỉ khi task thật sự tách độc lập, phần việc thuộc về ai đã rõ và có một nơi chịu trách nhiệm gom kết quả.

Bài này không nhằm biến mọi tính năng thành một đội quân agent. Mục tiêu là biết lúc nào một agent là đủ, lúc nào nên giao một nhánh cho agent phụ và lúc nào các agent thực thi cần worktree riêng.

Nhiều agent không tạo thành một agent lớn hơn

Khi dùng nhiều agent, mình không mở rộng bộ não của agent hiện tại.

Mình tạo thêm những agent phụ có ngữ cảnh riêng.

Mỗi agent phụ vẫn phải đọc sổ tay project, hiểu task, mở file liên quan và tự dựng ngữ cảnh. Nó không tự biết mọi thứ đã xảy ra trong session chính, trừ khi mình truyền phần đó vào prompt hoặc đặt trong một nguồn chuẩn mà cả hai cùng đọc được.

Vì vậy, cách làm nhiều agent thường có hai vai trò:

• Agent chính giữ mục tiêu, các quyết định, phần phụ thuộc và kết quả cuối.
• Agent phụ nhận một phần việc có ranh giới rõ rồi trả lại đầu ra hoặc bản tóm tắt.

Nếu agent phụ còn phải hỏi agent chính sau mỗi vài phút, phần việc đó chưa đủ độc lập để chạy song song.

Mình thường nhìn các cách chạy như sau:

Tên gọi có thể khác giữa Codex, Claude Code hoặc công cụ khác. Ranh giới quan trọng hơn tên sản phẩm: agent phụ thấy ngữ cảnh nào, có được sửa file không, ai sở hữu phần việc và kết quả quay về đâu.

Câu hỏi quan trọng không phải là cần bao nhiêu agent

Mình không bắt đầu bằng câu hỏi “task này gọi thêm mấy agent?”.

Mình bắt đầu bằng câu hỏi phần việc nào có thể hoàn thành mà không phải chờ phần còn lại?

Lợi ích thực tế của việc chạy song song có thể nghĩ đơn giản như vầy:

Nếu một agent có thể làm task trong hai mươi phút, còn mình mất mười lăm phút để chia việc và ghép kết quả, gọi cả đội vào cũng không giúp được nhiều.

Một phần việc phù hợp để chạy song song thường có bốn đặc điểm:

1. Đầu ra có thể mô tả rõ trước khi bắt đầu.
2. Nó không phụ thuộc liên tục vào quyết định của agent khác.
3. Phạm vi file hoặc tài nguyên nó được phép chạm vào đủ tách biệt.
4. Agent chính có cách kiểm tra và tổng hợp kết quả sau cùng.

Thiếu một trong bốn điều này chưa chắc phải quay về một agent. Nhưng càng thiếu nhiều, tiền điều phối càng đắt.

Những việc mình thường giao ra trước

Nếu mới bắt đầu, mình thường giao ra những việc đọc nhiều, sửa ít trước.

Đây là những task tạo ra nhiều đầu ra trung gian nhưng ít rủi ro làm hỏng thư mục làm việc.

Tìm hiểu nhiều vùng codebase là ví dụ dễ nhất. Một agent phụ tìm cách project xử lý auth, một agent đọc flow email, một agent tìm test fixture. Mỗi agent trả về phát hiện có file tham chiếu. Agent chính không cần ôm toàn bộ log tìm kiếm của cả ba.

Review theo nhiều góc nhìn cũng khá hợp. Một agent phụ tìm bug và race condition. Một agent xem khoảng trống trong test. Một agent kiểm tra khả năng bảo trì. Chúng có thể đọc cùng diff nhưng trả về các loại phát hiện độc lập.

Debug bằng nhiều giả thuyết có ích khi chưa biết nguyên nhân gốc. Thay vì một agent thử lần lượt năm hướng, ba agent phụ có thể kiểm tra ba hướng khác nhau rồi trả bằng chứng về cho agent chính.

Chạy kiểm tra độc lập cũng thường an toàn. Một agent phụ chạy test tích hợp, một agent kiểm tra lỗi kiểu dữ liệu, một agent đọc log của test lúc xanh lúc đỏ. Điều kiện là chúng không cùng thay đổi trạng thái dùng chung hoặc tự sửa code trong lúc đang kiểm tra.

Khi một agent vẫn tốt hơn

Không phải task lớn nào cũng nên chia cho nhiều agent.

Mình sẽ giữ một agent khi công việc có phần phụ thuộc nối tiếp nhau. Ví dụ phải chọn mô hình database trước khi viết API, rồi chốt thoả thuận API trước khi làm giao diện. Cho ba agent bắt đầu cùng lúc chỉ khiến hai agent phía sau phải đoán một quyết định chưa tồn tại.

Một agent cũng hợp lý hơn khi:

• Task nhỏ và chỉ chạm một vài dòng
• Nhiều bước phải sửa cùng một file
• Yêu cầu còn mơ hồ và cần hỏi đáp liên tục
• Một quyết định kiến trúc ảnh hưởng tới mọi phần còn lại
• Các agent phải dùng chung database, cổng, emulator hoặc đầu ra sinh tự động
• Review và merge tốn nhiều thời gian hơn phần thực thi

Đặc biệt, đừng dùng số đông để thay thế một quyết định chưa được chốt.

Ba agent cùng bỏ phiếu cho một thiết kế API không biến thiết kế đó thành đúng. Mình vẫn cần so bằng chứng với yêu cầu, code hiện tại và giới hạn của project.

Chia theo đầu ra và người chịu trách nhiệm

Ở bài 04, mình đã nói về cách chia tính năng thành task có kết quả riêng thay vì cắt máy móc theo frontend, backend và test.

Cách làm nhiều agent vẫn theo nguyên tắc đó.

Một prompt kiểu này nghe có vẻ rõ:

Nhưng ranh giới thật sự vẫn còn mơ hồ.

Backend chọn schema phản hồi nào? Frontend có được tự thêm trường không? Agent viết test bám đặc tả hay bám phần code của hai agent kia? Ai sửa kiểu dữ liệu dùng chung? Ai quyết định mã lỗi?

Mình thích chia trách nhiệm cụ thể hơn:

Điểm quan trọng nhất là một vùng file chỉ có một người phụ trách tại một thời điểm.

Vùng đó có thể là một file, chuỗi migration, thoả thuận API, schema sinh tự động hoặc một vùng code dính chặt với nhau. Hai file khác tên nhưng cùng sinh ra từ một nguồn vẫn là vùng dùng chung.

Giao agent phụ thì phải nói rõ nó trả về gì

Đặt tên agent phụ là researcher, reviewer hay security-agent có ích, nhưng chưa đủ. Tên nghe chuyên nghiệp không tự làm phần việc rõ hơn.

Agent phụ cần biết khi nào phần việc của nó hoàn thành và phải trả gì về agent chính.

Đây là mẫu mình hay dùng:

Với agent chỉ đọc, mình còn nói rõ không đổ toàn bộ log hoặc nội dung file về luồng chính. Mình cần bản tóm tắt có bằng chứng, không cần bê nguyên một cửa sổ ngữ cảnh mới vào cửa sổ cũ.

Một prompt thực tế có thể ngắn như sau:

Tách nhánh để tìm hiểu, gom nhánh để quyết định

Một lỗi khá dễ gặp là gọi thêm agent xong rồi để mỗi đứa chạy tới lúc tự báo done.

Cách làm nhiều agent cần một điểm quay về.

Mình thường chia cách làm thành hai nhịp:

1. Fan-out, hay tách nhánh: agent chính giao các phần độc lập cho agent phụ.
2. Fan-in, hay gom nhánh: agent chính chờ kết quả, so bằng chứng, giải quyết mâu thuẫn và cập nhật nguồn chuẩn.

Sau khi gom nhánh, mình mới quyết định có mở đợt tiếp theo hay không.

Một vòng đầy đủ trông như vầy:

1. Agent chính đọc sổ tay project, đặc tả và tiêu chí hoàn thành.
2. Nó ghi rõ phần nào đã chốt, phần nào còn là câu hỏi mở.
3. Các agent chỉ đọc tìm hiểu những vùng độc lập.
4. Agent chính nhận bản tóm tắt, kiểm tra file tham chiếu và đưa quyết định còn mở về cho người sở hữu xác nhận.
5. Đặc tả hoặc task được cập nhật với quyết định đã chốt trước khi agent thực thi bắt đầu.
6. Agent thực thi nhận phần việc riêng và làm trong workspace phù hợp.
7. Agent chính review từng đầu ra, ghép theo thứ tự phụ thuộc.
8. Lượt kiểm tra cuối chạy trên trạng thái đã ghép, không chạy trên từng bản tóm tắt rời rạc.

Gom nhánh không chỉ là ghép ba câu trả lời thành một danh sách.

Đó là lúc mình loại phát hiện trùng, thấy các giả định mâu thuẫn, chọn quyết định và biến kết quả tìm hiểu thành nguồn chuẩn mà đợt sau có thể dùng.

Worktree tách file, không tách được quyết định

Nếu nhiều agent cùng sửa trong một thư mục làm việc, chúng nhìn thấy thay đổi của nhau ngay lập tức.

Điều này đôi khi tiện, nhưng cũng dễ tạo tranh chấp. Agent A đang sửa kiểu dữ liệu thì agent B format lại file. Agent C chạy test trên trạng thái nằm giữa hai thay đổi. Tới lúc review, không còn biết diff nào thuộc task nào.

Git worktree cho mỗi agent một checkout riêng. Mỗi agent có vùng file và nhánh độc lập nhưng vẫn dùng chung lịch sử Git của repository.

Worktree giúp:

• Tránh hai agent ghi đè cùng thư mục làm việc
• Giữ diff và nhánh theo từng task
• Cho phép chạy câu lệnh hoặc test trong môi trường riêng
• Review và tích hợp từng phần có chủ đích

Nhưng worktree không giải quyết xung đột về logic.

Hai agent ở hai worktree vẫn có thể chọn hai schema không tương thích. Hai nhánh vẫn có thể tạo migration cùng thứ tự. Hai agent vẫn có thể thay đổi cùng một thoả thuận công khai theo hai hướng khác nhau.

Tách môi trường chỉ thật sự an toàn sau khi phần việc và quyền quyết định đã rõ.

Ví dụ với tính năng mời vào workspace

Tiếp tục tính năng lời mời từ hai bài trước.

Đặc tả hiện có mục tiêu, phân quyền, cách xử lý lời mời trùng, thời hạn và tiêu chí hoàn thành. Các task cũng đã được chia nhỏ. Đây là lúc mình có thể cân nhắc chạy song song.

Mình không bắt đầu bằng ba agent cùng viết code.

Đợt đầu tiên chỉ gồm ba agent chỉ đọc:

Agent A - xác thực và thành viên

• Tìm cách kiểm tra quyền đang dùng cho admin của workspace
• Xác định luồng kiểm tra email đã là thành viên
• Trả file tham chiếu và dữ liệu test có thể dùng lại

Agent B - email và tác vụ nền

• Tìm cách đưa email vào hàng đợi hiện tại
• Xác định chuyện thử lại, tính idempotent và quy ước mẫu email
• Trả phần phụ thuộc hoặc trạng thái dùng chung có thể ảnh hưởng việc thực thi

Agent C - test và trường hợp biên

• Lập bảng test từ tiêu chí hoàn thành
• Tìm helper test và cách dựng database liên quan
• Chỉ ra trường hợp tranh chấp hoặc yêu cầu trùng cần quyết định

Agent chính chờ cả ba rồi gom kết quả.

Từ bằng chứng đó, nó đề xuất các quyết định để mình xác nhận rồi mới cập nhật đặc tả hoặc task:

• Helper phân quyền nào phải dùng lại
• Lời mời trùng trả thành công hay conflict
• Email được đưa vào hàng đợi trong hay sau transaction
• Tính idempotent nằm ở ràng buộc database hay lớp service
• Test tích hợp nào bắt buộc phải qua

Lúc này đợt sửa code mới bắt đầu.

Một task tạo lời mời có thể giao cho một agent thực thi sở hữu trọn lát cắt gồm cách hoạt động, service và test liên quan. Task giao diện chỉ chạy song song nếu thoả thuận API đã khoá và phạm vi file không giao nhau. Task chấp nhận lời mời phải chờ schema hoặc cách hoạt động mà nó phụ thuộc hoàn thành trước.

Phần phụ thuộc có thể hình dung như sau:

Không phải càng nhiều mũi tên song song càng tốt.

Mục tiêu là chỉ chạy song song phần thật sự độc lập, còn phần phụ thuộc phải được giữ tuần tự.

Khi các agent không đồng ý

Hai agent phụ có thể đọc cùng code nhưng đưa ra kết luận khác nhau.

Mình không giải quyết bằng cách lấy ý kiến số đông.

Agent chính cần hỏi lại ba thứ:

1. Phát hiện dựa trên file, test hoặc hành vi nào?
2. Nó có khớp nguồn chuẩn hiện tại không?
3. Có giả định nào chưa được xác nhận không?

Nếu agent A nói service đã idempotent còn agent B nói chưa, yêu cầu cả hai trỏ tới đường code và test cụ thể. Có thể một agent chỉ nhìn luồng thuận, còn agent kia thấy race condition ở ranh giới transaction.

Một lượt review độc lập có thể giúp thử thách kết luận. Nhưng người review cũng phải trả bằng chứng. Thêm agent không thay thế việc đọc nguồn.

Quyết định cuối nên được ghi lại vào đặc tả, task hoặc tài liệu project phù hợp. Đừng để kết luận chỉ nằm trong bản tóm tắt của một agent rồi biến mất sau khi luồng đóng.

Kiểm tra lần cuối trên trạng thái đã ghép

Mỗi agent phụ báo test đã qua chưa có nghĩa tính năng đã ổn.

Agent A có thể test nhánh A. Agent B test nhánh B. Khi merge hai nhánh, kiểu dữ liệu dùng chung thay đổi, thứ tự migration khác hoặc mock không còn khớp.

Agent chính hoặc người tích hợp cần chạy lượt kiểm tra cuối sau khi gom nhánh:

• Review diff theo từng phần được giao
• Kiểm tra tiêu chí hoàn thành từ nguồn chuẩn
• Chạy test cho từng slice đã tích hợp
• Chạy test tích hợp hoặc build liên quan trên trạng thái cuối
• Kiểm tra file ngoài phạm vi và thay đổi bị bỏ sót
• Ghi lại rủi ro hoặc phần chưa kiểm tra được

Đây cũng là lý do mình không giao quyền merge cho mọi agent phụ.

Agent phụ chịu trách nhiệm cho đầu ra của nó. Người tích hợp chịu trách nhiệm cho cách toàn bộ trạng thái sau cùng hoạt động.

Codex và Claude Code gọi các phần này thế nào

Nguyên tắc của bài không phụ thuộc công cụ, nhưng đối chiếu tên gọi sẽ giúp đọc tài liệu dễ hơn.

Tài liệu Codex mô tả subagent workflow là luồng chính gọi các agent có luồng riêng rồi thu kết quả về. Tài liệu khuyên bắt đầu với việc đọc nhiều như khám phá code, test, phân loại và tóm tắt; việc để nhiều agent cùng sửa file cần thận trọng hơn. Trong CLI, có thể dùng /agent để xem hoặc chuyển giữa các luồng đang chạy.

Codex trong ứng dụng ChatGPT desktop còn có worktree để chạy task trên checkout riêng rồi bàn giao về Local khi cần xem hoặc tiếp tục. Agent phụ và worktree giải quyết hai vấn đề khác nhau: một bên tách ngữ cảnh, một bên tách file.

Claude Code cũng có agent phụ với ngữ cảnh riêng và kết quả quay về cuộc trò chuyện chính. Worktree được dùng để tách các session hoặc agent thực thi song song. Ngoài ra Claude Code có agent teams, nơi các agent có ngữ cảnh riêng, danh sách task chung và có thể nhắn trực tiếp cho nhau. Tài liệu hiện đánh dấu tính năng này là thử nghiệm và cho biết nó tốn nhiều token hơn một session đơn.

Nhiều agent không miễn phí

Mỗi agent phụ có ngữ cảnh riêng nên nó phải đọc lại hướng dẫn, task và file liên quan.

Ba agent không chỉ cho cảm giác nhanh gấp ba. Chúng cũng có thể dùng gần gấp ba phần xử lý của model, cộng thêm token cho prompt giao việc, tóm tắt và điều phối.

Ngoài token còn có chi phí khó thấy hơn:

• Thời gian khởi động để mỗi agent hiểu task
• Sự tập trung của mình khi theo dõi nhiều luồng
• Xung đột merge và lỗi khi ghép
• Phát hiện trùng lặp
• Mệt mỏi khi nhiều diff cùng quay về

Mình không xem số agent đang chạy là KPI. Màn hình có nhiều ô hoạt động nhìn rất bận rộn, nhưng bận rộn chưa chắc đồng nghĩa với xong việc.

Nếu hai agent đủ để phủ hai hướng độc lập, gọi năm agent thường chỉ tạo thêm tiếng ồn. Nếu một agent hoàn thành phần tìm hiểu sớm và phần còn lại trở thành tuần tự, mình dừng tách nhánh thay vì cố giữ cả đội bận rộn.

Checklist trước khi gọi thêm agent

Trước mỗi đợt chạy nhiều agent, mình kiểm tra nhanh:

• Mỗi agent phụ có một đầu ra độc lập và quan sát được không?
• Nguồn chuẩn đã đủ rõ để chúng không tự chốt yêu cầu chưa?
• Phần phụ thuộc nào bắt buộc phải hoàn thành trước?
• Có một người duy nhất phụ trách mỗi vùng file không?
• Agent chỉ đọc hay được phép sửa?
• Nếu sửa, chúng có workspace hoặc worktree tách biệt không?
• Ai gom kết quả, giải quyết mâu thuẫn và cập nhật quyết định?
• Lượt kiểm tra cuối chạy ở đâu?
• Token và chi phí điều phối có đáng với thời gian tiết kiệm không?

Nếu mình chưa trả lời được ba câu liên tiếp, mình thường quay về một agent và làm rõ task trước.

Cách nhỏ gọn cho lần đầu

Đừng bắt đầu bằng agent team sáu người cùng sửa code.

Thử một vòng nhỏ hơn:

1. Chọn một task đã có mục tiêu và tiêu chí hoàn thành rõ.
2. Giữ agent chính làm người dẫn nhịp.
3. Gọi hai agent chỉ đọc cho hai câu hỏi tìm hiểu độc lập.
4. Yêu cầu mỗi agent trả bản tóm tắt có file tham chiếu và câu hỏi mở.
5. Agent chính gom kết quả, chốt quyết định và cập nhật task.
6. Chỉ một agent thực thi viết code.
7. Agent thứ hai review diff hoặc chạy kiểm tra độc lập.
8. Agent chính kiểm tra tiêu chí hoàn thành và trạng thái cuối.

Prompt có thể như vầy:

Vòng này chưa tận dụng song song tối đa.

Nhưng nó dạy đủ ba kỹ năng quan trọng: chia ranh giới, mô tả đầu ra và gom bằng chứng. Khi ba phần này ổn, thêm agent thực thi hoặc worktree chỉ là bước mở rộng.

Với Knowns, task list là chỗ giữ nhịp

Từ khi dùng Knowns, mình không để agent chính giữ toàn bộ trạng thái của cả đội trong chat.

Đặc tả dài và quyết định nằm trong doc. Trách nhiệm, phần phụ thuộc, tiêu chí hoàn thành và tiến độ nằm trong task. memory chỉ giữ cách làm có thể dùng lại, không giữ trạng thái tạm thời của từng agent.

Một agent có thể nhận @task-123, đọc đúng phạm vi rồi trả phát hiện về ghi chú task. Agent chính nhìn danh sách để biết việc nào đang chờ, đang làm hoặc đã xong thay vì hỏi từng luồng.

Nếu đi từ một đặc tả đã được duyệt, mình có thể dùng:

Chỉ nên giao việc khi task thật sự an toàn để chạy song song. Task có phần phụ thuộc hoặc vùng file giao nhau vẫn phải đi theo thứ tự.

Knowns không làm nhiều agent tự hiểu nhau.

Nó chỉ cho chúng một nguồn chuẩn và trạng thái task chung để việc điều phối bớt phụ thuộc vào đoạn chat.

Kết

Nhiều agent không phải nút tăng tốc cho mọi task.

Nó là một bài toán điều phối.

Một agent với task rõ thường tốt hơn năm agent nhận năm prompt mơ hồ. Hai agent chỉ đọc có đầu ra độc lập thường hữu ích hơn ba agent cùng lao vào một thư mục làm việc.

Nếu muốn bắt đầu, hãy giữ cách làm đơn giản:

• Một agent chính giữ mục tiêu và quyết định
• Tách phần tìm hiểu hoặc review độc lập
• Một người phụ trách cho mỗi vùng file
• Worktree khi nhiều agent thực thi thật sự cần chạy song song
• Gom nhánh và kiểm tra trên trạng thái đã ghép

Khi phần phụ thuộc, người phụ trách và điểm quay về đều rõ, nhiều agent mới thật sự giúp mình làm nhanh hơn mà không biến phần tiết kiệm được thành một buổi dọn conflict.

See yah.

Tài liệu tham khảo