Kỹ năng đã 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à đơn giản để phân phối.
Nhưng chính sự linh hoạt này cũng khiến bạn khó biết thế nào là tốt và hiệu quả. Loại kỹ năng nào đáng để tạo? Bí mật để viết một kỹ năng tốt là gì? Khi nào bạn nên chia sẻ chúng với người khác?
Tôi đã sử dụng kỹ năng một cách sâu rộng với nhiều kỹ năng đang được vận hành thực tế. Dưới đây là một số mẹo tôi đã học được trong quá trình đó.

1. Hiểu rõ Kỹ năng là gì

Một kỹ năng là một thư mục chứa tệp SKILL.md và (tùy chọn) một số tệp hỗ trợ:
my-skill/
├── SKILL.md          ← Tệp duy nhất bắt buộc
├── scripts/          ← Mã nguồn có thể tái sử dụng mà agent có thể chạy
├── references/       ← Tài liệu agent đọc khi cần thiết
└── assets/           ← Các mẫu (templates), hình ảnh hoặc tệp dùng trong đầu ra
Một Kỹ năng bao gồm 3 lớp:
  1. Tên (name) và Mô tả (description) trong Frontmatter: Nằm trong mọi câu lệnh (prompt) và cho agent biết khi nào cần dùng kỹ năng này.
  2. Thân tệp SKILL.md: Các chỉ dẫn bằng Markdown (phía dưới frontmatter), cho agent biết cách thức thực hiện nhiệm vụ.
  3. Tài nguyên (Assets): Các thư mục tùy chọn như scripts/, references/, và assets/.
Kỹ năng luôn thuộc vào hai nhóm:
  • Kỹ năng Năng lực (Capability skills): Giúp agent làm điều mà mô hình nền tảng không thể làm ổn định nếu thiếu nó (ví dụ: điền biểu mẫu PDF). Những kỹ năng này có thể trở nên không cần thiết khi mô hình cải tiến; các bài kiểm tra (evals) sẽ cho bạn biết khi nào điều đó xảy ra.
  • Kỹ năng Ưu tiên (Preference skills): Mã hóa quy trình làm việc cụ thể của bạn (ví dụ: các bước đánh giá mã nguồn của nhóm bạn). Những kỹ năng này có tính bền vững nhưng cần được cập nhật đồng bộ với quy trình thực tế của bạn.

2. Chú trọng vào phần Mô tả

Phần description trong SKILL.md là cơ chế kích hoạt. Nếu nó mơ hồ, agent sẽ không biết khi nào nên kích hoạt kỹ năng. Nếu quá rộng, kỹ năng sẽ kích hoạt trong mọi yêu cầu. Hãy cụ thể về việc kỹ năng làm gì VÀ khi nào nên dùng nó. Thân của kỹ năng chỉ được tải sau khi kỹ năng được kích hoạt.
| Quá mơ hồ | Cụ thể và có thể thực thi |
|------|-----|-----|
| "Giúp xử lý tài liệu" | "Tạo, chỉnh sửa và phân tích các tệp .docx; dùng để theo dõi thay đổi, bình luận, định dạng hoặc trích xuất văn bản" |
| "Hỗ trợ API" | "Dùng khi viết mã gọi Gemini API để tạo văn bản, chat nhiều lượt, tạo hình ảnh hoặc truyền dữ liệu (streaming)" |
Tôi đã thấy hiệu suất cải thiện tới 50% chỉ bằng việc cải thiện phần mô tả.

3. Viết Chỉ dẫn, đừng viết Tiểu thuyết

Agent rất thông minh. Việc của bạn là nói cho nó biết những gì nó chưa biết. Nghiên cứu cho thấy các chỉ dẫn dài dòng, quá bao quát với quá nhiều ngữ cảnh thực tế lại làm giảm hiệu suất.
  • Sử dụng các mệnh lệnh trực tiếp: Hãy viết "Luôn sử dụng interactions.create()", thay vì "Interactions API là cách tiếp cận được khuyến khích". Câu đầu là một chỉ dẫn, câu sau chỉ là thông tin bên lề mà agent có thể không thực hiện.
  • Ưu tiên ví dụ: Một đoạn mã 5 dòng có giá trị hơn một đoạn giải thích 5 đoạn văn.
  • Giải thích lý do: Khi một quy tắc là quan trọng, hãy nói rõ tại sao. "Dùng mô hình X, mô hình Y đã lỗi thời và sẽ trả về lỗi" giúp agent có khả năng khái quát hóa thay vì chỉ ghi nhớ máy móc.
  • Đừng "ép" dữ liệu (overfit): Tránh những thay đổi vụn vặt chỉ để vượt qua vài câu lệnh kiểm tra của riêng bạn. Hãy viết những kỹ năng có thể hoạt động ổn định qua hàng triệu lần gọi.

4. Giữ cho Kỹ năng tinh gọn

Đừng nhồi nhét mọi thứ vào một tệp. Agent tải thông tin theo các lớp:
  • Luôn được tải: Frontmatter của SKILL.md (tên + mô tả).
  • Tải khi kích hoạt kỹ năng: Thân tệp SKILL.md (nên giữ dưới 500 dòng).
  • Tải theo yêu cầu: Các tệp tham chiếu (references), script, asset.
Nếu kỹ năng của bạn bao quát nhiều chủ đề (ví dụ: triển khai trên AWS và GCP), hãy tách chúng thành các tệp tham chiếu riêng biệt. Agent chỉ đọc tệp nó cần, giúp tiết kiệm ngữ cảnh cho nhiệm vụ thực tế.

5. Thiết lập mức độ tự do phù hợp

Một sai lầm phổ biến là biến kỹ năng thành một quy trình từng bước: "Bước 1: Đọc tệp. Bước 2: Phân tích JSON. Bước 3: Trích xuất dữ liệu...". Khi bạn áp đặt mọi bước, bạn tước đi khả năng thích nghi, xử lý lỗi hoặc tìm cách tiếp cận tốt hơn của Agent. Hãy mô tả kết quả bạn muốn, không phải con đường để đạt được nó.
Nói cho agent biết mục tiêu cần đạt được:
❌ "Bước 1: Đọc tệp cấu hình. Bước 2: Tìm URL cơ sở dữ liệu. Bước 3: Cập nhật cổng..."
✅ "Cập nhật cổng cơ sở dữ liệu trong tệp cấu hình theo giá trị người dùng chỉ định."
Đưa ra các ràng buộc, không phải quy trình:
❌ "Bước 1: Tạo nhánh. Bước 2: Thay đổi mã. Bước 3: Chạy test..."
✅ "Luôn chạy kiểm tra (test) trước khi tạo PR. Tuyệt đối không đẩy mã trực tiếp vào nhánh main."
Nếu các bước thực hiện cần sự chính xác tuyệt đối, hãy viết một đoạn mã (script). Nếu một nhiệm vụ dễ hỏng đến mức làm bước 3 trước bước 2 sẽ phá hỏng mọi thứ, thì đó không phải vấn đề của kỹ năng, đó là vấn đề cần giải quyết bằng script.

6. Đừng bỏ qua các trường hợp phủ định

Hãy nghĩ về việc khi nào kỹ năng không nên kích hoạt. Một mô tả kiểu như "Dùng cho mọi tác vụ lập trình" sẽ chiếm quyền điều khiển của mọi yêu cầu.
"Dùng khi làm việc với tệp PDF. KHÔNG dùng cho việc chỉnh sửa văn bản thông thường, bảng tính hoặc tệp văn bản thuần túy."
Kiểm tra cả hai trường hợp "nên kích hoạt" và "không nên kích hoạt" là điều thiết yếu để tránh tối ưu kỹ năng lệch về một hướng.

7. Kiểm tra kỹ trước khi triển khai

Đừng phát hành một kỹ năng mà không có đánh giá. Mỗi lần chạy có thể có hành vi khác nhau, nên một lần kiểm tra là không đủ.
  • Chạy thủ công vài lần với các câu lệnh khác nhau. Quan sát xem nó bị lỗi ở đâu.
  • Viết ra tiêu chí "thành công" có thể đo lường được. Kết quả có biên dịch được không? Có dùng đúng API không? Có tuân thủ các bước không? Hãy đánh giá kết quả, không phải đánh giá cách làm.
  • Thử nghiệm với 10–20 câu lệnh. Trộn lẫn các câu lệnh mà kỹ năng nên xử lý, các câu lệnh nó nên bỏ qua và các trường hợp biên (edge cases).
  • Chạy nhiều lần (Multiple trials): Đầu ra của Agent không mang tính định hình. Hãy chạy 3–5 lần cho mỗi câu lệnh để xem phân phối kết quả thay vì chỉ nhìn vào một lần đạt/hỏng duy nhất.
  • Cô lập mỗi lần chạy: Sử dụng môi trường sạch cho mỗi bài kiểm tra để tránh rò rỉ ngữ cảnh giữa các lần chạy.
  • Sửa phần mô tả trước tiên: Hầu hết các vấn đề nằm ở cơ chế kích hoạt, không phải ở phần hướng dẫn.

8. Biết khi nào nên cho một Kỹ năng "nghỉ hưu"

Hãy chạy thử các bài đánh giá (evals) mà không có kỹ năng đó. Nếu chúng vẫn đạt, điều đó có nghĩa là mô hình đã hấp thụ được giá trị của kỹ năng và kỹ năng đó không còn cần thiết nữa. Điều này đặc biệt đúng với các kỹ năng năng lực; khi mô hình mạnh lên, khoảng cách sẽ thu hẹp lại.
Nguồn bài viết từ Tác giả Phil Schmid