Mở đầu

Trí tuệ nhân tạo (AI), đặc biệt là các mô hình ngôn ngữ lớn (LLMs), đã đạt được những bước tiến phi thường, mang đến khả năng trò chuyện, sáng tạo và giải quyết vấn đề ấn tượng. Tuy nhiên, khi chúng ta tương tác với AI trong các cuộc hội thoại kéo dài hoặc các tác vụ phức tạp gồm nhiều bước, một thách thức lớn thường xuất hiện: làm thế nào để AI "nhớ" được những gì đã xảy ra trước đó? Làm sao để nó duy trì được ngữ cảnh (context) và trạng thái (state) một cách nhất quán?

Việc quản lý ngữ cảnh này thường được thực hiện theo những cách khác nhau giữa các ứng dụng và mô hình, dẫn đến sự thiếu nhất quán và khó khăn trong việc xây dựng các hệ thống AI thực sự mạnh mẽ, có khả năng "ghi nhớ" và duy trì mạch tương tác phức tạp. Để giải quyết vấn đề này, một sáng kiến đang được đề xuất chính là MCP (Model Context Protocol) - Giao thức Ngữ cảnh cho Mô hình.

Vấn đề Cốt lõi: Tại sao chúng ta cần một Giao thức Ngữ cảnh? Hiệu suất, sự liên quan và mạch lạc của bất kỳ mô hình Generative AI nào phụ thuộc rất nhiều vào ngữ cảnh được cung cấp cho nó. Ngữ cảnh là thông tin mà mô hình sử dụng để hiểu yêu cầu và tạo ra kết quả phù hợp.

Biểu hiện ở các loại mô hình khác nhau:

• Mô hình Văn bản (GPT, LLaMA...): Ngữ cảnh đến từ prompt, giới hạn token (token window), lịch sử hội thoại, và dữ liệu truy xuất (RAG).
• Mô hình Ảnh & Đa phương thức (DALL-E, Gemini...): Ngữ cảnh là mô tả văn bản, hình ảnh đầu vào (nếu có), hoặc sự kết hợp của cả hai.
• Mô hình Sinh mã (Codex, DeepSeek-Coder...): Ngữ cảnh bao gồm code đã có, tên hàm, comment, cú pháp ngôn ngữ, và đôi khi là tài liệu bên ngoài.
• Mô hình Âm thanh/Giọng nói (Whisper, AudioPaLM...): Ngữ cảnh là các đoạn âm thanh trước đó, đặc điểm ngôn ngữ và âm học (ngữ điệu, tốc độ...).

Trước khi có MCP, việc quản lý ngữ cảnh và trạng thái trong các ứng dụng AI thường đối mặt với các vấn đề:

1. Thiếu Tiêu chuẩn Chung: Mỗi nhà phát triển, mỗi nền tảng có thể tự định nghĩa cách riêng để lưu trữ và truyền tải lịch sử hội thoại, thông tin người dùng, hoặc trạng thái của một tác vụ đang diễn ra. Điều này tạo ra sự phân mảnh, khiến việc tích hợp các thành phần khác nhau hoặc chuyển đổi giữa các mô hình AI trở nên khó khăn. Số lượng lớn ứng dụng client cần tương tác với số lượng lớn server/công cụ tạo ra một mạng lưới tích hợp phức tạp, tốn kém chi phí phát triển và bảo trì (NxM).
2. AI "Hay quên": Các mô hình LLM có giới hạn về "cửa sổ ngữ cảnh" (context window) – lượng thông tin chúng có thể xử lý cùng lúc. Nếu không có cơ chế quản lý thông minh, chúng dễ dàng quên mất các chi tiết quan trọng ở đầu cuộc trò chuyện dài.
3. Khó khăn trong Tương tác Phức tạp: Việc xây dựng các ứng dụng đòi hỏi AI phải nhớ nhiều bước, nhiều thông tin qua các lượt tương tác (ví dụ: một trợ lý ảo đặt vé máy bay gồm nhiều bước xác nhận) trở nên phức tạp và dễ lỗi nếu không có cấu trúc quản lý trạng thái rõ ràng.

Chính những thách thức này đã thúc đẩy sự ra đời của ý tưởng về một giao thức chuẩn như MCP.

MCP là gì?

MCP (Model Context Protocol) là một tiêu chuẩn mở (open standard) được thiết kế để kết nối các hệ thống AI với các nguồn dữ liệu và công cụ (kho lưu trữ, công cụ nghiệp vụ, môi trường phát triển...). MCP mang lại sự "Thay thế lẫn nhau" (Fungibility) - Giúp các client AI và server/công cụ có thể dễ dàng tương thích và thay thế lẫn nhau nếu chúng cùng tuân thủ MCP. Nó chuẩn hóa các hoạt động:

• Chia sẻ thông tin ngữ cảnh với các mô hình ngôn ngữ.
• "Trình bày" (expose) các công cụ và khả năng cho hệ thống AI.
• Xây dựng các tích hợp và quy trình làm việc có thể kết hợp (composable).

MCP hoạt động như thế nào?

Nền tảng

Sử dụng định dạng thông điệp JSON-RPC 2.0. Đây là một giao thức gọi thủ tục từ xa (Remote Procedure Call) nhẹ và phổ biến.

Bao gồm các thành phần:

• Hosts: Các ứng dụng LLM khởi tạo kết nối (ví dụ: trình soạn thảo code có tích hợp AI, chatbot...).
• Clients: Các trình kết nối (connectors) nằm bên trong Host, chịu trách nhiệm giao tiếp qua MCP.
• Servers: Các dịch vụ cung cấp ngữ cảnh hoặc khả năng/công cụ (ví dụ: dịch vụ tìm kiếm vector, API nghiệp vụ, máy phân tích mã...).

Mô hình kiến trúc tổng thể

• Ba thành phần chính: Host, Client, và Server.
  • Hosts: Các ứng dụng LLM khởi tạo kết nối (ví dụ: trình soạn thảo code có tích hợp AI, chatbot...).
  • Clients: Các trình kết nối (connectors) nằm bên trong Host, chịu trách nhiệm giao tiếp qua MCP.
  • Servers: Các dịch vụ cung cấp ngữ cảnh hoặc khả năng/công cụ (ví dụ: dịch vụ tìm kiếm vector, API nghiệp vụ, máy phân tích mã...).
• Mối quan hệ:
  • Một Host có thể quản lý và chạy nhiều thực thể (instances) Client.
  • Mỗi Client duy trì một kết nối 1:1 và trạng thái (stateful) với một Server cụ thể.
• Nền tảng Giao thức:
  • MCP được xây dựng dựa trên JSON-RPC 2.0, cung cấp một giao thức phiên (session protocol) có trạng thái, tập trung vào việc trao đổi ngữ cảnh (context exchange) và điều phối lấy mẫu (sampling coordination) giữa Client và Server.

Vai trò và trách nhiệm của từng thành phần

• Host (Tiến trình Chủ / Bộ chứa):

  • Vai trò: Đóng vai trò là "vỏ bọc" hoặc bộ điều phối chính của ứng dụng LLM (ví dụ: IDE, ứng dụng chatbot, môi trường phát triển tích hợp AI).
  • Trách nhiệm chính:
    • Tạo và quản lý vòng đời của nhiều thực thể Client.
    • Kiểm soát quyền kết nối của Client đến các Server.
    • Thực thi các chính sách bảo mật và yêu cầu sự đồng ý (consent) từ người dùng.
    • Xử lý các quyết định ủy quyền (authorization) của người dùng.
    • Điều phối việc tích hợp và lấy mẫu (sampling) từ AI/LLM. (Đây là điểm quan trọng, Host đóng vai trò điều phối tổng thể).
    • Quản lý việc tổng hợp ngữ cảnh (context aggregation) từ nhiều Client/Server khác nhau.

• Client (Trình kết nối / Đại diện AI):

  • Vai trò: Là một trình kết nối (connector) được tạo và quản lý bên trong Host. Nó đại diện cho logic của ứng dụng AI hoặc agent cần truy cập ngữ cảnh hoặc công cụ từ bên ngoài. Các ví dụ được đưa ra bao gồm ứng dụng của Anthropic, Cursor, Windsurf, agent Goose.
  • Trách nhiệm chính:
    • Thiết lập và duy trì một phiên kết nối có trạng thái (stateful session) duy nhất với một Server cụ thể.
    • Xử lý việc "thương lượng" giao thức và trao đổi khả năng (capabilities) với Server.
    • Định tuyến (route) các thông điệp giao thức MCP hai chiều giữa Host và Server.
    • Quản lý các đăng ký (subscriptions) và thông báo (notifications) từ Server.
    • Duy trì ranh giới bảo mật giữa các kết nối Server khác nhau mà nó quản lý.
    • Chủ động gọi (invoke) các công cụ (tools) được Server cung cấp. Quyết định này thường được đưa ra bởi mô hình ngôn ngữ (LLM) nằm bên trong ứng dụng Client/Host.
    • Truy vấn (query) các tài nguyên (resources) mà Server cung cấp. Client có quyền kiểm soát cách sử dụng dữ liệu tài nguyên này.
    • Nội suy (interpolate) các prompts được Server định nghĩa sẵn (người dùng thường kích hoạt thông qua Client).

• Server (Nhà cung cấp Ngữ cảnh/Công cụ):

  • Vai trò: Cung cấp ngữ cảnh và các khả năng/công cụ chuyên biệt. Nó hoạt động như một lớp bao bọc (wrapper) hoặc trung gian (intermediary), cung cấp một giao diện MCP chuẩn hóa để truy cập vào các hệ thống phức tạp bên dưới (ví dụ: cơ sở dữ liệu, CRM Salesforce, hệ thống file cục bộ, Git, Vector DB).
  • Trách nhiệm chính:
    • "Trình bày" (expose) các khả năng của mình dưới dạng các nguyên tắc cơ bản (primitives) của MCP: Tài nguyên (Resources), Công cụ (Tools), và Prompts.
    • Hoạt động độc lập, tập trung vào nhiệm vụ chuyên biệt của nó.
    • Yêu cầu việc lấy mẫu (request sampling) thông qua giao diện của Client (ví dụ: yêu cầu Host/Client chạy LLM để lấy kết quả nào đó).
    • Phải tuân thủ các ràng buộc bảo mật do Host đặt ra.
    • Có thể là một tiến trình cục bộ (local process) hoặc một dịch vụ từ xa (remote service).
    • Người xây dựng Server có nhiệm vụ đóng gói và trình bày các khả năng này theo chuẩn MCP để bất kỳ Client tương thích nào cũng có thể sử dụng.

Vai trò của Giao thức MCP

• Đóng vai trò là lớp giao tiếp (communication layer) giữa Client và Server (dưới sự quản lý của Host).
• Chuẩn hóa cách các yêu cầu và phản hồi được cấu trúc và trao đổi, đặc biệt là liên quan đến ngữ cảnh và việc sử dụng công cụ/tài nguyên.
• Là một giao thức có trạng thái (stateful), cho phép duy trì ngữ cảnh phiên làm việc giữa Client và Server.
• Hỗ trợ điều phối lấy mẫu (sampling coordination), cho phép Server yêu cầu Client/Host thực hiện các tác vụ liên quan đến LLM.

Ví dụ thực tế

Hãy hình dung một chatbot RAG cho phép người dùng hỏi về các tài liệu nội bộ của công ty. Các thành phần của chatbot này có thể được ánh xạ vào kiến trúc MCP như sau:

1. Host:

   • Đây chính là ứng dụng chatbot tổng thể mà người dùng tương tác (có thể là giao diện web, ứng dụng desktop, hoặc tích hợp trong Slack/Teams) kết hợp với phần backend logic chính (orchestrator) của nó.
   • Trách nhiệm của Host:
     • Nhận tin nhắn từ người dùng qua giao diện.
     • Điều phối luồng RAG: quyết định khi nào cần truy xuất thông tin, khi nào cần gọi LLM.
     • Tạo và quản lý các Client cần thiết (ví dụ: Client để nói chuyện với Vector DB).
     • Thực thi các chính sách bảo mật, quản lý phiên làm việc của người dùng.
     • Tích hợp và gọi LLM chính để tạo ra câu trả lời cuối cùng (LLM này thường là một phần cốt lõi của Host hoặc được Client gọi theo sự điều phối của Host).
     • Tổng hợp ngữ cảnh từ nhiều nguồn (nếu chatbot phức tạp, ví dụ: kết hợp kết quả RAG với lịch sử chat và thông tin người dùng).
     • Hiển thị câu trả lời cuối cùng cho người dùng.

2. Client:

   • Bên trong ứng dụng Host, sẽ có (ít nhất) một module hoặc trình kết nối đóng vai trò Client để giao tiếp với hệ thống truy xuất dữ liệu.
   • Ví dụ: RetrievalClient (Client Truy xuất):
     • Module này được Host tạo ra và quản lý.
     • Nó thiết lập một phiên kết nối MCP (stateful) với VectorDBServer (xem bên dưới).
     • Khi Host quyết định cần truy xuất thông tin cho câu hỏi của người dùng, nó sẽ yêu cầu RetrievalClient.
     • RetrievalClient sẽ gửi yêu cầu truy vấn (ví dụ: tìm kiếm các đoạn tài liệu liên quan) đến VectorDBServer thông qua giao thức MCP (sử dụng JSON-RPC). Yêu cầu này có thể là truy vấn một "Resource" mà Server cung cấp.
     • Nó nhận kết quả (danh sách các đoạn tài liệu liên quan) từ VectorDBServer qua MCP.
     • Nó trả kết quả này về cho Host để Host tiếp tục xử lý (ví dụ: đưa vào prompt cho LLM).
   • (Nếu chatbot cần thêm chức năng, ví dụ tra cứu thông tin nhân viên qua API nội bộ, Host có thể tạo thêm một EmployeeAPIClient khác để kết nối với một EmployeeAPIServer tương ứng qua MCP).

3. Server:

   • Đây là các thành phần cung cấp dữ liệu hoặc công cụ chuyên biệt, được "bọc" lại bằng một giao diện MCP chuẩn.
   • Ví dụ 1: VectorDBServer (Server Cơ sở dữ liệu Vector):
     • Là một dịch vụ (có thể chạy riêng) đóng gói logic truy cập vào cơ sở dữ liệu vector (nơi lưu trữ embeddings và các đoạn tài liệu).
     • Nó "trình bày" (exposes) khả năng tìm kiếm vector dưới dạng các "Resource" hoặc "Tool" theo chuẩn MCP. Ví dụ: cung cấp một Resource là "corporate_documents" mà Client có thể truy vấn.
     • RetrievalClient kết nối đến Server này.
     • Bên trong, Server này có thể sử dụng Pinecone, Weaviate, Chroma, hoặc một giải pháp vector DB khác, nhưng đối với Client, nó chỉ giao tiếp qua MCP.
   • Ví dụ 2: EmbeddingModelServer (Server Mô hình Embedding - Có thể có):
     • Nếu việc tạo embedding cho truy vấn được tách thành một dịch vụ riêng, nó cũng có thể được coi là một Server, cung cấp một "Tool" để tạo embedding qua MCP. Client sẽ gọi tool này trước khi truy vấn VectorDBServer.
   • Ví dụ 3: AuthenticationServer (Server Xác thực - Có thể có):
     • Một Server chuyên xử lý việc xác thực quyền truy cập vào các tài liệu nhạy cảm, cung cấp một "Tool" kiểm tra quyền mà VectorDBServer hoặc RetrievalClient có thể gọi.

Tóm tắt lợi ích trong ví dụ RAG Chatbot:

• Tiêu chuẩn hóa: RetrievalClient không cần biết VectorDBServer dùng công nghệ gì bên trong. Nếu công ty đổi từ Pinecone sang Weaviate, chỉ cần cập nhật VectorDBServer để vẫn tuân thủ MCP, RetrievalClient và Host không cần thay đổi (hoặc thay đổi rất ít).
• Tái sử dụng: VectorDBServer này có thể được sử dụng bởi nhiều ứng dụng/agent khác trong công ty (ví dụ: một công cụ tìm kiếm nội bộ khác, một agent tự động tóm tắt tài liệu) mà không cần viết lại logic tích hợp vector DB.
• Phân tách: Nhóm phát triển chatbot (xây dựng Host và RetrievalClient) có thể tập trung vào trải nghiệm người dùng và logic RAG, trong khi nhóm hạ tầng/dữ liệu tập trung vào việc tối ưu VectorDBServer.

Như vậy, kiến trúc Host-Client-Server của MCP giúp cấu trúc hóa hệ thống RAG chatbot một cách rõ ràng, tạo điều kiện cho việc tích hợp, bảo trì và mở rộng dễ dàng hơn.

References

• https://modelcontextprotocol.io/introduction
• https://medium.com/@nimritakoul01/the-model-context-protocol-mcp-a-complete-tutorial-a3abe8a7f4ef