Tôi vẫn thích MCP hơn kỹ năng

TL;DR: Không gian AI đang nỗ lực hết sức để coi “Kỹ năng” là tiêu chuẩn mới để cung cấp các khả năng của LLM nhưng tôi không phải là người hâm mộ. Các kỹ năng rất tốt cho kiến ​​thức thuần túy và dạy LLM cách sử dụng công cụ hiện có. Nhưng để cấp cho LLM quyền truy cập thực tế vào các dịch vụ, Giao thức bối cảnh mô hình (MCP) là sự lựa chọn kiến ​​trúc thực dụng hơn, ưu việt hơn nhiều. Chúng ta nên xây dựng các trình kết nối chứ không chỉ nhiều CLI hơn.

Có thể đó là kết quả của việc dành quá nhiều thời gian cho X, nhưng gần đây, câu chuyện rằng “MCP đã chết” và “Kỹ năng là tiêu chuẩn mới” đã in sâu vào đầu tôi. Ở mọi nơi tôi nhìn, ai đó đang ăn mừng sự khai tử của Giao thức bối cảnh mô hình để ủng hộ việc thả SKILL.md vào kho lưu trữ của họ.

Tôi là một người dùng AI rất nhiều. Tôi sử dụng Claude Code, Codex và Gemini để viết mã. Hầu như ngày nào tôi cũng dựa vào ChatGPT, Claude và Perplexity để quản lý mọi thứ từ ghi chú Notion đến cơ sở dữ liệu DEVONthink và thậm chí cả email của tôi.

Thành thật mà nói thì sao? Tôi chỉ không thích Kỹ năng.

Tôi hy vọng MCP vẫn tiếp tục. Tôi thực sự không muốn có một tương lai trong đó mọi hoạt động tích hợp dịch vụ đều yêu cầu CLI chuyên dụng và hướng dẫn đánh dấu.

Đây là lý do tại sao tôi cho rằng việc thúc đẩy Kỹ năng như một giải pháp phổ quát là một bước lùi và tại sao MCP vẫn có được kiến trúc phù hợp.

Điều tôi muốn làm 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 phải hiểu cách thức; nó chỉ cần biết cái gì. Nếu LLM muốn tương tác với DEVONthink, nó sẽ gọi devonthink.do_x() và máy chủ MCP sẽ xử lý phần còn lại.

Việc tách biệt mối quan tâm này mang lại một số lợi thế vượt trội:

• Sử dụng từ xa 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ộ. Bạn chỉ cần trỏ ứng dụng khách của mình tới URL máy chủ MCP và URL đó sẽ 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 khách hàng sẽ ngay lập tức nhận được phiên bản mới nhất. Không cần đẩy các bản cập nhật, nâng cấp gói hoặc cài đặt lại các tệp nhị phân.
• Saner Auth: Quá trình xác thực được xử lý một cách khéo léo (thường là với OAuth). Sau khi khách hàng kết thúc quá trình bắt tay, nó có thể thực hiện các hành động chống lại MCP. Bạn không buộc người dùng phải quản lý mã thông báo thô và bí mật ở dạng văn bản thuần túy.
• Khả năng di động thực sự: Máy chủ MCP từ xa của tôi hoạt động từ mọi nơi: máy Mac, điện thoại của tôi, trên web. Nó không quan trọng. Tôi có thể quản lý Notion của mình thông qua LLM mà tôi chọn từ bất cứ nơi nào có khách hàng.
• Hộp cát: MCP từ xa được đóng hộp cát một cách tự nhiên. Chúng hiển thị giao diện được kiểm soát thay vì cung cấp sức mạnh thực thi thô LLM 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 sẵn tính năng tìm kiếm công cụ. Họ chỉ tìm kiếm và tải các công cụ khi thực sự cần thiết, lưu lại cửa sổ ngữ cảnh quý giá.
• Tự động cập nhật không ma sát: Ngay cả đối với các thiết lập cục bộ, MCP được cài đặt trực tiếp qua npx -y hoặc uv có thể tự động cập nhật trên mọi thiết bị ra mắt.

Sự ma sát với các kỹ năng

Không phải tất cả các Kỹ năng đề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 cam kết, viết bài kiểm tra 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. Vấn đề bắt đầu khi một Kỹ năng yêu cầu CLI để thực sự làm điều gì đó.

Tôi phàn nàn lớn nhất về Kỹ năng là giả định rằng mọi môi trường đều có thể hoặc nên chạy CLI tùy ý.

Hầu hết các kỹ năng đều yêu cầu bạn cài đặt CLI chuyên dụng. Nhưng nếu bạn không ở nhà ga địa phương thì sao? ChatGPT không thể chạy CLI. Perplexity hoặc phiên bản web tiêu chuẩn của Claude cũng không thể. Trừ khi bạn đang sử dụng môi trường điện toán toàn diện (như Perplexity Computer, Claude Cowork, Claude Code hoặc Codex), mọi kỹ năng dựa trên CLI đều sẽ ngừng hoạt động khi xuất hiện.

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

• Việc triển khai Lộn xộn: CLI cần được xuất bản, quản lý và cài đặt thông qua các tệp nhị phân, NPM, uv, v.v.
• Cơn ác mộng quản lý bí mật: Bạn đặt mã thông báo API cần thiết để xác thực ở đâu? Nếu bạn may mắn, môi trường có tệp .env mà bạn có thể chuyển các bí mật văn bản thuần túy vào. Một số môi trường phù du sẽ tự xóa sạch, nghĩa là CLI của bạn hoạt động hôm nay nhưng lại 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 đang là miền tây 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 thông qua npx Skills nhưng chỉ hoạt động trong Codex và Claude Code chứ không phải Claude Cowork hay Claude tiêu chuẩn. Những kỹ năng kiến ​​thức thuần túy có tác dụng với Claude, nhưng hầu hết những người khác thì không. Một số công cụ hỗ trợ “thị trường kỹ năng”, một số khác thì không. Một số có thể cài đặt từ GitHub, số khác thì không. Bạn cố gắng cài đặt một kỹ năng OpenClaw vào Claude và kỹ năng này phát sinh lỗi phân tích cú pháp YAML do các trường siêu dữ liệu không khớp.
• Bị phồng bối cảnh: Sử dụng một 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ụ duy nhất mà nó cần. Điều này giống như buộc ai đó phải đọc toàn bộ hướng dẫn sử dụng ô tô 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 Kỹ năng bắt đầu bằng “trước tiên hãy cài đặt CLI này”, thì 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 sử dụng MCP từ xa thay thế?

Công cụ phù hợp cho công việc

Tôi không muốn Kỹ năng trở thành phương tiện thực tế để kết nối LLM với một dịch vụ. Chúng tôi có thể giải thích các hình dạng API trong Kỹ năng để LLM có thể cuộn nó, nhưng điều đó tốt hơn việc cung cấp giao diện rõ ràng, được định kiểu mạnh mẽ thông qua MCP?

Tôi nghĩ hệ sinh thái sẽ trông như sau:

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

• Hãy sử dụng Lịch Google. CLI gcal là được. Vấn đề là một Kỹ năng yêu cầu LLM cài đặt nó, quản lý mã thông báo xác thực và chi trả cho nó. MCP từ xa được hỗ trợ bởi OAuth do Google sở hữu sẽ xử lý tất cả những điều đó ở cấp giao thức và hoạt động từ bất kỳ ứng dụng khách nào mà không cần bất kỳ thiết lập nào.
• Để kiểm soát Chrome, trình duyệt phải hiển thị điểm cuối MCP để kiểm soát trạng thái, thay vì dựa vào chrome-cli.
• Để gỡ lỗi bằng Hopper, MCP tích hợp hiện tại cho phép LLM chạy step() tốt hơn rất nhiều so với MCP hopper-cli.
• Xcode phải đi kèm với MCP tích hợp sẵn để xử lý xác thực khi LLM kết nối với một dự án.
• Notion nên có sẵn mcp.notion.so/mcp buộc tôi tải xuống notion-cli và quản lý trạng thái xác thực theo cách thủ công. (Thực tế hiện tại họ đã có MCP từ xa, đây chính xác là quyết định đúng đắn.)

Khi nào nên sử dụng Kỹ năng: Kỹ năng phải “thuần túy”. Họ nên tập trung vào kiến thức và bối cảnh.

• Dạy các công cụ hiện có: Tôi thích có một thư mục .claude/skills hướng dẫn LLM cách sử dụng các công cụ mà tôi đã có có đã cài đặt. Kỹ năng giải thích cách sử dụng curl, git, gh hoặc gcloud hoàn toàn có ý nghĩa. Chúng tôi không cần một “MCP cuộn tròn”. Chúng ta chỉ cần dạy LLM cách xây dựng các lệnh curl tốt. Tuy nhiên, GitHub MCP từ xa chuyên dụng sẽ hữu ích hơn nhiều trong việc quản lý sự cố so với việc dựa vào gh kỹ năng CLI.
• Tiêu chuẩn hóa quy trình làm việc: Các kỹ năng này hoàn hảo để dạy Claude thuật ngữ kinh doanh, phong cách giao tiếp nội bộ hoặc tổ chức của bạn cấu trúc.
• Dạy cách xử lý một số vấn đề nhất định: Đây là một ví dụ tuyệt vời khác và những gì Anthropic cũng làm như vậy với Kỹ năng PDF - nó giải thích cách xử lý các tệp PDF và cách thao tác với chúng bằng Python.
• Mẫu quản lý bí mật: Có một kỹ năng cho Claude biết "Sử dụng fnox cho việc này repo, đây là cách sử dụng nó” rất hợp lý. Mỗi lần chúng tôi giải quyết những bí mật, Claude đều nâng cao kỹ năng này. Điều đó tốt hơn nhiều so với việc xây dựng một MCP tùy chỉnh chỉ để gọi get_secret().

Trình kết nối so với Hướng dẫn sử dụng

Suy nghĩ: Có thể thuật ngữ có vấn đề. Các kỹ năng chỉ nên được gọi là LLM_MANUAL.md và MCP nên được gọi là Connectors.

Cả hai đều có vai trò của mình.

Đối với các dịch vụ mà tôi sở hữu, tôi đã thực hiện việc này. Một vài ví dụ:

• mcp-server-devonthink: Máy chủ MCP cục bộ cung cấp cho mọi LLM quyền kiểm soát trực tiếp đối với DEVONthink. Không có trình bao bọc CLI, chỉ có giao diện công cụ sạch.
• microfn: Hiển thị MCP từ xa tại mcp.microfn.dev để bất kỳ khách hàng nào có khả năng MCP đều có thể sử dụng nó ngoài box.
• Kikuyo: Câu chuyện tương tự, MCP từ xa tại mcp.kikuyo.dev.
• MCP Nest: Kết nối các máy chủ MCP cục bộ thông qua đám mây để có thể truy cập chúng từ xa tại mcp.mcpnest.dev/mcp. Tôi xây dựng nó vì tôi luôn muốn truy cập từ xa vào các MCP cục bộ mà không để lộ trực tiếp máy của mình.

Đối với microfn và Kikuyo, tôi cũng đã xuất bản các Kỹ năng nhưng chúng bao gồm CLI chứ không phải MCP. Điều đó nói lên rằng, việc viết bài này khiến tôi nhận ra: một kỹ năng giải thích cách sử dụng máy chủ MCP thực sự rất có ý nghĩa. Không phải để thay thế MCP mà để cung cấp ngữ cảnh LLM trước khi nó bắt đầu gọi tools. Dịch vụ làm gì, các công cụ liên quan với nhau như thế nào, khi nào nên sử dụng cái nào. Một lớp kiến ​​thức nằm trên lớp kết nối. Đó là sự kết hợp mà tôi mong muốn.

Và đây thực sự là mẫu mà tôi ngày càng sử dụng nhiều hơn trong thực tế. Khi làm việc với máy chủ MCP, tôi chắc chắn sẽ phát hiện ra lỗi và các mẫu không rõ ràng: định dạng ngày cần phải là YYYY-MM-DD thay vì YYYYMMDD, một chức năng tìm kiếm cắt bớt kết quả trừ khi bạn gặp một tham số, một tên công cụ không hoạt động như những gì bạn mong đợi. Thay vì khám phá lại những điều này mỗi buổi, tôi chỉ yêu cầu Claude gói gọn mọi thứ chúng tôi đã học thành một Kỹ năng. LLM đã có sẵn bối cảnh từ cuộc trò chuyện của chúng tôi, do đó, nó viết Kỹ năng với tất cả các vấn đề cần lưu ý, các mẫu phổ biến và các giả định đã sửa được đưa vào.

Kết quả là một Kỹ năng hoạt động như một bảng ghi chú cho MCP chứ không phải là sự thay thế cho nó. MCP vẫn xử lý kết nối thực tế và thực thi công cụ. Kỹ năng chỉ đảm bảo LLM không lãng phí mã thông báo khi vấp phải những cạm bẫy tương tự mà tôi đã giải quyết. Chính sự kết hợp của cả hai đã giúp trải nghiệm thực sự mượt mà.

Đồng thời, tôi sẽ tiếp tục duy trì kho dotfiles của mình chứa đầy các Kỹ năng cho các quy trình tôi sử dụng thường xuyên và tôi sẽ tiếp tục thả .claude/skills vào kho lưu trữ của mình để hướng dẫn AI hành vi.

Tôi chỉ hy vọng ngành này không từ bỏ Giao thức bối cảnh mô hình. Ước mơ tích hợp AI liền mạch dựa trên các giao diện được tiêu chuẩn hóa, chứ không phải dựa trên bối cảnh đứt gãy của các CLI bị hack. Tôi vẫn nuôi hy vọng vào các MCP chính thức của Skyscanner, Booking.com, Trip.com và agoda.com.

Hai xu của tôi.

Nói về MCP từ xa: Tôi đã xây dựng MCP Nest dành riêng cho vấn đề này. Rất nhiều máy chủ MCP hữu ích chỉ có tính chất cục bộ, hãy nghĩ đến Fastmail, Gmail hoặc bất kỳ thứ gì chạy trên máy của bạn. MCP Nest chuyển chúng qua đám mây để chúng có thể truy cập được từ xa, có thể sử dụng được từ Claude, ChatGPT, Perplexity hoặc bất kỳ ứng dụng khách nào hỗ trợ MCP, trên tất cả các thiết bị của bạn. Nếu bạn muốn MCP cục bộ của mình hoạt động ở mọi nơi mà không làm lộ máy trực tiếp thì đó chính là mục đích của nó.