MCP bỏ qua những bài học quý giá từ các hệ thống phân tán
(julsimon.medium.com)- MCP(Model Context Protocol) tuyên bố chuẩn hóa tích hợp công cụ AI, nhưng có vấn đề là bỏ qua các thông lệ tốt nhất về hệ thống phân tán và RPC đã tích lũy trong 40 năm
- Vì vậy trong môi trường doanh nghiệp, các chức năng cốt lõi như độ tin cậy vận hành, tính an toàn kiểu dữ liệu, bảo mật, khả năng quan sát và quản lý chi phí
- MCP không chỉ phụ thuộc vào các thư viện bên ngoài để thực hiện các chức năng bắt buộc, mà còn làm phát sinh sự phân mảnh giao thức và độ phức tạp tích hợp, cùng với gánh nặng kiểm toán và bảo mật
- Các yêu cầu vận hành chính như theo dõi phân tán, quản lý phiên bản schema, service discovery, tối ưu hóa hiệu năng, v.v. vẫn còn thiếu
- Việc đưa MCP vào quá sớm có nguy cơ dẫn đến sự cố nghiêm trọng cho doanh nghiệp khi dựa vào cơn sốt AI, rủi ro vận hành, phát triển trùng lặp, phát sinh chi phí không cần thiết
Nguy cơ do sự đơn giản hóa của MCP
Model Context Protocol (MCP) tự định vị mình như "USB-C trong AI" cho tích hợp công cụ AI, nhấn mạnh sự đơn giản để hạ thấp rào cản triển khai. Nhưng sự đơn giản này lại bỏ qua những bài học tích lũy trong 40 năm của hệ thống phân tán, khiến thực tế vận hành phát sinh những thiếu hụt tính năng nghiêm trọng. Các doanh nghiệp đang triển khai MCP hiện nay đang dựng hệ thống trên nền tảng thiếu các chức năng thiết yếu của RPC.
Khoảng cách nguy hiểm giữa kỳ vọng và thực tế
Những người ủng hộ MCP giới thiệu giao thức này như một hạ tầng sẵn sàng cho production, nhưng triết lý thiết kế thực tế lại thiên về sự tiện lợi cho phát triển nên thiếu độ bền vững vận hành. Có thể kết nối công cụ AI trong thời gian ngắn, nhưng khi sử dụng hàng triệu lượt request thực tế trong kinh doanh, nó sẽ bộc lộ các khiếm khuyết nghiêm trọng. Do kỳ vọng thị trường quá mức vào AI, việc áp dụng được đẩy lên trước khi đạt đến mức trưởng thành kiến trúc, làm gia tăng nguy cơ thất bại vận hành.
Những sai lầm lặp đi lặp lại từ lịch sử 40 năm
-
UNIX RPC (1982) đã đưa vào XDR (External Data Representation) và IDL (Interface Definition Language) để đảm bảo khả năng tương thích dữ liệu giữa các hệ thống dị thể, ví dụ như số nguyên 32-bit, cho phép phát hiện lỗi sai lệch kiểu tại thời điểm biên dịch
MCP bỏ qua kinh nghiệm này khi chỉ cung cấp JSON không có schema và các gợi ý không bắt buộc. Lỗi kiểu có thể phát sinh ở runtime, AI có thể sinh ra ngày tháng sai, dẫn đến lỗi chuyển đổi dữ liệu nghiêm trọng và vấn đề chất lượng trong các môi trường thực tế như tài chính, chăm sóc sức khỏe, sản xuất -
CORBA (1991) dùng OMG IDL để đảm bảo cùng một giao diện hoạt động trên nhiều ngôn ngữ. MCP được triển khai riêng cho từng ngôn ngữ, nên không nhất quán trong cách tuần tự hóa, xử lý lỗi và các thành phần khác giữa ngôn ngữ/thư viện, gây ra cơn ác mộng tích hợp
-
REST (2000) đạt khả năng mở rộng và độ tin cậy lớn nhờ cấu trúc stateless, ý nghĩa rõ ràng dựa trên verb và cache header
MCP thì ranh giới giữa stateful/stateless mơ hồ, thiếu phân biệt ý nghĩa chuẩn hóa của yêu cầu theo cache, idempotency. Việc mở rộng server, retry và load balancing vì thế trở nên cực kỳ khó -
SOAP/WSDL có hợp đồng đọc được bởi máy, khả năng tự động hóa và khả năng mở rộng bảo mật
MCP chỉ đưa ra schema JSON đơn giản, thiếu các khả năng như hợp đồng đọc được bằng máy, tự động sinh mã, an toàn kiểu, kiểm toán bảo mật. OAuth 2.1 chỉ được bổ sung muộn cho truyền tải HTTP, và stdio phụ thuộc biến môi trường nên kiểm soát bảo mật vẫn yếu -
gRPC (2016) tích hợp sẵn khả năng quan sát, theo dõi phân tán, streaming hai chiều, deadline, mã lỗi có cấu trúc
MCP chỉ hỗ trợ streaming một chiều kiểu Event và kém hiệu quả khi cài đặt các tương tác phức tạp. Ngữ cảnh theo dõi, deadline, phân loại lỗi và các thành phần bắt buộc khác còn thiếu
Rủi ro của khẩu hiệu 'chỉ cần dùng thư viện này'
Mỗi khi nêu lên các lỗi nghiêm trọng, MCP phản hồi bằng việc thêm các thư viện thứ ba (ví dụ: mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator). Tuy nhiên, đây là tuyến thất bại cốt lõi của chính giao thức. Khi các chức năng quan trọng bị phân tán ra ngoài, các vấn đề như phân mảnh, thiếu nhất quán, chia tách trách nhiệm bảo trì, bảo mật, tích hợp ngày càng nghiêm trọng. Trong môi trường doanh nghiệp, trong vài tháng chi phí chuẩn hóa, kiểm toán và tích hợp đã tăng cao, trong khi việc đào tạo phát triển và mức độ phụ thuộc bên ngoài cũng tăng bất thường.
Những bản vá tạm thời ngày càng được dán thêm
Phiên bản 2025–03–26 của MCP giống như bản ghi chú vá cho các lỗi được phát hiện muộn trong sản xuất. OAuth, quản lý phiên, thuộc tính công cụ (annotation), thông báo trạng thái tiến trình… chỉ là các tính năng đã thiếu từ đầu nhưng được bổ sung về sau. Ngay cả việc phân biệt thuộc tính công cụ cũng thiếu trong giai đoạn đầu, và xác thực bảo mật cũng ban đầu được xem là không cần thiết. Điều này cho thấy sự thiếu hụt hiểu biết bản chất về yêu cầu doanh nghiệp.
Cơn ác mộng debug và không thể theo dõi vận hành
Trong môi trường gRPC, theo dõi phân tán và trace ID giúp debug nhanh chóng, nhất quán MCP trái lại, không có ID liên kết giữa các request, định dạng log không nhất quán, và yêu cầu triển khai riêng dẫn đến phải mất vài ngày để debug/trace lỗi Ở góc độ vận hành và kinh doanh, phân bổ chi phí và quản lý mức sử dụng (header, đếm token, quota, v.v.) không khả thi. Trong môi trường cloud, các chức năng cơ bản chưa được MCP cung cấp, khiến chi phí và trách nhiệm của việc sử dụng AI gần như không thể truy vết
Những vấn đề vận hành quan trọng vẫn còn tồn tại
- Thiếu service discovery khiến khả dụng, mở rộng đa vùng và cập nhật không gián đoạn không khả thi
- Không có quản lý phiên bản schema riêng cho từng tool nên khi cập nhật tool, nguy cơ làm toàn bộ client lỗi mà không có cảnh báo luôn hiện diện
- Giới hạn hiệu năng: overhead JSON, thiếu pooling kết nối, thiếu giao thức nhị phân và nén, giao tiếp theo tiến trình... tái diễn các mô thức lỗi thời
Rủi ro nghiêm trọng khi áp dụng cho doanh nghiệp
Khi AI bước vào các lĩnh vực chịu trách nhiệm trực tiếp về doanh thu, an toàn và chất lượng (tài chính, y tế, sản xuất, hỗ trợ khách hàng), rủi ro của việc triển khai MCP gia tăng Thay vì tận dụng các mô thức tích hợp đã vững chắc qua thời gian, doanh nghiệp rơi vào trạng thái bổ sung tạm thời sau này cho các yêu cầu về bảo mật, kiểm toán, an toàn kiểu và ổn định vận hành Chiến lược "làm nhanh rồi hỏng" chỉ phù hợp cho prototype thử nghiệm, nhưng với dịch vụ quan trọng sẽ dẫn đến hậu quả nghiêm trọng
Hướng cải thiện và yêu cầu dài hạn
- Ngắn hạn: bắt buộc loại bỏ các thiếu hụt tại mức giao thức như an toàn kiểu, theo dõi phân tán (correlation ID), ủy quyền, chuẩn kiểm toán, quản lý phiên bản schema độc lập theo từng công cụ
- Vận hành: yêu cầu service discovery, connection pool, truyền nhị phân, deadline, chính sách lỗi/retry chuẩn hóa v.v.
- Dài hạn: streaming hai chiều, quản lý quota & chi phí tích hợp, thực thi SLA, orchestration quy trình công việc và các chức năng cấp doanh nghiệp khác
Kết luận
Thiết kế của MCP thiên về tính đơn giản có thể phù hợp cho tích hợp công cụ AI theo chu kỳ ngắn và mang tính thử nghiệm, nhưng trong vận hành doanh nghiệp quy mô lớn nó dẫn đến rủi ro vận hành và chi phí vận hành có tính chất chí mạng Việc chậm lại để đi trước AI boom đã khiến việc triển khai diễn ra quá nhanh, với xu hướng lặp lại việc thêm tạm các chức năng bắt buộc như bảo mật, quan sát, ổn định vận hành về sau Cuối cùng, rủi ro lớn là việc phân mảnh và phát triển trùng lặp mà giao thức cố gắng ngăn chặn sẽ lại tái hiện trên MCP Ngành AI đang đứng trước ngã rẽ: lặp lại các vấn đề mà lịch sử 40 năm của hệ thống phân tán đã giải quyết, hay học hỏi từ lịch sử Nếu đi tiếp như vậy, triển khai thất bại, lỗ hổng bảo mật, ác mộng vận hành sẽ lặp lại và chi phí hoàn toàn rơi vào doanh nghiệp
1 bình luận
Bình luận Hacker News
Ban đầu mình chỉ nhìn tiêu đề bài này và nghĩ chắc là một câu chuyện an toàn kiểu thông thường. Nhưng khi đọc mới thấy nó thực sự có nhiều chiều sâu. Đặc biệt có đoạn này rất đáng chú ý: MCP bỏ qua các bài học đó, dùng gợi ý không bắt buộc trong JSON không có schema, khiến việc kiểm tra kiểu dữ liệu chỉ diễn ra ở runtime hoặc thậm chí không diễn ra. Ví dụ AI tool mong đợi timestamp ISO-8601 nhưng nhận giá trị epoch Unix, mô hình có thể không thất bại đúng cách mà vẫn sinh ra bất kỳ ngày nào. Ở dịch vụ tài chính, AI giao dịch có thể diễn giải sai số và thực thi giao dịch với độ chính xác thập phân sai; y tế có thể gợi ý sai liều do chuyển đổi sai kiểu dữ liệu bệnh nhân; sản xuất có thể gặp vấn đề kiểm soát chất lượng khi dữ liệu cảm biến mất độ chính xác trong quá trình tuần tự hóa JSON. Là người dùng LLM hàng ngày, mình thấy vấn đề này diễn ra khá thường xuyên. Mình hình dung một ngày nào đó sẽ có sự cố lớn trong hệ thống có MCP, và khi điều tra sẽ thấy MCP server phát sinh dữ liệu kỳ quặc, LLM nhận vào rồi bắn ra hallucination, và hậu quả theo chuỗi biến thành vấn đề lớn hơn. Khi lỗi của con người, bản chất LLM thiếu xử lý ngoại lệ (dễ hallucinate) và văn hóa startup phóng sản phẩm vội vã hòa trộn vào nhau, thì bug kiểu mới gần như không tránh khỏi. Khi nó xảy ra, người dùng Twitter sẽ la lối AGI đang hack mã phóng hạt nhân, cảnh đó cũng thú vị không ít.
Thành thật mà nói, trước năm 2023 mình từng nghĩ các lỗi kỹ thuật kiểu Star Trek quá hư cấu nên chẳng thể thành hiện thực. Nhưng kể từ khi LLM ra đời, mình có cảm giác rõ ràng rằng chuyện đó sẽ thật sự xảy ra. Việc tích hợp LLM còn liên quan gì đến engineering nữa không? Có hợp lý khi giao toàn bộ hạ tầng công ty cho điều khiển bên ngoài không? Hơn nữa, với vấn đề về khả năng tái tạo, không thể gọi “thử đi rồi ổn” là engineering được.
Không hiểu hết phê phán của tác giả. MCP hỗ trợ JSON Schema và server response bắt buộc phải theo schema đó. Nếu schema yêu cầu timestamp ISO-8601 nhưng server gửi epoch Unix thì đó là vi phạm giao thức rõ ràng. Bài viết vừa nói MCP hỗ trợ JSON Schema vừa lập luận không thể tạo được client type-safe, trong khi thực tế đã có quá nhiều generator code JSON Schema.
PEBKAC đã có từ trước, LLM chỉ nâng mức tự động hóa của nó lên.
Về điểm cho rằng trong y tế chuyển đổi sai kiểu dữ liệu có thể làm sai đơn thuốc, khi từng làm telemetry y tế, mình càng thấm tầm quan trọng của parse timestamp đúng. Có lẽ đó cũng là lý do mình viết unit tests đầu tiên. Thậm chí từng chỉnh lại timestamp trong header để bù khi thiếu NTP. Những biện pháp ấy để tránh rủi ro trong review sự cố và trách nhiệm y khoa. Ví dụ, khác nhau vài phút giữa lúc bệnh nhân vừa ngừng tim được tiêm thuốc và thời điểm sau đó nhận thuốc có thể quyết định sống chết. Như vụ bưu điện Anh gần đây, một lỗi dữ liệu có thể huỷ hoại cuộc đời ai đó; còn dữ liệu y tế thì sai 1 phút cũng có thể đảo lộn thế giới.
MCP chủ yếu nhằm truyền và quản lý context. Nói cách khác, trách nhiệm thực thi interface hợp lý như định nghĩa schema và validation thuộc về người dùng. Tương tự như chuyện chỉ trích “HTTP không hỗ trợ validate JSON” — đó là nhận xét hiển nhiên.
MCP tự nhận là “USB-C của thế giới AI”, nhưng paradoxically mình xem đây là minh chứng cho nhược điểm của MCP hơn là thành tựu của nó. USB-C gần như cắm được mọi thứ, nhưng chuẩn tuân thủ tệ, rất giống parsing JSON không nhất quán hay protocol non-compliance của MCP. Giống như thế giới có nhiều loại cáp USB-C, ngoài mặt nhìn thì tưởng đơn giản hóa nhưng thực tế cực kỳ phức tạp. Có lẽ tách rõ API/protocol riêng rẽ vẫn tốt hơn.
Một ví dụ thất bại rõ nhất của USB-C là khi Apple bỏ cổng USB-A ở Mac mini M4 mới nhất. Cùng một cổng nhưng hiệu năng khác biệt hoàn toàn, người dùng chỉ nhận ra muộn hơn khi sản phẩm đã ra mắt. Trước kia mọi USB-C trên máy desktop/laptop Apple Silicon thường kỳ vọng Thunderbolt 40Gbps, giờ thì một số chỉ là USB3 10Gbps. Muốn biết cổng nào là cái nào phải đọc spec hay nhìn icon nhỏ. Nếu Apple giữ vài cổng USB-A thì giới hạn 10Gbps đã rõ ràng hơn, nhưng họ lại làm mờ giá trị của thương hiệu USB-C. Cuối cùng, đa số thiết bị USB-C vẫn phải dùng adapter nối sang USB-A; bản USB-C lại đắt hơn, ít phổ biến và thậm chí còn kém chất lượng. Nhưng đây là thời đại mà hype và fanboy vượt xa tính thực dụng, usability.
Thành thật mà nói, mấy câu kiểu “USB-C = phổ quát nhưng không minh bạch” khiến mình cười to. Gọi là đạt mục tiêu là đắt.
Có người nói về SOAP là “dài dòng nhưng hiểu điều mà MCP chưa hiểu”, nhưng thực ra SOAP bản thân cũng chưa được hiểu. Mình đang duy trì hệ thống SOAP kế thừa nên không có gì để ca ngợi về SOAP; không có thứ nào làm role model được cả.
SOAP thực sự là thảm họa lớn. Lạ là nó làm cho ý tưởng đơn giản trở nên quá phức tạp. XML vốn đã phức tạp, thêm các định nghĩa WSDL hay multipart HTTP không rõ chuẩn, lại còn thiếu tương tác đúng giữa ngôn ngữ (ví dụ .NET server và Java client). Khi trend qua rồi, mọi người thường nhớ lại chỉ phần tốt, còn mình chắc chọn làm việc với JSON API không schema trong 50 năm hơn là SOAP cả tháng. Cá nhân mình nghĩ protobuf và capnp tốt hơn hẳn.
Mình thấy REST (thực ra là JSON-RPC) và GraphQL vẫn đang cố đuổi kịp chức năng mà SOAP và SOA từng có. Mỗi công nghệ mới đến rồi, đáng tiếc là ta lại vứt luôn cả phần tốt của cái cũ.
Protocol nào có chữ “Simple” gần như chẳng đơn giản. Mình đoán sắp có các protocol kiểu SMCP.
Có một bài mô tả SOAP rất hay và chuẩn: https://harmful.cat-v.org/software/xml/soap/simple. Mình thích công nghệ dựa trên XML, đặc biệt khả năng kết hợp type và validation của XML Schema vẫn vẫn vô song. Nhưng SOAP khiến mọi thứ như con quái vật. Chỉ cần một đặc tả remote call đơn giản mà nó hóa thành đặc tả mọi thứ và chẳng cái nào làm trọn vẹn. SOAP nói rằng hỗ trợ mọi giao thức truyền tải (thậm chí SOAP over email), nhiều kiểu RPC, UDDI và RPC tự xưng kỹ thuật đều có, nhưng thực tế auth, caching, HTTP response code và các phần cốt lõi vẫn để cho người dùng tự làm.
Mỉa mai thay, thứ khiến mình từ chối SOAP mãi là bài trình bày về SOAP lúc đó. Nó tương đối ổn trong cùng ngôn ngữ, nhưng khác ngôn ngữ thì tệ nhất. Mình nghĩ Microsoft yêu thích SOAP vì điều này.
CORBA ra đời năm 1991 với insight rằng trong môi trường dị thể thì không thể chỉ implement protocol riêng cho từng ngôn ngữ; OMG IDL đúng ở điểm tạo binding nhất quán giữa các ngôn ngữ để giữ interface consistency và tránh vấn đề serialize. Nhưng còn là một case thành công thật sự?
Môi trường API trung tâm JSON hiện nay xem như phản ứng trước thất bại CORBA và SOAP; có thể xem là cố tình bác bỏ, chứ không phải quên bài học CORBA.
Mình từng làm ở nơi dùng CORBA rất hiệu quả. Mình đoán thành công vì có kỹ sư senior rành CORBA trong team.
Năm 1998 mình từng apply vào chỗ của AT&T dùng CORBA; đó là lần cuối sau đó (và rồi mình chỉ thấy AT&T kéo chậm JDK download). Ở buổi phỏng vấn họ nói code concurrency của mình không ổn; dù mình có nêu điều kiện race, vẫn không thuyết phục được. Về sau thì rõ ràng câu trả lời mình lại đúng nhờ Java Memory Model.
CORBA có nhiều thứ làm tốt, nhưng nó sinh ra từ cuối những năm 80 của mạng viễn thông truyền thống và cơn bùng nổ OOP. Nó mặc định mặc định network là trong suốt, đáng tin, đối xứng; thực tế lại là timeout, retry, tắc nghẽn mạng, crash hệ thống... Đặc biệt binding C++ của CORBA trước STL kinh khủng đến mức tồi tệ, trong khi ngôn ngữ khác còn ổn hơn.
Về kỹ thuật có thể vượt trội, nhưng đây là dự án thương mại thất bại đáng công nhận.
Một bài học mà các cuộc thảo luận về MCP đang bỏ quên, và cũng là bài học MCP thực sự học được, là việc đa số chức năng cao cấp làm tăng độ phức tạp khiến nơi dùng thực tế chọn cách đơn giản nhất, chính là lý do JSON over HTTP thịnh hành. Ngay cả tech giant cũng cần vài năm để chuyển sang protocol serialization đầy tính năng như gRPC, và có thể nhiều lần thất bại giữa chừng. Trách nhiệm thật sự của MCP là chuẩn hóa hợp đồng JSON API cơ bản để LLM dễ tạo token/chia kiểu gọi tool.
MCP không hoàn hảo, nhưng nó học được bài học đúng trong lịch sử RPC rằng độ phức tạp là rào cản lớn nhất cho adoption và vận hành (tương tự sự nổi lên của JSON so với XML). SOAP quá phức tạp để hỗ trợ interop hệ thống, XML và schema cũng quá dài dòng. CORBA lại mắc kẹt vì lib/framework rối, nên thời đó ngôn ngữ mới nào cũng tránh. gRPC nhanh nhưng readability thấp và cần mapping. Khung xương RPC ngày nay là REST và JSON. Các chuẩn kể trên bị thay thế dần, chỉ còn gRPC cho nhu cầu hiệu năng cực đoan. Lý do REST và JSON thành dòng chính là thắng lợi của sự đơn giản, MCP cũng là sản phẩm thiết kế theo hướng đó.
Nhiều comment hay. Có vẻ chúng ta đang hiểu lầm về MCP. Vấn đề lớn hơn là hiểu và định hướng sai về bản chất của agent trong cả ngành. Nhiều web platform tin rằng agent sẽ ăn sâu vào hạ tầng phân tán trên network, nên họ nhắm mục tiêu để mọi agent trong container attach vào MCP qua service mesh. Mình nghĩ rằng nói web-native agent/SDK/framework phải deploy như server app là sai, và đó không phải agent; ngay cả giai đoạn đầu nó cũng chưa như vậy. Agent harness thật sự chỉ vài nhà cung cấp như Frontier labs làm được, rồi sẽ dần đi tới cá nhân hóa (ví dụ một MCP server riêng cho Claude Desktop trên desktop của mình). MCP server vốn dành cho kịch bản single instance và harness kiểu này.
Mong ai đó giải thích rõ vì sao MCP cần thiết thay cho Swagger hay proto.
OpenAPI (Swagger) hay Proto (protobuf) không bao quát hết vai trò MCP. Về lý thuyết có thể stack MCP lên trên, nhưng trường hợp local use của MCP thì assumption giao tiếp của Swagger không phù hợp, còn protobuf vốn không include giao thức truyền thông nên phải thiết kế thêm. Ngay cả khi thay JSON-RPC, về bản chất vẫn phải giữ gần như toàn bộ spec MCP, càng phức tạp hơn.
MCP là công nghệ mới.
MCP hỗ trợ streaming responses. Polling hay session state có thể làm, nhưng đó là hack không tối ưu.
OpenAI bị tính $50.000 trong tháng trước do API, mà không thể truy được MCP tool nào của phòng ban gây ra, gọi tool nào, user nào, case nào. Nhiều công nghệ AI đều đang đi sau lỗi phát sinh. Nhưng như web framework, blockchain, khi công nghệ đủ lớn thì đừng mong giai đoạn đầu đã biết hết. Khoảng trống này sẽ dần thu hẹp. Với AI mình đồng ý rằng cần tiếp tục chia sẻ ý tưởng và cảnh giác. Thật sự đang là thời kỳ cực kỳ thú vị.
Khi phải chọn giữa thiết kế tốt hơn và thiết kế đủ tốt, mình nghĩ “đủ tốt” luôn thắng. Multics vs Unix, SOAP dựa trên XML vs REST dựa trên json, thất bại của xhtml, JavaScript bản thân... có thể nêu vô vàn ví dụ. Vì vậy con người luôn tái tạo thứ “đủ tốt”, vá tạm vấn đề khi lộ rồi chấp nhận sống với nó.
Đây là hiện tượng Worse is Better lặp lại, đã chứng minh nhiều lần (https://en.m.wikipedia.org/wiki/Worse_is_better). Dù thời gian trôi qua vẫn đúng. Mình cũng thường bị cuốn bởi “giải pháp tốt hơn”, nhưng thực tế không phải lúc nào cũng vậy.
Cần 1 phút tưởng niệm cho xforms 2.0. Một thế giới ta có thể đang sống: validation form web đúng, microdata...