Tại sao tôi vẫn ưu tiên MCP hơn Skills trong kỷ nguyên AI

Tại sao tôi vẫn ưu tiên MCP hơn Skills trong kỷ nguyên AI

Có lẽ do dành quá nhiều thời gian trên X (Twitter), nhưng gần đây tôi liên tục bắt gặp quan điểm cho rằng "MCP đã chết" và "Skills là tiêu chuẩn mới". Ở khắp mọi nơi, ai cũng đang ăn mừng sự sụp đổ của Model Context Protocol (MCP) để chuyển sang việc bỏ các tệp SKILL.md vào kho lưu trữ của họ.

Tuy nhiên, với tư cách là một người dùng AI nặng ký, sử dụng Claude Code, Codex, Gemini hàng ngày, tôi thực sự không thích Skills. Tôi hy vọng MCP sẽ tiếp tục tồn tại. Tôi thực sự không muốn một tương lai nơi mọi tích hợp dịch vụ đều yêu cầu một CLI (giao diện dòng lệnh) chuyên dụng và một hướng dẫn dạng markdown.

Dưới đây là lý do tại sao tôi cho rằng việc đẩy mạnh Skills như một giải pháp phổ quát là một bước lùi, và tại sao MCP vẫn làm đúng về mặt kiến trúc.

Banner bài viết

Điều tôi yêu thích ở MCP

Triết lý cốt lõi của MCP rất đơn giản: đó là sự trừu tượng hóa API. LLM không cần hiểu "cách" thực hiện; nó chỉ cần biết "cái gì" cần thực hiện. Nếu LLM muốn tương tác với DEVONthink, nó gọi devonthink.do_x(), và máy chủ MCP sẽ xử lý phần còn lại.

Sự tách biệt quan tâm này mang lại những lợi thế không thể đánh bại:

• Sử dụng từ xa mà không cần cài đặt: Đối với máy chủ MCP từ xa, bạn không cần cài đặt bất cứ thứ gì cục bộ. Chỉ cần trỏ máy khách của bạn đến URL máy chủ MCP và nó hoạt động.
• Cập nhật liền mạch: Khi máy chủ MCP từ xa được cập nhật với các công cụ hoặc tài nguyên mới, mọi máy khách đều nhận được phiên bản mới nhất ngay lập tức. Không cần đẩy bản cập nhật, nâng cấp gói hay cài đặt lại tệp nhị phân.
• Xác thực hợp lý hơn: Xác thực được xử lý một cách thanh lịch (thường là với OAuth). Khi máy khách hoàn thành bắt tay, nó có thể thực hiện hành động đối với MCP. Bạn không ép buộc người dùng quản lý các token và bí mật thô dưới dạng văn bản thuần túy.
• Tính di động thực sự: Các máy chủ MCP từ xa của tôi hoạt động từ bất cứ đâu: máy Mac, điện thoại, web. Không quan trọng là gì. Tôi có thể quản lý Notion của mình thông qua LLM tôi chọn từ bất cứ đâu có sẵn máy khách.
• Sandboxing: MCP từ xa tự nhiên được sandbox. Chúng hiển thị một giao diện được kiểm soát thay vì cấp cho LLM quyền thực thi thô trong môi trường cục bộ của bạn.
• Khám phá thông minh: Các ứng dụng hiện đại (ChatGPT, Claude, v.v.) có tích hợp tìm kiếm công cụ. Chúng chỉ tìm kiếm và tải công cụ khi thực sự cần thiết, giúp tiết kiệm cửa sổ ngữ cảnh quý giá.

Claude lấy phản hồi người dùng từ Kikuyo thông qua Kikuyo MCP

Sự ma sát với Skills

Không phải mọi Skills đều giống nhau. Một kỹ năng kiến thức thuần túy (dạy LLM cách định dạng thông báo commit, viết kiểm thử theo một cách nhất định hoặc sử dụng thuật ngữ nội bộ của bạn) thực sự hoạt động tốt. Các vấn đề bắt đầu khi một Skill yêu cầu CLI để thực sự làm điều gì đó.

Trách nhiệm lớn nhất của tôi với Skills là giả định rằng mọi môi trường đều có thể, hoặc nên, chạy các CLI tùy ý.

Hầu hết các kỹ năng yêu cầu bạn cài đặt một CLI chuyên dụng. Nhưng nếu bạn không ở trong thiết bị đầu cuối cục bộ thì sao? ChatGPT không thể chạy CLI. Perplexity hay phiên bản web tiêu chuẩn của Claude cũng không. Trừ khi bạn đang sử dụng môi trường tính toán đầy đủ (như Perplexity Computer, Claude Cowork, Claude Code hoặc Codex), bất kỳ kỹ năng nào dựa vào CLI đều "chết" khi mới ra mắt.

Điều này dẫn đến một chuỗi các vấn đề UX và kiến trúc khó chịu:

• Mớ hỗn loạn triển khai: CLI cần được xuất bản, quản lý và cài đặt thông qua tệp nhị phân, NPM, uv, v.v.
• Cơn ác mộng quản lý bí mật: Bạn đặt API token cần thiết để xác thực ở đâu? Nếu may mắn, môi trường có tệp .env mà bạn có thể đổ bí mật văn bản thuần túy vào đó. Một số môi trường nhất thời sẽ tự xóa, nghĩa là CLI của bạn hoạt động hôm nay nhưng quên bí mật của bạn vào ngày mai.
• Hệ sinh thái phân mảnh: Quản lý kỹ năng hiện tại là vùng hoang dã. Khi một kỹ năng được cập nhật, bạn phải cài đặt lại nó. Một số công cụ hỗ trợ cài đặt kỹ năng qua npx skills, nhưng điều đó chỉ hoạt động trong Codex và Claude Code, không phải Claude Cowork hay Claude tiêu chuẩn.
• Phình to ngữ cảnh: Sử dụng kỹ năng thường yêu cầu tải toàn bộ SKILL.md vào cửa sổ ngữ cảnh của LLM, thay vì chỉ hiển thị chữ ký công cụ đơn lẻ mà nó cần. Nó giống như ép buộc ai đó đọc toàn bộ hướng dẫn sử dụng xe hơi khi tất cả những gì họ muốn làm là gọi car.turn_on().

Nếu hướng dẫn của một Skill bắt đầu bằng "cài đặt CLI này trước", bạn vừa thêm một lớp trừu tượng không cần thiết và các bước bổ sung. Tại sao không chỉ sử dụng MCP từ xa?

Codex sử dụng kỹ năng kiến thức thuần túy để tìm hiểu cách hook hoạt động

Công cụ đúng cho công việc đúng

Tôi không muốn Skills trở thành cách de facto để kết nối LLM với một dịch vụ. Chúng ta có thể giải thích hình dạng API trong một Skill để LLM có thể curl nó, nhưng làm thế nào điều đó tốt hơn việc cung cấp một giao diện kiểu mạnh, sạch sẽ thông qua MCP?

Dưới đây là cách tôi nghĩ hệ sinh thái nên trông như thế nào:

Khi nào nên sử dụng MCP:

MCP nên là tiêu chuẩn để cung cấp cho LLM một giao diện để kết nối với một cái gì đó: một trang web, một dịch vụ, một ứng dụng. Bản thân dịch vụ nên quy định giao diện mà nó hiển thị.

Ví dụ, Google Calendar. Một gcal CLI thì ổn. Vấn đề là một Skill bảo LLM cài đặt nó, quản lý token xác thực và chạy nó. Một MCP từ xa được hỗ trợ bởi OAuth thuộc sở hữu của Google xử lý tất cả những điều đó ở cấp giao thức và hoạt động từ bất kỳ máy khách nào mà không cần thiết lập nào.

Để kiểm soát Chrome, trình duyệt nên hiển thị một điểm cuối MCP để kiểm soát có trạng thái, thay vì dựa vào một chrome-cli lộn xộn.

Để gỡ lỗi với Hopper, MCP tích hợp sẵn hiện tại cho phép LLM chạy step() tốt hơn nhiều so với một hopper-cli riêng biệt.

Khi nào nên sử dụng Skills:

Skills nên "thuần túy". Chúng nên tập trung vào kiến thức và ngữ cảnh.

• Dạy các công cụ hiện có: Tôi thích có thư mục .claude/skills dạy LLM cách sử dụng các công cụ tôi đã cài đặt. Một kỹ năng giải thích cách sử dụng curl, git, gh hoặc gcloud hoàn toàn hợp lý. Chúng ta không cần "curl MCP". Chúng ta chỉ cần dạy LLM cách xây dựng các lệnh curl tốt.
• Chuẩn hóa quy trình làm việc: Skills hoàn hảo để dạy Claude thuật ngữ kinh doanh của bạn, phong cách giao tiếp nội bộ hoặc cấu trúc tổ chức.
• Mô hình quản lý bí mật: Có một kỹ năng bảo Claude "Sử dụng fnox cho repo này, đây là cách sử dụng nó" rất hợp lý. Mỗi khi chúng ta xử lý bí mật, Claude sẽ kéo lên kỹ năng đó.

Kết nối vs. Hướng dẫn sử dụng

Có lẽ thuật ngữ là vấn đề. Skills nên chỉ được gọi là LLM_MANUAL.md, và MCP nên được gọi là Connectors (Bộ kết nối).

Cả hai đều có vị trí của mình. Đối với các dịch vụ tôi sở hữu, tôi đã làm điều này. Ví dụ: mcp-server-devonthink là một máy chủ MCP cục bộ cung cấp quyền kiểm soát trực tiếp cho bất kỳ LLM nào nào đối với DEVONthink. Không có bao bọc CLI, chỉ là giao diện công cụ sạch sẽ.

Kết quả là một Skill đóng vai trò là "tờ cheat sheet" cho MCP, không phải thay thế cho nó. MCP vẫn xử lý kết nối thực tế và thực thi công cụ. Skill chỉ đảm bảo LLM không lãng phí token để vấp ngã qua cùng một cái bẫy mà tôi đã giải quyết. Chính sự kết hợp của cả hai mới làm cho trải nghiệm thực sự suôn sẻ.

Tôi chỉ hy vọng ngành công nghiệp không từ bỏ Model Context Protocol. Giấc mơ về tích hợp AI liền mạch dựa vào các giao diện chuẩn hóa, không phải là một cảnh quan phân mảnh của các CLI hacky. Tôi vẫn hy vọng vào các MCP chính thức từ Skyscanner, Booking.com, Trip.com và Agoda.com.