Thiết kế subagent hiệu quả

Giờ bạn đã biết cách tạo subagent, hãy xem các pattern khiến chúng thực sự hiệu quả. Một subagent cấu hình kém sẽ lan man, chạy quá lâu, hoặc tạo ra output mà agent chính không dùng được. Cách khắc phục gói gọn trong bốn điều: viết description tốt, định nghĩa định dạng output, báo cáo trở ngại, và giới hạn quyền truy cập tool.

Dữ liệu cấu hình subagent được dùng như thế nào

Khi bạn gửi một tin nhắn cho agent ở cửa sổ ngữ cảnh chính, tên và description của mọi subagent khả dụng đều được đưa vào system prompt. Đây là cách agent chính quyết định nên khởi động subagent nào và khi nào. Nếu bạn muốn kiểm soát tốt hơn việc khi nào một subagent được tự động kích hoạt, tên và description chính là thứ bạn nên điều chỉnh.

Description còn có một vai trò thứ hai. Khi agent chính khởi động một subagent, nó viết ra một input prompt để bắt đầu tác vụ. Nó dùng description như một chỉ dẫn để viết prompt đó. Vậy nên description không chỉ kiểm soát khi nào một subagent chạy - nó còn định hình subagent được yêu cầu làm gì.

Viết description định hình input prompt

Hãy xét một subagent review code. Với một description chung chung, agent chính có thể viết một input prompt kiểu “dùng get diff để tìm các thay đổi hiện tại”. Điều đó khá mơ hồ. Subagent phải tự tìm ra file nào quan trọng.

Nếu bạn cập nhật description để bao gồm điều gì đó như “bạn phải nói rõ cho agent chính xác những file nào bạn muốn nó review”, agent chính giờ sẽ viết một input prompt cụ thể hơn nhiều, liệt kê đúng các file cần review.

Kỹ thuật này áp dụng được cho nhiều loại subagent khác nhau. Ví dụ, thêm “hãy trả về nguồn có thể trích dẫn” vào description của một subagent tìm kiếm web sẽ khiến agent chính đưa chỉ dẫn đó vào khi giao việc.

Định nghĩa định dạng output

Cải tiến quan trọng nhất bạn có thể làm cho một subagent là định nghĩa một định dạng output trong system prompt của nó. Điều này mang lại hai lợi ích:

• Nó tạo ra các điểm dừng tự nhiên - subagent biết nó đã xong khi đã điền đầy đủ mỗi phần trong định dạng.
• Nó ngăn subagent chạy quá lâu. Không có định dạng output rõ ràng, subagent gặp khó khăn trong việc quyết định khi nào đã nghiên cứu đủ, và có xu hướng chạy lâu hơn nhiều so với cần thiết.

Đây là ví dụ một định dạng output có cấu trúc cho một subagent review code:

Provide your review in a structured format:

1. Summary: Brief overview of what you reviewed and overall assessment
2. Critical Issues: Any security vulnerabilities, data integrity risks, or logic errors that must be fixed immediately
3. Major Issues: Quality problems, architecture misalignment, or significant performance concerns
4. Minor Issues: Style inconsistencies, documentation gaps, or minor optimizations
5. Recommendations: Suggestions for improvement, refactoring opportunities, or best practices to apply
6. Approval Status: Clear statement of whether the code is ready to merge/deploy or requires changes

Định dạng này cho subagent một checklist rõ ràng để thực hiện. Một khi mọi phần đã được điền, subagent biết nó có thể dừng lại.

Field name và description của subagent định hình input prompt mà agent chính viết ra.

Agent chính giao việc cho subagent với một input prompt cụ thể, liệt kê rõ file và trọng tâm review.

Báo cáo trở ngại

Khi một subagent phát hiện ra một cách giải quyết (workaround) trong lúc làm việc - như xử lý một vấn đề dependency, hay phát hiện một lệnh cần cờ đặc biệt - những chi tiết đó cần xuất hiện trong bản tóm tắt nó trả về. Nếu không, luồng chính sẽ phải tự khám phá lại đúng những giải pháp đó, gây lãng phí thời gian và token.

Những thứ bạn muốn được nêu ra bao gồm:

• Vấn đề thiết lập hoặc đặc điểm riêng của môi trường.
• Các workaround được phát hiện trong lúc thực hiện tác vụ.
• Các lệnh cần cờ hoặc cấu hình đặc biệt.
• Dependency hoặc import gây ra vấn đề.

Cách để lấy được thông tin này là yêu cầu rõ ràng trong định dạng output. Thêm một phần “Obstacles Encountered” vào template output của bạn sẽ giúp thông tin này luôn được nêu ra một cách đáng tin cậy.

7. Obstacles Encountered: Report any obstacles encountered during the review process. This can be: setup issues, workarounds discovered or environment quirks. Report commands that needed a special flag or configuration. Report dependencies or imports that caused problems.

Phần “Obstacles Encountered” trong system prompt, đảm bảo các trở ngại luôn được báo cáo.

Giới hạn quyền truy cập tool

Không phải subagent nào cũng cần quyền truy cập mọi tool. Hãy nghĩ xem subagent thực sự cần làm gì, và chỉ cấp cho nó những tool cần thiết cho công việc đó. Điều này mang lại hai lợi ích: ngăn các tác dụng phụ ngoài ý muốn, và làm rõ vai trò của mỗi subagent khi bạn có nhiều subagent cùng lúc.

Đây là cách suy nghĩ về quyền truy cập tool cho các loại subagent phổ biến:

• Subagent nghiên cứu / chỉ-đọc - chỉ cần Glob, Grep, và Read. Không thể vô tình sửa file.
• Code reviewer - cần quyền Bash để chạy git diff và xem những gì đã thay đổi, nhưng vẫn không cần Edit hay Write.
• Agent chỉnh sửa style / code - đây là trường hợp bạn cấp quyền Edit và Write, vì công việc của subagent là thực sự thay đổi code của bạn.

Gộp lại

Các subagent hiệu quả có chung bốn đặc điểm:

1. Description cụ thể - description kiểm soát khi nào subagent được khởi động và nó nhận chỉ dẫn gì. Hãy viết nó để định hướng cả hai.
2. Output có cấu trúc - định nghĩa một định dạng output trong system prompt để subagent biết khi nào nó xong, và trả về thông tin mà luồng chính dùng được.
3. Báo cáo trở ngại - thêm một phần trong định dạng output cho các workaround, đặc điểm riêng, và vấn đề, để luồng chính không phải khám phá lại chúng.
4. Giới hạn quyền truy cập tool - chỉ cấp cho subagent những tool nó thực sự cần. Chỉ-đọc cho nghiên cứu, bash cho reviewer, edit/write chỉ cho các agent cần thay đổi code.

Mỗi pattern này đơn giản khi đứng riêng lẻ, nhưng kết hợp lại, chúng biến một subagent từ thứ mơ hồ cố gắng giúp đỡ thành một công nhân tập trung, dễ đoán, hoàn thành đúng hạn và báo cáo lại rõ ràng.

Nguồn

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