- Tác nhân phụ hiệu quả khi công việc trung gian không quan trọng đối với luồng chính và quá trình khám phá tách biệt với quá trình thực thi, giúp cô lập thông tin và cung cấp tóm tắt.
- Chúng lý tưởng cho nhiệm vụ nghiên cứu, review mã khách quan và các tác vụ sáng tạo đòi hỏi lời nhắc hệ thống tùy chỉnh về giọng điệu, phong cách hoặc quy tắc thiết kế.
- Tránh dùng tác nhân phụ cho việc tuyên bố chuyên môn, các quy trình tuần tự phụ thuộc lẫn nhau, hoặc làm công cụ chạy kiểm thử, vì chúng có thể che giấu thông tin hoặc không mang lại giá trị gia tăng.
Using subagents effectively
- Sử dụng tác nhân phụ cho các nhiệm vụ nghiên cứu khi bạn chỉ cần câu trả lời cuối cùng, không phải toàn bộ hành trình tìm kiếm (ví dụ: tìm vị trí xác thực JWT trong một codebase lớn).
- Áp dụng tác nhân phụ để review mã, giúp đảm bảo tính khách quan và áp dụng các tiêu chí review cụ thể theo dự án thông qua lời nhắc hệ thống của tác nhân phụ.
- Thiết kế tác nhân phụ cho các nhiệm vụ chuyên biệt và sáng tạo như viết quảng cáo hoặc tạo kiểu (styling), cung cấp cho chúng các hướng dẫn về giọng điệu, đối tượng hoặc tham chiếu đến các tệp hệ thống thiết kế.
- Tránh khởi chạy tác nhân phụ chỉ để "tuyên bố chuyên môn" (ví dụ: "bạn là chuyên gia Python"), vì Claude đã có kiến thức đó và chi phí khởi tạo không mang lại giá trị gia tăng.
- Không sử dụng tác nhân phụ cho các quy trình tuần tự mà mỗi bước phụ thuộc vào những khám phá từ bước trước, vì điều này dẫn đến mất thông tin trong quy trình bàn giao.
- Hạn chế dùng tác nhân phụ làm công cụ chạy kiểm thử (
test runner) vì chúng có xu hướng che giấu đầu ra chi tiết cần thiết để chẩn đoán vấn đề khi kiểm thử thất bại. - Quyết định sử dụng tác nhân phụ dựa trên câu hỏi then chốt: "Liệu công việc trung gian có quan trọng đối với luồng chính không?". Nếu không, hãy ủy quyền cho tác nhân phụ xử lý.
tác nhân phụ— sub-agentluồng chính— main flowngữ cảnh— contextlời nhắc hệ thống— system promptquy trình bàn giao— handoff processcodebase— codebaselời gọi hàm— function callsđường dẫn mã— code pathstiêu chí review— review criteriakiểm thử— testsđầu ra có cấu trúc— structured outputủy quyền— delegate
Khi Nào Sử Dụng và Tránh Dùng Tác Nhân Phụ
Bạn đã biết cách tạo và thiết kế các tác nhân phụ. 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ông việc trung gian có quan trọng đối với luồng chính của bạn hay không. Khi quá trình khám phá tách biệt với quá trình thực thi, các tác nhân phụ sẽ phát huy tác dụng. Khi mỗi bước phụ thuộc vào những gì bước trước đó đã khám phá, thông tin sẽ bị mất trong quy trình bàn giao.
Tác Nhân Phụ trong Nhiệm Vụ Nghiên Cứu
Các tác nhân phụ rất giỏi trong các nhiệm vụ nghiên cứu, nơi bạn chỉ cần một câu trả lời, chứ không phải toàn bộ hành trình. Hãy xem xét việc điều tra cách thức hoạt động của xác thực trong một codebase không quen thuộc. Luồng chính có thể cần biết 'JWT được xác thực ở đâu?', nhưng không cần xem mọi tệp đã được tìm kiếm. Một tác nhân phụ nghiên cứu có thể đọc hàng chục tệp, theo dõi các lời gọi hàm và khám phá các đường dẫn mã khác nhau. Tất cả quá trình khám phá đó vẫn nằm trong ngữ cảnh của tác nhân phụ. Luồng chính của bạn sẽ nhận được thông tin như: 'xác thực JWT diễn ra trong middleware/offJS tại dòng 42 được gọi từ express router và route/API.js' hoặc tương tự.
Tác Nhân Phụ trong Quy Trình Review Mã
Các review của Claude hoạt động hiệu quả hơn khi mã được trình bày như thể 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 với luồng chính của mình, việc yêu cầu luồng chính sau đó review nó thường không mang lại phản hồi tốt nhất. Claude đã tham gia vào việc tạo ra nó, vì vậy nó khó có thể nhìn nhận lại với cái nhìn khách quan.
Một tác nhân phụ review sẽ xem 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 của nó mà không cần biết lịch sử cách mã được viết. Và sự tách biệt này cũng cho phép bạn mã hóa các tiêu chuẩn review cụ thể theo dự án trong lời nhắc hệ thống của tác nhân phụ, đảm bảo tiêu chí review nhất quán trong toàn nhóm.
Tác Nhân Phụ cho Nhiệm Vụ Chuyên Biệt và Sáng Tạo
Lời nhắc hệ thống mặc định của Claude Code nhấn mạnh các phản hồi ngắn gọn, tập trung vào mã, và điều này rất hiệu quả cho lập trình nhưng không phải cho mọi thứ. Ví dụ, một tác nhân phụ viết quảng cáo với các hướng dẫn về giọng điệu, đối tượng và phong cách sẽ tạo ra văn bản tiếp thị tốt hơn so với luồng chính. Lời nhắc mặc định của Claude Code có xu hướng viết kỹ thuật ngắn gọn, điều mà bạn thực sự không muốn cho một trang đích hoặc chiến dịch email, trừ khi bạn muốn khiến khách hàng của mình buồn ngủ. Một tác nhân phụ viết quảng cáo có thể có các hướng dẫn hoàn toàn khác nhau về giọng văn và cấu trúc.
Một tác nhân phụ tạo kiểu (styling) đề cập đến các tệp hệ thống thiết kế của bạn sẽ áp dụng các mẫu CSS nhất quán. Khi tác nhân phụ chạy, các tệp đó sẽ tự động tải vào ngữ cảnh. Vì vậy, nó biết các biến màu, quy ước khoảng cách và mẫu thành phần của bạn trước khi bắt đầu viết bất kỳ CSS nào.
Khi Nào Không Nên Dùng Tác Nhân Phụ
Tuyên bố chuyên môn
Các tác nhân phụ tự nhận là chuyên gia hiếm khi hữu ích. Các lời nhắc như 'bạn là chuyên gia Python' hoặc 'bạn là chuyên gia Kubernetes' không có giá trị vì Claude đã có kiến thức đó rồi. Chi phí để khởi chạy một tác nhân phụ, mất khả năng hiển thị công việc của nó và nén các phát hiện của nó thành một bản tóm tắt chỉ có ý nghĩa khi tác nhân phụ làm điều gì đó mà luồng chính không thể làm, chẳng hạn như áp dụng một lời nhắc hệ thống tùy chỉnh hoặc giữ cho công việc khám phá được cô lập.
Quy trình tuần tự
Các quy trình xử lý tác nhân phụ tuần tự tạo ra vấn đề. Hãy xem xét một luồng tác nhân ba bước: một để tái hiện bug, một để debug nó và một để sửa nó. Các quy trình xử lý chỉ hoạt động khi các nhiệm 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 đó.
Chạy kiểm thử
Các tác nhân phụ chạy kiểm thử (test runner sub agents) có xu hướng che giấu thông tin bạn cần. Khi các kiểm thử thất bại, bạn muốn có toàn bộ đầu ra để chẩn đoán vấn đề. Một tác nhân phụ chỉ trả về 'kiểm thử thất bại' buộc bạn phải tạo thêm các script debug để có được chi tiết lẽ ra đã hiển thị trong đầu ra trực tiếp. Thử nghiệm đã chỉ ra rằng mẫu test runner hoạt động kém hiệu quả nhất trong số tất cả các cấu hình.
Tổng Kết và Khuyến Nghị
Xuyên suốt loạt bài này, chúng ta đã tìm hiểu cách các tác nhân phụ hoạt động như các luồng riêng biệt trả về bản tóm tắt, cách tạo chúng bằng lệnh /agents và cách thiết kế chúng với đầu ra có cấu trúc và mô tả cụ thể. Hãy sử dụng chúng cho nghiên cứu, review và các nhiệm vụ cần lời nhắc hệ thống tùy chỉnh, nhưng tránh sử dụng chúng cho các tuyên bố chuyên môn, các quy trình xử lý đa bước và các test runner. Câu hỏi then chốt: Liệu công việc trung gian có quan trọng không? Nếu không, hãy ủy quyền cho tác nhân phụ xử lý.
TL;DR
- Tác nhân phụ hiệu quả khi công việc trung gian không quan trọng đối với luồng chính và quá trình khám phá tách biệt với quá trình thực thi, giúp cô lập thông tin và cung cấp tóm tắt.
- Chúng lý tưởng cho nhiệm vụ nghiên cứu, review mã khách quan và các tác vụ sáng tạo đòi hỏi lời nhắc hệ thống tùy chỉnh về giọng điệu, phong cách hoặc quy tắc thiết kế.
- Tránh dùng tác nhân phụ cho việc tuyên bố chuyên môn, các quy trình tuần tự phụ thuộc lẫn nhau, hoặc làm công cụ chạy kiểm thử, vì chúng có thể che giấu thông tin hoặc không mang lại giá trị gia tăng.
Điểm chính
- Sử dụng tác nhân phụ cho các nhiệm vụ nghiên cứu khi bạn chỉ cần câu trả lời cuối cùng, không phải toàn bộ hành trình tìm kiếm (ví dụ: tìm vị trí xác thực JWT trong một codebase lớn).
- Áp dụng tác nhân phụ để review mã, giúp đảm bảo tính khách quan và áp dụng các tiêu chí review cụ thể theo dự án thông qua lời nhắc hệ thống của tác nhân phụ.
- Thiết kế tác nhân phụ cho các nhiệm vụ chuyên biệt và sáng tạo như viết quảng cáo hoặc tạo kiểu (styling), cung cấp cho chúng các hướng dẫn về giọng điệu, đối tượng hoặc tham chiếu đến các tệp hệ thống thiết kế.
- Tránh khởi chạy tác nhân phụ chỉ để "tuyên bố chuyên môn" (ví dụ: "bạn là chuyên gia Python"), vì Claude đã có kiến thức đó và chi phí khởi tạo không mang lại giá trị gia tăng.
- Không sử dụng tác nhân phụ cho các quy trình tuần tự mà mỗi bước phụ thuộc vào những khám phá từ bước trước, vì điều này dẫn đến mất thông tin trong quy trình bàn giao.
- Hạn chế dùng tác nhân phụ làm công cụ chạy kiểm thử (
test runner) vì chúng có xu hướng che giấu đầu ra chi tiết cần thiết để chẩn đoán vấn đề khi kiểm thử thất bại. - Quyết định sử dụng tác nhân phụ dựa trên câu hỏi then chốt: "Liệu công việc trung gian có quan trọng đối với luồng chính không?". Nếu không, hãy ủy quyền cho tác nhân phụ xử lý.
Từ vựng
tác nhân phụ— sub-agentluồng chính— main flowngữ cảnh— contextlời nhắc hệ thống— system promptquy trình bàn giao— handoff processcodebase— codebaselời gọi hàm— function callsđường dẫn mã— code pathstiêu chí review— review criteriakiểm thử— testsđầu ra có cấu trúc— structured outputủy quyền— delegate
Nội dung chi tiết
Khi Nào Sử Dụng và Tránh Dùng Tác Nhân Phụ
Bạn đã biết cách tạo và thiết kế các tác nhân phụ. 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ông việc trung gian có quan trọng đối với luồng chính của bạn hay không. Khi quá trình khám phá tách biệt với quá trình thực thi, các tác nhân phụ sẽ phát huy tác dụng. Khi mỗi bước phụ thuộc vào những gì bước trước đó đã khám phá, thông tin sẽ bị mất trong quy trình bàn giao.
Tác Nhân Phụ trong Nhiệm Vụ Nghiên Cứu
Các tác nhân phụ rất giỏi trong các nhiệm vụ nghiên cứu, nơi bạn chỉ cần một câu trả lời, chứ không phải toàn bộ hành trình. Hãy xem xét việc điều tra cách thức hoạt động của xác thực trong một codebase không quen thuộc. Luồng chính có thể cần biết 'JWT được xác thực ở đâu?', nhưng không cần xem mọi tệp đã được tìm kiếm. Một tác nhân phụ nghiên cứu có thể đọc hàng chục tệp, theo dõi các lời gọi hàm và khám phá các đường dẫn mã khác nhau. Tất cả quá trình khám phá đó vẫn nằm trong ngữ cảnh của tác nhân phụ. Luồng chính của bạn sẽ nhận được thông tin như: 'xác thực JWT diễn ra trong middleware/offJS tại dòng 42 được gọi từ express router và route/API.js' hoặc tương tự.
Tác Nhân Phụ trong Quy Trình Review Mã
Các review của Claude hoạt động hiệu quả hơn khi mã được trình bày như thể 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 với luồng chính của mình, việc yêu cầu luồng chính sau đó review nó thường không mang lại phản hồi tốt nhất. Claude đã tham gia vào việc tạo ra nó, vì vậy nó khó có thể nhìn nhận lại với cái nhìn khách quan.
Một tác nhân phụ review sẽ xem 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 của nó mà không cần biết lịch sử cách mã được viết. Và sự tách biệt này cũng cho phép bạn mã hóa các tiêu chuẩn review cụ thể theo dự án trong lời nhắc hệ thống của tác nhân phụ, đảm bảo tiêu chí review nhất quán trong toàn nhóm.
Tác Nhân Phụ cho Nhiệm Vụ Chuyên Biệt và Sáng Tạo
Lời nhắc hệ thống mặc định của Claude Code nhấn mạnh các phản hồi ngắn gọn, tập trung vào mã, và điều này rất hiệu quả cho lập trình nhưng không phải cho mọi thứ. Ví dụ, một tác nhân phụ viết quảng cáo với các hướng dẫn về giọng điệu, đối tượng và phong cách sẽ tạo ra văn bản tiếp thị tốt hơn so với luồng chính. Lời nhắc mặc định của Claude Code có xu hướng viết kỹ thuật ngắn gọn, điều mà bạn thực sự không muốn cho một trang đích hoặc chiến dịch email, trừ khi bạn muốn khiến khách hàng của mình buồn ngủ. Một tác nhân phụ viết quảng cáo có thể có các hướng dẫn hoàn toàn khác nhau về giọng văn và cấu trúc.
Một tác nhân phụ tạo kiểu (styling) đề cập đến các tệp hệ thống thiết kế của bạn sẽ áp dụng các mẫu CSS nhất quán. Khi tác nhân phụ chạy, các tệp đó sẽ tự động tải vào ngữ cảnh. Vì vậy, nó biết các biến màu, quy ước khoảng cách và mẫu thành phần của bạn trước khi bắt đầu viết bất kỳ CSS nào.
Khi Nào Không Nên Dùng Tác Nhân Phụ
Tuyên bố chuyên môn
Các tác nhân phụ tự nhận là chuyên gia hiếm khi hữu ích. Các lời nhắc như 'bạn là chuyên gia Python' hoặc 'bạn là chuyên gia Kubernetes' không có giá trị vì Claude đã có kiến thức đó rồi. Chi phí để khởi chạy một tác nhân phụ, mất khả năng hiển thị công việc của nó và nén các phát hiện của nó thành một bản tóm tắt chỉ có ý nghĩa khi tác nhân phụ làm điều gì đó mà luồng chính không thể làm, chẳng hạn như áp dụng một lời nhắc hệ thống tùy chỉnh hoặc giữ cho công việc khám phá được cô lập.
Quy trình tuần tự
Các quy trình xử lý tác nhân phụ tuần tự tạo ra vấn đề. Hãy xem xét một luồng tác nhân ba bước: một để tái hiện bug, một để debug nó và một để sửa nó. Các quy trình xử lý chỉ hoạt động khi các nhiệm 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 đó.
Chạy kiểm thử
Các tác nhân phụ chạy kiểm thử (test runner sub agents) có xu hướng che giấu thông tin bạn cần. Khi các kiểm thử thất bại, bạn muốn có toàn bộ đầu ra để chẩn đoán vấn đề. Một tác nhân phụ chỉ trả về 'kiểm thử thất bại' buộc bạn phải tạo thêm các script debug để có được chi tiết lẽ ra đã hiển thị trong đầu ra trực tiếp. Thử nghiệm đã chỉ ra rằng mẫu test runner hoạt động kém hiệu quả nhất trong số tất cả các cấu hình.
Tổng Kết và Khuyến Nghị
Xuyên suốt loạt bài này, chúng ta đã tìm hiểu cách các tác nhân phụ hoạt động như các luồng riêng biệt trả về bản tóm tắt, cách tạo chúng bằng lệnh /agents và cách thiết kế chúng với đầu ra có cấu trúc và mô tả cụ thể. Hãy sử dụng chúng cho nghiên cứu, review và các nhiệm vụ cần lời nhắc hệ thống tùy chỉnh, nhưng tránh sử dụng chúng cho các tuyên bố chuyên môn, các quy trình xử lý đa bước và các test runner. Câu hỏi then chốt: Liệu công việc trung gian có quan trọng không? Nếu không, hãy ủy quyền cho tác nhân phụ xử lý.