Skill, MCP và subagent: giải thích dễ hiểu cho người không code

Thử tưởng tượng bạn vừa loay hoay làm xong một cái app AI chạy khá ổn. Hớn hở khoe lên Discord, và rồi ai đó phán: "Nhớ set up skill đàng hoàng nha", "Gắn MCP vào chưa?", hoặc "Cái này chạy bằng subagent mới mượt". Bạn khựng lại, đi tìm hiểu, và nhận ra hầu hết các bài hướng dẫn dường như đều mặc định bạn đã rành mấy chữ này từ kiếp nào rồi.

Tóm lại trong một câu cho dễ nhớ:

Skill thay đổi thứ AI của bạn biết. MCP thay đổi thứ nó chạm được. Subagent thay đổi ai là người làm việc đó.

Chỉ vậy thôi. Phần còn lại của bài viết này sẽ đi sâu vào việc: mỗi công cụ trông như thế nào trong thực tế, làm sao để biết vấn đề bạn đang gặp cần dùng cái nào, và quan trọng nhất là những chỗ nếu chọn sai, bạn sẽ tốn tiền thật.

Và bạn yên tâm, không cần phải là lập trình viên hay biết đọc code để theo dõi bài này.

80%

người đang xây app trên Lovable tự nhận mình làm ở vị trí phi kỹ thuật (non-technical). Số liệu tự khai, chưa qua kiểm toán độc lập, khảo sát hơn 14.300 người dùng của một nền tảng duy nhất. Lovable Build Economy 2026

66%

lập trình viên nói thứ khó chịu nhất ở code AI là loại "nhìn có vẻ đúng nhưng không đúng hẳn". Số liệu tự khai, khảo sát khoảng 49.000 người. Stack Overflow 2025

Bảng so sánh nhanh

Có một sự thật thú vị: hai trong ba thứ ở trên hoàn toàn có thể được tạo ra bởi người không biết code, bằng ngôn ngữ giao tiếp hàng ngày. Skill và Subagent đúng nghĩa đen chỉ là những file text bình thường đi kèm vài dòng tiêu đề. Lát nữa chúng ta sẽ xem ví dụ cụ thể.

Trước hết, có một gốc rễ giải thích được cả ba

Cả ba công cụ này sinh ra để giải quyết chung một giới hạn cốt lõi. Hiểu được giới hạn này, mọi thứ sẽ tự động hợp lý.

AI của bạn có một thứ gọi là context window — cứ hiểu nó như bộ nhớ làm việc tạm thời cho cuộc hội thoại hiện tại. Mọi thứ bạn trao đổi đều bị nhồi nhét vào không gian đó: câu bạn dặn dò, file bạn yêu cầu nó mở, mã lỗi nó gặp phải, và cả những câu trả lời trước đó của chính nó. Bộ nhớ này rất lớn, nhưng nó có giới hạn, và đặc biệt là nó không tự biết dọn dẹp.

Vì thế, câu chuyện quen thuộc này hay xảy ra:

Ở bước số 5, bạn sẽ có cảm giác: "Sao chiều nay con AI này tự nhiên ngốc đi vậy?". Sự thật là nó không ngốc đi. Nó chỉ bị quá tải thông tin. Nhìn từ góc độ "giải phóng bộ nhớ" này, ba công cụ lập tức tìm được chỗ đứng của mình:

• Skill giúp bạn không phải lặp đi lặp lại cùng một câu dặn dò ở mỗi phiên làm việc mới — và điều tuyệt vời là nó gần như không chiếm dung lượng bộ nhớ cho tới tận lúc AI thực sự cần dùng đến nó.
• MCP giúp AI không phải "đoán mò" những dữ liệu nó không được phép nhìn thấy (việc mở 40 file ở ví dụ trên thường là do nó đang cố đoán).
• Subagent thì mang toàn bộ phần công việc bừa bộn đó sang làm ở một không gian bộ nhớ khác, rồi chỉ mang đúng kết quả cuối cùng về cho bạn. Nhờ vậy, nội dung của 40 file kia không bao giờ làm rác phiên chat chính của bạn.

Skill: Cuốn cẩm nang chỉ cần viết một lần

Skill đơn giản là một thư mục, trong đó chứa một file có tên là SKILL.md. File này có vài dòng tiêu đề (header) ở trên cùng, phần còn lại là những hướng dẫn bằng ngôn ngữ tự nhiên về cách bạn muốn một việc gì đó được thực hiện.

Phần header chỉ bắt buộc có đúng hai thông tin: name (tên) và description (mô tả) — theo tài liệu chính thức về Agent Skills của Anthropic. Trong đó, description là phần sống còn, vì AI sẽ đọc nó để tự quyết định xem skill này có liên quan tới yêu cầu hiện tại của bạn hay không. Do đó, mô tả phải nói rõ cả skill này làm việc gì và trong trường hợp nào thì nên lấy ra dùng. Đây là một ví dụ thực tế (đã rút gọn):

---
name: deploy-checklist
description: những thứ phải kiểm tra trước khi đẩy app lên production — bao gồm env var, luật database, trang lỗi. dùng mỗi khi user nhắc tới các từ như deploy, ship, hoặc go live.
---

# trước khi deploy

1. kiểm tra đảm bảo không có api key nào nằm trong biến bắt đầu bằng NEXT_PUBLIC_.
2. kiểm tra xem row level security đã được bật cho mọi bảng chứa dữ liệu khách hàng chưa.
3. kiểm tra các trang báo lỗi 404 và 500 có render ra giao diện thật không.
...

Đơn giản vậy là xong một skill. Bạn cứ viết bằng lời nói bình thường, lưu vào đúng thư mục, và từ đó về sau mọi phiên làm việc đều tự động áp dụng các quy tắc này mà bạn chẳng cần tốn công nhắc lại.

Tại sao dùng skill lại không làm nghẽn context window?

Điều này khá thú vị và đáng để hiểu, vì nó giải thích tại sao bạn có thể cài sẵn 30 skill nhưng lại không tốn kém gì cho 29 cái đang nằm im.

Anthropic gọi cơ chế này là progressive disclosure (nạp thông tin luỹ tiến theo nhu cầu). Họ mô tả nó hoạt động hệt như cách bạn dùng một cuốn sổ tay được thiết kế tốt: đầu tiên chỉ đọc mục lục, tiếp theo mới lật tới chương cần đọc, và chỉ dở tới phần phụ lục nếu thực sự cần tra cứu chi tiết (Nguồn: Anthropic Engineering).

100 token chỉ tương đương với khoảng một câu nói ngắn. Vậy nên nếu bạn thắc mắc "tạo bao nhiêu skill là quá nhiều?", thì câu trả lời thực tế là: cứ tạo thoải mái, giới hạn duy nhất là thời gian bạn ngồi viết ra chúng.

Khi nào thì bạn cần viết Skill?

Bất cứ khi nào bạn nhận ra mình đang phải gõ lại cùng một câu nhắc nhở đến lần thứ ba. Chỉ đơn giản vậy thôi.

• "Nhớ luôn dùng tiếng Anh chuẩn Anh (British English)."
• "Tuyệt đối đừng đụng vào thư mục migrations của tôi."
• "Nút bấm trong hệ thống này là component có sẵn, đừng viết lại bằng HTML thô."

Mỗi câu cằn nhằn đó xứng đáng là một skill, và bạn chỉ mất chưa tới bốn phút để viết nó ra. Skill được lưu ở ~/.claude/skills/ nếu bạn muốn AI nhớ nó ở mọi dự án, hoặc lưu ở .claude/skills/ ngay trong thư mục dự án nếu nó chỉ dành riêng cho project đó.

MCP: Giao chiếc chìa khoá cho AI

Skill giúp AI biết cách làm. Nhưng bản thân skill không giúp AI nhìn thấy được những dữ liệu mới. Việc đó là nhiệm vụ của MCP.

MCP (Model Context Protocol) là một tiêu chuẩn mở, sinh ra để kết nối các ứng dụng AI với các hệ thống dữ liệu bên ngoài. Trang tài liệu chính thức miêu tả nó rất hình tượng: đây là "cổng USB-C cho các ứng dụng AI" (Nguồn: modelcontextprotocol.io). Sự ví von này vô cùng chính xác: trước đây, muốn AI đọc được Notion hay Github, mỗi công cụ phải tự chế ra một loại "đầu cắm" riêng. Giờ đây, tất cả thống nhất dùng chung một chuẩn kết nối.

Để làm được việc này, bạn kết nối AI với một MCP server — hiểu nôm na là một phần mềm trung gian nhỏ gọn đứng giữa AI và hệ thống bạn muốn truy cập. Hiện tại đã có sẵn server cho Figma, Github, Stripe, Postgres, và thậm chí là hệ thống file trên chính máy tính của bạn. Vì nó là tiêu chuẩn mở chứ không phải đặc quyền riêng của Anthropic, nên từ Claude, ChatGPT cho đến VS Code hay Cursor đều có thể giao tiếp mượt mà qua giao thức này.

Một MCP server có thể cung cấp cho AI của bạn ba thứ (Kiến trúc MCP):

• Tool (Công cụ) — Những hành động AI được phép làm. Ví dụ: Tạo lệnh hoàn tiền (refund) trên Stripe. Chạy một câu query database.
• Resource (Tài nguyên) — Những dữ liệu AI có thể đọc. Ví dụ: Xem cấu trúc các bảng database. Đọc file thiết kế Figma.
• Prompt (Mẫu lệnh) — Các kịch bản giao tiếp được soạn sẵn cho những tác vụ thường xuyên lặp lại.

Server này có thể chạy ngay trên máy tính của bạn (local), hoặc chạy trên một máy chủ xa xôi qua Internet. Sự khác biệt này không phải là tiểu tiết — nó chính là lằn ranh quyết định độ an toàn cho dữ liệu của bạn.

Nói thẳng với nhau về rủi ro bảo mật

Việc cấp quyền truy cập thẳng vào database production cho một con AI là một quyết định cần sự nghiêm túc. Tuy nhiên, rủi ro lớn nhất không nằm ở viễn cảnh khoa học viễn tưởng rằng "AI bỗng nhiên nổi loạn phá hoại". Rủi ro thực tế là: bất cứ thứ gì agent của bạn đọc được, đều có thể chứa những dòng lệnh ẩn mà nó sẽ ngây thơ làm theo. Trong ngành bảo mật, hai rủi ro này đã được đặt tên rõ ràng.

1. Tool poisoning (Đầu độc công cụ). Một server MCP độc hại có thể lén giấu những câu lệnh thao túng ngay trong phần mô tả của tool — đây là đoạn văn bản mà chỉ có AI đọc để hiểu công cụ, còn bạn thì gần như không bao giờ nhìn thấy. Một nghiên cứu công bố năm 2026 khảo sát qua bảy ứng dụng hỗ trợ MCP (MCP client) đã kết luận đây là lỗ hổng phía client phổ biến và nghiêm trọng nhất. Họ cũng nhận thấy khả năng phòng thủ của các client hiện nay là rất chênh lệch (Nguồn: arXiv:2603.22489 — lưu ý đây là bản preprint, nên hãy coi nó là một bằng chứng có sức nặng chứ chưa phải kết luận cuối cùng).

2. Indirect prompt injection (Bơm lệnh gián tiếp). Giả sử agent của bạn được giao đi đọc nội dung của một trang web, một ticket báo lỗi, hay tiêu đề của một pull request trên Github. Kẻ xấu chỉ cần viết sẵn các câu lệnh thao túng vào những chỗ đó. Khi AI lấy dữ liệu về đọc, đoạn văn bản đó hoà vào bộ nhớ, và một agent thiếu cơ chế phòng thủ sẽ tự động thực hiện các câu lệnh ẩn kia (Nguồn: Đội ngũ Unit 42, Palo Alto Networks). Không cần phải có hacker cao siêu nào phá vỡ tường lửa. Họ chỉ cần thả văn bản vào đúng nơi AI sẽ quét qua.

Nhưng bạn không cần phải học làm kỹ sư bảo mật để dùng AI. Chỉ cần duy trì ba thói quen thực tế sau đây:

1. Hãy coi việc cài MCP server giống hệt như cài extension (tiện ích) cho trình duyệt — chỉ cài đồ chính chủ từ nhà phát hành uy tín, nếu không thì thôi.
2. Luôn cấp quyền hẹp nhất có thể. Nếu một kết nối database chỉ có quyền "đọc" (read-only), thì dù AI có bị lừa dối kiểu gì, nó cũng không thể nào xoá mất dữ liệu khách hàng của bạn được.
3. Đừng bao giờ nối các server nhạy cảm (như thanh toán, database production) vào một phiên AI mà bạn định bật lên rồi để đó không kiểm soát. Sự tiện lợi mang lại không bù đắp nổi thiệt hại nếu có rủi ro xảy ra.

Subagent: Thuê thêm người, cho ngồi bàn riêng

Subagent đơn giản là một phiên làm việc AI phụ, do phiên làm việc chính tạo ra để giao việc. Đặc điểm nhận diện cốt lõi của nó là nó sở hữu một context window hoàn toàn riêng biệt — nghĩa là nó có trí nhớ riêng, được dặn dò bằng một câu lệnh hệ thống (system prompt) riêng, và bộ công cụ (tool) của nó cũng được cấp phát riêng rẽ (Nguồn: Tài liệu Claude Code).

Hãy quay lại ví dụ 40 file làm tràn bộ nhớ ở đầu bài. Khi có subagent, việc lục lọi tìm kiếm sẽ diễn ra ở "bàn làm việc" của nó. 40 file đó có thể làm đầy bộ nhớ của con subagent, nhưng thứ cuối cùng nó báo cáo lại cho bạn chỉ gọn gàng trong ba ý: file cần sửa nằm đây, ở dòng này, và lý do lỗi là đây. Phiên làm việc chính của bạn vẫn sạch sẽ, không hề bị rác bởi 39 file không liên quan kia.

Về cách tạo, subagent cũng giống skill, chỉ là một file markdown kèm vài dòng tiêu đề:

---
name: code-improver
description: chuyên quét các file và đề xuất cách tối ưu. dùng ngay sau khi bạn vừa viết xong tính năng hoặc sửa code.
tools: Read, Grep, Glob
model: sonnet
---

bạn là một chuyên gia tối ưu mã nguồn. với mỗi vấn đề tìm thấy, hãy giải thích lỗi,
trích dẫn đoạn code hiện tại, và sau đó đưa ra phiên bản đã được sửa chữa.

Đừng đánh giá thấp hai dòng thông số trong cấu hình trên. Dòng tools: Read, Grep, Glob chính là ranh giới quyền lực — bạn đang giới hạn rõ ràng những gì subagent này được phép làm. Cả ba công cụ này đều chỉ có chức năng đọc (read-only), nên dù subagent có "nổi hứng" quyết định gì đi nữa, về mặt vật lý, nó hoàn toàn không có khả năng tự ý sửa đổi file của bạn. Còn dòng model: sonnet giúp bạn điều phối công việc phụ sang một mô hình AI có chi phí rẻ hơn so với phiên làm việc chính. Việc này quan trọng hơn bạn nghĩ rất nhiều.

Sử dụng subagent, bạn nhận được đúng những lợi ích mà Anthropic thiết kế: tách bạch quá trình dò dẫm khỏi luồng suy nghĩ chính, giới hạn rủi ro cho một tác vụ cụ thể, và tối ưu chi phí bằng cách đẩy việc vặt cho model rẻ hơn.

Đánh đổi bằng chi phí

Đây là phần bạn cần nhớ kỹ. Đội ngũ kỹ sư (engineering) của Anthropic đã trực tiếp đo lường trên hệ thống của họ và công bố những con số sau: một agent đơn lẻ tốn khoảng 4× lượng token so với việc bạn chat bình thường, còn nếu chạy một hệ thống nhiều agent cùng lúc (multi-agent), chi phí vọt lên khoảng 15× so với chat thường (Nguồn: Anthropic Engineering).

Con số 15× không phải sinh ra để doạ bạn không dùng subagent. Nó sinh ra để nhắc bạn rằng tư duy "cứ ném cho 5 con agent tự chạy" là một quyết định đốt tiền, và bạn cần cân nhắc xem kết quả thu về có đáng với chi phí đó không.

Khi nào thì KHÔNG nên dùng Subagent?

Hãy đọc kỹ đoạn này, vì nó đi ngược lại với rất nhiều lời khuyên "thần thánh hoá AI" bạn hay thấy trên mạng. Chính bài viết phân tích của Anthropic đã khẳng định rằng: kiến trúc nhiều agent (multi-agent) không hề phù hợp cho những công việc đòi hỏi các agent phải liên tục chia sẻ context (ngữ cảnh) cho nhau, các tác vụ mà bước sau phụ thuộc quá chặt vào bước trước, hoặc — nói thẳng ra — phần lớn các công việc lập trình thông thường. Đơn giản vì lập trình thường không có nhiều tác vụ thực sự có thể băm nhỏ để chạy song song độc lập.

Nơi subagent thực sự toả sáng, và xứng đáng tới từng xu, là những công việc đòi hỏi "bề rộng": cày xới một hệ thống mã nguồn khổng lồ, nghiên cứu song song nhiều phương án giải quyết cùng lúc, hoặc đi kiểm tra chéo một lỗi ở hàng loạt hệ thống khác nhau. Trên bài đánh giá (benchmark) nội bộ do chính Anthropic công bố, mô hình kết hợp một agent chính giao việc cho các subagent đã vượt trội hơn agent đơn lẻ tới 90,2% (Anthropic Engineering — benchmark nội bộ, do nhà cung cấp tự công bố). Dù vậy, hãy nhớ đây là kết quả trên các tác vụ thiên về "nghiên cứu" (research). Bạn nên xem con số này là kim chỉ nam về tiềm năng, chứ không phải lời cam kết chắc nịch cho ứng dụng của bạn.

Tóm lại, bạn đang cần dùng cái nào?

Nguyên tắc vàng: Hãy xuất phát từ nỗi đau (triệu chứng) của bạn, đừng xuất phát từ việc thấy công cụ hay quá nên cố tìm chỗ nhét vào.

Cái dòng cuối cùng trong bảng không phải là lời nói đùa. Trong thực tế, phần lớn những vấn đề trông có vẻ như "tôi đang thiếu công cụ xịn", thật ra lại là "tôi đang thiếu hướng dẫn rõ ràng". Nếu yêu cầu của bạn vốn đã mơ hồ, thì Skill, MCP hay Subagent cũng chỉ là những cỗ máy khuếch đại một yêu cầu mơ hồ thành một kết quả mơ hồ lớn hơn mà thôi.

Ba công cụ này sinh ra để phối hợp cùng nhau

Chúng không phải là ba lựa chọn để bạn cân nhắc bỏ cái này lấy cái kia. Anthropic mô tả Skill như một mảnh ghép bổ trợ hoàn hảo cho MCP server: MCP cung cấp công cụ, còn Skill sẽ dạy agent quy trình cách sử dụng công cụ đó. Nói gọn lại là: "MCP nối Claude với dữ liệu; còn Skill dạy Claude phải làm gì với mớ dữ liệu đó" (Nguồn: Bài viết Skills Explained, Anthropic).

Hãy xem một ví dụ thực tế. Giả sử bạn muốn AI làm báo cáo hàng tuần về những khách hàng có nguy cơ rời bỏ ứng dụng (churn).

• MCP sẽ đóng vai trò cắm thẳng vào database để lấy dữ liệu thực, đảm bảo AI không tự bịa ra con số.
• Skill sẽ đóng vai trò lưu giữ: định nghĩa thế nào là "khách rời bỏ" theo chuẩn công ty bạn, định dạng báo cáo bạn thích, và ba chỉ số bạn luôn ưu tiên xem đầu tiên — nhờ vậy, tuần nào bạn cũng nhận đúng chuẩn báo cáo mà không phải nhắc lại.
• Subagent sẽ đóng vai trò người thợ cày: nhận lệnh kéo dữ liệu về, cặm cụi phân tích trong một bộ nhớ riêng biệt, rồi chỉ nộp lại cho bạn bản tóm tắt tinh gọn. Phiên chat chính của bạn vẫn rộng rãi, đủ chỗ để bạn thong thả ngồi bàn bạc với AI xem tuần tới nên có chiến lược gì để giữ chân tập khách hàng đó.

Với tới được (MCP), biết cách làm (Skill), và có người cày cuốc (Subagent). Mỗi công cụ gánh vác đúng phần việc mà hai cái kia không làm được.

Bắt đầu từ đâu trong tuần này?

Nếu muốn ứng dụng ngay, hãy đi theo thứ tự sau (ưu tiên cái rẻ và nhanh trước):

1. Viết một Skill. Hãy nghĩ xem trong tháng này, câu nào bạn phải gõ đi gõ lại nhiều nhất để nắn lưng AI. Tạo một thư mục .claude/skills/ trong project, thả vào đó một file SKILL.md. Nhớ viết name và description (nói rõ khi nào thì AI nên dùng cái này), và dán câu nhắc nhở thường ngày của bạn xuống dưới. Mất đúng bốn phút. Thậm chí bạn có thể nhờ chính AI viết hộ cái file đó, bạn chỉ cần đọc lại và sửa phần description sao cho chuẩn — vì nó là thứ duy nhất bắt buộc phải chính xác.
2. Gắn đúng một cái MCP server. Hãy chọn của nhà phát hành uy tín, set quyền chỉ đọc (read-only), và nhắm thẳng vào cái hệ thống mà bạn đang mệt mỏi nhất vì phải copy-paste bằng tay mỗi ngày.
3. Khoan đụng tới Subagent cho tới khi bạn thực sự thấy đau. Khi nào bạn thấy một phiên làm việc cứ kéo dài là gãy gánh giữa đường, đó mới là tín hiệu. Trước lúc đó thì chưa cần — hãy nhớ con số 15× token, nó là thứ duy nhất trong ba công cụ này có khả năng âm thầm bòn rút ví tiền của bạn.

Một thực tế thú vị: những người vắt kiệt được nhiều giá trị nhất từ các công cụ AI này hiếm khi là những lập trình viên lõi đời — con số 80% ở đầu bài rất khớp với xu hướng chúng tôi quan sát thấy. Kỹ năng thực sự ở kỷ nguyên này không phải là viết code giỏi, mà là hiểu thật rõ quy trình làm việc của chính mình để có thể viết nó ra rành mạch. Và tin vui là, phần đó thì bạn đã có sẵn rồi.