MCP, Skills và Subagents

Ba khái niệm này giải quyết ba vấn đề khác nhau: kết nối công cụ, chuẩn hóa quy trình và chia nhỏ tác vụ.

Ba khái niệm

Khái niệm	Vai trò
MCP	Cho Codex gọi công cụ ngoài như browser, Figma, Notion, DB
Skill	Hướng dẫn workflow có thể tái sử dụng
Subagent	Chia tác vụ lớn thành nhiều nhánh độc lập

Khi nào dùng MCP

Dùng MCP khi Codex cần thao tác một hệ thống ngoài mà đọc file local không đủ:

• Browser automation.
• Figma/design.
• Notion/knowledge base.
• Database hoặc internal API.
• GitHub, issue tracker, BI tool.

Trước khi bật MCP, xác định quyền: chỉ đọc hay được ghi, domain nào được truy cập, secret nằm ở đâu và cách audit.

Khi nào viết Skill

Viết Skill khi workflow lặp lại và có tiêu chí kiểm chứng rõ.

Ví dụ:

---
name: pr-review
description: Dùng khi người dùng yêu cầu review PR hoặc diff.
---

# PR Review

## Quy trình
1. Đọc diff.
2. Ưu tiên bug, regression, thiếu test.
3. Không sửa file.
4. Trả kết quả theo mức độ nghiêm trọng.

Skill tốt nên ngắn, rõ trigger và có output format.

Khi nào dùng Subagents

Dùng subagents khi các nhánh độc lập và có thể chạy song song:

• Một nhánh đọc docs, một nhánh đọc code, một nhánh đọc log.
• Nhiều module khác nhau không sửa chung file.
• Nhiều nguồn nghiên cứu độc lập.

Không dùng khi các bước phụ thuộc nhau hoặc cùng sửa một vùng code.

Template phân công

Hãy chia thành 3 nhánh độc lập:
1. kiểm tra frontend build,
2. kiểm tra backend tests,
3. kiểm tra docs/deploy.
Mỗi nhánh báo file đã đọc, phát hiện chính và đề xuất tiếp theo.
Chưa sửa file cho đến khi tôi chọn hướng.

Automation nằm ở đâu

Automation phù hợp với tác vụ theo thời gian: nhắc, monitor, báo cáo định kỳ. Nếu automation cần gọi công cụ ngoài, nó có thể dùng MCP; nếu quy trình lặp lại phức tạp, nên ghi thành Skill trước.

Checklist an toàn

• MCP có quyền tối thiểu chưa?
• Skill có chứa secret không?
• Subagents có sửa chung file không?
• Automation có spam hoặc hành động nguy hiểm không?
• Có log/audit cho thao tác quan trọng không?