AI Agent Skills: cách đóng gói một kỹ năng để AI làm việc ổn định hơn

Khi mới tìm hiểu AI Agent, rất dễ gặp những từ nghe kỹ thuật như “skill”, “workflow”, “tool”, “guardrail”, “schema”. Nhưng ý tưởng cốt lõi thực ra rất gần với cách doanh nghiệp vận hành: nếu muốn một trợ lý làm cùng một loại việc nhiều lần, bạn phải chỉ rõ việc cần đạt gì, dữ liệu lấy ở đâu, làm theo bước nào, lỗi nào phải dừng và kết quả đúng trông như thế nào.

Một AI Agent Skill có thể hiểu đơn giản là quy trình làm việc đóng gói để AI dùng lại. Nó không phải một câu thần chú dài. Prompt giúp AI xử lý một lượt; skill giúp AI xử lý một loại việc theo chuẩn.

Bài này dành cho người mới. Không cần biết code. Bạn sẽ thấy cách đi từ một công việc thật → template → skill → test → version, kèm ví dụ cụ thể cho Sales, SEO và báo cáo.

1. Prompt, template, workflow và skill khác nhau thế nào?

Prompt là lời giao việc trong một lần. Template là mẫu giao việc dùng lại. Workflow là chuỗi bước từ input đến output. Skill đóng gói workflow, nguồn, tool, QA và điểm dừng để AI có thể thực hiện nhất quán hơn.

Ví dụ: prompt là “hãy tóm tắt cuộc họp này”. Template là mẫu luôn yêu cầu quyết định, owner, deadline và câu hỏi mở. Workflow là lấy transcript → lọc quyết định → kiểm tên người → tạo follow-up. Skill là toàn bộ quy trình đó, kèm rule “không tự bịa deadline” và nơi lưu kết quả.

Người mới thường nhảy từ prompt thẳng sang “xây agent”. Cách dễ hơn là ổn định template và workflow trước. Khi bạn còn chưa biết output đúng là gì, skill chỉ đóng gói sự mơ hồ.

Một dấu hiệu nên nâng từ template lên skill: công việc lặp thường xuyên, có nguồn tương đối ổn, có ít nhất vài bước và người dùng đã biết lỗi nào thường xảy ra.

2. Bảy thành phần tối thiểu của một skill dễ kiểm

Một skill cơ bản nên trả lời bảy câu. Outcome: kết quả cuối cần đạt là gì? Input: cần file hoặc dữ liệu nào? Nguồn chuẩn: khi mâu thuẫn tin nơi nào? Steps: làm theo thứ tự nào? Tools: dùng công cụ nào? Guardrails: lỗi nào phải dừng? DoD: tiêu chí nào mới tính là hoàn thành?

Với người mới, “guardrail” chỉ là hàng rào an toàn. Ví dụ: thiếu bảng giá thì không tự nghĩ giá; thiếu nguồn thì ghi MISSING; không chắc người nhận email thì không gửi.

Ví dụ skill tạo proposal draft: outcome là bản proposal để sales duyệt; input gồm brief khách, hồ sơ năng lực và bảng giá; nguồn giá chỉ lấy từ rate card; steps là trích nhu cầu → xác định data gap → chọn giải pháp → lấy giá → draft; guardrail là không bịa case và không tự giảm giá; DoD là proposal có đủ phạm vi, giá nguồn và câu hỏi mở.

Chỉ cần viết được bảy phần này bằng tiếng Việt đời thường, bạn đã có bộ xương của một skill. Chưa cần code hay agent framework.

3. Xây skill từ công việc đã chạy thật, không từ trí tưởng tượng

Cách an toàn nhất là chọn một việc đã làm thủ công vài lần. Ghi lại từng bước và đặc biệt ghi lại lỗi. Skill tốt thường được sinh ra từ “điều chúng ta đã học sau khi thực thi”, không phải từ một buổi brainstorm.

Ví dụ nghiên cứu đối thủ: lần đầu AI có thể lấy nguồn cũ, trộn fact với opinion, bỏ qua đối thủ quan trọng. Sau vài lần, team nhận ra cần rule nguồn tối đa 6 tháng, fact phải có link, inference tách riêng và data gap phải hiện rõ. Những bài học này trở thành skill.

Mini-case SEO: writer tạo bài hay nhưng trùng intent với URL đã live. Skill được bổ sung bước cannibalization trước outline. Sau đó team phát hiện bài vẫn thiếu ảnh, nên thêm Visual Gate. Skill trưởng thành nhờ lỗi thật được biến thành rule.

Đây cũng là lý do nên có changelog. Khi chất lượng tăng hoặc giảm, bạn biết thay đổi nào đã xảy ra thay vì đoán.

Nếu công việc chưa từng được thực hiện ổn định bằng người, đừng vội tự động hóa. Trước hết hãy làm rõ quy trình bằng tay.

4. Skill phải biết dừng: “không biết” đôi khi là output đúng nhất

Một skill nguy hiểm không phải skill làm ít, mà là skill luôn cố tạo kết quả. Trong công việc thật, có những lúc dừng là hành vi đúng.

Ví dụ: skill báo giá cần bảng giá canonical. Nếu bảng giá không truy cập được, output đúng là “BLOCKED: thiếu rate card”, không phải tự lấy giá từ email cũ. Skill nghiên cứu không tìm thấy nguồn chính thức thì ghi data gap, không tạo một citation có vẻ hợp lý.

Nguyên tắc này thường gọi là “fail-closed”: khi thiếu điều kiện quan trọng, hệ thống dừng thay vì đi tiếp bằng giả định. Người mới chỉ cần nhớ: đừng để AI lấp chỗ trống mà bạn muốn con người nhìn thấy.

Tình huống quyền: AI có thể draft email nhưng không biết người nhận cuối. Skill nên tạo draft và hỏi người dùng, không tự chọn địa chỉ gần giống trong danh bạ.

Guardrail tốt giúp agent tự chủ hơn ở vùng an toàn, vì người quản lý biết nó sẽ dừng khi chạm biên.

5. Tách skill nhỏ và nối lại thay vì tạo một “siêu skill” làm mọi thứ

Một skill khổng lồ từ nghiên cứu → viết → ảnh → xuất bản → báo cáo rất khó debug. Khi kết quả sai, bạn không biết lỗi ở nguồn, writer hay publisher.

Cách rõ hơn là tách năng lực: research skill, brief skill, writing skill, QA skill, visual skill, publish skill. Một orchestrator — tức bộ điều phối — ghép chúng theo thứ tự.

Ví dụ: SEO workflow có thể là Research → Evidence Pack → Brief → Writer → Beginner QA → Visual Editor → Publisher. Nếu ảnh lỗi, text vẫn giữ nguyên. Nếu cannibalization fail, writer chưa được gọi. Mỗi skill có đầu vào và đầu ra riêng.

Với doanh nghiệp nhỏ, không cần tách quá vụn. Chỉ tách khi một phần có nguồn, rủi ro hoặc tiêu chí QA khác rõ ràng.

6. Input/output có cấu trúc giúp skill nối với nhau ổn định

Nếu skill nào cũng nhận một đoạn văn tự do và trả một đoạn văn tự do, workflow dài sẽ dễ lệch. Có thể dùng một cấu trúc đơn giản để các bước hiểu nhau.

Ví dụ output research: facts, sources, insights, data gaps, recommended angles. Writer nhận đúng các trường đó. QA trả verdict, blockers, required fixes. Publisher chỉ nhận bài khi verdict PASS.

“Schema” chỉ là mẫu cấu trúc dữ liệu. Người mới có thể bắt đầu bằng bảng hoặc JSON đơn giản; không cần xây API ngay.

Ví dụ Sales: lead intake trả tên công ty, nhu cầu đã nêu, timeline, budget nếu có nguồn, data gap và câu hỏi cần hỏi. Proposal skill đọc đúng cấu trúc đó. Nếu field budget là MISSING, proposal không tự tạo budget.

Output có cấu trúc cũng giúp log và đo dễ hơn: bạn biết field nào thường thiếu, bước nào thường fail, thay vì chỉ đọc một đống text.

7. Versioning và test set: cách không để skill tốt hôm nay thành tệ ngày mai

Skill sẽ thay đổi khi model, tool, dữ liệu và yêu cầu thay đổi. Vì vậy cần phiên bản: 0.1, 0.2, 1.0 hoặc cách đặt tên tương tự. Mỗi output quan trọng nên biết được tạo bởi version nào.

Ví dụ: Writer 0.1 tạo bài quá mỏng nhưng điểm QA vẫn cao. Bản 0.2 thêm Beginner Gate và Visual Gate. Nếu không ghi version, vài tháng sau team khó biết bài nào dùng chuẩn cũ và bài nào dùng chuẩn mới.

Test set là một bộ tình huống cố định để chạy lại sau mỗi thay đổi. Một skill proposal có thể có case dữ liệu đầy đủ, thiếu giá, khách yêu cầu ngoài policy, file mâu thuẫn. Kỳ vọng từng case là PASS, ASK, BLOCK hoặc ESCALATE.

Người mới có thể bắt đầu bằng 10 case. Không cần hệ thống đánh giá phức tạp. Chỉ cần ghi input, expected action và lỗi không được phép.

Nếu chỉ nhớ ba điều: skill phải có đầu ra rõ, phải biết dừng và phải có test set trước khi mở rộng.

8. Đo skill bằng output được chấp nhận và outcome thật

Đừng chấm skill bằng độ dài prompt hoặc vẻ “thông minh” của tài liệu. Chấm bằng tỷ lệ output đạt QA, số lần phải sửa, số lỗi nghiêm trọng, thời gian xử lý và outcome cuối.

Ví dụ Writer Skill: không phải viết 2.500 từ là tốt. Bài phải đúng intent, dễ hiểu, có ví dụ, có nguồn, có ảnh hữu ích, không trùng URL và được publish. Sau publish mới theo dõi impression, click, traffic.

Ví dụ Sales Skill: meeting prep tốt khi sales dùng được, ít phải sửa và bước vào cuộc gọi với đủ context. Không phải vì AI tạo 20 trang.

Một chỉ số hữu ích là accepted output rate — tỷ lệ đầu ra được người dùng chấp nhận sau QA. Nếu tỷ lệ thấp, cần xem lỗi ở input, skill hay model.

Làm ngay: chọn một công việc lặp và viết 7 thành phần của skill trên một trang. Sau đó tạo 5–10 tình huống test. Nếu muốn xây skill cho đội ngũ AI theo workflow thật, liên hệ Học viện AI để bắt đầu từ công việc và outcome.

Một cách tự kiểm skill trước khi cho chạy thật: hãy nhờ một người không tham gia viết skill đọc duy nhất phần hướng dẫn và chạy 3 case. Nếu họ phải hỏi lại “nguồn ở đâu?”, “đầu ra cần dạng gì?” hoặc “trường hợp thiếu dữ liệu thì làm gì?”, skill vẫn đang dựa vào kiến thức trong đầu người viết thay vì tự mô tả đủ.

Tiếp theo, thử cố tình làm input xấu: bỏ một file bắt buộc, đưa hai nguồn mâu thuẫn, dùng một yêu cầu ngoài phạm vi. Skill tốt phải phản ứng đúng: hỏi thêm, báo thiếu hoặc dừng. Đây là phần nhiều demo bỏ qua vì demo thường chỉ dùng case đẹp.

Ví dụ rất đời thường: skill viết bài Facebook nhận đầu vào là chủ đề nhưng thiếu brand voice. Nếu brand voice là bắt buộc, nó nên dừng và yêu cầu nguồn; nếu không bắt buộc, phải nói rõ đang dùng giọng mặc định. Sự minh bạch này giúp người dùng biết mức tin cậy của output.

Khi skill đi vào vận hành, nên lưu ba loại bằng chứng: input nào đã dùng, version skill nào chạy và output cuối được chấp nhận hay bị sửa. Sau vài chục lượt, bạn sẽ thấy phần nào của skill tạo lỗi nhiều nhất và cải tiến dựa trên dữ liệu thay vì cảm giác.

Một nguyên tắc hữu ích nữa là đừng nhồi kiến thức doanh nghiệp vào prompt nếu đã có nguồn chuẩn. Skill nên biết nơi đọc policy, bảng giá hoặc guideline hiện hành. Khi nguồn đổi, bạn cập nhật nguồn; không phải sửa 10 prompt khác nhau.

Với đội nhiều người, hãy chỉ định owner của skill. Owner không cần tự chạy mọi task, nhưng chịu trách nhiệm version, test set và quyết định khi nào một thay đổi đủ tốt để phát hành. Nhờ vậy skill không bị “mỗi người sửa một chút” rồi mất chuẩn.

Khi nào chưa nên tạo skill? Nếu công việc chỉ xảy ra một lần, đầu vào thay đổi hoàn toàn mỗi lượt hoặc đội chưa thống nhất thế nào là kết quả đúng, hãy dùng chat/template trước. Skill chỉ đáng đóng gói khi có một pattern đủ ổn định để kiểm thử và cải tiến.

Kết luận: model mạnh hơn làm skill có giá trị hơn, không ít giá trị hơn

AI càng mạnh, một prompt đơn lẻ càng dễ cho kết quả đẹp. Nhưng doanh nghiệp vẫn cần skill để giữ nguồn, quyền, QA, version và cách phối hợp với hệ thống khác.

Đừng bắt đầu bằng personality của agent. Bắt đầu bằng một công việc thật: input là gì, output đúng là gì, lỗi nào phải dừng và bằng chứng nào chứng minh skill tạo giá trị. Khi những câu này rõ, AI Agent mới trở thành một phần của vận hành thay vì một chatbot được đặt tên.