Kiểm soát Thực thi & Reviewability (Gói nhỏ & Conditional LGTM)

Xem MCP như một bề mặt tích hợp trong môi trường production

MCP cho phép một server mở ra các tool hoặc tài nguyên cho nhiều client tương thích, nhưng sự tương thích về giao thức không tạo ra tính sẵn sàng cho môi trường production. Mỗi MCP server đều trở thành một phần trong ranh giới thẩm quyền và ngữ cảnh của sản phẩm.

Theo dõi một lượt gọi ở cả client lẫn server

Vòng đời cơ bản gồm hai nửa. Server công bố tool có kiểu dữ liệu và xác thực từng lượt gọi, gồm cả quy tắc đọc/ghi, chẳng hạn chỉ cho phép SELECT với tool truy vấn. Client khởi chạy hoặc kết nối server, tạo phiên, khám phá tool, chọn tool, gửi argument hợp lệ theo schema và nhận nội dung có cấu trúc. Khám phá không phải phân quyền: server vẫn phải thực thi danh tính, phạm vi tài nguyên, xác thực đầu vào và chính sách ghi ở mọi lượt gọi. Kiểm tra tiền tố chuỗi SELECT chỉ là ví dụ giảng dạy, không phải ranh giới bảo mật SQL cho production; hãy dùng thao tác có tham số, chuyên biệt theo mục đích và phân quyền cơ sở dữ liệu.

Theo sales agent qua vòng đời ấy. Server khởi động và công bố get_account_evidence(account_id) cùng propose_crm_update(account_id, fields, evidence). Client kết nối qua transport đã chọn, khởi tạo và liệt kê các schema. Model chọn tool đọc, gửi ID tài khoản; trước khi thực thi, server kiểm tra danh tính người gọi và phạm vi tài khoản, sau đó trả về bằng chứng có cấu trúc kèm thông tin nguồn gốc. Về sau model có thể gọi tool lập bản nháp, nhưng server vẫn bắt buộc ở chế độ “chỉ đề xuất”, dù năng lực đó đã được công bố. Nếu kết nối ngắt sau một cập nhật đề xuất, correlation ID và quy tắc idempotency sẽ cho client biết nên tiếp tục, thử lại hay hiển thị trạng thái chưa xác định.

Sự phân tách này quan trọng vì sự thành công của client và độ an toàn của server là hai tuyên bố khác nhau. Một client có thể khám phá đúng schema nhưng vẫn gửi đi các argument sai định dạng hoặc chưa được phân quyền. Một server có thể thực thi chính sách chính xác trong khi client xử lý sai thời gian chờ và gửi lặp lại một yêu cầu. PM vì thế cần bằng chứng từ cả hai phía: sự tương thích trong việc bắt tay và schema, phân quyền trên mỗi lệnh gọi, nguồn gốc của kết quả, dữ liệu trace về việc hủy bỏ và thử lại, cùng trạng thái lỗi hiển thị cho người dùng.

Đối với mỗi server, hãy định nghĩa:

• Hợp đồng (Contract): Tên tool, đầu vào và đầu ra có kiểu dữ liệu, ngữ nghĩa lỗi, phiên bản schema và chính sách ngưng hỗ trợ.
• Danh tính & phân quyền: Danh tính người dùng và agent nào tới được server, tài nguyên nào được lọc, và quyền hạn có được kiểm tra lại khi thực thi hay không.
• Truyền tải & triển khai: Transport stdio cục bộ hay từ xa, mã hóa, xác thực, kết nối mạng đi ra, tính đa người dùng (tenancy) và lưu trữ dữ liệu.
• Độ tin cậy: timeout, ngân sách thử lại, giới hạn tốc độ, idempotency cho thao tác ghi, hủy bỏ và cách xử lý lỗi một phần.
• Niềm tin: Văn bản trả về có được xem là dữ liệu hay không, việc tiêm lệnh và các đường dẫn không an toàn được làm sạch như thế nào, và thông tin nguồn gốc nào đi cùng câu trả lời.
• Vận hành: Chủ sở hữu, mục tiêu mức dịch vụ (SLO), log kiểm toán, phân bổ chi phí, triển khai phiên bản và công tắc tắt khẩn cấp.

Hãy thiết kế tool xoay quanh mục tiêu người dùng, thay vì primitive backend thô. propose_crm_update(account_id, fields, evidence) dễ phân quyền và đánh giá hơn execute_sql(query) chung chung. Tách riêng tool đọc, lập bản nháp và ghi chính thức; bảo đảm các lượt gọi có tính phá huỷ là idempotent khi có thể; đồng thời trả về biên nhận gồm đối tượng đích, tác động, quyết định chính sách và correlation ID.

Thẻ đánh giá mức độ sẵn sàng MCP (MCP readiness card) do PM sở hữu phải nêu rõ các hành trình được hỗ trợ, các lớp dữ liệu, các hành động được phép, các sự phê duyệt bắt buộc, mục tiêu độ trễ và tính sẵn sàng, giao diện khi thất bại và chủ sở hữu. Các chỉ số thử nghiệm bao gồm tỷ lệ thành công của tool, độ trễ p95, số lần thử lại trên mỗi tác vụ, các lỗi do schema cũ, các lần bị từ chối phân quyền, các lần bị chính sách chặn, các lần quá thời gian chờ chưa giải quyết, và các lệnh gọi ghi thiếu hóa đơn hợp lệ.

Hãy kiểm thử lỗi từ cả client và server: danh sách tool đổi giữa lúc lập kế hoạch và thực thi; thao tác ghi được thử lại sau timeout; server trả dữ liệu giống chỉ dẫn; client gửi argument sai định dạng; phân quyền đổi giữa phiên; hoặc transport kết thúc trước khi biên nhận tới. Bằng chứng gồm test hợp đồng, khả năng tương thích schema, idempotency key, dấu vết hủy bỏ, quyết định phân quyền và correlation ID có thể phát lại.