MCP vs Skills vs Subagents: chọn đúng cái, đừng viết nhầm

Bạn vừa thấy người ta nói MCP, vừa thấy Skill, vừa thấy Subagent. Ba cái nghe giống nhau — đều là 「cho AI làm được nhiều hơn」 — nhưng nếu chọn nhầm, bạn sẽ:

• viết cả một MCP server chỉ để… nhét checklist,
• hoặc cắm 8 MCP vào Cursor rồi mỗi tin nhắn đốt vài chục nghìn token schema,
• hoặc để agent đọc 200 file trong context chính rồi session 「cháy」 giữa chừng.

Bài này viết như ngồi cạnh nhau debug: chọn cái nào, khi nào, ví dụ copy được.

Dành cho: ai đang dùng Cursor / Claude Code / Codex và muốn setup gọn, không theo hype.

Ý chính: MCP = búa. Skill = cách đóng đinh. Subagent = đưa việc ồn sang phòng khác. Đừng làm búa bằng checklist.

Liên quan: Repo GitHub hữu ích khi dùng AI coding.

Ba thứ, ba việc

Một câu nhớ: bạn đã có shell + đọc file rồi. Skill và subagent chủ yếu dạy cách dùng những thứ đó. MCP mới mở cổng ra hệ thống agent chưa với tới.

Ví dụ 1 · Skill (đây là chỗ bắt đầu)

Giả sử mỗi lần review PR bạn phải nhắc: 「đọc diff, tìm null / secrets, 3 bullet rủi ro」.

Đừng viết MCP. Hãy tạo skill:

.cursor/skills/pr-risk-scan/SKILL.md

---
name: pr-risk-scan
description: >
  Quét rủi ro PR trước khi merge. Dùng khi user bảo review PR,
  check risk, hoặc "nhìn diff này có gì nguy hiểm không".
---

# PR risk scan

1. Đọc diff (ưu tiên file đổi logic / auth / billing).
2. Liệt kê tối đa 5 rủi ro: null, secret, migration, race, breaking API.
3. Mỗi rủi ro: `file:line` + 1 câu vì sao + 1 câu fix gợi ý.
4. Không refactor. Không format lại file không liên quan.

Trong Cursor, skill nằm under .cursor/skills/<tên>/. Agent chỉ nạp tên + description (~30–50 token) cho đến khi thật sự gọi skill — đó là progressive disclosure. Năm mươi skill vẫn rẻ hơn một MCP fat.

Quy tắc ngón tay cái: bạn phải nhắc lại cùng quy trình ≥ 2 lần → viết skill.

Ví dụ 2 · MCP (chỉ khi agent chạm không được)

Agent trong repo đã grep / git / đọc file được. Nhưng nó không tự query Postgres production, không tự tạo Linear issue, không tự lấy log Sentry — trừ khi có tool.

Đó mới là MCP.

Ví dụ cấu hình Cursor (ý tưởng — đường dẫn config tùy bản Cursor của bạn):

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Rồi ghép skill lên trên:

---
name: triage-bug
description: Triage bug từ issue GitHub — label, reproduce steps, owner gợi ý.
---

# Triage bug

1. Dùng MCP GitHub lấy issue + comment mới nhất.
2. Tóm tắt triệu chứng + bước tái hiện tối thiểu.
3. Gợi ý label: bug / question / needs-repro.
4. Không đóng issue. Không comment trừ khi user bảo gửi.

Skill = playbook. MCP = tay nối GitHub. Thiếu một trong hai → hoặc agent nói chung chung, hoặc có tool mà vẫn làm lung tung.

Ví dụ 3 · Subagent (khi việc làm bẩn phòng chính)

Bạn bảo: 「đọc hết apps/api/src rồi tóm tắt auth flow」.

Nếu làm trong chat chính: agent nhồi hàng trăm file vào context → tin sau chậm, đắt, hay quên mục tiêu gốc.

Subagent = giao việc sang 「nhân viên phụ」, chỉ trả bản tóm tắt về phòng chính.

Dùng khi:

• audit / explore rộng,
• chạy test + parse log dài,
• research nhiều file rồi bạn chỉ cần kết luận 10 dòng.

Không dùng subagent cho: đổi một prop, sửa typo, một câu hỏi 30 giây.

Bảng quyết định (dán gần màn hình)

Trả lời theo thứ tự:

1. Agent đã với tới hệ thống đó chưa?

   • Chưa (DB live, SaaS, internal API) → MCP
   • Rồi (file, shell, git trong repo) → xuống bước 2

2. Bạn đang lặp lại cùng hướng dẫn?

   • Có → Skill
   • Không → xuống bước 3

3. Việc có làm ồn / dài, spoils context chính?

   • Có → Subagent (có thể kèm skill)
   • Không → prompt thẳng, đừng over-engineer

Sai phổ biến

Token: vì sao chọn đúng = đỡ cháy bill

• Skill: mô tả luôn rẻ; body chỉ vào khi gọi.
• MCP: schema tool hay load sớm — vài server có thể hàng chục nghìn token trước khi bạn kịp hỏi.
• Subagent: tốn token riêng, nhưng cứu context chính (thường đáng hơn).

Gợi ý thực tế nhỏ team / solo:

• MCP: GitHub hoặc DB staging — bắt đầu một cái.
• Skills: 3–7 playbook hay dùng (review, release, incident, commit message…).
• Rule always-on: Karpathy-style ngắn + 「đừng commit .env」 — không nhét cả skill pack.

Xem thêm góc tối ưu miệng/token: bài repo AI.

Setup Cursor 15 phút (làm được luôn)

Phút 0–5 · Một skill đầu tiên

1. Tạo .cursor/skills/ship-check/SKILL.md.
2. Nội dung gợi ý:

---
name: ship-check
description: >
  Checklist trước khi bảo "xong" / sẵn sàng merge hoặc deploy.
  Dùng khi user hỏi ship được chưa, ready to merge, pre-deploy.
---

# Ship check

1. `pnpm lint` (hoặc lệnh lint của project) — báo lỗi cụ thể.
2. Nhắc test tay: login + 1 happy path chính.
3. Hỏi: có đụng migration / env chưa?
4. Output: ✅ / ⚠️ / ❌ từng mục — không viết tiểu thuyết.

3. Chat mới, gõ: 「ship được chưa?」 — xem skill có được gọi không.

Phút 5–10 · Chỉ thêm MCP nếu thiếu tay

Hỏi thẳng: agent cần kéo issue GitHub / query DB live không?

• Không → dừng. Skill + shell là đủ nhiều việc.
• Có → thêm một MCP, tắt bớt server thừa trong settings.

Phút 10–15 · Quy ước team (kể cả team = 1 người)

Ghi 4 dòng vào .cursor/rules/ (ngắn):

• Stack chính là gì
• Lint trước khi bảo xong
• Không đụng secret / .env
• Việc explore rộng → nhờ subagent / Task explore

Mini playbook ghép cả ba

Tình huống: 「Bug thanh toán trên staging — tìm nguyên nhân và draft Linear.」

1. Subagent / explore: lần theo webhook + log (ồn).
2. MCP: (nếu có) tạo Linear issue từ bản tóm tắt.
3. Skill incident-notes: format postmortem 5 dòng + bước tái hiện.

Không có MCP Linear? Skill vẫn viết issue markdown — bạn paste tay. Đừng vì thiếu paste mà dựng MCP ngày đầu.

Kết

Năm 2026 AI tooling ồn ào vì tên nhiều. Bản chất chỉ ba van:

• Chạm hệ thống mới → MCP
• Nhớ cách làm của team → Skill
• Giữ đầu óc session sạch → Subagent

Bắt đầu bằng một skill hữu ích. MCP chỉ khi tay thật sự ngắn. Subagent khi phòng chính sắp ngộp.

Làm đúng thứ tự đó — agent nhanh hơn, bill dịu hơn, bạn bớt giải thích lần thứ năm.

---

Thử tối nay: viết một SKILL.md cho việc bạn nhắc agent nhiều nhất tuần này. Ngày mai mới bàn MCP.