Dùng subagent hiệu quả

Bạn đã biết cách tạo subagent và thiết kế chúng tốt. Giờ câu hỏi là: khi nào chúng thực sự giúp ích, và khi nào chúng gây cản trở? Sự khác biệt nằm ở một điều duy nhất - liệu công việc trung gian có quan trọng với luồng chính của bạn hay không.

Khi nào subagent toả sáng

Subagent hoạt động tốt nhất khi việc khám phá tách biệt khỏi việc thực thi. Nếu mỗi bước trong một tác vụ phụ thuộc vào những gì bước trước đó phát hiện ra, bạn muốn giữ công việc đó trong luồng chính. Nhưng nếu bạn chỉ cần một câu trả lời và không quan tâm tới hành trình tìm ra nó, hãy giao nó cho subagent.

Subagent nổi trội ở các tác vụ mà:

• Bạn cần một kết quả, không phải tường thuật từng bước cách nó được tìm ra.
• Công việc khám phá sẽ làm rối ngữ cảnh của luồng chính.
• Tác vụ được lợi từ một góc nhìn mới hoặc một system prompt tùy chỉnh.

Tác vụ nghiên cứu

Nghiên cứu là use case kinh điển của subagent. Hãy xét việc tìm hiểu cách authentication hoạt động trong một codebase xa lạ. Luồng chính của bạn cần biết JWT được kiểm chứng ở đâu, nhưng không cần thấy từng file đã được tìm kiếm dọc đường.

Một subagent nghiên cứu có thể đọc hàng chục file, lần theo các lệnh gọi hàm, và khám phá nhiều nhánh code khác nhau. Toàn bộ việc khám phá đó nằm trong ngữ cảnh riêng của subagent. Luồng chính của bạn nhận được một bản tóm tắt gọn gàng, kiểu như:

JWT validation happens in middleware/auth.js line 42,
called from the Express router in route/api.js

Subagent đã làm phần việc nặng nhọc. Luồng chính của bạn nhận được đúng những gì cần để tiếp tục.

Review code

Claude review code hiệu quả hơn khi code được trình bày như thể do người khác viết. Nếu bạn xây một tính năng qua nhiều lượt với luồng chính, yêu cầu chính luồng đó review lại thường cho ra phản hồi yếu. Claude đã tham gia tạo ra nó, nên nó khó nhìn nhận với cái nhìn hoàn toàn mới.

Một subagent reviewer nhìn thấy các thay đổi trong một ngữ cảnh riêng biệt. Nó chạy git diff, đọc các file đã sửa, và áp dụng tiêu chí review chuyên biệt của nó mà không mang theo lịch sử về cách code được viết ra. Sự tách biệt này cũng cho phép bạn mã hoá các tiêu chuẩn review riêng của project vào system prompt của subagent, đảm bảo tiêu chí review nhất quán trong cả team.

System prompt tùy chỉnh

System prompt mặc định của Claude Code nhấn mạnh vào các phản hồi ngắn gọn, tập trung vào code. Điều đó rất tốt cho việc lập trình, nhưng không phù hợp với mọi việc.

Đây là hai trường hợp mà một system prompt tùy chỉnh khiến subagent thực sự tốt hơn luồng chính:

• Subagent viết nội dung (copywriting) - cho nó chỉ dẫn về giọng văn, đối tượng đọc, và phong cách. Prompt mặc định của Claude Code thiên về văn phong kỹ thuật ngắn gọn, không phù hợp cho một landing page hay chiến dịch email. Một subagent copywriting có thể có chỉ dẫn hoàn toàn khác về giọng điệu và cấu trúc.
• Subagent styling - trỏ nó vào các file design system của bạn. Khi subagent chạy, các file đó tự động nạp vào ngữ cảnh của nó, nên nó biết biến màu, quy ước khoảng cách, và pattern component của bạn trước cả khi bắt đầu viết bất kỳ dòng CSS nào.

Khi nào subagent gây hại

Chi phí khởi động một subagent - mất khả năng quan sát công việc của nó và nén phát hiện thành một bản tóm tắt - chỉ hợp lý khi subagent làm được điều gì đó luồng chính không làm được. Có ba anti-pattern phổ biến cần tránh.

Tự nhận là “chuyên gia”

Subagent tự nhận có chuyên môn hiếm khi hữu ích. Các prompt như “bạn là chuyên gia Python” hay “bạn là chuyên gia Kubernetes” không mang lại giá trị gì thêm, vì Claude vốn đã có kiến thức đó. Không có gì một subagent “chuyên gia” tự xưng làm được mà luồng chính của bạn không thể làm trực tiếp.

Pipeline tuần tự

Các pipeline subagent nối tiếp nhau gây ra vấn đề. Hãy xét một luồng ba agent: một để tái tạo bug, một để debug nó, một để sửa nó. Pipeline chỉ hoạt động khi các tác vụ thực sự độc lập với nhau. Chúng thất bại khi mỗi bước phụ thuộc vào phát hiện của bước trước - và việc sửa bug hầu như luôn như vậy. Thông tin bị thất lạc trong quá trình bàn giao giữa các agent.

Agent chạy test

Subagent chạy test có xu hướng che giấu thông tin bạn cần. Khi test fail, bạn cần toàn bộ output để chẩn đoán vấn đề. Một subagent chỉ trả về “test failed” buộc bạn phải tạo thêm script debug để lấy được chi tiết vốn đã hiển thị sẵn trong output trực tiếp. Các thử nghiệm cho thấy pattern “test runner” này có kết quả kém nhất trong số các cấu hình được thử.

Quy tắc quyết định

Khi quyết định có nên dùng subagent hay không, hãy tự hỏi một câu duy nhất: công việc trung gian có quan trọng không?

Nếu câu trả lời là không - bạn chỉ cần kết quả cuối cùng - hãy giao nó cho một subagent. Nếu câu trả lời là có - bạn cần thấy và phản ứng với những gì đang diễn ra dọc đường - hãy giữ nó trong luồng chính.

Dùng subagent cho:

• Nghiên cứu và khám phá.
• Review code.
• Các tác vụ cần một system prompt tùy chỉnh.

Tránh dùng subagent cho:

• Các persona “chuyên gia” không mang lại năng lực thực sự nào thêm.
• Pipeline nhiều bước mà mỗi bước phụ thuộc vào bước trước.
• Chạy test khi bạn cần toàn bộ output để debug.

Đây là bài giảng cuối cùng trong khóa. Xem thêm tại academy.claude.com/courses/introduction-to-subagents/complete.

Nguồn

Dịch từ bài giảng “Using subagents effectively”, khóa Introduction to subagents trên Claude Academy.