(Show All)_ · **Bài 4/4** · [🌐 English](../../en/04-using-subagents-effectively/en.md)

← Bài trước · 📋 Mục lục khoá · Bài sau: —

Sử dụng subagent hiệu quả

👨‍💻 Track: Developer Track · 📚 Course: Introduction to Subagents · 🧭 Path C

📖 Nội dung bài học

Bạn đã biết cách tạo và thiết kế subagent. Bây giờ câu hỏi là: khi nào chúng thực sự hữu í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 (intermediate work) có quan trọng đối với luồng chính (main thread) của bạn hay không.

Khi nào subagent tỏa sáng

Subagent hoạt động tốt nhất khi quá trình khám phá tách biệt với quá trình 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 đó tìm ra, bạn nên thực hiện công việc đó trong luồng chính. Nhưng nếu bạn chỉ cần câu trả lời và không quan tâm đến hành trình tìm ra nó, hãy ủy thác (delegate).

Subagent xuất sắc ở các tác vụ mà:

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

Các tác vụ nghiên cứu (Research tasks)

Nghiên cứu là trường hợp sử dụng subagent điển hình. Hãy cân nhắc việc điều tra cách hoạt động của xác thực (authentication) trong một codebase lạ. Luồng chính của bạn cần biết JWT được xác thực ở đâu, nhưng nó không cần thấy mọi tệp tin đã được tìm kiếm trong suốt quá trình đó.

Một subagent nghiên cứu có thể đọc hàng chục tệp, truy vết qua các lệnh gọi hàm và khám phá các đường dẫn mã nguồn khác nhau. Tất cả quá trình khám phá đó nằm lại trong ngữ cảnh 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 như:

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

Subagent đã thực hiện phần việc nặng nhọc. Luồng chính của bạn nhận được chính xác những gì nó cần để tiếp tục.

Review mã nguồn (Code Reviews)

Claude review mã nguồn hiệu quả hơn khi mã đó được trình bày như là do người khác viết. Nếu bạn xây dựng một tính năng qua nhiều lượt trao đổi với luồng chính, việc yêu cầu chính luồng đó review thường tạo ra phản hồi yếu. Claude đã tham gia vào việc tạo ra nó, nên nó khó có được cái nhìn khách quan (fresh eyes).

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

System prompt tùy chỉnh

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

Dưới đây là hai trường hợp mà một system prompt tùy chỉnh giúp subagent thực sự tốt hơn luồng chính:

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

Khi nào subagent gây hại

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

Tự xưng là chuyên gia (Expert Claims)

Các subagent tự xưng là chuyên gia hiếm khi giúp ích. Các prompt như "bạn là một chuyên gia Python" hoặc "bạn là một chuyên gia Kubernetes" không thêm giá trị vì Claude đã có sẵn kiến thức đó. Không có gì mà một subagent "chuyên gia" có thể làm mà luồng chính của bạn không thể làm trực tiếp.

Chuỗi xử lý tuần tự (Sequential Pipelines)

Các chuỗi subagent tuần tự tạo ra vấn đề. Hãy xem xét một luồng gồm ba agent: một để tái hiện lỗi, một để debug và một để sửa lỗi. Chuỗi xử lý (pipeline) chỉ hoạt động khi các tác vụ thực sự độc lập. Chúng thất bại khi mỗi bước phụ thuộc vào những khám phá từ bước trước -- và việc sửa lỗi hầu như luôn như vậy. Thông tin sẽ bị thất lạc trong quá trình bàn giao giữa các agent.

Trình chạy thử nghiệm (Test Runners)

Các subagent đóng vai trò test runner có xu hướng che giấu thông tin bạn cần. Khi các bài kiểm tra (test) thất bại, bạn muốn có toàn bộ đầu ra (output) để chẩn đoán sự cố. Một subagent chỉ trả về "tests failed" buộc bạn phải tạo thêm các script debug để lấy thông tin chi tiết mà lẽ ra đã có thể thấy rõ trong output trực tiếp. Thử nghiệm đã cho thấy mô hình test runner hoạt động kém nhất trong tất cả các cấu hình.

Quy tắc quyết định

Khi bạn đang quyết định có nên sử dụng subagent hay không, hãy tự hỏi mình một câu: 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 ủy thác 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 xảy ra trong quá trình thực hiện -- hãy giữ nó ở luồng chính.

Sử dụng subagent cho:

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

Tránh dùng subagent cho:

• Các vai diễn "chuyên gia" không thêm năng lực thực tế
• Các chuỗi xử lý 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

🎬 Bản ghi video

Source video: n5LoKZ8Oa-A

📜 Mở rộng bản ghi (đã chỉnh sửa + dịch AI)

Bạn đã biết cách tạo và thiết kế subagent hiệu quả. Bây giờ, hãy cùng tìm hiểu khi nào chúng thực sự hữu ích và khi nào chúng gây cản trở. Nói một cách đơn giản, sự khác biệt nằm ở việc liệu các bước trung gian có quan trọng đối với main thread của bạn hay không.

Subagent phát huy tối đa sức mạnh khi quá trình khám phá tách biệt với quá trình thực thi. Ngược lại, khi mỗi bước phụ thuộc chặt chẽ vào kết quả của bước trước đó, thông tin dễ bị thất lạc trong quá trình bàn giao. Hãy sử dụng subagent cho các tác vụ nghiên cứu – nơi bạn chỉ cần kết quả cuối cùng chứ không cần quan tâm đến toàn bộ hành trình tìm kiếm.

Nghiên cứu và Khám phá Code

Hãy cân nhắc việc tìm hiểu cơ chế xác thực (authentication) trong một codebase lạ. Main thread có thể chỉ cần biết nơi JWT được xác thực, chứ không cần xem qua mọi tệp tin đã được tìm kiếm. Một subagent chuyên nghiên cứu có thể đọc hàng chục tệp, truy vết các lệnh gọi hàm và khám phá các luồng xử lý khác nhau.

Toàn bộ quá trình khám phá đó nằm gói gọn trong ngữ cảnh của subagent. Main thread của bạn chỉ nhận được kết quả: "Việc xác thực JWT diễn ra tại middleware/auth.js dòng 42, được gọi từ Express router trong routes/api.js."

Code Review và Góc nhìn mới

Claude thực hiện review hiệu quả hơn khi mã nguồn được trình bày như thể do một người khác viết. Nếu bạn xây dựng một tính năng qua nhiều lượt trao đổi với main thread, việc yêu cầu chính luồng đó review thường không mang lại phản hồi tốt nhất. Claude đã tham gia vào quá trình tạo ra nó, nên sẽ khó có được cái nhìn khách quan.

Một subagent đóng vai trò reviewer sẽ xem xét các thay đổi trong một ngữ cảnh riêng biệt. Nó chạy git diff, đọc các tệp đã sửa đổi và áp dụng các tiêu chí review chuyên biệt mà không bị ảnh hưởng bởi lịch sử viết code. Sự phân tách này cũng cho phép bạn thiết lập các tiêu chuẩn review riêng của dự án trong system prompt của subagent, đảm bảo tính nhất quán về tiêu chí đánh giá trong toàn đội ngũ.

System Prompt chuyên biệt: Copywriting và Styling

System prompt mặc định của Claude Code ưu tiên các phản hồi súc tích, tập trung vào mã nguồn. Điều này tuyệt vời cho việc lập trình, nhưng không phải cho mọi tác vụ.

Một subagent chuyên về copywriting với các chỉ dẫn về tông giọng, đối tượng độc giả và phong cách sẽ tạo ra nội dung marketing tốt hơn main thread. Prompt mặc định của Claude Code có xu hướng viết kỹ thuật ngắn gọn – điều bạn không hề muốn cho một landing page hay chiến dịch email, trừ khi bạn muốn khách hàng của mình "buồn ngủ". Một subagent copywriting có thể sở hữu các chỉ dẫn hoàn toàn khác biệt về văn phong và cấu trúc.

Tương tự, một subagent chuyên về styling có khả năng @mention các tệp design system để áp dụng các mẫu CSS nhất quán. Khi subagent chạy, các tệp đó sẽ tự động được nạp vào ngữ cảnh, giúp nó nắm rõ các biến màu sắc, quy chuẩn khoảng cách và các component pattern trước khi bắt đầu viết bất kỳ dòng CSS nào.

Anti-patterns: Khi Subagent gây cản trở

Các subagent được tạo ra chỉ để "tự xưng" là chuyên gia thường hiếm khi giúp ích. Những prompt như "Bạn là chuyên gia Python" hay "Bạn là chuyên gia Kubernetes" không thêm giá trị vì Claude vốn đã có sẵn kiến thức đó. Chi phí vận hành để khởi tạo một subagent, việc mất đi khả năng quan sát trực tiếp quá trình làm việc và việc phải nén kết quả thành một bản tóm tắt chỉ có ý nghĩa khi subagent thực hiện điều gì đó mà main thread không thể – chẳng hạn như áp dụng một system prompt tùy chỉnh hoặc cô lập quá trình khám phá.

Các chuỗi subagent tuần tự (sequential pipelines) cũng gây ra nhiều vấn đề. Hãy tưởng tượng một quy trình ba agent: một để tái hiện bug, một để debug và một để sửa. Pipeline chỉ hiệu quả khi các tác vụ thực sự độc lập; chúng sẽ thất bại nếu mỗi bước phụ thuộc nặng nề vào những phát hiện từ bước trước.

Các subagent đóng vai trò test runner có xu hướng che giấu thông tin quan trọng. Khi test thất bại, bạn cần toàn bộ output để chẩn đoán lỗi. Một subagent chỉ trả về "test failed" sẽ buộc bạn phải tạo thêm các script debug để lấy thông tin chi tiết – những thứ lẽ ra đã hiển thị trực tiếp ở output. Các thử nghiệm cho thấy mô hình test runner có hiệu suất kém nhất trong tất cả các cấu hình.

Tổng kết các thực hành tốt nhất

Trong phần này, chúng ta đã tìm hiểu:

• Cách subagent hoạt động như các luồng cô lập và trả về bản tóm tắt.
• Cách tạo chúng bằng lệnh /agents.
• Cách thiết kế chúng với cấu trúc đầu ra và mô tả cụ thể.

Hãy sử dụng chúng cho nghiên cứu, review và các tác vụ cần system prompt tùy chỉnh. Tránh sử dụng chúng cho các tuyên bố "chuyên gia", pipeline nhiều bước và test runner. Câu hỏi then chốt là: Các bước trung gian có quan trọng không? Nếu không, hãy ủy quyền cho subagent.

🔁 Bài học liên quan

• Bài trước: Designing effective subagents
• Cùng section: What are subagents? · Creating a subagent · Designing effective subagents
• Thuộc lộ trình: Path C
• Docs tham khảo: Glossary · Skills atlas · By use-case

📚 Nguồn & ghi nhận

• Bài học gốc Anthropic Academy: https://anthropic.skilljar.com/introduction-to-subagents/450701
• © 2025 Anthropic. Chỉ dùng cho mục đích giáo dục, fair-use.
• Crawl: 2026-04-23 · Chuẩn hoá: 2026-05-01