Skill là SOP viết cho agent

Có một yêu cầu tôi đã gõ lại cho agent không biết bao nhiêu lần: viết tiếng Việt cho ra văn viết doanh nghiệp, đừng dịch sát từ bản tiếng Anh, đừng dùng khẩu ngữ. Mỗi phiên mới, agent lại bắt đầu từ con số không, và tôi lại sửa đúng những chữ đã sửa hôm trước.

Cách giải thì các công ty đã dùng từ lâu cho nhân viên: viết quy trình ra giấy. Với con người, thứ đó gọi là SOP (Standard Operating Procedure). Với agent, nó gọi là skill.

SOP tốt có những phần gì

SOP mô tả cách làm một việc lặp lại, để công việc không phụ thuộc vào trí nhớ của một người. Một SOP dùng được thường có năm phần:

• Khi nào áp dụng (trigger).
• Các bước theo thứ tự.
• Bối cảnh: công cụ, quyền hạn, thông tin cần có.
• Ngoại lệ và cách xử lý.
• Ai chịu trách nhiệm, ai phê duyệt.

Skill là SOP viết cho agent

Theo đặc tả mở Agent Skills, một skill là một thư mục chứa tệp SKILL.md. Đầu tệp có hai trường bắt buộc là name và description, trong đó description nói skill làm gì và khi nào dùng. Phần thân là hướng dẫn chi tiết.

---
name: viet-tieng-viet
description: Dùng khi viết hoặc rà nội dung tiếng Việt
  mà người khác sẽ đọc: trang web, bài blog, email, đề xuất.
---

- Viết mới từ dàn ý, không dịch từng câu từ bản tiếng Anh.
- Không dùng khẩu ngữ: "rẻ" → "ít tốn kém",
  "chạy thật" → "đưa vào vận hành".
- Khi tôi tự sửa chữ trong bài, đọc phần đã sửa
  và ghi từ mới vào quy tắc này.

Cách agent nạp skill là chỗ đáng chú ý. Đặc tả mô tả ba mức:

• Tên và mô tả của mọi skill được nạp ngay khi khởi động, khoảng 100 token mỗi skill.
• Phần thân, khuyến nghị dưới 5.000 token, chỉ nạp khi skill được dùng.
• Các tệp đi kèm như script hay tài liệu tham chiếu chỉ nạp khi việc cần tới.

Đặt cạnh SOP thì description là trigger, phần thân là các bước và ngoại lệ. Chỉ người thực thi là khác.

Skill tốt lớn lên từ lỗi thật

Đoạn mẫu ở trên rút gọn từ quy tắc viết tiếng Việt mà tôi dùng hằng ngày, chủ yếu là những cặp "đừng viết thế này, hãy viết thế kia" lấy từ chính các lần tôi sửa bài. Dòng quan trọng nhất là dòng cuối: khi tôi tự sửa chữ, agent phải đọc phần đã sửa và bổ sung vào quy tắc. Nhờ vậy skill dày lên theo những lỗi có thật, giống một SOP được cập nhật sau mỗi sự cố.

Phần ngoại lệ cũng đến theo cách đó. Công cụ cào web tôi dùng có lúc trả về bài viết nhưng thiếu ngày đăng, dù trang gốc có. Tôi ghi vào hướng dẫn: kết quả thiếu thì kiểm lại bằng công cụ khác và ghi rõ trường nào lấy từ đâu. Mục này chỉ có sau khi đã gặp.

Chuyển một SOP sẵn có thành skill

Quy trình sẵn có trên Google Docs, Notion hay Confluence chuyển được theo bốn bước:

1. Viết description thật cụ thể. "Khi sửa lỗi trong module thanh toán" tốt hơn nhiều so với "khi review code", vì agent dựa vào câu này để quyết định có dùng skill hay không.
2. Giữ ràng buộc, công cụ, định dạng đầu ra và lỗi hay gặp. Bỏ phần giải thích cho người mới.
3. Viết thành mệnh lệnh: "hãy làm X", "không được làm Y", thay cho "nhân viên cần làm X".
4. Chạy thử trên việc thật rồi sửa. Skill hiếm khi đúng ngay lần đầu.

Ví dụ, SOP khoá sổ cuối tháng thường có câu "kế toán không tự điều chỉnh số liệu, mọi chênh lệch trình kế toán trưởng". Sang skill, câu đó thành lệnh: đánh dấu dòng lệch quá 10% so với ngân sách, không tự sửa số, chỉ báo cáo. Ranh giới agent được làm gì và không được làm gì là phần đáng viết kỹ nhất.

Skill không làm agent hết sai

Phần này hay bị bỏ qua:

• Agent không phải lúc nào cũng dùng skill. Tài liệu của Claude Code ghi agent dùng skill khi thấy phù hợp, tức là nó tự đánh giá dựa trên description. Việc nào cần chắc chắn thì gọi thẳng skill bằng tên.
• Có dùng skill, agent vẫn có thể bỏ bước hoặc hiểu sai. Skill bớt việc nhắc lại, không thay việc kiểm tra kết quả. Có quy tắc tiếng Việt hẳn hoi, tôi vẫn đọc lại từng câu trước khi gửi đi.
• Skill nào cũng tốn chỗ. Mô tả của mọi skill luôn nằm trong context, nên cài hàng trăm skill không dùng tới là trả token cho thứ không cần.
• Quy trình sai thì agent chỉ làm sai nhanh hơn và đều tay hơn.

Viết hẹp, đừng viết rộng

Những skill kiểu "viết code tốt hơn" hay "rà soát mọi thứ trước khi phát hành" gần như vô dụng. Không có trigger rõ thì agent không biết lúc nào dùng, và phạm vi rộng thì nội dung không đủ sâu.

Skill tốt chỉ áp dụng cho một loại việc, nhưng khi áp dụng thì agent có đủ thông tin để làm trọn việc đó. Hẹp như vậy mới đủ ổn định để giao cho agent chạy định kỳ, miễn là vẫn có người xem kết quả.

Khi nào đáng viết một skill

Tôi không có con số hoà vốn nào để đưa ra. Tài liệu Claude Code gợi ý một dấu hiệu mà tôi thấy đúng: khi bạn cứ phải dán lại cùng một đoạn hướng dẫn, một checklist hay một quy trình nhiều bước vào khung chat. Với tôi, dấu hiệu rõ nhất là thấy mình sửa cùng một lỗi thêm một lần nữa.

Cũng đừng chép nguyên một kho skill đang được chia sẻ nhiều trên mạng. Người viết kho đó không biết nghiệp vụ và ràng buộc của bạn. Skill đáng dùng là skill bạn hiểu từng dòng và biết khi nào cần sửa, kể cả khi bản đầu do agent soạn.

Ai giỏi nhất một việc thì nên là người viết hoặc duyệt skill cho việc đó. Đưa skill vào kho mã chung thì cả nhóm dùng cùng một cách làm, và cách làm đó ở lại kể cả khi người viết nghỉ việc.

Quy trình là phương tiện

Trong thư gửi cổ đông năm 2016, Jeff Bezos viết: "Good process serves you so you can serve customers. But if you're not watchful, the process can become the thing." Quy trình tốt phục vụ bạn để bạn phục vụ khách hàng, nhưng nếu không để ý, chính quy trình sẽ thành mục tiêu.

Skill cũng vậy. Có nhiều skill không phải thành tích. Thước đo là agent ra kết quả đúng và đều, và khi kết quả lệch, bạn biết sửa dòng nào.

Skill khác prompt và RAG ra sao, tôi đã viết trong bài ChatGPT khác GPT, agent khác chatbot, và hóa đơn cũng khác.