Trong bối cảnh AI hiện tại, một khái niệm đang tạo ra tiếng vang lớn: MCP, hay Model Context Protocol. Đáng ngạc nhiên là sự chú ý xung quanh hệ thống giao thức này đã làm lu mờ ngay cả những bản phát hành mô hình mới nhất từ OpenAI, trở thành tâm điểm của các cuộc thảo luận trong ngành.
Sự gia tăng về mức độ phổ biến của công nghệ Agent, được thúc đẩy bởi sự trỗi dậy của Manus, đã thúc đẩy sự nhiệt tình của các nhà phát triển toàn cầu. MCP, được định vị là một ‘giao thức thống nhất’ cho việc triệu gọi công cụ Agent, đã nhanh chóng đạt được sức hút, đảm bảo sự hỗ trợ từ các đối thủ AI lớn như OpenAI và Google chỉ trong vòng hai tháng. Sự thăng tiến nhanh chóng này đã biến MCP từ một đặc tả kỹ thuật tương đốiobscure thành một tiêu chuẩn nền tảng trong hệ sinh thái AI, đánh dấu một ‘sự kiện phi thường’ trong lĩnh vực cơ sở hạ tầng AI.
Tuy nhiên, khi sự phấn khích ban đầu lắng xuống, những câu hỏi quan trọng nổi lên: MCP có thực sự có thể áp dụng phổ quát không? Liệu những kỳ vọng về khả năng của nó có trở nên thổi phồng không?
Cuộc khám phá này đi sâu vào nguồn gốc của MCP, mổ xẻ những điểm mạnh và hạn chế cốt lõi của nó, làm rõ những quan niệm sai lầm phổ biến và kiểm tra quỹ đạo tương lai tiềm năng của nó. Mục tiêu không phải là bác bỏ giá trị vốn có của MCP mà là thúc đẩy một sự hiểu biết có căn cứ hơn về vai trò và ranh giới của nó. Chỉ thông qua sự rõ ràng như vậy, tiềm năng của nó mới có thể được nhận ra đầy đủ.
Tiết lộ MCP: Một giao thức triệu gọi công cụ thống nhất
Định nghĩa MCP
MCP là một giao thức kỹ thuật mở được thiết kế để tiêu chuẩn hóa cách Large Language Models (LLMs) tương tác với các công cụ và dịch vụ bên ngoài. Hãy coi nó như một trình dịch phổ quát trong thế giới AI, cho phép các mô hình AI ‘nói chuyện’ với một loạt các công cụ bên ngoài. Nó cung cấp một ngôn ngữ và cấu trúc chung để LLMs yêu cầu và sử dụng các chức năng do các ứng dụng và dịch vụ khác nhau cung cấp.
Sự cần thiết của MCP
Trước khi có sự ra đời của MCP, việc triệu gọi công cụ AI bị ảnh hưởng bởi hai thách thức chính:
- Phân mảnh giao diện: Mỗi LLM sử dụng các định dạng hướng dẫn riêng biệt, trong khi mỗi API công cụ có cấu trúc dữ liệu độc đáo của nó. Các nhà phát triển buộc phải viết mã kết nối tùy chỉnh cho mọi sự kết hợp, dẫn đến một quy trình phát triển phức tạp và kém hiệu quả.
- Hiệu quả phát triển: Cách tiếp cận ‘dịch một đối một’ này tỏ ra tốn kém và khó mở rộng. Nó giống như thuê một người dịch chuyên dụng cho mỗi khách hàng nước ngoài, cản trở năng suất và sự nhanh nhẹn.
MCP giải quyết những điểm khó khăn này bằng cách cung cấp một khuôn khổ tiêu chuẩn hóa để LLMs tương tác với các công cụ bên ngoài, đơn giản hóa quy trình phát triển và cho phép khả năng mở rộng lớn hơn.
Hiểu chức năng của MCP
Kiến trúc kỹ thuật của MCP có thể được khái niệm hóa như một hệ thống bao gồm ba thành phần cốt lõi: MCP Host, MCP Client và MCP Server. Những yếu tố này hoạt động phối hợp để tạo điều kiện giao tiếp liền mạch giữa các mô hình AI và thế giới bên ngoài.
Để nắm bắt vai trò của MCP, hãy xem xét một môi trường doanh nghiệp hiện đại. Trong phép loại suy này:
- Người dùng đại diện cho các giám đốc điều hành cấp cao, chịu trách nhiệm hiểu nhu cầu của người dùng và đưa ra các quyết định cuối cùng.
- Large Language Models (LLMs) (như Claude hoặc GPT) hiểu các hướng dẫn điều hành, lập kế hoạch các bước nhiệm vụ, xác định thời điểm sử dụng các dịch vụ bên ngoài và hợp nhất thông tin để cung cấp câu trả lời.
- Hệ thống Agent hoạt động như trợ lý cá nhân hoặc thư ký điều hành, thực hiện các nhiệm vụ theo hướng dẫn.
- MCP hoạt động như một nền tảng giao tiếp tiêu chuẩn hóa hoặc hệ thống truy cập dịch vụ doanh nghiệp được sử dụng bởi các thư ký. Nó không đưa ra quyết định mà thay vào đó tuân theo hướng dẫn, giao tiếp với các nhà cung cấp dịch vụ khác nhau ở định dạng và giao thức thống nhất.
Trước MCP, sự tương tác của AI với các công cụ bên ngoài giống như một kỷ nguyên của các tiêu chuẩn giao tiếp hỗn loạn. Mỗi khi một thư ký (Agent) cần liên hệ với một bộ phận hoặc nhà cung cấp bên ngoài khác, họ phải sử dụng một thiết bị hoặc phần mềm giao tiếp khác. Điều này đòi hỏi sự quen thuộc với các hệ thống đa dạng, dẫn đến sự kém hiệu quả. Các nhà phát triển phải viết mã kết nối riêng biệt cho mỗi công cụ, dẫn đến lãng phí thời gian và khả năng mở rộng hạn chế.
MCP sắp xếp quy trình này bằng cách cung cấp một nền tảng giao tiếp thống nhất, cho phép các thư ký liên hệ với bất kỳ bộ phận hoặc nhà cung cấp dịch vụ nào bằng cùng một hệ thống và giao thức giao tiếp. Các nhà phát triển chỉ cần triển khai giao diện MCP một lần, cho phép các hệ thống AI tương tác với tất cả các công cụ hỗ trợ giao thức.
MCP: Một hộp công cụ được xây dựng trên Function Call
Điều quan trọng là phải hiểu rằng MCP không phải là sự thay thế cho Function Call truyền thống; thay vào đó, nó là một thành phần bổ sung giúp tăng cường khả năng của nó.
Function Call là cơ chế cốt lõi mà LLMs tương tác với các công cụ hoặc API bên ngoài. Đó là một khả năng cơ bản của LLMs, cho phép chúng xác định khi nào một công cụ là cần thiết và loại công cụ nào là cần thiết.
MCP hoạt động như một hệ thống phân loại công cụ, cung cấp một khuôn khổ có cấu trúc để tổ chức và truy cập các công cụ khác nhau. Do đó, MCP không thay thế Function Call mà thay vào đó hoạt động cùng với Agents để hoàn thành các nhiệm vụ phức tạp.
Quá trình triệu gọi công cụ hoàn chỉnh bao gồm sự kết hợp của ‘Function Call + Agent + Hệ thống MCP’.
Về bản chất, LLM thể hiện sự cần thiết phải gọi một công cụ cụ thể thông qua Function Call. Agent tuân theo hướng dẫn để thực hiện việc triệu gọi công cụ, trong khi MCP cung cấp một đặc tả triệu gọi công cụ được tiêu chuẩn hóa.
Hãy xem xét phép loại suy sau: một ông chủ (người dùng) muốn cà phê. Trong văn phòng (MCP Host), người quản lý văn phòng (LLM) hướng dẫn thư ký (Agent) mua một ly Americano (Function Call). Thư ký kiểm tra danh sách nhà cung cấp và thấy rằng một nhà cung cấp cà phê Americano đã tích hợp với Meituan hoặc hệ thống mua sắm thống nhất của công ty (đã triển khai MCP Server). Sau đó, thư ký định vị nhà cung cấp trong hệ thống mua sắm (MCP Client) và đặt hàng.
Trước đây, nếu không có MCP, khi LLM phát hành Function Call, Agent sẽ dịch và kết nối trực tiếp với API để triệu gọi công cụ. Mỗi API yêu cầu một chế độ triệu gọi riêng biệt và một danh sách công cụ được xác định và chế độ triệu gọi để Agent diễn giải. Với MCP, nhiều API có thể được đặt hàng trực tiếp thông qua MCP Client của nhà cung cấp, giúp Agent tiết kiệm thời gian và công sức. Tuy nhiên, Function Call của LLM vẫn không thay đổi, vẫn ở định dạng {tool: ‘mua cà phê’, ‘type’: ‘Americano’}.
Bằng cách phân biệt giữa Function Call và MCP, rõ ràng là MCP không xác định công cụ nào cần sử dụng, cũng không xử lý việc lập kế hoạch nhiệm vụ hoặc ý định của người dùng. Những khía cạnh này thuộc phạm vi của lớp Agent. MCP chỉ đơn giản cung cấp một giao diện công cụ thống nhất, trở thành một giao thức tiêu chuẩn được công nhận trong ngành.
Thách thức phát triển và bối cảnh thị trường của MCP
Bài toán phát triển
Kể từ tháng Hai, cộng đồng phát triển AI đã chứng kiến một ‘cơn sốt vàng MCP’. Trong trường hợp không có một cửa hàng ứng dụng chính thức, hàng ngàn công cụ đã tự nguyện tích hợp với giao thức MCP trong vòng ba tháng.
Sự tăng trưởng nhanh chóng này đã đẩy MCP vào tâm điểm của ngành nhưng cũng vạch trần khoảng cách giữa khát vọng và thực tế. Ban đầu, các nhà phát triển xem MCP như một ‘chìa khóa vạn năng’ nhưng đã thấy nó giống một ‘cờ lê chuyên dụng’ hơn, vượt trội trong một số trường hợp nhất định nhưng tỏ ra kém hiệu quả hơn trong những trường hợp khác.
Những người tham gia MCP có thể được phân loại là các ứng dụng khách cục bộ, các ứng dụng khách đám mây và các nhà phát triển máy chủ MCP. Các ứng dụng cục bộ tương tự như các trợ lý AI cục bộ, trong khi các ứng dụng khách đám mây giống với các phiên bản dựa trên web của ChatGPT. Các nhà phát triển máy chủ MCP là những nhà cung cấp công cụ thực tế, những người cần đóng gói lại API của họ để tuân thủ các quy tắc MCP.
Sự nổi lên của MCP ban đầu được các ứng dụng khách cục bộ hoan nghênh, nhưng các ứng dụng khách đám mây và các nhà phát triển máy chủ MCP phải đối mặt với những thách thức.
MCP có nguồn gốc từ ứng dụng Claude Desktop của Anthropic, ban đầu được thiết kế như một giao thức giao diện để triệu gọi các tệp và chức năng cục bộ, bắt nguồn sâu sắc từ nhu cầu phía máy khách.
Đối với người dùng ứng dụng khách cục bộ, MCP đại diện cho một cuộc cách mạng, cung cấp một hộp công cụ có thể mở rộng vô hạn cho phép người dùng liên tục mở rộng khả năng của trợ lý AI của họ.
Các ứng dụng khách cục bộ như Cursor và Claude Desktop đã tận dụng MCP để cho phép người dùng tự động thêm các công cụ dựa trên nhu cầu cá nhân, đạt được sự mở rộng không giới hạn về khả năng trợ lý AI.
MCP giải quyết một điểm khó khăn cốt lõi trong phát triển máy khách cục bộ: làm thế nào để cho phép các ứng dụng AI tương tác liền mạch với môi trường cục bộ và các công cụ bên ngoài mà không cần phát triển các giao diện riêng biệt cho mỗi công cụ. Giao thức thống nhất này làm giảm đáng kể chi phí tích hợp, cung cấp cho các công ty khởi nghiệp nhỏ và các nhà phát triển cá nhân một phím tắt để xây dựng các ứng dụng AI giàu tính năng với nguồn lực hạn chế.
Tuy nhiên, sức hấp dẫn của MCP giảm đi khi xem xét phát triển phía máy chủ (MCP Server) và các máy khách đám mây. Các phiên bản đầu của MCP sử dụng cơ chế liên kết kép cho các máy chủ đám mây (từ xa), sử dụng kết nối dài SSE để đẩy thông báo một chiều từ máy chủ đến máy khách và kết nối ngắn HTTP để gửi thông báo.
Cách tiếp cận này hoạt động tốt để phản hồi và can thiệp kịp thời của người dùng nhưng tạo ra một loạt các thách thức kỹ thuật trong môi trường phía máy chủ.
Thứ nhất, việc triển khai giao diện MCP thể hiện một khối lượng công việc bổ sung cho các nhà cung cấp dịch vụ doanh nghiệp lớn, mà không nhất thiết mang lại lợi ích tương ứng. Các dịch vụ này thường có các hệ thống API trưởng thành và việc cung cấp thêm một lớp điều hợp MCP có thể chỉ làm tăng chi phí bảo trì mà không tạo ra giá trị đáng kể. Nhiều ứng dụng cấp doanh nghiệp thích các cơ chế triệu gọi công cụ khép kín, có thể kiểm soát hơn là hệ sinh thái mở của MCP.
Hơn nữa, để xử lý các lời gọi đồng thời cao, các dịch vụ MCP thường cần được mở rộng sang kiến trúc đa máy chủ. Mô hình kết nối kép của MCP giới thiệu sự phức tạp của việc định địa chỉ trên các máy. Khi một kết nối dài được thiết lập trên một máy chủ và một yêu cầu được định tuyến đến một máy chủ khác, cần có một cơ chế hàng đợi phát sóng bổ sung để điều phối các kết nối phân tán này, làm tăng đáng kể độ khó triển khai và chi phí bảo trì.
Thứ hai, MCP có những hạn chế trong lĩnh vực ứng dụng đám mây. AI Agents đám mây (Agents phía máy chủ) thường chạy trong các dịch vụ không trạng thái, xử lý các tác vụ sau khi chấp nhận và giải phóng tài nguyên sau khi hoàn thành. Sử dụng MCP Client ở phía máy chủ đòi hỏi việc tạo tạm thời một liên kết SSE, gửi một yêu cầu triệu gọi công cụ, nhận kết quả từ SSE và sau đó đóng liên kết SSE, đây là một cách tiếp cận không hiệu quả làm tăng sự phức tạp và giảm hiệu suất. Một yêu cầu RPC duy nhất sẽ đủ trong trường hợp này.
Trong thực tế, các ứng dụng đám mây sử dụng MCP thường dựa vào các bộ công cụ được thiết lập sẵn và không sử dụng khả năng chữ ký của MCP về khám phá công cụ động và tải linh hoạt.
Chế độ tương tác dữ liệu của môi trường đám mây hạn chế khả năng sử dụng công cụ một cách tự do như MCP dự định. Nó đòi hỏi một quy trình tiêu chuẩn hóa cao để triệu gọi các công cụ được mã hóa cứng, cụ thể, hy sinh tính linh hoạt.
Nhóm MCP đã chứng minh sự nhạy bén với phản hồi của người dùng. Sau khi nhận được phản hồi từ các nhà phát triển phía máy chủ, MCP đã cập nhật giao thức của mình vào ngày 26 tháng 3, thay thế vận chuyển SSE ban đầu bằng vận chuyển HTTP có thể truyền phát. Giao thức mới hỗ trợ cả các trường hợp dịch vụ không trạng thái chỉ yêu cầu các yêu cầu triệu gọi công cụ đơn lẻ và các yêu cầu đẩy theo thời gian thực mà trước đây đã được đáp ứng thông qua các liên kết kép HTTP + SSE.
Những cải tiến này cho thấy rằng các vấn đề MCP hiện tại bắt nguồn từ những hạn chế thiết kế ban đầu nhưng không phải là không thể vượt qua.
Sự rối loạn của thị trường
Một thách thức khác mà MCP phải đối mặt là khả năng sử dụng thấp của nhiều triển khai trên thị trường.
Thị trường MCP hiện tại đang trải qua một chu kỳ cường điệu công nghệ điển hình. Tương tự như sự hỗn loạn của App Store ban đầu, ít hơn 20% trong số hàng ngàn công cụ MCP hiện có có giá trị thực tế. Nhiều triển khai có các vấn đề nghiêm trọng, từ lỗi cấu hình đơn giản đến hoàn toàn không sử dụng được. Một số được đưa ra thị trường vội vàng mà không được kiểm tra đầy đủ, trong khi những số khác là các sản phẩm thử nghiệm chưa bao giờ được dự định sử dụng trong thực tế.
Một vấn đề cơ bản hơn là nhiều triển khai MCP có thể không cần thiết cho thị trường. Nhiều công cụ được cung cấp thông qua MCP chỉ đơn giản là các API được đóng gói lại đã có sẵn và được sử dụng trước khi MCP xuất hiện, thêm ít giá trị độc đáo.
Ví dụ: hàng tá dịch vụ tìm kiếm được cung cấp thông qua MCP, nhưng chất lượng của chúng khác nhau đáng kể. Một số dịch vụ có thể không chính xác hoặc chậm, khiến chúng kém mong muốn hơn so với các giải pháp hiện có.
Hơn nữa, MCP thiếu một hệ thống đánh giá mạnh mẽ, khiến các Agent khó chọn công cụ phù hợp nhất dựa trên các số liệu đáng tin cậy. Quá trình lựa chọn không hiệu quả này lãng phí tài nguyên điện toán, kéo dài thời gian hoàn thành nhiệm vụ và làm giảm trải nghiệm người dùng.
Việc thiếu một hệ thống đánh giá khiến các agent khó chọn công cụ phù hợp nhất. Nếu nhiều dịch vụ MCP cung cấp các công cụ có tên và mô tả tương tự, agent có thể gặp khó khăn trong việc chọn tùy chọn tốt nhất, dẫn đến lãng phí mã thông báo và giảm hiệu quả.
Các ứng dụng AI thành công nhất thường thực hiện cách tiếp cận ngược lại, cung cấp các công cụ chính xác hơn thay vì số lượng công cụ lớn hơn. Manus, chẳng hạn, đã chọn xây dựng các ứng dụng nội bộ thay vì áp dụng giao thức MCP, mặc dù nó đã tồn tại. Manus ưu tiên độ chính xác và ổn định của cuộc gọi hơn là tích hợp với hệ sinh thái MCP.
Các trình chỉnh sửa mã như Cursor có các chức năng phát triển tích hợp, khiến hầu hết các công cụ MCP bên ngoài trở nên dư thừa.
Trạng thái hỗn loạn hiện tại của thị trường MCP không nhất thiết là một dấu hiệu thất bại mà là một giai đoạn tăng trưởng cần thiết cho bất kỳ hệ sinh thái công nghệ mới nổi nào. Tiền lệ lịch sử cho thấy rằng sự mở rộng quá mức ban đầu này sẽ dần dần hội tụ thông qua các cơ chế lựa chọn thị trường, để lại những yếu tố có giá trị nhất.
Quá trình này sẽ cho phép ngành học hỏi từ những thách thức hiện tại và tạo ra một khuôn khổ MCP mạnh mẽ hơn, đáng tin cậy hơn. Tương tự như cách bong bóng dot-com dẫn đến những đổi mới thay đổi cuộc chơi trong thương mại điện tử và phương tiện truyền thông xã hội, xu hướng MCP có thể dẫn đến một hệ sinh thái công cụ hợp lý và có giá trị hơn.
Thái độ cởi mở của nhóm MCP đối với phản hồi của người dùng là đáng khích lệ và ngành cần các công cụ tốt hơn để đánh giá và đảm bảo chất lượng của các dịch vụ MCP, điều này sẽ giúp hệ sinh thái trở nên dễ sử dụng hơn.
MCP là tốt, không phải là thuốc chữa bách bệnh
Các vấn đề được đề cập ở trên đến từ những hạn chế và thiếu sót của MCP, làm nổi bật những gì nó có thể đạt được một cách thực tế. Tuy nhiên, những lời chỉ trích khác đến từ nhữngkỳ vọng không thực tế.
Một lời chỉ trích gần đây gắn nhãn MCP là một giao thức bị lỗi vì nó không quy định các kiểu tương tác giữa LLMs và MCP.
Một số người mong đợi MCP tự động cải thiện việc ra quyết định của hệ thống AI hoặc tăng cường hiệu quả lập kế hoạch tác vụ. Kỳ vọng này nhầm lẫn các công cụ với các nghệ nhân.
Vấn đề bắt nguồn từ sự không phù hợp về nhận thức – mong đợi một giao thức giao tiếp thực hiện các nhiệm vụ của một hệ thống thông minh. Điều này giống như đổ lỗi cho USB vì không chỉnh sửa ảnh hoặc đổ lỗi cho các tiêu chuẩn 5G vì không viết mã. MCP chủ yếu là một ‘ổ cắm công cụ’ được tiêu chuẩn hóa, đảm bảo khả năng tương thích của phích cắm hơn là quy định thiết bị nào cần sử dụng hoặc cách sử dụng.
Tính hiệu quả của việc triệu gọi công cụ Agent phụ thuộc vào các yếu tố như khả năng chọn công cụ, kỹ năng lập kế hoạch tác vụ và khả năng hiểu ngữ cảnh, không yếu tố nào thuộc phạm vi của MCP. MCP chỉ đảm bảo một giao diện công cụ được tiêu chuẩn hóa, không phải cách các công cụ đó sẽ được chọn và kết hợp.
Chúng ta thường tìm kiếm những viên đạn bạc trong công nghệ, những giải pháp có thể áp dụng phổ quát. Giống như tiên đề ‘không có viên đạn bạc’ của kỹ thuật phần mềm, việc sử dụng công cụ AI không có giải pháp kỳ diệu. Một hệ thống AI mạnh mẽ cần các thành phần được thiết kế: LLMs để hiểu và tạo, khung Agent để lập kế hoạch và thực thi và MCP tập trung vào các giao diện công cụ thống nhất.
MCP cho thấy thiết kế giao thức tốt – tập trung vào một vấn đề và giải quyết tốt chứ không phải tất cả. Sự kiềm chế của nó giúp nó tiến bộ trong việc tích hợp công cụ phía máy khách.
Các thực thể như Qwen của Alibaba, ‘Xinxiang’ của Baidu và Kouzi Space của ByteDance chấp nhận giao thức MCP, cố gắng thiết lập các hệ sinh thái MCP nội bộ hiệu quả hơn.
Tuy nhiên, có những khác biệt chính trong việc triển khai: Baidu và ByteDance quyết liệt hơn. Baidu cố gắng tiếp cận C-end, tích hợp một số mô hình AI và các công cụ bên ngoài thông qua ‘Xinxiang’ (Kokone) tận dụng giao thức MCP, chủ yếu dành cho các thiết bị di động, để tích hợp vào cuộc sống hàng ngày của người dùng và khuyến khích việc áp dụng.
Kouzi Space của ByteDance có hơn 60 plugin mở rộng MCP. Được truy cập thông qua một trang web, nó cũng đã ra mắt một IDE gốc AI, Trae, hỗ trợ MCP, chủ yếu nhắm mục tiêu đến các tình huống năng suất.
Alibaba đã tích hợp giao thức MCP vào các sản phẩm như Alipay, cho phép triệu gọi công cụ AI bằng một cú nhấp chuột và mã nguồn mở mô hình Qwen3, hỗ trợ giao thức MCP, nâng cao khả năng Agent của nó.
Các nhà phát triển Tencent Cloud đã phát hành một bộ phát triển AI hỗ trợ các dịch vụ lưu trữ plugin MCP. Công cụ kiến thức mô hình lớn của Tencent Cloud cho phép người dùng gọi các plugin MCP. Agent thông minh phát triển phần mềm Craft do CodeBuddy của Tencent Cloud ra mắt tương thích với hệ sinh thái mở MCP. Ngoài ra, Tencent Maps và Tencent Cloud Storage đã phát hành MCP SERVER của riêng họ.
Việc sử dụng công cụ AI có thể phát triển từ thao tác công cụ đơn lẻ, trực tiếp đến cộng tác Agent chuyên nghiệp, giống như các kiểu lập trình đã phát triển từ ngôn ngữ hợp ngữ sang hướng đối tượng.
Trong mô hình này, MCP có thể chỉ đơn giản trở thành một phần của cơ sở hạ tầng cơ bản, thay vì một giao diện hướng đến người dùng hoặc nhà phát triển. Một kế hoạch hoàn chỉnh hơn có thể yêu cầu các kiến trúc như Agent to Agents (A2A) để nâng cao hiệu quả lập kế hoạch tác vụ và chọn công cụ bằng cách tăng mức độ trừu tượng.
Bằng cách trả MCP về vai trò ‘giao thức’ của nó, chúng ta có thể nhận ra sức mạnh thực sự của nó để thúc đẩy tiêu chuẩn hóa ngành – đây có thể là khoảnh khắc ‘giải mã’ được trân trọng nhất trong quá trình phát triển công nghệ.