Cứ vài tháng, OpenAI hay các nhà cung cấp khác lại tung ra một khuôn khổ “khả năng” (skills) hay “bộ công cụ” (tools) mới, và tất cả chúng ta đều đổ xô tái thiết toàn bộ hệ thống của mình. Tôi đã thử qua nhiều loại, và tôi cứ mãi quay trở lại với MCP. Nếu bạn đang xây dựng các hệ thống AI nghiêm túc, chứ không chỉ là các bản demo, thì sự khác biệt này là rất quan trọng. Nó thể hiện ở cách bạn triển khai, gỡ lỗi và bảo vệ hệ thống khỏi việc trở thành một khối YAML và schema JSON khó bảo trì. Hãy cùng bàn về lý do tại sao MCP vẫn mang lại cảm giác là phương pháp tiếp cận “mang tính kỹ thuật chuyên nghiệp” hơn so với các hệ thống kiểu skills.
**Định nghĩa cơ bản để chúng ta thống nhất:**
Nếu bạn chưa biết MCP là gì, không sao cả. Hầu hết mọi người chỉ gặp nó khi tương tác với Claude hoặc các công cụ liên quan. Nói ngắn gọn:
* **Skills (Khả năng):** Là các “khả năng” mang tính cụ thể của mô hình hoặc nhà cung cấp. Bạn đăng ký chúng bên trong một nền tảng nhất định, thường gắn kết chặt chẽ với môi trường runtime và giao diện người dùng của nhà cung cấp đó.
* **MCP (Model Context Protocol – Giao thức Ngữ cảnh Mô hình):** Là một giao thức trung lập để phơi bày các công cụ hoặc dữ liệu dưới dạng một máy chủ mà bất kỳ client hoặc mô hình tuân thủ nào cũng có thể gọi đến.
Nói cách khác, Skills thường giống như “plugin dành cho chatbot này”. Trong khi đó, MCP lại giống như “một API tiêu chuẩn chạy qua một quy trình công cụ lâu dài, bền vững”. Sự khác biệt này nghe có vẻ nhỏ nhặt, nhưng trên thực tế, nó thay đổi hoàn toàn cách bạn kiến trúc mọi thứ.
**Vì sao Skills ban đầu lại có vẻ ổn?**
Skills rất hấp dẫn. Bạn chỉ cần liên kết một hàm, viết một schema, và ngay lập tức mô hình có thể thực hiện những thủ thuật mới. Bạn có một lộ trình thành công nhanh chóng. Nó rất dễ tạo mẫu thử (prototype). Tuyệt vời cho các buổi trình diễn demo của nhà cung cấp. Việc tích hợp chặt chẽ với một giao diện chat cụ thể là điểm cộng lớn. Nếu bạn đang xây dựng một trợ lý dùng một lần bên trong một sản phẩm duy nhất, skills thường là đủ. Đặc biệt nếu tất cả các công cụ đều nằm trong backend của sản phẩm đó.
Tuy nhiên, vấn đề bắt đầu phát sinh khi bạn cố gắng mở rộng quy mô ngoài phạm vi đó. Bạn cần nhiều tác nhân (agents) cùng lúc. Bạn cần nhiều ứng dụng khác nhau. Bạn cần các công cụ phức tạp có trạng thái, phiên làm việc (sessions) và vòng đời riêng. Đó là lúc MCP bắt đầu tỏa sáng.
**MCP thực chất là gì, về mặt kỹ thuật?**
MCP không phải là một thư viện hay SDK. Nó là một **giao thức (Protocol)**. Ở cấp độ cao, MCP định nghĩa:
* Cách một “máy chủ công cụ” (tool server) công bố khả năng của nó: các công cụ, các mẫu prompt, các tài nguyên.
* Cách một client yêu cầu gọi công cụ và nhận kết quả.
* Cách xử lý luồng dữ liệu (streaming), cập nhật tiến độ và hủy bỏ.
Hầu hết các triển khai MCP đều sử dụng JSON-RPC qua stdio hoặc WebSockets. Vì vậy, máy chủ MCP của bạn chỉ là một quy trình chạy dài, giao tiếp bằng JSON. Điều này có thể nghe nhàm chán, nhưng đó lại là điều tốt. Nó có nghĩa là bạn có thể:
* Viết các máy chủ MCP bằng bất kỳ ngôn ngữ lập trình nào.
* Triển khai chúng dưới dạng các dịch vụ riêng biệt hoặc sidecar container.
* Tái sử dụng chúng trên nhiều mô hình và client khác nhau.
Trái lại, Skills thường được định nghĩa bên trong SDK hoặc cấu hình của một nhà cung cấp duy nhất. Chúng không được thiết kế để có tính di động (portable).
**Sự khác biệt kiến trúc lớn nhất:**
Đây là mô hình tư duy đã giúp tôi nhận ra điều này.
* **Skills:** Là “các khả năng tồn tại bên trong môi trường runtime mô hình cụ thể.”
* **MCP Servers:** Là “các hệ thống bên ngoài mà mô hình có thể gọi qua một giao thức cụ thể.”
Với Skills, bạn buộc phải nhét càng nhiều logic vào một ngăn xếp theo chiều dọc (vertical stack) duy nhất. Với MCP, bạn đẩy độ phức tạp ra các thành phần riêng biệt, có thể kiểm thử được. Điều này dẫn đến một vài hậu quả quan trọng: Thứ nhất, bạn có thể triển khai và mở rộng các máy chủ MCP một cách độc lập. Thứ hai, bạn có thể quản lý phiên bản và kiểm thử chúng như các dịch vụ phần mềm thông thường. Thứ ba, bạn có thể kết nối nhiều mô hình khác nhau với cùng một bộ công cụ. Bạn ngừng coi stack AI của mình như một “viên pha lê đặc biệt”. Thay vào đó, bạn coi nó như một hệ thống phân tán thông thường.
**Một ví dụ MCP đơn giản:**
Hãy tưởng tượng một máy chủ MCP phơi bày một công cụ duy nhất: lấy thông tin về một issue trên GitHub. (Phần code vẫn giữ nguyên tính minh họa).
Về phía client, agent hoặc ứng dụng chat của bạn chỉ biết “có một máy chủ MCP tên là github-mcp với công cụ getIssue”. Nó không cần biết công cụ đó được triển khai như thế nào. Bạn có thể chạy nó bên cạnh ứng dụng của mình, trong một container, hoặc đằng sau một dịch vụ trung
Đối với các hệ thống cần khả năng mở rộng và tích hợp nhiều ứng dụng, việc sử dụng các máy chủ MCP (Model Component Platforms) là một giải pháp toàn diện. Với MCP, bạn nhận được:
* **Giảm thiểu sự trùng lặp:** Đảm bảo các trợ lý và ứng dụng hoạt động với hành vi đồng nhất.
* **Một điểm kiểm soát tập trung:** Cho phép thiết lập an ninh và tuân thủ một cách duy nhất.
Về mặt kiến trúc, các kỹ năng (Skills) không thể mở rộng theo cách này trên nhiều hệ sinh thái khác nhau. Chúng xuất sắc cho một ngăn xếp (stack) duy nhất, chứ không phải nhiều ngăn xếp.
**An ninh và Kiểm soát Truy cập**
Đây là lĩnh vực mà MCP thể hiện tính chuyên nghiệp và trưởng thành hơn. Vì máy chủ MCP là các quy trình bên ngoài, bạn có thể đặt chúng sau các lớp bảo mật tiêu chuẩn của tổ chức. Bạn có thể:
* Triển khai các máy chủ MCP trong mạng nội bộ (private networks).
* Yêu cầu hai yếu tố xác thực máy khách-máy chủ (mTLS) hoặc OAuth.
* Buộc thực thi các quyền truy cập theo người dùng hoặc theo thuê bao (tenant).
* Thậm chí tự xây dựng các kiểm tra chính sách bên trong máy chủ. Ví dụ: chặn các công cụ có nguy cơ gây hỏng hóc đối với người dùng nhất định.
Ngược lại, khi sử dụng Skills, bạn thường liên kết trực tiếp vào hệ thống backend hoặc dữ liệu của mình, và an ninh mô hình chỉ phụ thuộc vào những gì nhà cung cấp cho bạn. Đối với các môi trường được quản lý nghiêm ngặt, điều này thường là chưa đủ. Bạn cần các ranh giới và khả năng kiểm toán minh bạch. MCP cung cấp nơi để thực hiện điều đó.
**Khi nào Skills vẫn là lựa chọn tốt hơn**
Để công bằng, tôi thừa nhận rằng Skills không vô dụng. Có những trường hợp tôi chắc chắn sẽ chọn Skills hơn MCP. Khi bạn có một sản phẩm đơn giản, chỉ dự định sử dụng một nhà cung cấp duy nhất, và các công cụ của bạn rất nhỏ và gắn chặt với một trải nghiệm duy nhất. Trong thế giới đó, Skills nhanh chóng hơn để thiết lập. Bạn có ít bộ phận chuyển động và phụ thuộc hơn. Nếu bạn đang thực hiện các thử nghiệm nội bộ hoặc các bản mẫu ngắn hạn, Skills rất tuyệt vời. Bạn không cần phải thiết lập máy chủ MCP cho mọi thứ. Khoảnh khắc bạn thấy con đường dẫn đến nhiều ứng dụng hoặc nhiều mô hình, tôi sẽ bắt đầu nghiêm túc xem xét MCP. Việc đầu tư sớm sẽ dễ dàng hơn nhiều so với việc chuyển đổi sau này.
**Di chuyển từ Skills sang MCP một cách ít rủi ro**
Nếu bạn đã có một hệ thống dựa trên Skills, bạn không cần phải vứt bỏ nó. Bạn có thể từ từ trích xuất logic vào các máy chủ MCP. Một lộ trình thực tế sẽ như sau:
1. **Xác định:** Tìm các Skills phức tạp nhất hoặc được tái sử dụng nhiều nhất.
2. **Trích xuất:** Tách logic cốt lõi thành một dịch vụ độc lập.
3. **Công bố:** Công bố nó dưới dạng một công cụ MCP.
4. **Cập nhật:** Cập nhật triển khai Skills của bạn để gọi công cụ MCP này nội bộ.
Từ góc độ của mô hình (model), không có gì thay đổi. Theo thời gian, càng ngày càng nhiều Skills của bạn sẽ trở thành lớp bao bọc mỏng (thin wrappers) xung quanh MCP. Cuối cùng, bạn có thể chuyển sang các tác tử (agents) nói chuyện trực tiếp với MCP. Điều này cho phép bạn dần dần hưởng lợi thế của MCP mà không cần phải thực hiện một lần tái cấu trúc lớn.
**Tư duy cốt lõi giúp tôi chọn MCP**
Theo cách tôi suy nghĩ, nó rất đơn giản. Skills giống như tiện ích mở rộng trình duyệt (browser extension) dành cho một trình duyệt. Máy chủ MCP giống như API HTTP mà bất kỳ máy khách (client) nào cũng có thể sử dụng. Chúng *nhàm chán*, minh bạch và có tính di động cao. Khi bạn đang thử nghiệm, hãy sử dụng thứ gì nhanh nhất. Nhưng khi bạn đang xây dựng thứ gì đó được cho là phải tồn tại vượt qua các chu kỳ hype tiếp theo, bạn cần sự “nhàm chán” đó. Sự “nhàm chán” này giúp bạn:
* Thay đổi mô hình (models) mà không cần viết lại các công cụ.
* Cho phép nhiều nhóm chia sẻ cùng một khả năng.
* Giữ cho đội ngũ hạ tầng và bảo mật hài lòng.
MCP “nhàm chán” theo cách tốt nhất. Trong khi đó, Skills hào hứng theo những cách sẽ nhanh chóng trở nên lỗi thời.
**Lời kết luận**
Skills giống như một *tính năng* (feature). Còn MCP giống như *cơ sở hạ tầng* (infrastructure). Nếu bạn là một lập trình viên độc lập (solo dev) viết code lúc đêm khuya, Skills có thể là tất cả những gì bạn cần. Nhưng nếu bạn đang xây dựng một nền tảng mà người khác phải phụ thuộc, MCP là lựa chọn an toàn hơn. Bạn đạt được sự tách biệt giữa các mối quan tâm (separation of concerns), khả năng kiểm thử tốt hơn, quan sát tốt hơn và tính di động thực tế. Bạn cũng có thể coi các công cụ AI của mình giống như các dịch vụ (services) thông thường thay vì những khối cấu hình ma thuật. Hệ sinh thái xung quanh MCP vẫn còn non trẻ, nhưng giao thức của nó đủ đơn giản để sẽ tồn tại lâu dài. Về bản chất, nó chỉ là JSON có cấu trúc truyền qua một phương thức vận chuyển, không có gì hoa mỹ. Vì vậy, tôi vẫn ưu tiên MCP hơn Skills. Không phải vì nó đang thịnh hành, mà vì nó mang lại cảm giác như thứ mà một kỹ sư thâm niên khó tính sẽ thiết kế sau khi sống qua vài “nền tảng AI” thất bại.
Tham khảo: medium.com
Bài viết liên quan: