Subagent trong Claude Code: khi nào nên tách việc

Trả lời nhanh: Subagent là một phiên làm việc con được giao đúng một việc, chạy riêng với ngữ cảnh riêng, xong thì trả về bản tóm tắt cho phiên chính. Giá trị thật nằm ở chỗ giữ cho phiên chính không bị ngập rác: việc đọc năm mươi file để tìm một chỗ sửa vốn tạo ra rất nhiều nội dung trung gian mà phiên chính không cần giữ. Nhưng đừng lạm dụng: mỗi lần tách là một lần khởi động lại từ con số không, nên với việc nhỏ thì tách còn tốn hơn tự làm.

Ai dùng lâu cũng nhận ra phiên làm việc có tuổi thọ: càng về sau agent càng lơ đãng, vì thứ nó cần nhớ bị chôn dưới hàng nghìn dòng kết quả tìm kiếm và nội dung file. Tách việc ra phiên con là cách xử lý gốc rễ của chuyện này. Bài này bàn về khi nào tách thì lợi và khi nào tách chỉ tốn thêm tiền.

Vì sao ngữ cảnh sạch lại quan trọng

Mô hình đọc lại toàn bộ cuộc hội thoại ở mỗi lượt. Nghĩa là ba trăm dòng kết quả tìm kiếm bạn xin từ nửa tiếng trước vẫn đang được đọc lại ở lượt hiện tại, dù việc đó đã xong. Hai hậu quả: tốn tiền đều đặn, và quan trọng hơn là thông tin quan trọng bị pha loãng giữa đống chi tiết cũ.

Tách việc ra phiên con cắt đúng chỗ đó. Phiên con đọc bao nhiêu file cũng được, nhưng thứ quay về phiên chính chỉ là kết luận, ví dụ logic tính giá nằm ở ba file này, chỗ cần sửa là hàm kia. Phiên chính nhận đúng phần cần dùng, không nhận rác.

Nguyên tắc này giống hệt thứ đã nói ở bài CLAUDE.md: thứ gì được đọc lại ở mọi lượt thì phải quý, thứ gì dùng một lần thì đừng để nó nằm mãi trong ngữ cảnh.

Việc nào đáng tách

Bốn dạng việc gần như luôn đáng tách:

• Dò tìm trong repo lớn. Câu hỏi kiểu chức năng này nằm ở đâu thường phải mở hàng chục file. Phiên con làm rồi trả về danh sách đường dẫn kèm giải thích ngắn.
• Đọc log dài. Một file log vài nghìn dòng chỉ có vài dòng đáng chú ý. Đừng để cả file nằm trong phiên chính.
• Rà soát theo danh mục. Ví dụ kiểm tra toàn bộ điểm cuối API xem có chỗ nào thiếu kiểm tra quyền, kết quả cần là bảng tổng hợp chứ không phải nội dung từng file.
• Việc song song không đụng nhau. Ba việc trên ba thư mục khác nhau chạy cùng lúc thì nhanh hơn hẳn làm tuần tự.

Điểm chung: đầu vào lớn nhưng đầu ra nhỏ. Đó là dấu hiệu nhận biết đáng tin cậy nhất.

Việc nào không nên tách

Phiên con phải tìm hiểu lại bối cảnh từ đầu, và đó là chi phí thật. Vì vậy đừng tách khi:

Việc ngắn. Sửa một dòng trong file đang mở thì tách chỉ làm chậm và tốn thêm.

Việc cần đối thoại qua lại. Nếu bạn cần xem kết quả rồi điều chỉnh hướng đi liên tục, giữ trong phiên chính tiện hơn nhiều.

Nhiều phiên con cùng sửa một file. Đây là lỗi hay gặp khi chia việc song song. Hai phiên cùng sửa một file thì bên sau đè bên trước. Chia việc song song thì phải chia theo file, mỗi phiên sở hữu tập file riêng.

Việc mà tiêu chí đúng sai khó mô tả. Phiên con không thấy được cuộc hội thoại trước đó, nên nếu bạn không viết ra được thế nào là hoàn thành thì kết quả trả về gần như chắc chắn lệch.

Viết prompt giao việc cho phiên con

Phiên con bắt đầu từ con số không, nên prompt phải tự đứng vững. Năm phần nên có:

1. Việc cần làm, một câu, cụ thể.
2. File cần đọc, ghi đường dẫn thật thay vì bảo tự tìm, trừ khi tìm chính là việc.
3. File được phép sửa, hoặc ghi rõ chỉ đọc không sửa.
4. Thế nào là xong, tiêu chí kiểm chứng được.
5. Định dạng kết quả trả về, thường là danh sách ngắn kèm đường dẫn.

Phần thứ năm hay bị bỏ và đó là lý do phiên con trả về ba trang văn xuôi, làm mất sạch lợi ích của việc tách. Hãy nói thẳng: trả về tối đa mười dòng, mỗi dòng một phát hiện kèm đường dẫn và số dòng.

Nếu quy trình giao việc này lặp lại thường xuyên, đóng gói nó thành skill như trong bài viết skill đầu tiên, khỏi phải gõ lại mỗi lần.

Chi phí và nơi chạy

Tách việc không miễn phí. Mỗi phiên con là một lượt gọi riêng với ngữ cảnh riêng, nên tách bừa sẽ tốn hơn làm tuần tự. Cách nghĩ đúng: tách khi phần rác tiết kiệm được lớn hơn phần bối cảnh phải dựng lại. Việc đọc năm mươi file thì rõ ràng lợi, việc sửa một dòng thì rõ ràng lỗ.

Khi chạy nhiều phiên con song song, máy của bạn cũng phải chịu tải tương ứng: nhiều tiến trình cùng đọc ghi file, cùng chạy lệnh. Đây là lúc laptop bắt đầu ì, và cũng là lý do nhiều người chuyển hẳn phần này lên máy chủ theo cách trong bài chạy Claude Code trên VPS. Máy chủ còn một cái lợi nữa: bạn đóng laptop đi ăn trưa, việc vẫn chạy tiếp.

Việc nào đáng tách và việc nào không

Nguyên tắc gốc: tách khi việc đó tạo ra nhiều dữ liệu trung gian mà bạn chỉ cần kết luận. Đừng tách khi việc đó cần biết bối cảnh của phiên chính.

Viết yêu cầu giao việc cho phiên con

# Phien con khong biet gi ve cuoc tro chuyen chinh.# Yeu cau phai tu du, gom nam phan: # 1. Viec can lam, noi cu the# 2. File nao duoc doc, file nao duoc sua (duong dan chinh xac)# 3. Tieu chi hoan thanh, lam sao biet la xong# 4. Rang buoc: khong duoc lam gi# 5. Ket qua tra ve o dang nao # Sai lam pho bien: viet "tim hieu ve phan xac thuc"# Dung: "Doc src/auth/*.ts, liet ke moi ham xu ly dang nhap,#        neu ro ham nao khong kiem thoi han cua the.#        Chi doc, khong sua file nao. Tra ve danh sach gach dau dong."

Mỗi phiên con là một khoản chi riêng

• Mỗi phiên con tốn riêng. Tách năm phiên là tốn gấp năm lần cho phần việc đó. Chỉ tách khi giá trị rõ ràng.
• Chạy song song nhiều phiên tốn tài nguyên máy, chủ yếu là ổ đĩa và bộ nhớ. Xem cấu hình gợi ý ở bài chạy nhiều phiên song song.
• Loại thư mục thư viện khỏi phạm vi quét trước khi tách phiên. Không làm thì mỗi phiên con đều quét lại toàn bộ, và đó là lãng phí lớn nhất.
• Đọc kết quả phiên con trước khi dùng. Chúng không phải lúc nào cũng đúng, và bạn là người chịu trách nhiệm với mã cuối cùng.