Skill đã trở thành một trong những điểm mở rộng được sử dụng nhiều nhất trong các agent. Chúng linh hoạt, dễ tạo và dễ phân phối.
Nhưng sự linh hoạt này cũng khiến việc biết skill nào tốt và skill nào hiệu quả trở nên khó khăn. Loại skill nào đáng để tạo ra? Bí quyết để viết một skill tốt là gì? Khi nào thì nên chia sẻ chúng với người khác?
Skill hiện đang được sử dụng rất nhiều. Dưới đây là một số lời khuyên hữu ích trong quá trình này!
1. Hiểu rõ skill là gì
Skill là một thư mục chứa file SKILL.md và có thể kèm một số file hỗ trợ:
my-skill/
├── SKILL.md ← File bắt buộc duy nhất
├── scripts/ ← Code có thể tái sử dụng mà agnet có thể chạy
├── references/ ← Tài liệu mà agent đọc khi cần
└── assets/ ← Template, hình ảnh hoặc file được sử dụng trong đầu ra
Một skill bao gồm 3 lớp:
namevàdescription(Frontmatter): Được đưa vào mọi prompt và cho agent biết khi nào cần sử dụng skill.- Nội dung (body) của
SKILL.md: Hướng dẫn bằng Markdown (bên dưới phần mở đầu), cho agent biết cách thực hiện nhiệm vụ. - Assets (tùy chọn): Các thư mục
scripts/,references/vàassets/.
Skill luôn được chia thành hai loại:
- Capability skill giúp agent thực hiện những việc mà mô hình cơ bản không thể làm một cách nhất quán (ví dụ: điền biểu mẫu PDF) nếu không có nó. Những skill này có thể trở nên không cần thiết khi mô hình được cải thiện, các đánh giá sẽ cho bạn biết khi nào.
- Preference skill mã hóa workflow cụ thể của bạn (ví dụ: các bước xem xét code của nhóm bạn). Những skill này bền vững nhưng cần phải đồng bộ với quy trình thực tế của bạn.
2. Hoàn thiện phần mô tả
Phần description trong SKILL.md của bạn là cơ chế kích hoạt. Nếu nó mơ hồ, agent sẽ không biết khi nào cần kích hoạt skill. Nếu nó quá chung chung, skill sẽ được kích hoạt trên mọi yêu cầu. Hãy cụ thể về những gì skill làm VÀ khi nào cần sử dụng nó. Bao gồm cả "cái gì" và "khi nào" trong phần mô tả. Phần thân của skill chỉ được load sau khi skill được kích hoạt.
| ❌ Quá mơ hồ | ✅ Cụ thể và khả thi |
| - "Tài liệu hỗ trợ" - "Trợ giúp API" | - "Tạo, chỉnh sửa và phân tích các file .docx, sử dụng cho các thay đổi được theo dõi, nhận xét, định dạng hoặc trích xuất văn bản" - "Sử dụng khi viết code gọi Gemini API để tạo văn bản, trò chuyện nhiều lượt, tạo hình ảnh hoặc stream" |
Hiệu suất có thể được cải thiện 50% chỉ bằng cách cải thiện mô tả.
3. Viết hướng dẫn, không phải bài luận
Các agent rất thông minh. Nhiệm vụ của bạn là cho chúng biết những gì chúng chưa biết. Nghiên cứu cho thấy mô tả dài, toàn diện với quá nhiều ngữ cảnh thực sự làm giảm hiệu suất.
- Sử dụng chỉ thị: "Luôn sử dụng
interactions.create()", chứ không phải "Interactions API là phương pháp được khuyến nghị". Câu đầu tiên là một chỉ thị, câu thứ hai là thông tin vụn vặt mà agent sẽ không thực hiện. - Nên bao gồm ví dụ: Một đoạn code 5 dòng tốt hơn một lời giải thích 5 đoạn.
- Giải thích lý do: Khi một quy tắc quan trọng, hãy nói rõ lý do. "Sử dụng mô hình X, mô hình Y đã lỗi thời và sẽ trả về lỗi" giúp agent khái quát hóa vượt ra ngoài các trường hợp test cụ thể, chứ không chỉ ghi nhớ.
- Đừng huấn luyện quá mức: Tránh những thay đổi "rườm rà" chỉ vượt qua 3 prompt test của bạn. Viết các skill hoạt động trên hàng triệu lần gọi.
4. Giữ cho skill gọn nhẹ
Đừng cho tất cả mọi thứ vào một file. Agent load thông tin theo từng lớp:
- Luôn được load: Frontmatter of
SKILL.md,name+description - Được load khi skill được kích hoạt: phần thân của
SKILL.md(giữ ở mức dưới 500 dòng) - Được load theo yêu cầu: Các file tham chiếu, script, asset
Nếu skill của bạn bao gồm nhiều chủ đề (ví dụ: triển khai AWS so với GCP), hãy chia chúng thành các file tham chiếu riêng biệt. Agent chỉ đọc file mà nó cần. Điều này giúp tiết kiệm ngữ cảnh cho nhiệm vụ thực tế.
Mẹo: Nếu một file tham chiếu dài hơn 500 dòng, hãy thêm mục lục với "gợi ý dòng" ở đầu để agent có thể nhanh chóng tìm thấy những gì nó cần.
5. Thiết lập mức độ tự do phù hợp
Một lỗi thường gặp khi tạo skill là biến skill thành workflow từng bước: "Bước 1: Đọc file. Bước 2: Phân tích JSON. Bước 3: Trích xuất các trường…" Khi chỉ định từng bước, bạn sẽ tước đi khả năng thích ứng, khắc phục lỗi hoặc tìm ra cách tiếp cận tốt hơn của họ. Hãy mô tả điều bạn muốn, chứ không phải con đường để đạt được điều đó.
Hãy cho agent biết mục tiêu cần đạt được:
❌ "Bước 1: Đọc file cấu hình. Bước 2: Tìm URL cơ sở dữ liệu. Bước 3: Cập nhật số cổng. Bước 4: Ghi lại file."
✅ "Cập nhật cổng cơ sở dữ liệu trong file cấu hình thành giá trị do người dùng chỉ định."
Cung cấp các ràng buộc, không phải quy trình:
❌ "Bước 1: Tạo nhánh. Bước 2: Thực hiện thay đổi. Bước 3: Chạy thử nghiệm. Bước 4: Mở yêu cầu kéo (PR)."
✅ "Luôn chạy thử nghiệm trước khi mở yêu cầu kéo. Không bao giờ đẩy trực tiếp vào nhánh chính."
Nếu các bước cụ thể quan trọng, hãy viết một script. Nếu tác vụ dễ bị lỗi và việc thực hiện bước 3 trước bước 2 làm hỏng mọi thứ, đó không phải là vấn đề về skill, mà là vấn đề liên quan đến việc viết script.
6. Đừng bỏ qua các trường hợp phủ định!
Hãy nghĩ về khi nào skill không nên được kích hoạt. Một mô tả như "Sử dụng cho bất kỳ tác vụ lập trình nào" sẽ chiếm quyền kiểm soát mọi yêu cầu.
"Sử dụng khi làm việc với các file PDF. KHÔNG sử dụng cho việc chỉnh sửa tài liệu nói chung, bảng tính hoặc file plain text."
Kiểm tra cả trường hợp "nên kích hoạt" và "không nên kích hoạt" là điều cần thiết. Nếu không, bạn sẽ tối ưu hóa skill theo một hướng.
7. Kiểm tra trước khi phát hành
Đừng phát hành một skill mà không đánh giá. Mỗi lần chạy có thể hoạt động khác nhau, vì vậy một lần kiểm tra là không đủ.
- Chạy thủ công một vài lần với các prompt khác nhau. Quan sát xem nó bị lỗi ở đâu. Nó có giả định tồn tại một sự phụ thuộc nào đó không? Nó có bỏ qua các bước không?
- Hãy ghi lại những gì được coi là "thành công". Đầu ra có biên dịch được không? Nó có sử dụng đúng API không? Nó có tuân theo các bước không? Đánh giá kết quả, không phải đường dẫn.
- Hãy thử 10-20 prompt test. Kết hợp các prompt mà skill nên xử lý, những prompt mà skill nên bỏ qua và các trường hợp ngoại lệ khó. Mỗi prompt nên có tiêu chí thành công riêng.
- Chạy nhiều lần thử. Đầu ra của agent không mang tính xác định. Chạy 3-5 lần thử cho mỗi prompt và xem xét sự phân bố thay vì chỉ một kết quả thành công/thất bại.
- Tách biệt từng lần chạy. Sử dụng môi trường sạch cho mỗi lần kiểm thử. Sự rò rỉ ngữ cảnh giữa các lần chạy che giấu những lỗi thực sự.
- Sửa mô tả trước. Hầu hết các vấn đề nằm ở trình kích hoạt, không phải ở hướng dẫn.
8. Biết khi nào nên loại bỏ một skill
Chạy các bài đánh giá mà không có skill đó. Nếu chúng thành công, mô hình đã hấp thụ giá trị của skill và skill đó không còn cần thiết nữa. Hãy loại bỏ nó! Điều này đặc biệt đúng đối với các capability skill, khi những mô hình được cải thiện, khoảng cách sẽ thu hẹp lại.