Giới thiệu

Model Context Protocol, hay MCP, là một giao thức mở để kết nối các ứng dụng AI với các nguồn context và capability có thể thực thi bên ngoài. Một ứng dụng có thể sử dụng MCP để truy cập tệp, truy vấn một dịch vụ, gọi business logic hoặc tái sử dụng một prompt template thông qua mô hình tương tác nhất quán. Ý tưởng quan trọng là sự phân tách: ứng dụng điều phối cuộc hội thoại, còn MCP server cung cấp một interface được kiểm soát tới dữ liệu hoặc các tác vụ.

Sự phân tách này quan trọng vì các ứng dụng AI thường cần nhiều tích hợp. Nếu không có một giao thức dùng chung, mỗi ứng dụng phải tự định nghĩa định dạng connector, cơ chế discovery, luồng authentication và schema của tool cho từng dịch vụ. MCP cung cấp một contract chung cho host và server, giúp giảm lượng code dành riêng cho từng tích hợp và làm cho các capability dễ kiểm tra hơn. Bản thân MCP không làm cho mô hình ngôn ngữ trở nên chính xác hơn, không thay thế hệ thống authorization và cũng không đảm bảo rằng một thao tác bên ngoài là an toàn.

Một mental model hữu ích là một cầu nối được kiểm soát. Mô hình đề xuất rằng một capability có thể hữu ích, host quyết định request đó có được phép hay không, MCP client gửi một protocol request, còn server thực hiện hoặc từ chối thao tác. Sau đó, kết quả quay lại qua client đến host; host quyết định cách trình bày kết quả cho mô hình và người dùng.

Kiến trúc cốt lõi

MCP host là toàn bộ ứng dụng AI mà người dùng tương tác. Một trợ lý desktop, môi trường lập trình hoặc dịch vụ agent tùy chỉnh đều có thể đóng vai trò là host. Host chịu trách nhiệm về luồng hội thoại và thường quyết định server nào được cấu hình, quyền nào được áp dụng, kết quả của tool được đưa vào context của mô hình như thế nào và liệu người dùng có phải phê duyệt một thao tác hay không.

MCP client là thành phần protocol do host quản lý. Trong một kiến trúc phổ biến, host tạo một kết nối client cho mỗi MCP server. Client xử lý việc giao tiếp theo protocol, khởi tạo, thương lượng capability, đối chiếu request, notification và các chi tiết riêng của transport. Client không phải là mô hình ngôn ngữ và cũng không phải là phần triển khai server; đây là lớp kết nối giữa host và một server.

MCP server là một chương trình cung cấp các capability thông qua MCP. Tùy thuộc vào cách triển khai và khả năng hỗ trợ của client, server có thể chạy cục bộ dưới dạng subprocess hoặc chạy từ xa phía sau một network transport. Server có thể đọc từ một nguồn dữ liệu được phê duyệt, gọi một dịch vụ bên ngoài hoặc triển khai domain logic. Server nên cung cấp một interface rõ ràng, có phạm vi hẹp và tự thực hiện validation thay vì giả định rằng host hoặc mô hình đã kiểm tra mọi input.

Mô hình thường không trực tiếp mở các kết nối mạng thô đến máy chủ. Thay vào đó, host cung cấp các khả năng được phát hiện thông qua MCP và đưa các kết quả liên quan vào tương tác với mô hình. Ranh giới này cải thiện khả năng kiểm soát và quan sát, vì host có thể ghi nhật ký yêu cầu, yêu cầu xác nhận, áp dụng chính sách và xử lý lỗi trước khi một hành động bên ngoài diễn ra.

Luồng giao thức

Một phiên MCP bắt đầu bằng bước khởi tạo. Client và server xác định thông tin giao thức, đồng thời trao đổi các capability mô tả những tính năng mà mỗi bên hỗ trợ. Client phải hoàn tất bước này trong vòng đời trước khi sử dụng các tính năng thông thường của server. Client cũng nên xử lý khả năng server không hỗ trợ một capability tùy chọn, thay vì giả định rằng mọi server đều triển khai mọi tính năng.

Sau khi khởi tạo, client có thể khám phá các tính năng của server. Tool mô tả những thao tác có thể được gọi bằng các đầu vào có cấu trúc, chẳng hạn như tìm kiếm trong hệ thống theo dõi issue hoặc tạo một sự kiện lịch. Resource đại diện cho dữ liệu có thể được đọc làm ngữ cảnh, chẳng hạn như một tài liệu hoặc kết quả cơ sở dữ liệu. Prompt đại diện cho các cấu trúc thông điệp hoặc quy trình làm việc có thể tái sử dụng mà server cung cấp cho host. Các nhóm này có mục đích khác nhau và không nên được xem là những nhãn có thể thay thế lẫn nhau.

Một luồng tool điển hình gồm nhiều giai đoạn. Host cung cấp định nghĩa tool cho mô hình, mô hình đề xuất một lệnh gọi kèm các tham số, còn host đánh giá chính sách và sự đồng ý của người dùng. Nếu được phê duyệt, client gửi yêu cầu đến server. Server xác thực các tham số, thực hiện thao tác nếu được phép, rồi trả về kết quả hoặc lỗi. Sau đó, host quyết định có nên hiển thị kết quả cho người dùng, gửi kết quả trở lại mô hình hay thực hiện cả hai.

Thông điệp MCP sử dụng một giao thức có cấu trúc dựa trên các khái niệm của JSON-RPC, vì vậy request, result, error và notification đều có vai trò được định nghĩa. Cơ chế vận chuyển cụ thể được tách biệt khỏi ý nghĩa của thông điệp. Các tích hợp cục bộ thường sử dụng kết nối dựa trên tiến trình, chẳng hạn như đầu vào và đầu ra tiêu chuẩn, trong khi các tích hợp từ xa có thể sử dụng cơ chế vận chuyển dựa trên HTTP được implementation hỗ trợ. Cơ chế vận chuyển chỉ truyền thông điệp; nó không quyết định một hành động có được cấp quyền hay không.

Kịch bản tích hợp thực tế

Hãy xem xét một trợ lý hỗ trợ nội bộ được kết nối với hai server. Một server quản lý ticket cung cấp một tool để tìm kiếm ticket và một tool để thêm ghi chú nội bộ. Một server tài liệu cung cấp các resource chứa những trang hướng dẫn khắc phục sự cố đã được phê duyệt. Host kết nối với cả hai server thông qua các client MCP riêng biệt và khám phá capability của chúng trong quá trình khởi động.

Khi một kỹ sư hỗ trợ hỏi về nguyên nhân có khả năng xảy ra của một lỗi đã biết, host có thể cho phép mô hình sử dụng tool tìm kiếm ticket và các resource tài liệu. Kết quả tìm kiếm có thể xác định những sự cố liên quan, trong khi resource tài liệu cung cấp ngữ cảnh kỹ thuật đã được phê duyệt. Host có thể trình bày cả hai kết quả cho mô hình cùng với thông tin nguồn, giúp mô hình soạn câu trả lời dựa trên dữ liệu hiện có.

Nếu kỹ sư yêu cầu trợ lý thêm ghi chú vào một ticket, quy trình sẽ thay đổi vì thao tác này tạo ra tác động bên ngoài. Host nên hiển thị ticket đích và ghi chú được đề xuất, xác minh rằng người dùng có quyền, đồng thời yêu cầu xác nhận khi phù hợp. Server vẫn phải xác thực mã định danh ticket, độ dài ghi chú và ngữ cảnh cấp quyền. Việc một lớp đã phê duyệt không làm mất trách nhiệm xác thực của các lớp còn lại.

Các bài kiểm thử hữu ích nhất bao quát toàn bộ ranh giới tích hợp, không chỉ câu trả lời cuối cùng. Hãy xác minh rằng quá trình khởi tạo thành công, các capability không được hỗ trợ được xử lý đúng, tham số không hợp lệ tạo ra lỗi có kiểm soát, thao tác bị từ chối không làm thay đổi trạng thái bên ngoài và timeout của server không khiến host hiển thị thông báo thành công giả tạo. Những bài kiểm thử này làm cho hành vi tích hợp trở nên rõ ràng và dễ chẩn đoán hơn.

Các dạng lỗi thường gặp

Một lỗi thường gặp là nhầm lẫn MCP với một framework tác nhân tự chủ. MCP định nghĩa cách thức giao tiếp và cung cấp khả năng; MCP không quy định một thuật toán lập kế hoạch, nhà cung cấp mô hình, hệ thống bộ nhớ hay giao diện người dùng cụ thể nào. Một tác nhân có thể sử dụng MCP, nhưng vòng lặp của tác nhân vẫn là một quyết định trong thiết kế ứng dụng. Một lỗi khác là coi mọi tính năng của server đều là tool, điều này có thể khuyến khích thực hiện các hành động không cần thiết trong khi resource chỉ-đọc sẽ phù hợp hơn.

Các sự cố bảo mật thường bắt nguồn từ việc tin tưởng quá mức. Mô tả tool là metadata hữu ích, nhưng không phải là một ranh giới bảo mật hoàn chỉnh. Hãy xác thực đầu vào trên server, hạn chế quyền truy cập tệp và mạng, bảo vệ thông tin xác thực, đồng thời áp dụng cơ chế ủy quyền tại ranh giới thao tác. Tránh cung cấp một tool thực thi lệnh tổng quát khi một thao tác nhỏ, dành riêng cho miền nghiệp vụ, đã có thể đáp ứng trường hợp sử dụng.

Các sự cố vận hành thường liên quan đến việc xử lý vòng đời và transport. Client có thể gửi yêu cầu trước khi khởi tạo, giả định rằng một capability tồn tại, mất kết nối mà không xóa trạng thái, hoặc coi timeout là kết quả thành công. Hãy ghi log danh tính server, loại yêu cầu, thông tin tương quan, thời lượng và chi tiết lỗi đã được loại bỏ dữ liệu nhạy cảm. Không ghi log token, mật khẩu hoặc nội dung nhạy cảm của người dùng chỉ để đơn giản hóa việc gỡ lỗi.

Một lỗi khác là cho phép kết quả của tool đi vào context của model mà không kiểm tra nguồn gốc hoặc mức độ liên quan. Nội dung bên ngoài có thể chứa các chỉ dẫn gây hiểu lầm hoặc dữ liệu không an toàn khi lặp lại. Host cần duy trì ranh giới rõ ràng giữa chỉ dẫn, dữ liệu được truy xuất và các hành động đã được người dùng phê duyệt, đồng thời ứng dụng phải xác định cách xử lý nội dung không đáng tin cậy.

Tóm tắt

MCP cung cấp một phương thức tiêu chuẩn để các ứng dụng AI kết nối model với context và capability bên ngoài. Host chịu trách nhiệm về trải nghiệm ứng dụng và các quyết định chính sách, client quản lý kết nối theo protocol, còn server cung cấp dữ liệu hoặc thao tác đã được xác thực. Việc phân tách rõ ràng các trách nhiệm này giúp các tích hợp dễ phân tích và kiểm thử hơn.

Quy trình cốt lõi gồm khởi tạo, thương lượng capability, khám phá, gọi hoặc truy xuất có kiểm soát, và xử lý kết quả. Tool phù hợp với các thao tác có thể gọi, resource phù hợp với dữ liệu ngữ cảnh, còn prompt phù hợp với các mẫu tương tác có thể tái sử dụng. Protocol có thể truyền message qua nhiều transport khác nhau, nhưng việc lựa chọn transport không thay thế cho xác thực, ủy quyền, kiểm tra hợp lệ hay khả năng quan sát hệ thống.

Khi thiết kế một tích hợp MCP, hãy bắt đầu với interface server nhỏ nhất nhưng hữu ích. Xác định những gì server cung cấp, nhận diện các thao tác có tác dụng phụ, quyết định nơi cần sự đồng ý và quy định cách xử lý lỗi trước khi kết nối model. Một ứng dụng đáng tin cậy coi đầu ra của model là đề xuất, thực thi chính sách tại host và server, đồng thời xác minh các kết quả bên ngoài trước khi thông báo thành công.