Mở đầu: Vì sao “skill” nghe thông minh hơn thực tế
Cách nói chuyện quanh “skill” AI hiện nay ồn ào vì một lý do đơn giản: từ đó gợi năng lực, tiến bộ, gần như một dạng học. Cách đóng khung đó tiện cho demo và marketplace. Nó cũng dễ gây hiểu nhầm.
Từ góc nhìn hệ thống, skill không phải trí tuệ. Không phải engine suy luận mới. Không chứng minh model đã học được khả năng tái sử dụng theo nghĩa kỹ sư thường dùng. Thực tế, skill là cách cấu trúc hóa việc model nhận chỉ dẫn, chọn bước tiếp theo và được phép gọi công cụ nào.
Mô hình tư duy hữu ích nhất thường nhàm chán hơn nhưng chính xác hơn:
$$ \text{Skill} = \text{prompt chuẩn hóa} + \text{logic workflow} + \text{metadata thực thi} $$
Phân biệt đó quan trọng. Coi skill là gói trí tuệ đóng sẵn, bạn sẽ mua sai lớp trừu tượng. Coi chúng là artifact workflow phủ lên model xác suất, bạn có thể suy luận về failure mode trước khi production dạy bài đắt hơn.
Prompt là phần nổi. Phần lớn hành vi vận hành nằm dưới mặt nước: logic workflow, giả định routing và ranh giới thực thi công cụ.
Kiến trúc lõi: Prompt, skill và MCP là ba lớp khác nhau
Cách gọn nhất để mô tả stack:
- Prompt nói người dùng muốn gì.
- Skill kẹp cách hệ thống nên tiến hành.
- MCP là chuẩn kết nối model với công cụ, nguồn dữ liệu và workflow bên ngoài.
Giới thiệu chính thức về MCP mô tả đây là open standard để nối ứng dụng AI với hệ thống ngoài như data source, tool và workflow: What is the Model Context Protocol (MCP)?. Đó là tầng vận chuyển và tương tác, không phải suy luận.
Skill không thay thế model. Nó bọc model trong ràng buộc thủ tục và đường thực thi bên ngoài.
Phần tách lớp này nhiều đội bỏ qua. Họ gom ba mối quan tâm vào một nhóm gọi là “khả năng agent,” rồi ngạc nhiên khi debug không còn đường vào.
| Lớp | Bản chất thực | Việc chính | Tính xác định | Kiểu hỏng điển hình |
|---|---|---|---|---|
| Prompt | Chuỗi đầu vào | Diễn đạt ý định và ngữ cảnh cục bộ | Không | Mơ hồ, thiếu sót, prompt drift |
| Skill | Định nghĩa workflow | Định hình thứ tự suy luận, routing và kiểm tra | Không | Nhánh sai, giả định ẩn, tái dùng giòn |
| MCP | Ranh giới giao thức | Nối model với tool và dữ liệu | Phần lớn có | Lỗi quyền, schema xấu, lộ tool không an toàn |
Điểm then chốt: skill không “nâng cấp thần kỳ” model bên dưới. Nó thu hẹp lối model được phép đi.
Vòng thực thi: Hành vi thật hình thành ở đây
Hành vi của model không nằm gọn trong một file tên “skill.” Nó nổi lên trong lúc chạy, từng quyết định một.
Vì vậy câu “model có skill đó” không chính xác. Điều nó thực có là quyền truy cập tạm thời vào:
- mô tả workflow,
- bề mặt schema công cụ,
- một ít state cục bộ,
- và một chuỗi cơ hội để quyết định sai.
Câu cuối không phải hoài nghi. Đó là kiến trúc. AgentBench hữu ích ở đây vì đánh giá LLM như agent trong môi trường tương tác và làm rõ failure mode lặp lại như suy luận dài hạn kém, ra quyết định yếu và làm theo chỉ dẫn không đủ chặt: AgentBench: Evaluating LLMs as Agents.
Khi một đội nói “Chúng tôi đã thêm skill,” câu hỏi kế tiếp nên là: họ đã thêm vòng điều khiển mới nào, và nó có thể gãy ở đâu?
Bài toán marketplace: Nhiều mục trông giàu nhưng không phải năng lực
Catalog skill lớn tạo ảo giác trưởng thành. Số mục tăng nhanh, nhưng khối lượng không bằng khả năng khác biệt hóa.
Thực tế thường là:
- nhiều skill trùng ý định,
- đặt tên không nhất quán,
- tiêu chí đánh giá yếu hoặc không có,
- và phần lớn mục mã hóa quan điểm cách giải bài toán, không phải bảo chứng đã giải tốt.
Marketplace có thể trông phong phú nhưng vẫn bị thống trị bởi workflow chồng chéo và khác biệt nông.
Điều đó không làm marketplace vô dụng. Nó khiến việc đọc na ná trở nên nguy hiểm. Họ bán đóng gói, curation và ý kiến workflow. Đôi khi có giá trị. Đôi khi chỉ là kịch phân loại.
Vùng ác mộng: Trade-off kỹ thuật không biến mất
Hệ thống production không quan tâm workflow được marketing là skill, agent, recipe hay gói automation. Nó vẫn phải trả bằng độ trễ, độ phức tạp vận hành và blast radius.
Bốn điểm đau lặp lại gần như trong mọi triển khai nghiêm túc.
1. Chọn sai skill thường là lỗi đầu tiên
Khi tích lũy đủ skill, routing trở thành bài toán hệ thống thật sự. Thách thức không còn là “model có làm được việc này không?” mà là “runtime có chọn đúng workflow dưới ngữ cảnh một phần, ý định mơ hồ và trạng thái công cụ nhiễu không?”
Chọn sai skill làm hỏng mọi thứ phía sau. Hệ thống có thể chạy hoàn hảo trong workflow sai và vẫn cho ra rác.
2. Phi xác định không biến mất
Skill thêm khung. Nó không gỡ hành vi xác suất của model trong vòng lặp.
Bạn vẫn phải tính đến:
- bỏ qua chỉ dẫn,
- dùng tool lệch một phần,
- biện minh ảo giác,
- và hỏng im lặng khi đầu ra trung gian đủ “hợp lý” để qua cửa.
3. Độ trễ và chi phí cộng dồn từng bước
Mỗi lần thêm kiểm tra, tầng routing, gọi tool hay vòng reflection đều tốn thêm.
Ở mức đơn giản, tổng độ trễ có thể nghĩ gần đúng là:
$$ T_{total} \approx \sum_{i=1}^{n}(T_{reason,i} + T_{tool,i} + T_{validation,i}) $$
Trong đó $n$ là số giai đoạn workflow. Công thức không cần tinh xảo. Nó đủ để nhắc đội: “thêm một bước an toàn nữa” không bao giờ miễn phí.
4. Bảo mật tệ hơn ngay khi tool trở nên thật
Khoảnh khắc MCP (hoặc lớp tương đương) chạm file, database, API nội bộ hay điều khiển hạ tầng, bề mặt tấn công mở rộng.
Câu hỏi threat model quan trọng hơn vòng hype:
- Tool nào có thể đổi state?
- Ranh giới tin cậy ở đâu?
- Blast radius ra sao nếu model chọn hành động sai nhưng vẫn có credential hợp lệ?
- Thao tác nào bắt buộc có phê duyệt của người?
Nếu không ghi lại những câu đó, hệ thống chưa sẵn sàng production. Đó là demo kèm quyền.
Thực tế benchmark: Skill generic hiếm khi vào production “sạch”
Một lỗi dễ mắc là lẫn hiệu năng demo với độ tin cậy production. Skill đóng gói sẵn có thể trông ổn trong showcase hẹp và vẫn sụp khi gặp edge case theo miền, thiếu ngữ cảnh hay ràng buộc governance doanh nghiệp.
Điều đó không có nghĩa skill theo định nghĩa là thất bại. Nghĩa là giá trị đến từ khớp ngữ cảnh, không từ nhãn.
| Mẫu | Hợp nhất khi | Hỏng thường gặp | Sẵn sàng production |
|---|---|---|---|
| Chỉ prompt | Việc đơn giản, rủi ro thấp | Cấu trúc không ổn định, không có điều khiển vận hành | Thấp đến trung bình |
| Skill marketplace generic | Thử nhanh | Giả định ẩn, khớp miền yếu | Thấp |
| Skill nội bộ tinh theo ngữ cảnh | Workflow lặp, ranh giới rõ | Chi phí duy trì và phức tạp routing | Trung bình đến cao |
Kết luận nhàm chán mới đúng: tinh chỉnh nội bộ thắng đóng gói generic khi workflow thực sự quan trọng.
Ngã ba của kiến trúc sư
Nếu bạn đang xây hệ agent nghiêm túc, quyết định không phải skill tốt hay xấu. Quyết định là bạn muốn skill đóng vai trò gì trong control plane.
Phương án A: Coi skill như SOP nội bộ tái sử dụng
Hợp lý khi:
- workflow lặp lại,
- quyền được giới hạn,
- và có thể đo được chất lượng.
Đây là use case đáng tin nhất. Skill trở thành quy trình vận hành nội bộ có versioning, đánh giá và khả năng kiểm toán.
Phương án B: Coi skill như hàng hóa marketplace
Chỉ ổn nếu bạn chấp nhận đang mua giả định của người khác.
Có thể chấp nhận được cho thử nghiệm rủi ro thấp. Nền móng yếu cho quy trình cốt lõi kinh doanh trừ khi bạn tự xác minh lại workflow, quyền và đầu ra trong môi trường của mình.
Phương án C: Coi skill như lớp hỗ trợ con người
Đây thường là mẫu an toàn nhất.
Để skill soạn, phân loại, định tuyến, tóm tắt hoặc chuẩn bị. Giữ quyền quyết định cuối cho người với hành động mang chi phí, tuân thủ hoặc hậu quả khó đảo ngược. Thực tế, nhiều đội thấy tỷ lệ giá trị trên đau vận hành cao nhất ở đây.
Vòng làm việc khả thi thường lặp: định nghĩa workflow, thử trên case thật, triển khai có kiểm soát, thu thập lỗi và tinh chỉnh skill thay vì thần thánh hóa nó.
Kết
Skill không thay thế tư duy. Nó phóng đại hậu quả của tư duy đã cài sẵn trong hệ thống.
Nếu workflow gốc được thiết kế tốt, quyền bị siết và vòng đánh giá trung thực, skill có thể cải thiện tính nhất quán và giảm công vận hành. Nếu kiến trúc yếu, skill chỉ công nghiệp hóa suy luận yếu.
Đó mới là ranh giới thật.
Đội thắng ở đây sẽ không phải đội thu thập nhiều skill đóng gói nhất. Sẽ là đội hiểu workflow của chính họ đủ sâu để thiết kế, thử và siết chúng như mọi subsystem quan trọng khác.