Xây dựng AI agent với Model Context Protocol (MCP): Hướng dẫn thực tế cho đội vận hành

Xây dựng AI agent với Model Context Protocol (MCP) là tạo cách có kiểm soát để agent kết nối công cụ, dịch vụ và dữ liệu ngoài. MCP tách suy luận của model khỏi hệ thống nó cần truy cập, nhưng thành công khi vận hành vẫn phụ thuộc quyền hạn hẹp, logging, đánh giá, khôi phục lỗi và kiểm duyệt của con người.

Vấn đề thực tế là agent chỉ dùng prompt có thể trả lời, còn agent vận hành hữu ích cần lấy dữ liệu kho, xem log, tạo ticket hoặc kích hoạt quy trình. Mỗi năng lực mới cũng tạo ra đường lỗi mới. Nếu đội đang tìm hiểu phát triển AI agent, câu hỏi không chỉ là kết nối công cụ, mà là hành động nào được phép, khi nào cần kiểm duyệt và cách khôi phục sự cố.

Bối cảnh công cụ và độ phù hợp

Không đánh giá MCP một cách tách rời. Hãy so sánh LangGraph, LangChain, CrewAI, function calling gốc và MCP dựa trên nhu cầu workflow, orchestration và kiểm soát runtime.

Điểm chính

• MCP là giao thức tích hợp, không phải framework agent hoàn chỉnh.
• Quy trình an toàn tách truy xuất, hành động và kiểm duyệt.
• Ghi mọi lần gọi công cụ, input, output, quyết định model, quyết định kiểm duyệt và hành động khôi phục.
• Dùng SDK hoặc framework khi chúng giảm việc orchestration; xây MCP server tùy chỉnh khi cần ranh giới bền vững với hệ thống nội bộ.
• Kiểm duyệt con người quan trọng nhất với hành động khó đảo ngược, tốn kém, hiển thị với khách hàng, nhạy cảm tuân thủ hoặc độ tin cậy thấp.

Xây dựng AI agent với Model Context Protocol (MCP) là gì?

MCP cho agent cách khám phá và dùng năng lực ngoài qua MCP client và server. Tài liệu MCP chính thức mô tả đây là giao thức chung kết nối ứng dụng AI với công cụ và dữ liệu.

Thay vì hard-code mọi tra cứu database, API, đọc file hay bước tự động hóa, đội ngũ đưa năng lực đó vào MCP server. Ví dụ, trợ lý dữ liệu nội bộ có thể lấy trạng thái job, đọc log liên quan, tóm tắt nguyên nhân và chuyển người kiểm duyệt khi độ tin cậy thấp.

Các khối thành phần cốt lõi

• Ứng dụng agent: nhận yêu cầu, gọi model, quản lý trạng thái và phản hồi.
• MCP client: kết nối ứng dụng agent với MCP server.
• MCP server: cung cấp tool, resource hoặc prompt.
• Tool: hành động như truy vấn bảng, kiểm tra log, tạo ticket hoặc gọi API nội bộ.
• Resource: ngữ cảnh như tài liệu, schema, file, log hoặc bản ghi.
• Transport: cách client và server trao đổi dữ liệu.

Vì sao MCP quan trọng với quy trình AI agent

Nhiều agent có thể suy luận nhưng không truy cập được an toàn hệ thống nơi công việc diễn ra. MCP làm ranh giới tích hợp rõ ràng hơn: agent được đọc gì, hành động nào tự động được, tool nào cần phê duyệt, cuộc gọi chạy ở đâu, log gì và khôi phục lỗi thế nào.

Agent vận hành tốt không được đánh giá bằng số tool có thể gọi, mà bằng khả năng tạo kết quả hữu ích lặp lại với rủi ro dễ hiểu.

MCP hoạt động thế nào: kiến trúc vận hành thực tế

flowchart LR
 A[Yêu cầu người dùng] --> B[Ứng dụng agent]
 B --> C[Suy luận model]
 C --> D[MCP client]
 D --> E[MCP server]
 E --> F[Công cụ, nguồn dữ liệu hoặc dịch vụ]
 F --> E
 E --> D
 D --> C
 C --> G{Kiểm tra rủi ro}
 G -->|Rủi ro thấp| H[Phản hồi cuối]
 G -->|Cần kiểm duyệt| I[Hàng đợi kiểm duyệt]
 I --> J[Phê duyệt, sửa, từ chối hoặc chuyển cấp]

Tài liệu MCP của OpenAI Agents SDK và hướng dẫn Azure MCP là tài liệu hữu ích về tích hợp SDK và môi trường cloud. Câu hỏi vận hành là: cuộc gọi chạy ở đâu, ai được phê duyệt, cách kiểm tra sau này và điều gì xảy ra khi nó lỗi?

| Thành phần | Vai trò | Câu hỏi vận hành | Lỗi chính | Checkpoint | | -------------- | -------------------------------- | ------------------------------------------- | ------------------------------ | --------------------------- | | Ứng dụng agent | Sở hữu workflow và gọi model | Nó áp dụng state và chính sách nào? | Hành động ngoài luồng dự kiến | Rà soát chính sách workflow | | MCP client | Kết nối server | Server nào được phép? | Tool hoặc server sai khả dụng | Allowlist kết nối | | MCP server | Cung cấp tool và resource | Bộ năng lực nhỏ nhất an toàn là gì? | Truy cập nội bộ quá rộng | Rà soát phạm vi tool | | Tool | Thực hiện hành động hoặc tra cứu | Chỉ đọc, có thể đảo ngược hay tác động lớn? | Input xấu gây kết quả sai | Phê duyệt theo rủi ro | | Resource | Cung cấp ngữ cảnh | Dữ liệu hiện tại, được phép và liên quan? | Dùng ngữ cảnh cũ hoặc nhạy cảm | Rà soát truy cập dữ liệu | | Transport | Chuyển thông điệp | Ranh giới mạng, hosting nào áp dụng? | Dịch vụ không tới được hoặc lộ | Rà soát triển khai | | Log | Ghi thực thi | Có tái dựng quyết định được không? | Không gỡ lỗi được sự cố | Rà soát quan sát |

Cách bắt đầu xây MCP agent

1. Xác định workflow và hành động được phép

Viết công việc theo thuật ngữ vận hành: kiểm tra import hằng ngày, lấy đoạn log, tóm tắt nguyên nhân và tạo bản nháp incident. Phân loại hành động thành chỉ đọc, chỉ nháp, nội bộ có thể đảo ngược, nội bộ không thể đảo ngược, hiển thị khách hàng và nhạy cảm tuân thủ. Xem hướng dẫn AI agent với kiểm duyệt của con người để đặt checkpoint từ đầu.

2. Chọn ranh giới nguồn dữ liệu hoặc hệ thống

Chỉ cấp truy cập mà agent thực sự cần. Agent pipeline thường cần trạng thái, log, schema và lịch sử incident, không cần quyền ghi vào job production. Với ngữ cảnh gần thời gian thực, kiến trúc dữ liệu bên dưới phải đủ mới và đầy đủ. Xem kiến trúc hướng sự kiện với message queue.

3. Chọn mô hình xây dựng

| Mô hình | Phù hợp nhất | Điểm mạnh | Hạn chế | | -------------------------- | ------------------------------------ | ---------------------------- | ---------------------------- | | Tích hợp SDK nền tảng | Đội đã xây trên nền tảng AI cụ thể | Khởi động nhanh | Nền tảng định hình kiến trúc | | Framework agent | Cần orchestration, memory, routing | Giảm code workflow tùy chỉnh | Có thể che điểm lỗi | | MCP server tùy chỉnh | Hệ thống nội bộ cần ranh giới nghiêm | Kiểm soát truy cập rõ | Tốn công kỹ thuật ban đầu | | Stack nhà cung cấp quản lý | Ưu tiên tốc độ và hỗ trợ | Hosting, vận hành đóng gói | Ít kiểm soát nội bộ |

Framework như mcp-agent của lastmile-ai có ích khi orchestration là phần khó, nhưng không thay thế quyết định về quyền truy cập, kiểm duyệt và trách nhiệm.

4. Chỉ cung cấp bộ tool nhỏ nhất hữu ích

Tool nên có tên rõ, input hẹp và output dự đoán được. Với trợ lý pipeline, bắt đầu bằng get_pipeline_status, get_recent_failed_runs, fetch_log_excerpt và create_incident_draft. Tránh run_sql_anywhere, call_internal_api hoặc modify_pipeline_config khi chưa có phân quyền và checkpoint mạnh.

5. Thêm logging, quyền và kiểm duyệt

Ghi yêu cầu người dùng, tool được chọn, input, output, tóm tắt quyết định, phản hồi cuối, quyết định người kiểm duyệt và hành động khôi phục. Đặt ngân sách token theo lượt chạy, timeout, fallback và đường chuyển cấp.

6. Kiểm thử yêu cầu bình thường, mơ hồ và không an toàn

Kiểm thử ngày thiếu, không có bản ghi, log chứa dữ liệu nhạy cảm, model gọi tool ghi trước kiểm duyệt, nguồn mâu thuẫn và dịch vụ timeout. Mục tiêu là lỗi dễ thấy, được cô lập và có thể khôi phục.

Thực hành tốt khi xây AI agent với MCP

Giữ phạm vi tool hẹp

lookup_customer_contract_status an toàn hơn query_crm vì mô tả một nhiệm vụ kinh doanh cụ thể thay vì mời model ứng biến.

Tách truy xuất, hành động và kiểm duyệt

Hãy tách ngữ cảnh, quyết định và hành động. Tự động hóa web có thể đọc trang, trích xuất dữ liệu và soạn đề xuất; thay đổi hiển thị với khách hàng, gửi form hoặc gửi tin nhắn phải cần phê duyệt. Xem công việc tự động hóa web vận hành thực tế.

Xem MCP server là bề mặt tích hợp vận hành

Khi chạm hệ thống nội bộ, MCP server cần versioning, phân quyền, chủ sở hữu triển khai, giám sát và rollback như API nội bộ. Xác định service account, môi trường, dữ liệu trả về và xử lý thay đổi gây vỡ.

Đánh giá bằng trường hợp workflow thật

| Khu vực đánh giá | Cần kiểm tra | Tín hiệu vận hành | | ----------------- | ----------------------------- | ----------------------------------- | | Hoàn thành tác vụ | Agent có kết thúc workflow? | Kết quả đúng hoặc chuyển cấp rõ | | Chọn tool | Có chọn đúng MCP tool? | Không có hành động thừa | | Dùng ngữ cảnh | Có dựa dữ liệu đúng? | Tóm tắt chính xác, có nguồn | | An toàn | Có tránh hành động trái phép? | Kích hoạt kiểm duyệt khi cần | | Chi phí | Có dùng ngữ cảnh hiệu quả? | Không gọi tool hoặc prompt phình to | | Độ trễ | Workflow có dùng được? | Timeout và fallback dễ dự đoán | | Khôi phục | Lỗi có được cô lập? | Có retry, rollback hoặc chuyển cấp |

Thiết kế theo gánh nặng kiểm duyệt

Kiểm duyệt theo rủi ro là điểm cân bằng thực tế: kiểm duyệt hành động khó đảo ngược, thay đổi hiển thị khách hàng, câu trả lời độ tin cậy thấp và output có dữ liệu nhạy cảm; cho phép tóm tắt chỉ đọc rủi ro thấp qua khi đạt ngưỡng đánh giá.

Mẫu artifact triển khai thực tế

def run_reviewed_step(state, tool):
    if state.risk == "high":
        return {"status": "needs_review", "reason": "risk gate"}
    result = tool(**state.allowed_args)
    if not result.get("evidence"):
        return {"status": "needs_review", "reason": "missing evidence"}
    return {"status": "ready", "result": result}

Artifact này giúp kỹ thuật, vận hành và chủ sở hữu kiểm duyệt thống nhất ranh giới trước khi xây server.

Các lỗi thường gặp cần tránh

Đừng xem MCP là framework agent hoàn chỉnh, mở quá nhiều tool quá sớm hoặc bỏ ranh giới quyền hạn chỉ vì bản mẫu chạy được. Xác định vị trí thực thi vì nó ảnh hưởng độ trễ, secret, mạng, log và ứng phó sự cố. Đừng tuyên bố về độ chính xác, hiệu quả hay chi phí trước khi đo dữ liệu workflow thực.

Kết luận

MCP là cách thực tế để kết nối agent với tool và dữ liệu cần thiết, nhưng giao thức chỉ là một phần của sự sẵn sàng vận hành. Hãy bắt đầu với một workflow, xác định hành động được phép, xây bề mặt MCP nhỏ nhất hữu ích, thêm quan sát trước khi ra mắt, kiểm thử trường hợp bình thường lẫn không an toàn và đặt kiểm duyệt nơi rủi ro cao.

Van Data Team hỗ trợ hàng rào và chuyển cấp cho agent, tích hợp dữ liệu, thiết kế kiểm duyệt và lập kế hoạch triển khai. Xem Strategy Sprint và các lựa chọn hợp tác khi sẵn sàng xác định phạm vi trường hợp dùng đầu tiên.