MCP (Machine Communication Protocol) đã thu hút sự chú ý lớn trong giới công nghệ, đặc biệt trong lĩnh vực Mô hình Ngôn ngữ Lớn (LLMs). Mặc dù hứa hẹn hợp lý hóa sự tương tác giữa LLMs và tài nguyên bên ngoài, nhưng một cái nhìn kỹ hơn cho thấy một số vấn đề và hạn chế vốn có cần được xem xét cẩn thận. Phân tích này đi sâu vào những lời chỉ trích xung quanh MCP, khám phá các lỗ hổng, thách thức về khả năng mở rộng và các ý nghĩa rộng lớn hơn đối với sự phát triển của các tác nhân AI.
Quá tải trách nhiệm của MCP
Một lời chỉ trích phổ biến là MCP đang được giao quá nhiều trách nhiệm. Tác giả lập luận rằng MCP chủ yếu nên đóng vai trò là cổng để LLMs truy cập và tương tác với các tài nguyên bên ngoài. Xem nó chỉ đơn thuần là một ‘cánh cửa’ hoặc ‘cầu nối’ giúp làm rõ mục đích và giới hạn của nó.
Việc quy các vấn đề như vô tình làm lộ dữ liệu, các lỗ hổng tấn công prompt injection và sự thiếu hụt trong kiểm soát chi phí trực tiếp cho MCP là một sự đổ lỗi sai lầm. Đây là những vấn đề mà các nhà phát triển nên giải quyết trong phạm vi ranh giới mà họ kiểm soát. Các nhà phát triển cần triển khai giới hạn tỷ lệ và theo dõi việc sử dụng, bất kể giao thức nào được sử dụng. So sánh điều này với việc đổ lỗi cho con đường vì chạy quá tốc độ là thích hợp - cơ sở hạ tầng không chịu trách nhiệm cho hành vi cá nhân.
Cuối cùng, nhiều mối quan tâm được đưa ra là những vấn đề rộng lớn hơn liên quan đến việc ủy thác nhiệm vụ cho các tác nhân AI. Các nhà phát triển phải chịu trách nhiệm quản lý những thách thức này trong các ứng dụng cụ thể của họ, thay vì mong đợi chính API xử lý mọi thứ.
Con dao hai lưỡi của LLMs và Prompt Injection
Các cuộc thảo luận gần đây về MCP thường giống như những cảnh báo về những nguy hiểm vốn có của dao sắc - chúng có thể cắt nếu xử lý sai. Prompt injection, một mối quan tâm đáng kể, là hậu quả của bản chất của chính LLMs. Các nỗ lực để loại bỏ rủi ro prompt injection làm suy giảm chính những khả năng làm cho LLMs trở nên có giá trị.
Khái niệm về sự tách biệt ‘kiểm soát so với dữ liệu’, phổ biến trong các hệ thống truyền thống, không tồn tại tự nhiên trong LLMs. LLMs đạt được sức mạnh và tính tổng quát của chúng chính xác vì chúng thiếu sự tách biệt cứng nhắc này. Đặc điểm vốn có này làm cho chúng dễ bị tấn công prompt injection.
Mặc dù MCP từ xa dưới dạng Dịch vụ có thể gây ra rủi ro, nhưng lỗi không nằm ở chính giao thức mà ở việc giao phó các nhiệm vụ nhạy cảm cho các bên thứ ba không đáng tin cậy. Sự tương tự này mở rộng đến ý tưởng dán một con dao vào một Roomba thất thường - vấn đề không phải là bản thân con dao, mà là quyết định gắn nó vào một thiết bị không thể đoán trước.
Những lời khuyên ‘hãy cẩn thận’ hoặc gợi ý về thiết bị bảo vệ, mặc dù chính xác về mặt kỹ thuật, nhưng lại bỏ lỡ vấn đề cốt lõi: quyết định dại dột khi kết hợp một công cụ sắc bén với một hệ thống không được kiểm soát.
Thách thức về khả năng mở rộng
Ngoài những lo ngại về bảo mật, MCP còn phải đối mặt với những hạn chế về khả năng mở rộng cơ bản. Tác giả nhấn mạnh mối tương quan nghịch giữa độ tin cậy của LLM và lượng ngữ cảnh hướng dẫn được cung cấp. Điều này thách thức niềm tin phổ biến rằng việc thêm nhiều dữ liệu và tích hợp sẽ tự động giải quyết vấn đề. Khi số lượng công cụ và tích hợp tăng lên, hiệu suất của tác nhân có thể giảm trong khi đồng thời tăng chi phí cho mỗi yêu cầu.
Tác giả nhấn mạnh rằng MCP không mở rộng quy mô vượt quá một ngưỡng nhất định. Cố gắng thêm một số lượng công cụ không giới hạn vào ngữ cảnh của tác nhân chắc chắn sẽ ảnh hưởng tiêu cực đến khả năng của nó. Hạn chế này là vốn có trong khái niệm MCP và đòi hỏi sự chú ý nhiều hơn so với các vấn đề xác thực.
Người dùng có thể cuối cùng trải nghiệm sự suy giảm hiệu suất khi họ bật nhiều máy chủ MCP hơn, dẫn đến sự can thiệp giữa chúng. Điều này trái ngược hoàn toàn với các hệ thống quản lý gói điển hình, nơi sự không can thiệp là một thuộc tính cơ bản.
Vấn đề cốt lõi với MCP là hành vi thực tế của nó khác với mong đợi của người dùng. Điều quan trọng là phải nhận ra rằng MCP không phải là một giải pháp plug-and-play tích hợp liền mạch một số lượng công cụ không giới hạn mà không có hậu quả.
Giải quyết các hạn chế bằng UI và Quản lý Công cụ
Một giải pháp được đề xuất cho các hạn chế của MCP là cải thiện giao diện người dùng. Nếu một công cụ được thực thi vô tình, UI sẽ cung cấp một cách dễ dàng để tắt nó hoặc sửa đổi mô tả của nó để làm rõ mục đích sử dụng dự định của nó.
Tác giả cũng lưu ý rằng sự tăng trưởng ngữ cảnh thường dẫn đến cải thiện hiệu suất và khả năng sử dụng trong thế giới thực, mâu thuẫn với khái niệm về một mối tương quan hoàn toàn tiêu cực. Tuy nhiên, họ thừa nhận rằng trong một số trường hợp sử dụng nhất định hoặc với các ngữ cảnh được thiết kế kém, sự suy giảm hiệu suất có thể xảy ra.
Để giải quyết sự lựa chọn công cụ áp đảo, một cách tiếp cận ‘chia để trị’ được đề xuất. Điều này bao gồm việc thêm một công cụ được thiết kế đặc biệt để chọn các công cụ phù hợp nhất cho một nhiệm vụ nhất định. ‘Công cụ chọn công cụ’ này có thể là một lệnh gọi LLM khác, có nhiệm vụ trả về một tập hợp con các công cụ có sẵn cho tác nhân ‘mẹ’. Cách tiếp cận phân lớp này thêm các cấp độ gián tiếp bổ sung để quản lý sự phức tạp.
Tuy nhiên, chỉ cần có các công cụ trong ngữ cảnh có thể thay đổi đáng kể đầu ra của mô hình. Mặc dù các công cụ liên quan đến ngữ cảnh (đạt được thông qua các kỹ thuật như Retrieval-Augmented Generation hoặc RAG) là có lợi, nhưng việc ẩn tất cả các công cụ đằng sau một yêu cầu ‘get_tools’ có thể gây bất lợi.
MCP như một Lớp Vận chuyển và Ủy quyền
MCP chủ yếu hoạt động như một định dạng vận chuyển và dây với vòng đời yêu cầu/phản hồi, tập trung vào ủy quyền cấp công cụ. Bài luận lập luận rằng vấn đề lớn nhất với MCP là nó không cho phép các tác nhân AI kết hợp các công cụ một cách chức năng.
Tác giả cho rằng MCP có thể không cần thiết ngay từ đầu, vì LLMs đã có khả năng tương tác với các API được ghi lại bằng thông số kỹ thuật OpenAPI. Yếu tố còn thiếu là ủy quyền - khả năng kiểm soát AI nào có thể truy cập API nào. Thay vì MCP, tác giả đề xuất cho phép AI thực hiện các yêu cầu HTTP trong khi áp dụng ủy quyền cho các điểm cuối cụ thể. Cách tiếp cận này phù hợp với xu hướng hiện tại là gói các API hiện có với các công cụ MCP mỏng.
Một khía cạnh đặc biệt khó chịu của MCP là thiếu hỗ trợ cho kết quả lệnh gọi công cụ phát trực tuyến. Cặp yêu cầu/phản hồi duy nhất buộc khách hàng phải liên tục gọi các công cụ để phân trang, cản trở các quy trình chạy dài. Việc triển khai khả năng phát trực tuyến, có lẽ bằng cách sử dụng gRPC, có thể cải thiện đáng kể hiệu quả của MCP.
Dễ dàng làm lộ dữ liệu nhạy cảm
Một mối quan tâm đáng kể với MCP là khả năng dễ dàng làm lộ dữ liệu nhạy cảm. Hơn nữa, MCP không vốn có làm cho các tác nhân AI đáng tin cậy hơn; nó chỉ đơn giản là cấp cho chúng quyền truy cập vào nhiều công cụ hơn, điều này có thể nghịch lý làm giảm độ tin cậy trong một số tình huống nhất định.
Tác giả thừa nhận rằng họ không mong đợi MCP giải quyết hoặc chịu trách nhiệm cho tất cả những vấn đề này. Thay vào đó, MCP tạo ra một bề mặt lớn hơn cho những vấn đề này, đòi hỏi các nhà phát triển ứng dụng và người dùng phải cảnh giác.
Phép loại suy và Quy hoạch đô thị
Tác giả sử dụng phép loại suy về quy hoạch đô thị để minh họa vấn đề. So sánh MCP với một con đường thành phố sáu làn với giới hạn tốc độ 25mph làm nổi bật sự thiếu kết nối giữa thiết kế và mục đích sử dụng. Đơn giản chỉ cần áp đặt tiền phạt hoặc thêm các ‘sửa chữa’ bề ngoài không giải quyết được vấn đề cơ bản về thiết kế kém.
Quy hoạch đô thị hiệu quả bao gồm thiết kế các con đường tự nhiên khuyến khích tuân thủ giới hạn tốc độ. Tương tự, MCP nên được thiết kế để giảm thiểu các rủi ro tiềm ẩn một cách vốn có, thay vì chỉ dựa vào các biện pháp kiểm soát bên ngoài.
LLMs thực hiện các hành động không mong muốn
Bài viết chuyển sang một lời chỉ trích rộng hơn về các giao thức cho phép LLMs thực hiện các hành động trên các dịch vụ. Tác giả xác định một vấn đề cốt lõi: LLMs có thể thực hiện các hành động mà người dùng không có ý định thực hiện. Họ phân biệt giữa các hành động mà LLMs có thể thực hiện độc lập và những hành động yêu cầu người dùng nhắc nhở.
Mặc dù mục tiêu cuối cùng có thể là để LLMs quản lý toàn bộ doanh nghiệp, nhưng công nghệ vẫn chưa sẵn sàng cho sự tự chủ như vậy. Hiện tại, người dùng thậm chí có thể không muốn AI gửi email mà không cần xem xét trước.
Tác giả từ chối giải pháp nhắc người dùng xác nhận, viện dẫn rủi ro người dùng rơi vào một khuôn mẫu xác nhận tự động (‘chế độ YOLO’) khi hầu hết các công cụ dường như vô hại. Điều này được ví như hiện tượng tâm lý của việc mọi người chi tiêu nhiều hơn bằng thẻ so với tiền mặt - một vấn đề bắt nguồn từ hành vi của con người, không phải công nghệ.
Câu hỏi cơ bản: Tại sao không chỉ sử dụng API?
Một câu hỏi lặp đi lặp lại trong các cuộc thảo luận về MCP là tại sao không chỉ sử dụng API trực tiếp.
MCP cho phép các ứng dụng khách LLM mà người dùng không kiểm soát trực tiếp (ví dụ: Claude, ChatGPT, Cursor, VSCode) tương tác với các API. Nếu không có MCP, các nhà phát triển sẽ cần xây dựng các ứng dụng khách tùy chỉnh bằng cách sử dụng API LLM, một công việc tốn kém hơn nhiều so với việc sử dụng các ứng dụng khách hiện có với đăng ký và dạy chúng cách sử dụng các công cụ cụ thể.
Một nhà phát triển chia sẻ kinh nghiệm của họ về việc xây dựng máy chủ MCP để kết nối với bộ tổng hợp phần cứng FM của họ qua USB, cho phép thiết kế âm thanh do AI điều khiển.
Tích hợp Ứng dụng khách LLM và Tiêu chuẩn hóa
Vấn đề cốt lõi là không phải tất cả các ứng dụng khách LLM đều hỗ trợ tương tác API trực tiếp một cách tự nhiên, với các hành động ChatGPT tùy chỉnh là một ngoại lệ đáng chú ý. Anthropic, Google và OpenAI đã đồng ý áp dụng MCP làm giao thức chung để hợp lý hóa quy trình cho các ứng dụng khách được hỗ trợ bởi LLM như Claude, ChatGPT và Cursor.
MCP đơn giản hóa quy trình cho những người xây dựng ứng dụng khách LLM. Nếu bạn muốn LLM tương tác với API, bạn không thể chỉ cung cấp khóa API và mong đợi nó hoạt động - bạn cần tạo một Tác nhân.
MCP có thể được xem như một cách để ghi lại các API và mô tả cách gọi chúng, cùng với các công cụ tiêu chuẩn hóa để hiển thị tài liệu đó và tạo điều kiện cho các cuộc gọi. Nó cung cấp vừa đủ trừu tượng để gói các API mà không làm phức tạp không cần thiết, nhưng sự đơn giản này cũng có thể khiến người dùng ‘tự bắn vào chân mình’.
Hiệu quả và Khả năng tái sử dụng của MCP
Nếu không có MCP, các nhà phát triển sẽ cần lặp đi lặp lại giải thích cho LLM cách sử dụng một công cụ mỗi khi nó được gọi. Điều này mang theo rủi ro là LLM không sử dụng công cụ một cách chính xác do thông tin bị quên hoặc hành vi API không chuẩn.
Việc giải thích và sao chép liên tục này lãng phí mã thông báo trong ngữ cảnh, làm tăng chi phí và thời gian. MCP hợp lý hóa quy trình này bằng cách đóng gói tất cả thông tin cần thiết, làm cho việc sử dụng công cụ hiệu quả hơn và tạo điều kiện cho việc chia sẻ công cụ.
Bằng cách nói với nhà cung cấp LLM ‘đây là một công cụ bạn có thể sử dụng’ cùng với tài liệu API, người dùng có thể sử dụng lại công cụ đó trên nhiều cuộc trò chuyện mà không cần nhắc nhở lặp lại. Điều này cũng cho phép các ứng dụng khách LLM trên máy tính để bàn kết nối với các chương trình chạy cục bộ, giải quyết vấn đề về các quy trình thực thi dành riêng cho hệ điều hành.
MCP và Truy cập Tài nguyên Cục bộ
MCP tạo điều kiện truy cập vào các tài nguyên cục bộ như tệp, biến môi trường và truy cập mạng cho LLMs. Nó được thiết kế để chạy cục bộ, cấp cho LLM quyền truy cập được kiểm soát vào các tài nguyên này.
‘Hình dạng’ lệnh gọi công cụ LLM tiêu chuẩn phản ánh chặt chẽ ‘hình dạng’ lệnh gọi công cụ MCP, làm cho nó trở thành một tiêu chuẩn đơn giản để kết nối các công cụ với các tác nhân.
MCP đóng vai trò là cầu nối giữa lược đồ gọi hàm được hiển thị cho mô hình AI và các API cơ bản. Nó dịch các lệnh gọi hàm thành các công cụ, cho phép giao tiếp liền mạch.
Nếu bạn là nhà cung cấp công cụ, MCP cung cấp một giao thức tiêu chuẩn hóa để các giao diện người dùng tác nhân AI kết nối với công cụ của bạn. Điều này trả lời câu hỏi tại sao giao thức tiêu chuẩn không thể chỉ đơn giản là HTTP và OpenAPI.
MCP là một meta-API kết hợp các điểm cuối và chi tiết hoạt động của chúng vào thông số kỹ thuật, cho phép LLMs tương tác với chúng hiệu quả hơn.
MCP trong các Kịch bản Cụ thể
MCP có thể giải quyết các vấn đề khi người dùng đặt câu hỏi hoặc không chắc chắn nên sử dụng API nào. Nó cũng có thể xử lý các yêu cầu dựa trên các tin nhắn trước đó.
Một người dùng chia sẻ kinh nghiệm của họ về việc muốn truy xuất ‘X’ của người dùng và gửi nó đến một điểm cuối. Họ thấy MCP là quá mức cần thiết cho một tác vụ đơn giản như vậy, cho thấy rằng nó không phải lúc nào cũng cần thiết cho các tương tác API cơ bản.
MCP được ví như một khung ứng dụng web FastAPI để xây dựng phần mềm có thể giao tiếp qua mạng, được thiết kế đặc biệt cho trải nghiệm agentic. Nó có thể được xem như ‘Rails-for-Skynet’, cung cấp một khung tiêu chuẩn hóa cho sự phát triển của các tác nhân AI.
Lo ngại về Kiểm soát của Nhà cung cấp
Có những lo ngại rằng MCP đang được thúc đẩy để tăng cường kiểm soát phía nhà cung cấp đối với hệ thống. Các nhà cung cấp LLM cuối cùng có thể hạn chế quyền truy cập API, tương tự như cách Google gây khó khăn cho việc sử dụng IMAP/SMTP với Gmail.
Sử dụng OpenAPI cho phép các tác nhân truy xuất thông số kỹ thuật API từ /openapi.json.
MCP cho phép tương tác nhanh chóng, cho phép người dùng hoàn thành các tác vụ trong vài giây thay vì dành thời gian chuẩn bị dữ liệu đầu vào, gửi nó đến API, phân tích cú pháp đầu ra và lặp lại quy trình cho mỗi tin nhắn.
Sandboxing và Rủi ro Bảo mật
Một trong những vấn đề lớn nhất là cách đầu ra của một công cụ máy chủ MCP có thể ảnh hưởng đến các công cụ khác trong cùng một chuỗi tin nhắn. Điều này đòi hỏi sandboxing giữa các công cụ để ngăn chặn các hậu quả không mong muốn. Invariant labs đã giải quyết vấn đề này bằng các mô tả công cụ, trong khi những người khác đã sử dụng các tệp đính kèm tài nguyên MCP. Việc thiếu sandboxing làm trầm trọng thêm rủi ro prompt injection.
Điều này được ví như SQL injection - một hệ thống chắp vá nơi các lỗ hổng có thể bị khai thác tại bất kỳ thời điểm nào với khả năng quan sát tối thiểu.
Giao diện prompt cũng dễ bị tấn công một dạng SQL injection, vì mô hình không thể phân biệt các phần đáng tin cậy của prompt với đầu vào bị ô nhiễm của người dùng. Giải quyết vấn đề này đòi hỏi những thay đổi cơ bản đối với mã hóa, giải mã và đào tạo mô hình.
Điều này cho phép cả prompt injection và tool injection, có khả năng dẫn đến việc thực thi mã không đáng tin cậy.
Container hóa và Truy cập Được kiểm soát
Một nhà phát triển đã tạo ra một máy chủ MCP khởi động một container Docker với mã dự án được gắn. Cách tiếp cận này cho phép LLM truy cập toàn bộ bộ công cụ Unix và các công cụ dành riêng cho dự án trong một môi trường sandboxed.
Quy trình làm việc agentic này, được điều khiển thông qua giao diện dựa trên trò chuyện, đã được chứng minh là hiệu quả hơn các phương pháp truyền thống.
Điều quan trọng là cấp cho các tác nhân MCP quyền truy cập vào những gì họ cần và không hơn. Container hóa và UX công cụ minh bạch là rất quan trọng để giảm thiểu rủi ro bảo mật.
Máy ảo và Truy cập Internet
Cung cấp cho các tác nhân một máy tính với một cài đặt Linux tối thiểu (dưới dạng VM hoặc container) có thể mang lại kết quả tốt hơn, cho phép họ tìm nạp thông tin từ internet. Tuy nhiên, điều này làm dấy lên những lo ngại về bảo mật liên quan đến các hướng dẫn độc hại và trích xuất dữ liệu.
Hạn chế quyền truy cập vào các trang web đáng tin cậy có thể giảm thiểu một số rủi ro, nhưng ngay cả các nguồn đáng tin cậy cũng có thể lưu trữ nội dung độc hại. Sự đánh đổi giữa khả năng gặp phải các hướng dẫn độc hại và lợi ích năng suất phải được xem xét cẩn thận.
Sự khác biệt giữa nhân viên và các tác nhân AI là rất lớn. Nhân viên là những người hợp pháp tuân theo luật pháp và hợp đồng, cung cấp trách nhiệm giải trình. Các tác nhân AI thiếu khuôn khổ pháp lý này, khiến việc tin tưởng trở nên khó khăn hơn.
Các Giai đoạn Đầu của Phát triển MCP
MCP chỉ được công bố vào tháng 11 năm 2024 và RFC đang tích cực phát triển.
Một số người xem toàn bộ khái niệm trợ lý cá nhân AI, bao gồm cả MCP, là về cơ bản sai sót.
Sự thúc đẩy ban đầu cho Trợ lý AI vào cuối những năm 1990 và đầu những năm 2000 đã thất bại vì các nhà tổng hợp nội dung với tích hợp dọc và sức mua số lượng lớn đã được chứng minh là hiệu quả hơn. Điều này dẫn đến sự trỗi dậy của các nền tảng như Expedia và eBay.
Các hệ thống đa tác nhân yêu cầu các lập trình viên tác động đến trạng thái của các tác nhân, một nhiệm vụ lập trình đầy thách thức.
Giới hạn của Giá trị Miễn phí
Mong muốn ‘xếp hạng kết quả theo tính khả dụng của bãi đậu xe’ làm nổi bật vấn đề truy cập dữ liệu đằng sau các API trả phí hoặc giao diện người dùng được hỗ trợ quảng cáo. Các công ty khó có khả năng cung cấp miễn phí quyền truy cập vào toàn bộ tập dữ liệu của họ thông qua API.
Mặc dù không phải tất cả các công ty sẽ tích hợp dữ liệu của họ vào các tác nhân AI, nhưng tiềm năng kết hợp các công cụ khác nhau để cung cấp năng lượng cho quy trình làm việc vẫn rất lớn.
Các công ty ưu tiên duy trì một con hào dữ liệu sẽ có khả năng chống lại các công nghệ mới đe dọa con hào đó.
Nếu booking.com có API, họ có khả năng sẽ trả về cùng một kết quả như trang web của họ, có thể có định dạng JSON hoặc XML.
Bỏ qua Người trung gian
Việc một người trung gian như booking.com cho phép người dùng hoàn toàn bỏ qua các dịch vụ của họ là vô nghĩa.
Tuy nhiên, các khách sạn riêng lẻ có thể thấy có lợi khi bỏ qua booking.com, một người trung gian mà họ thường không thích.
Một AI Nghiên cứu Sâu có thể quét các khách sạn dựa trên các tiêu chí cụ thể và tương tác với các máy chủ MCP Khám phá Khách sạn do các khách sạn riêng lẻ điều hành, bỏ qua nhu cầu điều hướng giao diện và quảng cáo của booking.com.
Các Trường hợp Sử dụng Thực tế
MCP có thể tạo điều kiện thuận lợi cho các tác vụ như tìm nạp nhật ký từ Elasticsearch hoặc truy vấn cơ sở dữ liệu theo cách có cấu trúc hơn.
Bản chất tĩnh của cấu hình máy chủ MCP, nơi các máy chủ mới yêu cầu chỉnh sửa tệp .json và khởi động lại ứng dụng, có thể gây hạn chế.
Mô hình Tinh chỉnh
MCP có thể được xem như một mô hình nhỏ, tinh chỉnh hiểu nhiều công cụ MCP và chọn đúng công cụ cho mỗi cuộc trò chuyện.
Điều chỉnh động các công cụ dựa trên ngữ cảnh có thể cần thiết cho một số kịch bản nhất định.
Cuộc hội thoại mở và Vấn đề Kinh doanh
MCP rất phù hợp cho các hệ thống hội thoại chung, mở không có luồng được xác định trước. Tuy nhiên, nó không phải là một giải pháp phù hợp với mọi vấn đề kinh doanh. Nó không nhằm mục đích thay thế các khung như LangChain.
Giải pháp thay thế cho MCP, một tiêu chuẩn do cộng đồng điều khiển mở, là các giao thức bị phân mảnh, độc quyền và bị khóa bởi nhà cung cấp. Một tiêu chuẩn có thiếu sót nhưng đang phát triển vẫn tốt hơn là không có tiêu chuẩn nào cả.
Cách tốt nhất để xem MCP là một sự thay đổi từ các nhà phát triển cá nhân xây dựng các trình bao ứng dụng khách xung quanh API sang các nhà cung cấp API hoặc các trình bao do cộng đồng duy trì xây dựng chúng. Điều này cung cấp một hộp công cụ lớn, tương tự như NPM hoặc PyPi. Tuy nhiên, việc điều phối, bảo mật và định nghĩa sử dụng vẫn là bắt buộc.
Thế hệ Langchains tiếp theo sẽ được hưởng lợi từ hộp công cụ lớn hơn này, nhưng sự đổi mới vẫn là cần thiết.
Các Công cụ Dành riêng cho Người dùng
Trong một số trường hợp, các công cụ có thể dành riêng cho dữ liệu người dùng, chẳng hạn như các công cụ để cắt và thao tác các tệp CSV đã tải lên.
Một vấn đề thường bị bỏ qua là MCP có thể làm tắc nghẽn ngữ cảnh mô hình với quá nhiều tùy chọn. Ưu tiên và hiển thị siêu dữ liệu là rất quan trọng để tránh sử dụng mã thông báo lãng phí và hành vi mô hình thất thường.
Tiêu chuẩn và Công nghệ Đang phát triển
Các tiêu chuẩn mới nổi lên theo thời gian và đã quá lâu kể từ khi các tiêu chuẩn thực sự quan trọng đến mức mọi người đã quên cách chúng phát triển.
Tải xuống các chương trình máy chủ nhỏ từ các nhà phát triển ngẫu nhiên để thêm ‘công cụ’ vào ứng dụng khách LLM có thể gây rủi ro.
Các vấn đề được nêu ra là những vấn đề chính đáng mà hệ sinh thái MCP cần giải quyết. Một số giải pháp sẽ nằm trong đặc tả MCP, trong khi những giải pháp khác sẽ nằm bên ngoài.
Mã Claude và Sử dụng Thế giới Thực
Có những ý kiến trái ngược nhau về sự thành công của MCP. Một số người đã nghe những câu chuyện về các công ty tích hợp với MCP, trong khi những người khác đã nghe từ những người dùng thấy nó gây thất vọng.
Điều này làm nổi bật nhược điểm của sự cường điệu và áp dụng sớm.
Một số nhà phát triển thấy rằng API HTTP vượt trội hơn MCP đối với hầu hết các trường hợp sử dụng. Họ lập luận rằng việc sử dụng ‘công cụ’ quy về các điểm cuối API cho các khả năng và chức năng.
Các API không tự mô tả theo mặc định, thể hiện một cơ hội bị bỏ lỡ cho những người ủng hộ REST và HATEOAS để giới thiệu các phương pháp tiếp cận của họ.
MCP là một Giải pháp Thay thế cho LangChain?
MCP đã được mô tả là có ‘mùi LangChain’ - không giải quyết được một vấn đề cấp bách, quá trừu tượng và gặp khó khăn trong việc giải thích những lợi thế của nó.
Có lẽ nó cần nói ‘KẾT THÚC DÒNG’ và trục xuất những kẻ muốn trở thành hacker đến lưới trò chơi!
Một câu hỏi quan trọng là liệu mô hình Chatbot ‘chung’ có tồn tại hay không. Các ứng dụng chuyên dụng với các công cụ riêng của chúng có thể không cần MCP.
Ngược lại, khi LLMs trở nên có khả năng hơn, các công cụ bên ngoài có thể trở nên ít cần thiết hơn. Tại sao bạn muốn MCP điều khiển Photoshop khi LLM có thể chỉnh sửa hình ảnh trực tiếp?
Giấc mơ trợ lý robot khoa học viễn tưởng có thể không thành hiện thực và các công cụ thao tác ngôn ngữ chuyên dụng có thể hữu ích hơn.
Cơ sở Người dùng và Nhận thức về Bảo mật
Cơ sở người dùng của MCP bao gồm những cá nhân ít kỹ thuật hơn, làm cho các vấn đề bảo mật trở nên đặc biệt phù hợp. Nâng cao nhận thức về các phương pháp hay nhất về bảo mật là rất quan trọng.
Dựa trên Xops trên OpenRPC, yêu cầu xác định lược đồ kết quả, giúp lên kế hoạch cách các đầu ra kết nối với các đầu vào, cải thiện độ tin cậy cho các quy trình làm việc phức tạp.
Công nghệ có khả năng phát triển và ổn định theo thời gian.
Dự phòng và Cơ sở hạ tầng Đám mây
Một số người đặt câu hỏi về những lợi ích của việc sử dụng MCP so với tiêu chuẩn OpenAPI, xem nó là thừa.
LLM sẽ sử dụng gì để gọi đến một hệ thống OpenAPI? Làm thế nào nó sẽ liên kết với shell? Làm thế nào máy chủ của LLM sẽ điều phối điều đó?
MCP cung cấp một cách có cấu trúc để LLMs thực hiện các lệnh gọi công cụ.
Các máy chủ MCP đã là các máy chủ HTTP.
Lợi thế lớn nhất của MCP là dành cho các nhà cung cấp LLM như OpenAI, không phải các nhà phát triển ứng dụng.
LLMs là bộ não không có công cụ và việc gọi công cụ trao quyền cho chúng. Tuy nhiên, với các API thông thường, các nhà cung cấp LLM không có quyền truy cập vào những công cụ đó. MCP cấp cho họ quyền truy cập, định vị họ là cổng vào AI.
CLI so với API
Tại sao không sử dụng CLI trực tiếp, vì LLMs được đào tạo về ngôn ngữ tự nhiên và CLI là một giải pháp có thể đọc và viết được cho con người?
MCP xuất hiện quá nhanh và cần thời gian để trưởng thành. Nó thiếu sự kiểm tra của một cơ quan tiêu chuẩn thông thường và được thúc đẩy bởi sự cường điệu.
Thiếu các ứng dụng trong thế giới thực.
Các Ứng dụng Chính của MCP
MCP được sử dụng trong Claude Desktop và các ứng dụng trò chuyện AI thích hợp, các công cụ tự động hóa mã và các khung tự động hóa tác nhân/LLM.
Đó là một công nghệ vội vã khác có khả năng sẽ bị loại bỏ khi từ viết tắt có thể thổi phồng tiếp theo đến.
Có hai loại giao thức gọi công cụ mô hình ngôn ngữ: những loại mọi người phàn nàn và những loại không ai sử dụng.
Anthropic đã phát triển ‘tiêu chuẩn’ này trong chân không, dẫn đến các vấn đề bảo mật.
JSON-RPC 2.0
MCP được xây dựng trên JSON-RPC 2.0, một giao thức nhẹ cho phép giao tiếp ứng dụng khách và máy chủ bằng JSON.
Có cảm giác như một đặc tả tập trung được thiết kế cho một hệ sinh thái cụ thể, tuyên bố tính phổ quát mà không kiếm được nó.
MCP đủ mạnh để làm những điều hữu ích, điều này làm dấy lên những lo ngại về bảo mật.
Nó không phải là một tiêu chuẩn trưởng thành và không được thiết kế để an toàn.
Mặc dù các đề xuất tồn tại, nhưng chúng không được thực thi hoặc thực hiện.
Langchain và Gọi Công cụ
Langchain là một trong nhiều khung triển khai mẫu ‘gọi công cụ’.
MCP là một đặc tả cho cách thông tin bên ngoài đi vào cửa sổ ngữ cảnh của mô hình ngôn ngữ, bao gồm gọi công cụ, đầu vào được tạo mẫu, hủy bỏ, theo dõi tiến trình và tính trạng thái của máy chủ công cụ.
Nó giúp tiêu chuẩn hóa các chi tiết để bất kỳ sự kết hợp trợ lý/tích hợp nào cũng tương thích.
Mặc dù MCP có những vấn đề chính đáng, nhưng các nhà phê bình nên tinh chỉnh các lập luận của họ.
Xác thực là rất quan trọng và không nên bị bỏ qua trong phiên bản ban đầu.
Có quá nhiều phức tạp.