Sự xuất hiện của Web 2.0 2.0: MCP
(anildash.com)- Model Context Protocol (MCP) là một đặc tả do Anthropic tạo ra để kết nối LLM với các ứng dụng và hệ thống bên ngoài, và sau khi OpenAI hỗ trợ nó trong ChatGPT, nó đã lan rộng như một giao diện chung trên nhiều nền tảng
- Ngay cả khi đặc tả còn lỏng lẻo và chưa hoàn chỉnh, nếu nhiều bên tham gia nhanh chóng cùng áp dụng một cách làm giống nhau thì trong thực tế của web, một giao thức mở vẫn có thể giành được sức mạnh
- Giá trị ban đầu của Web 2.0 gần với hệ sinh thái nhà phát triển và người dùng do API mở và các công cụ có khả năng tương tác tạo ra hơn là các trang mạng xã hội đóng
- Kỳ vọng về khả năng tương tác đã suy yếu khi các nền tảng lớn như Facebook và Twitter đóng API, nhưng MCP có thể khôi phục điều đó thành một nền tảng có thể lập trình trong làn sóng công cụ lập trình AI
- MCP không phải là lời giải vạn năng, đồng thời cũng có mức độ rủi ro bảo mật và sự thiếu minh bạch trong xử lý dữ liệu rất lớn, nhưng nó có thể trở thành một cơ hội mới để yêu cầu tuân thủ tiêu chuẩn và tính minh bạch
Vì sao MCP lan rộng như một tiêu chuẩn
- Model Context Protocol, tức MCP, là một đặc tả được Anthropic thiết kế cho Claude
- Mục tiêu là để LLM có thể yêu cầu thông tin từ nhiều ứng dụng hoặc tương tác với các hệ thống khác
- Khi OpenAI hỗ trợ cùng giao thức này trong ChatGPT vài tháng trước, MCP bắt đầu được định vị như một tiêu chuẩn được áp dụng ở nhiều nơi
- MCP cũng được đưa vào Windows, cho thấy phạm vi lan rộng của nó
- Điểm quan trọng không nằm ở mức độ hoàn thiện của đặc tả mà ở việc nhiều bên chơi cùng nhanh chóng chấp nhận cùng một giao diện
- MCP gần với một đặc tả lỏng hơn, nhưng vì mở và hoạt động được, nó giống với cách web đã thành công
Web 2.0 ban đầu ám chỉ điều gì
- Web 2.0 không phải là cách gọi những trang web đóng và độc quyền như Facebook
- Ở trung tâm của cộng đồng Web 2.0 thời kỳ đầu là xu hướng nhiều trang web cung cấp API mở, cho phép nhà phát triển và người dùng kết nối con người và dữ liệu
- Flickr, Del.icio.us, Upcoming là những trang tiêu biểu của thời đại đã tiên phong các tính năng như gắn thẻ và chia sẻ xã hội
- Các nền tảng như LiveJournal và Movable Type cũng ảnh hưởng đến các nỗ lực tiêu chuẩn mở xoay quanh API và giao thức
- Những giá trị được chia sẻ khi đó khá rõ ràng
- Xây dựng công cụ, công nghệ và nền tảng trên dữ liệu mở và các giao thức mở
- Người dùng nắm quyền kiểm soát
- Nhà phát triển tương tác với hệ thống bằng các công cụ nhất quán và có khả năng tương tác
Các nền tảng đóng đã cắt đứt khả năng tương tác
- Trong suốt một thế hệ, nhà phát triển ngày càng khó coi khả năng tương tác giữa ứng dụng và nền tảng là điều hiển nhiên
- Cũng xuất hiện những chỉ trích rằng các quỹ VC lớn và lãnh đạo ngành công nghệ đã chấm dứt thời kỳ cởi mở
- Các công cụ phân tích hoạt động trên mạng xã hội đã chứng kiến những trường hợp sản phẩm và dịch vụ dựa trên người dùng bị ngừng lại khi các nền tảng mạng xã hội lớn đóng API
- Những nền tảng như Facebook và Twitter đã làm sụp đổ kỳ vọng về dữ liệu mở và công nghệ có khả năng tương tác vốn gắn với Web 2.0 đối với nhiều người
- Kết quả là tình trạng người dùng khó xử lý mạng lưới của mình theo cách mong muốn đã trở thành điều thường nhật
- Không thể xem ảnh Instagram được nhúng trong dòng thời gian Twitter
- Khó sử dụng các tính năng như nhập/xuất người theo dõi vốn khả thi trên fediverse hoặc Bluesky
- Khó kiểm soát mạng lưới của mình bằng ứng dụng mà bản thân muốn dùng
Khả năng mà MCP có thể mở lại
- Sự trỗi dậy của MCP, kết hợp với làn sóng AI trở nên phổ biến trong giới coder, tạo ra kỳ vọng rằng các nền tảng có thể mở ra không chỉ cho LLM mà còn cho nhiều mục đích lập trình khác nhau
- Điểm cốt lõi là các nền tảng khác đã chấp nhận nguyên vẹn đặc tả do Anthropic tạo ra
- Khi một công ty trung thành áp dụng giao thức của công ty khác với vai trò người theo sau, toàn bộ hệ sinh thái có thể hoạt động cùng nhau dễ dàng hơn theo cùng một cách
- Ngược lại, cách sao chép giao thức rồi mở rộng và cuối cùng loại bỏ nó có thể gây hại cho hệ sinh thái
- Khi có sự chấp nhận thiện chí rằng sẽ dùng cùng một giao diện, dư địa để nhiều công cụ và nền tảng cùng hoạt động sẽ lớn hơn
Khó khăn của việc tuân thủ nguyên trạng tiêu chuẩn
- Hỗ trợ tiêu chuẩn đúng như nguyên trạng khó hơn vẻ bề ngoài
- Ngay cả khi ra mắt sản phẩm semantic caching cho các nền tảng AI, việc thuyết phục nhà phát triển sử dụng nguyên trạng API ChatGPT thông thường cũng không hề dễ
- Nhà phát triển dễ nghĩ rằng mình có thể “làm cho nó tốt hơn”, nhưng ngay khi lệch khỏi tiêu chuẩn thì kết quả có thể lại tệ hơn
- Ngay cả với một đặc tả tệ và có nhiều điểm không khớp, việc mọi người cùng triển khai theo một cách vẫn có lúc quan trọng hơn
- HTML cũng là một đặc tả không hoàn chỉnh và thiếu rất nhiều thứ, nhưng web đã được xây dựng trên đó
- Toàn bộ Internet cũng dựa trên nhiều đặc tả không hoàn hảo
Yêu cầu về tuân thủ tiêu chuẩn và tính minh bạch
- Một thế hệ nhà phát triển mới đang trải nghiệm sự sáng tạo và khả năng nảy sinh khi những công cụ và nền tảng họ yêu thích dùng cùng giao thức và định dạng
- Các làn sóng như RSS, podcasting, OpenID, OAuth, OpenSocial về sau một phần đã dẫn đến những kết quả như fediverse và ActivityPub
- Nhà phát triển, coder, người đam mê công nghệ và cả người dùng phổ thông đều có thể yêu cầu quyền truy cập để kiểm soát trải nghiệm trên nền tảng bằng code
- Khi tiếp cận bằng các tiêu chuẩn mở như MCP, cũng cần đồng thời yêu cầu tính minh bạch về việc nền tảng thực sự đang làm gì
- MCP linh hoạt nhưng vẫn để lại nhiều rủi ro
- Không minh bạch về cách nền tảng xử lý dữ liệu người dùng
- Khó biết tương tác nào sẽ xảy ra thông qua MCP
- Rủi ro bảo mật là rất lớn
- Giao thức không xử lý đầy đủ những lo ngại này
Giới hạn và kỳ vọng của kiểu cởi mở Web 2.0
- MCP không phải là lời giải vạn năng có thể sửa mọi vấn đề của hệ sinh thái nhà phát triển
- Nó cũng không thể sửa lại sự cường điệu và méo mó trong các cuộc thảo luận xoay quanh AI
- Tuy vậy, những nhà phát triển trẻ chưa từng trải qua thời kỳ Web 2.0 của thế hệ trước có thể nhân dịp MCP để cố đưa web trở lại gần hơn với kiến trúc vốn có của nó
- Web không được định hình để trở thành một cấu trúc độc quyền hay bị kiểm soát bởi vài cá nhân thuộc một số tập đoàn lớn
- Web lẽ ra phải có thể lập trình được thông qua những đặc tả thô ráp mà mọi người cùng vội vàng chấp nhận, và niềm vui kiểu có thể hack đó đã tồn tại từ trước cả khi web được gắn số phiên bản
1 bình luận
Các ý kiến trên Hacker News
Điều nhiều người bỏ lỡ ở MCP là nó rất hợp với phần mềm doanh nghiệp
LLM là một bộ phiên dịch đa dụng, nên rất phù hợp làm chất keo kết nối các hệ thống rời rạc vốn cực kỳ khó nối với nhau nếu không có một lớp trung gian đủ lỏng lẻo
Vì vậy ngành B2B SaaS đang tung ra các máy chủ MCP, còn nội bộ thì thảo luận cách thiết kế lại API và các giới hạn của chúng cho phù hợp với mẫu sử dụng đã thay đổi
Giao thức này theo nhiều định nghĩa thì chưa “sẵn sàng cho doanh nghiệp”, nhưng như tác giả nói, điều đó không quá quan trọng. Nhìn vào lịch sử các tiêu chuẩn, cả những thứ lộn xộn và “tệ” cũng được chấp nhận rộng rãi nếu chúng khớp với đúng người vào đúng thời điểm
Bớt phải tranh luận kiểu đổi một trường của đối tượng người dùng thì là PUT thay thế toàn bộ đối tượng người dùng ban đầu hay là POST. Tôi đã tốn khá nhiều thời gian với mấy động từ REST rồi
LLM cũng không cần hiểu ngữ nghĩa REST của API. Nó chỉ cần nhìn các phương thức RPC có sẵn và gọi cái có vẻ dùng được. Tôi nghĩ cốt lõi thật sự chỉ đến thế
Cũng không phải kiểu các endpoint thương lượng với nhau một schema để sau này có thể truy vấn rẻ hơn
Chỉ với chúng cũng có thể làm các tính năng như tự khám phá
Nơi nào cung cấp MCP thì dù sao cũng sẽ cung cấp một API tử tế
Công ty nào mà chẳng muốn vắt được năng suất tối đa từ nhân viên trong giờ làm việc
Đoạn “so với thời trước, khi những ông già Unix khó tính viết đặc tả” là một trong nhiều lý do khiến web ngữ nghĩa thất bại, theo tôi. Nó cũng không mâu thuẫn với ý “cái tệ hơn lại tốt hơn” của tác giả
Tôi nghĩ mọi người đã quá say mê chữ eXtensible trong XML, và đã tích tụ một mức mệt mỏi nhất định. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS, v.v. trở nên quá nhiều
Thứ thế giới khi đó cần là một định dạng trao đổi đơn giản, và JSON đáp ứng nhu cầu đó, còn phía XML thì gần như là kiến trúc hàng không vũ trụ cho định dạng dữ liệu
Nhưng tôi cũng tin giờ đã đến thời của XML. Trong các system prompt bị rò rỉ từ những nơi như Anthropic, XML xuất hiện khá thường xuyên. Có vẻ LLM xử lý khá tốt các định dạng văn bản có cấu trúc, đặc biệt là Markdown và XML
Tuy nhiên tôi cho rằng MCP là mô hình sai. Thay vì chỉ thị cho mô hình tự “kéo” ngữ cảnh về, tôi nghĩ chúng ta nên “đẩy” ngữ cảnh vào mô hình
Bốn thẻ macro (
#=,#&,#?,#!) lần lượt tự thay thế bằng kết quả mở rộng macro của chính chúng theo kiểu gán, thay thế, rẽ nhánh điều kiện giốngcond, và gọi hàm do người dùng định nghĩa; rồi tôi nhận ra rốt cuộc mình đang tạo lại XSLTThứ tôi thật sự muốn là XPath. Đó là một cách mô tả cách duyệt tiến/lùi trên đồ thị theo nhiều trục, và thực sự là một đặc tả xuất sắc
Sau đó tôi tìm thấy BaseX https://basex.org/, cho phép đưa tài liệu XML tùy ý vào một cơ sở dữ liệu có thể truy vấn và truy vấn bằng XPath hoặc XQuery
Nếu muốn tạo một giao diện dataset bằng ngôn ngữ tự nhiên đáng tin cậy, không ảo giác, cách tốt nhất có vẻ là đưa XML schema vào system prompt và để mô hình viết truy vấn để lấy dữ liệu
Nếu đã biết trước thông tin, có lẽ tôi đã tự giải quyết vấn đề rồi
Giá trị nhận được từ MCP có vẻ gần với “đừng bắt tôi học cách nối 15 nguồn lại với nhau, hãy chạy truy vấn nào đó thay tôi”
Không ai™ nhét XML đúng nghĩa bắt đầu bằng khai báo XML vào LLM, cũng không dùng namespace, XSLT hay XML Schema gì cả
Nó gần giống một tập hợp tùy ý các thẻ kiểu SGML hơn
XML là một đặc tả lớn hơn nhiều so với chỉ dấu ngoặc nhọn, và nó cố bao phủ mọi trường hợp cũng như xử lý bảo mật và mã hóa ký tự cho đúng
Vì vậy “chỉnh sửa văn bản thuần” khá không trực quan. Nếu nhập một đoạn như đoạn này, ở chế độ tương thích nó có thể được parse, nhưng có thể không hợp lệ
Là định dạng trao đổi, hoặc định dạng được nạp vào các ứng dụng được xây dựng phù hợp với nó, thì nó có nhiều tiềm năng hơn; LLM chắc chắn cũng sẽ không gặp khó khăn khi hiểu nó, nên điều đó là tốt
Nhiều vấn đề trong quá khứ đến từ việc các lập trình viên thiếu thời gian và muốn nhét tính năng thật nhanh đã vung những đặc tả có cấu trúc chặt chẽ như một cây gậy cùn. “XML à? Dùng regex là được chứ gì.” Nếu ba chương trình khác nhau và ba tác giả lặp lại chuyện đó thì sẽ thành một mớ hỗn độn
Cá nhân tôi, định dạng thực sự gần với thứ tôi từng muốn là BBCode. Nó rất tuyệt làm định dạng nguồn cho nhiều thứ. Về cơ bản vẫn là họ hàng với dấu ngoặc nhọn, nhưng có đủ cấu trúc và độ linh hoạt để dùng tốt như cú pháp frontend đa dụng
Các triển khai ban đầu là kiểu “dùng regex là được”, nhưng sau nhiều thập kỷ được kiểm chứng trong thực tế, ngày nay cũng có những parser thanh lịch hơn
Tôi nghĩ ngược lại với câu: “Sự trỗi dậy của MCP mang lại hy vọng rằng, khi AI trở nên phổ biến trong giới lập trình viên, các nền tảng khác có thể được mở ra để LLM có thể lập trình được cho bất kỳ mục đích nào, chứ không chỉ để chúng điều khiển”
MCP được định sẵn là sẽ thất bại vì đúng lý do mà Semantic Web đã thất bại. Vì nếu thứ gì đó không bị khóa lại thì chẳng ai kiếm được tiền từ nó
Tôi tự hỏi có bao nhiêu phần trong việc AI tìm kiếm web thay chúng ta — xin lỗi, thứ được gọi là “deep-research” — lẽ ra đã có thể được giải quyết theo cách tốt hơn
Các nhà hàng lẽ ra có thể công bố thực đơn ở dạng metadata, và bất kỳ ai cũng có thể dùng một script Python để tìm chiếc taco rẻ nhất ở Texas. Nhưng thực tế là một tay thì khóa dữ liệu sau những rào cản nhân tạo, tay kia thì tạo ra AI, cả trung tâm dữ liệu, để vòng qua nó. Nhìn ở tầm vĩ mô thì đó chỉ là một việc ngu ngốc
Làn sóng agent trước đây chết đi vì cuối cùng mọi người nhận ra rằng họ không thể tin tưởng mã của chính mình chạy trên một cỗ máy mà mọi thứ đều có thể thương lượng. Đó là chuyện phía Java những năm 90
Về căn bản, giữa các agent tương tác với nhau có một vấn đề bất đối xứng thông tin được thiết kế có chủ ý. Nếu loại bỏ nó, một phần lớn của xã hội sẽ ngừng hoạt động
Dù bạn ném bao nhiêu tài nguyên vào vấn đề, sẽ luôn có người tìm ra cách làm cạn kiệt chúng chỉ để đạt được một lợi ích rất nhỏ
MCP chỉ làm vấn đề tệ hơn khi các AI agent đổ xô như đàn châu chấu vào các máy chủ MCP công khai
Lựa chọn ổn định có lẽ là định giá RPC tính phí theo mỗi lần gọi. Ít nhất thì bên vận hành mô hình hoặc agent sẽ đóng vai trò trung tâm thanh toán, nên khả năng thành công cao hơn so với API thời Web 2.0
Có lẽ cách tính phí hợp lý nhất là gộp những chi phí này vào gói thuê bao. Điều đó có vẻ là cách tốt nhất để căn chỉnh các động lực
Ngay từ đầu, người đặt cái tên HATEOAS đã coi như dọn sẵn bàn cho nó thất bại
Nếu việc công bố dữ liệu ở định dạng chuẩn có giá trị “dễ thấy”, hẳn các endpoint có khả năng tương tác đã được chấp nhận rộng rãi hơn nhiều
Ví dụ như dùng schema.org hay các ontology chung phổ biến. Nhưng thực tế là có rất nhiều định dạng tùy chỉnh, lần nào cũng cần một SDK phép thuật đặc biệt
Việc yêu cầu nhà hàng công bố thực đơn ở định dạng metadata mới là rào cản nhân tạo
Vẻ đẹp của các công cụ xử lý ngôn ngữ tự nhiên mới nằm ở đây. Chủ nhà hàng không cần học JSON hay mua một gói phần mềm tạo JSON
Chúng ta có thể dùng dữ liệu đúng như nó vốn có. Chi phí để tạo ra công cụ hữu ích gần như bằng 0
Nó sẽ không chính xác, nhưng ngôn ngữ của con người vốn là như vậy
Những người nghĩ rằng chỉ cần có MCP là có thể truy cập mọi thứ trông thật đáng thương
Những thứ đó sẽ bị giấu sau hàng chục lớp xác minh thanh toán và xác thực. Tất nhiên cũng sẽ có IP danh sách cho phép, và đương nhiên là IPv4
Thứ các bạn nhìn thấy có lẽ chỉ là
ERR 402;Điều khiến tôi lo nhất về MCP không phải là giao thức được làm quá tệ, mà là việc sửa chữa và cải thiện nó chỉ phụ thuộc vào các nhóm nội bộ của Anthropic và OpenAI
Những người tạo ra giao thức này trông không giống các kỹ sư thật sự cũng tự triển khai nó
Mơ hồ có cảm giác như thế độc quyền nhóm Visa-Mastercard
https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
Giờ đây nếu LLM có thể đọc tài liệu API và thích nghi, chẳng phải việc tuân theo API chuẩn đã bớt cần thiết hơn trước sao
Lợi ích quan trọng với tôi là sẽ hình thành kỳ vọng rằng một site “có” API, bất kể nó có tuân theo đặc tả MCP hay không
Ngay cả khi tài liệu tốt, LLM vẫn có thể sinh mã sai để tương tác với API. Nếu bạn sửa mã được sinh ra rồi để LLM gọi mã đó nhằm tương tác với API, thì dù sao bạn cũng đã bước lên con đường đi tới một tầng trung gian. Về thực chất là đang tạo một máy chủ “kiểu MCP”
Khi cho LLM truy cập trực tiếp API cũng có các vấn đề về bảo mật hoặc phân bổ tài nguyên. LLM có hiểu biết hạn chế về lần cuối API được gọi là khi nào. Nó có thể gọi quá thường xuyên, và nếu chi phí mỗi lần gọi đắt thì sẽ phát sinh hóa đơn hạ tầng ngoài dự kiến
Ngoài ra còn nhiều điểm đau tiềm tàng khác có thể được giải quyết bằng cách đặt một thứ gì đó ở giữa
Việc “thứ gì đó” ấy có phải là MCP hay không thì những người hợp lý có thể nhìn nhận khác nhau. Hiện tại, có vẻ nó hoạt động đủ tốt để xử lý những việc mọi người cần làm
Giờ chúng ta có thể tạo ra Semantic Web. Chỉ cần tạo một giao thức nhỏ để các tổ chức chia sẻ SQL
CREATE TABLEDDL dưới dạng tệp tĩnh mà ứng dụng MCP có thể đọc. Một phần mở rộng tùy chọn của MCP là đủKhi đó, bằng cách dùng các công cụ vốn đã tồn tại để nối lời gọi hàm AI/LLM với SQL, ta có thể hiểu và truy vấn dữ liệu; đó sẽ chính là Semantic Web
Cách này lấp đầy mắt xích còn thiếu từng luôn cản trở Semantic Web: vấn đề các công ty không có động lực dùng “kiểu dữ liệu” chuẩn thay vì kiểu dữ liệu độc quyền
Khi có MCPQ, tức MCP có kèm truy vấn, các tổ chức đột nhiên sẽ có lý do để hợp tác ở tầng cấu trúc dữ liệu
Hóa ra “Semantic Web” từ trước đến nay vẫn là Syntactic Web, và có lẽ lần này mới là thật
Tôi tò mò không biết sẽ mất bao lâu trước khi ai đó tạo ra một máy chủ MCP để điều khiển thứ gì đó như gián
Tài liệu tham khảo:
https://www.technologynetworks.com/informatics/news/robo-roa...
https://www.sciencealert.com/scientists-turned-cockroaches-i...
Và còn nhiều ví dụ khác có từ hơn 10 năm trước
Cách diễn đạt “thời mà các bản đặc tả được viết bởi những ông chú Unix già khó tính” khá buồn cười
Thú vị là thế hệ này lại tưởng tượng “những ông chú Unix già” là những người khó tính. Unix vốn là cuộc nổi loạn di chuyển nhanh và phá vỡ mọi thứ tối thượng chống lại trường phái MIT mà
Có lẽ có những thứ chẳng bao giờ thay đổi :-)