Bản chất của Skill & Cấu trúc SKILL.md

Skill đóng gói cách thức công việc được thực hiện

Ngày 2 đã giúp agent vươn tới các tool và protocol. Tuy nhiên, khả năng tiếp cận không đồng nghĩa với việc sở hữu chuyên môn. Một MCP server có thể mở ra dữ liệu tồn kho (inventory), lịch sử khách hàng hoặc kho tài liệu, nhưng nó không thể dạy cho agent cách một chuyên gia quản lý ngành hàng (merchandiser) lập kế hoạch dự án hay cách một trưởng nhóm hỗ trợ (support lead) xử lý trường hợp ngoại lệ.

Một Agent Skill sẽ đóng gói bí quyết chuyên môn (know-how) đó thành một quy trình (procedure) tập trung, linh hoạt và dễ dàng di chuyển. Một skill thường bắt đầu bằng file SKILL.md và có thể đính kèm các script, reference (tài liệu tham chiếu) cùng các asset (tài nguyên). Agent chỉ nhìn thấy một phần mô tả (description) ngắn gọn ban đầu, chỉ nạp toàn bộ quy trình khi yêu cầu của người dùng khớp với mô tả đó, và chỉ truy xuất các tài liệu hỗ trợ khi thực sự cần thiết.

Cấu trúc package tiêu chuẩn giúp cụ thể hóa cơ chế bóc tách tiệm tiến (progressive disclosure):

refund-duplicate-charge/
├── SKILL.md                 # Bắt buộc: metadata + luồng điều khiển (control flow)
├── scripts/                 # Trích xuất, tính toán và định dạng mang tính cố định (deterministic)
├── references/              # Chính sách và kiến thức xử lý ngoại lệ, chỉ nạp khi cần
└── assets/                  # Template, schema và tài nguyên đầu ra

Runtime sẽ nạp package theo ba cấp độ (level). Level 1 gồm name và description-luôn hiển thị sẵn nên đóng vai trò là giao diện định tuyến (routing interface). Level 2 là nội dung chính (body) của SKILL.md, chỉ được nạp sau khi đã khớp yêu cầu. Level 3 là từng tài liệu tham chiếu (reference) hoặc tài nguyên (asset) cụ thể, chỉ được tải khi quy trình đang chạy cần tới; các script có thể thực thi trực tiếp mà không cần đưa mã nguồn của chúng vào prompt. Trong các thành phần này, chỉ duy nhất file SKILL.md là bắt buộc.

Cấu tạo này đem lại một quy tắc sản phẩm đơn giản cho PM: hãy giữ cho luồng quyết định (decision path) và các điều kiện ngoại lệ nằm trong SKILL.md; chuyển các công việc tính toán cố định, lặp đi lặp lại vào scripts/, tài liệu chuyên môn sâu vào references/, và các mẫu đầu ra dùng lại nhiều lần vào assets/. Nếu một chỉ dẫn (instruction) bắt buộc phải có mặt ở mọi lượt thoại (turn), nó thuộc về hướng dẫn chung (global guidance) hoặc hướng dẫn dự án (project guidance), chứ không thuộc về skill.

Hãy cùng theo dõi ví dụ refund-duplicate-charge qua cơ chế này. Khi phiên làm việc bắt đầu, agent chỉ nhìn thấy một mô tả ngắn: “Điều tra các khoản phí bị tính trùng trên thẻ cho một đơn hàng đã biết; không sử dụng cho yêu cầu kiểm tra trạng thái giao hàng hoặc thẻ bị từ chối.” Khi người dùng nói “Tôi bị tính tiền hai lần,” phần mô tả khớp yêu cầu và phần body được nạp. Body yêu cầu agent xác định đơn hàng, kiểm tra sổ sách (ledger), giải thích điều kiện hoàn tiền và dừng lại trước bất kỳ thao tác ghi (write action) nào. Sau đó, agent nạp tài liệu tham chiếu về chính sách trả hàng cho đúng thị trường liên quan, gọi script đã qua kiểm thử để chuẩn hóa mốc thời gian giao dịch, rồi trình bày kết quả bằng mẫu hóa đơn (receipt template). Chính sách chi tiết, code và template không hề tiêu tốn sự chú ý (attention) của model trước khi ý định của người dùng được xác định.

Bây giờ hãy xét tới sự đánh đổi khi đặt sai thành phần. Nếu đưa chính sách thị trường vào metadata, mọi lượt thoại đều phải trả phí token; nếu giấu ranh giới “không dùng cho thanh toán bị từ chối” trong phần reference, skill phù hợp có thể không bao giờ được nạp; nếu viết logic tính toán thời gian bằng văn xuôi (prose), model có thể thực thi khác nhau ở mỗi lần chạy. Do đó, buổi kiểm tra cấu trúc của PM cần trace một yêu cầu hợp lệ (positive request) và một yêu cầu lân cận không hợp lệ (adjacent negative request) qua cả ba cấp độ, ghi nhận rõ thành phần nào đi vào context, thành phần nào chạy ngoài context và kết quả (artifact) thu được là gì.

Hai hướng xây dựng, một thành phẩm được quản trị

Các team thường tạo ra skill theo một trong hai con đường. Con đường A: Chuyển đổi chuyên môn hiện có (Path A)-một runbook tuân thủ, hướng dẫn onboarding hoặc bài phỏng vấn chuyên gia được chuyển thành một quy trình tập trung. Chuyên gia ngành cung cấp thông tin chuẩn xác (truth); người xây dựng phân rã thông tin đó và làm cho từng quy tắc có thể kiểm chứng được. Con đường B: Đúc kết từ lịch sử thành công (Path B)-sau khi agent hoàn thành một tác vụ khó lặp đi lặp lại nhiều lần, một meta-skill sẽ đề xuất các bước, script và trường hợp đánh giá (eval case) có thể tái sử dụng. Con người vẫn phải kiểm duyệt bản nháp vì một bản ghi trace thành công có thể chỉ chứa một phương án xử lý tạm thời (workaround) chứ không phải quy tắc kinh doanh bền vững.

Cả hai hướng đều phải dẫn tới cùng một thành phẩm sản phẩm (product artifact): một folder có quản lý phiên bản (versioned), có chủ sở hữu chịu trách nhiệm (accountable owner), hợp đồng kích hoạt (trigger contract), phạm vi phân quyền (permission scope), bộ đánh giá (eval suite) và cấp độ phát hành (release tier). Con đường A có thể thất bại nếu chép nguyên văn cuốn runbook dài 30 trang; Con đường B có thể thất bại nếu bị học vẹt (overfit) theo một đợt chạy may mắn. Do đó, buổi kiểm tra thiết kế cần đặt câu hỏi: bằng chứng nào hỗ trợ cho từng bước và trường hợp thực tế (production case) nào có thể phản bác (falsify) nó?

Hãy phân biệt rõ ràng giữa các lớp (layer):

Skill và MCP kết hợp chặt chẽ với nhau. Skill nắm rõ quy trình; MCP tool cung cấp dữ liệu hoặc thực hiện hành động. Skill cũng khác với file chỉ dẫn dự án chung vì nó chỉ được nạp khi có liên quan. Điều này biến skill thành một thành tố sản phẩm (product primitive) hữu ích cho một general agent cần biến thành specialist theo yêu cầu.

Cùng một thư mục có thể có tính linh hoạt cao (portable) nhưng đường dẫn kích hoạt thì không. Một local coding agent có thể quét thư mục dự án sau khi khởi động lại, một enterprise chatbot có thể yêu cầu admin bật một bản ghi trong registry, còn ADK runtime có thể mở ra một tool load_skill được tự động sinh ra. Trong cả ba trường hợp, việc cài đặt chỉ hoàn tất khi một yêu cầu hợp lệ tự nhiên nạp đúng skill, một yêu cầu không hợp lệ không nạp skill đó, phân quyền tool chính xác và dữ liệu trace xác định đúng phiên bản đã cài.

Bảng sau tổng kết ba mô hình cài đặt (installation paradigm):

Định dạng mở không chuẩn hóa đường dẫn cài đặt, chi tiết kích hoạt, allowed-tools hay cơ chế cấp phát doanh nghiệp. Do đó, một tuyên bố về tính linh hoạt (portability claim) cần có bảng đối soát cài đặt trên nhiều runtime (cross-runtime install matrix), chứ không thể chỉ nói đơn giản “nó là Markdown nên chạy được mọi nơi.”

Ví dụ về Agents CLI trong tài liệu gốc đóng gói bảy skill xoay quanh ADK, bao phủ từ hướng dẫn quy trình, viết code, dựng khung (scaffolding), đánh giá, triển khai, phát hành cho đến khả năng quan sát (observability), rồi cài đặt chúng vào một coding agent tương thích hiện có. Bài học cho PM không nằm ở lệnh thực thi: việc đóng gói năng lực phải bao quát toàn bộ vòng đời sản phẩm và kết hợp hài hòa với giao diện hiện có của người dùng. Hãy bổ sung sơ đồ bao phủ vòng đời (lifecycle coverage map) vào bảng cài đặt để khái niệm “linh hoạt” bao gồm cả các khâu dựng, đánh giá, triển khai và quan sát, chứ không chỉ dừng lại ở bước khám phá (discovery).

Skill trở nên phổ biến vì chúng giải quyết bốn điểm nghẽn (frictions): sự phình đại ngữ cảnh (context bloat) do quá nhiều chỉ dẫn, việc thiếu bộ nhớ quy trình (procedural memory) về cách thực hiện công việc, sự quá tải vận hành khi phải tạo một subagent cho từng vai trò chuyên gia, và tính linh hoạt giữa các agent runtime khác nhau. Việc áp dụng rộng rãi bắt đầu từ các skill xử lý tài liệu cho chatbot, nhanh chóng lan sang các coding agent, và giờ đây kết hợp với các hệ thống multi-agent doanh nghiệp thông qua các thư viện skill có phân vùng phạm vi.

Hãy sử dụng thành tố (primitive) nhỏ nhất nhưng đáp ứng đủ nhu cầu:

Ví dụ, đưa 100 quy trình vận hành (runbook) logistics vào một prompt sẽ gây suy thoái ngữ cảnh (context rot) ngay lập tức; tạo 100 subagent sẽ tạo ra 100 bề mặt triển khai và đánh giá; RAG truy xuất từng đoạn thông tin nhưng không đảm bảo được thứ tự quy trình. Một thư viện gồm 100 skill hẹp sẽ giữ cho metadata định tuyến luôn sẵn sàng và chỉ nạp đúng quy trình phù hợp. Theo ước tính sơ bộ của tài liệu gốc là 50 token metadata cho mỗi skill, 100 skill tiêu tốn khoảng 5.000 token luôn thường trực trước khi phần body chính được nạp. Hồ sơ quyết định của PM phải nêu rõ ranh giới biện minh cho primitive đã chọn và tính đến khoản chi phí định tuyến cố định này.

Trước khi tạo agent thứ hai, hãy tự hỏi xem năng lực mới có thực sự cần một identity, runtime, ranh giới phân quyền hay luồng thực thi song song riêng hay không. Nếu không, một agent đi kèm thư viện skill có phân vùng phạm vi có thể giảm đáng kể chi phí triển khai, định tuyến và đánh giá.