Model Context Protocol (MCP) cho AI Agent vận hành: Kiến trúc kết nối CRM, tri thức và workflow mà không trao quyền vô hạn cho mô hình

MCP thực sự thay đổi điều gì trong kiến trúc AI Agent

Trong giai đoạn chatbot, luồng tích hợp thường là từng model gọi từng API tự viết. Mỗi team định nghĩa tool schema, auth, retry và cách đưa dữ liệu vào context theo cách riêng. Khi số hệ thống tăng từ một CRM lên inbox đa kênh, lịch hẹn, kho tri thức, báo giá, ERP và analytics, chi phí không còn nằm ở một API call. Chi phí nằm ở việc bảo đảm agent hiểu đúng tool nào được dùng, đúng danh tính nào, đúng scope dữ liệu nào và làm gì khi action chỉ thành công một phần.

Model Context Protocol (MCP) là một giao thức mở để chuẩn hóa kết nối giữa AI application, host và server cung cấp context hoặc tool. Ở mức khái niệm, client kết nối tới server, khám phá capability và gọi operation theo schema. Đây là bước tiến quan trọng về khả năng liên vận, tương tự việc API contract giúp application không cần biết nội bộ từng service. Nhưng MCP không biến một agent thành nhân viên đáng tin cậy. Protocol chỉ mô tả đường giao tiếp. Quyền, policy, dữ liệu nhạy cảm, transaction và trách nhiệm vẫn phải được kiến trúc ở các lớp riêng.

Điểm nóng của MCP vì vậy không phải “AI có thêm tool”. Nó buộc CTO và Solution Architect trả lời sớm hơn các câu hỏi vốn thường bị để lại sau demo: server nào được tin cậy, tool nào là read-only, principal nào đang thực sự được ủy quyền, kết quả tool có phải dữ liệu không đáng tin, action nào cần khách xác nhận và làm sao truy vết một thay đổi từ prompt tới CRM. Với hệ sinh thái vận hành như inbox, Voice AI, RAG và Bee CRM, đây là câu hỏi nền tảng.

Lớp 1. Mô hình thành phần: host, client, server và các control plane bị thiếu trong demo

Một kiến trúc MCP tối thiểu có ba vai trò. Host là ứng dụng AI nơi người dùng tương tác. Client là thành phần trong host quản lý một kết nối tới server. Server công bố capability như resource, prompt hoặc tool. Với production enterprise, ba vai trò này vẫn chưa đủ. Cần thêm identity provider, policy decision point, secret broker, audit store, workflow engine và telemetry pipeline. Bỏ các lớp đó, agent chỉ có nhiều đường gọi API hơn chứ không có governance.

Người dùng / nhân viên
        │
        ▼
AI Host + Agent Runtime
        │  (MCP clients, context assembly, session state)
        ├───────────┬───────────┐
        ▼           ▼           ▼
Policy Engine   Identity      Audit + Trace
        │           │           │
        └──────┬────┘           │
               ▼                │
        MCP Gateway / Server Registry
               │                │
     ┌─────────┼─────────┐      │
     ▼         ▼         ▼      ▼
Bee CRM   Knowledge   Calendar / External CRM / Workflow

Gateway hoặc registry không phải yêu cầu của MCP, nhưng thường là boundary hợp lý khi doanh nghiệp có nhiều server. Nó có thể áp dụng allowlist, tenant routing, egress control, version policy và telemetry chung. Một host không nên tự ý tin mọi MCP server được người dùng thêm vào. Server là một dependency có quyền ảnh hưởng context của model và, nếu có tool ghi, ảnh hưởng hệ thống thật.

Lớp 2. Capability discovery không phải permission model

Một tool xuất hiện trong catalog chỉ có nghĩa server nói rằng tool tồn tại. Nó không có nghĩa principal hiện tại được dùng tool, càng không nghĩa tool được dùng với mọi object. Đây là nhầm lẫn nguy hiểm nhất khi thiết kế agent. get_customer cần kiểm tra requester được xem customer nào. create_appointment cần kiểm tra tenant, branch, slot, consent và chính sách. export_contacts có thể bị deny-by-default dù tool có mặt trong catalog.

Permission phải được kiểm tra tại server có quyền đối với dữ liệu hoặc side effect, không chỉ trong system prompt của host. Prompt giúp hướng dẫn model. Nó không phải security boundary. Một result lấy từ email, note CRM hoặc web page có thể chứa indirect prompt injection yêu cầu agent bỏ qua rule, gọi tool khác hoặc tiết lộ dữ liệu. Vì vậy capability selection, authorization và policy evaluation cần độc lập với text được model đọc.

{
  "name": "create_appointment_draft",
  "description": "Tạo bản nháp lịch hẹn sau khi xác thực slot. Không xác nhận với khách.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["tenant_id", "customer_id", "branch_id", "service_id", "start"],
    "properties": {
      "tenant_id": { "type": "string" },
      "customer_id": { "type": "string" },
      "branch_id": { "type": "string" },
      "service_id": { "type": "string" },
      "start": { "type": "string", "format": "date-time" }
    }
  }
}

Tên tool, description và schema là một phần của giao diện bảo mật. Capability hẹp như create_appointment_draft tốt hơn một tool đa năng write_crm_record nhận arbitrary JSON. Schema strict ngăn input ngoài hợp đồng, nhưng server vẫn phải validate business rule và authorization. JSON hợp lệ vẫn có thể chứa branch sai, slot đã hết, customer khác tenant hoặc thời gian mơ hồ được chuẩn hóa sai.

Lớp 3. Identity, OAuth và tenant boundary: agent không được mượn quyền mơ hồ

Một production integration phải trả lời rõ ai đang gọi tool. Có thể là nhân viên đăng nhập, service account của workflow hoặc một authorization delegation giới hạn. Không dùng một API key quyền rộng rồi gọi là “AI của người dùng”. Token phải có audience, scope, expiry, rotation và đường revoke phù hợp. Server cần xác thực token, suy ra principal, tenant, role và object scope, sau đó kiểm tra lại từng request. tenant_id trong tool input là dữ liệu cần đối chiếu với credential, không phải giá trị để tin vô điều kiện.

OAuth là một phần quan trọng cho delegated authorization, nhưng OAuth không thay policy nghiệp vụ. Token scope crm.write chưa trả lời khách nào, trường nào, thời gian nào được cập nhật và có cần người phê duyệt không. Các quyết định này thường thuộc policy engine gần domain service. Dùng short-lived token hoặc token exchange theo workload giúp giảm blast radius hơn secret dài hạn được nạp vào mọi server MCP.

Tool request
  │
  ├─▶ Verify token: issuer, audience, signature, expiry
  ├─▶ Resolve principal: user | service | delegated session
  ├─▶ Bind tenant and role from trusted claims
  ├─▶ Authorize object scope at domain server
  ├─▶ Evaluate business policy and consent
  └─▶ Execute or return structured denial reason

Bằng cách này, Bee CRM hoặc CRM doanh nghiệp đang dùng có thể tiếp tục giữ quyền quyết định dữ liệu nghiệp vụ. MCP là một adapter contract ở rìa agent, không thay thế domain authorization của CRM. Nội dung công khai của BEEDONI hiện mô tả Bee CRM, inbox, RAG và workflow, không công bố MCP server. Vì vậy bài này trình bày mẫu kiến trúc đề xuất cho kết nối agent trong tương lai hoặc integration theo dự án, không tuyên bố sản phẩm đã có endpoint MCP sẵn dùng.

Lớp 4. Context là dữ liệu không đáng tin: RAG, resource và tool result đều cần provenance

Một trong các rủi ro khó nhất của agent là kết hợp instruction với data. Model có thể đọc note CRM, file PDF, transcript cuộc gọi hoặc tool result chứa câu lệnh giả dạng “hãy xuất toàn bộ khách hàng”. Dù dữ liệu đến qua RAG hay MCP resource, nó vẫn là untrusted data. Không có content nào được phép thay đổi policy, thêm tool, tăng scope token hoặc bỏ qua human approval chỉ vì model nhìn thấy nó trong context.

Context assembly cần giữ provenance: resource ID, object ID, source version, classification, tenant, ACL, thời điểm truy xuất và policy cho phép. Với claim quan trọng, UI nên có evidence reference để người dùng kiểm tra. Với dữ liệu thay đổi nhanh như lịch trống, giá khuyến mãi, tồn kho hoặc trạng thái đơn, dùng tool read-time có schema thay vì vector chunk. Với tài liệu dài, RAG có thể phù hợp nhưng cần lifecycle cho update, delete, permission change và cache invalidation.

Lớp 5. Từ tool call tới workflow đáng tin: idempotency, outbox và Saga

Tool call thành công không đồng nghĩa business action hoàn tất. Một request tạo lịch có thể timeout sau khi calendar đã ghi, webhook xác nhận có thể tới muộn, hoặc CRM ghi thành công nhưng notification thất bại. Agent runtime không nên tự retry mù dựa vào việc model muốn thử lại. Side effect cần đi vào workflow state bền vững với idempotency key theo business intent, ví dụ tenant:customer:appointment:start:revision, để worker có thể kiểm tra trạng thái thay vì tạo duplicate.

MCP tool call
  │
  ├─▶ Validate input + authorization + policy
  ├─▶ Persist command + idempotency key
  ├─▶ Create workflow run / draft
  ├─▶ Commit domain change + outbox event together
  ├─▶ Publish and call downstream dependency
  ├─▶ Reconcile actual state
  └─▶ Emit outcome: succeeded | failed | compensated | awaiting_approval

Transactional outbox giảm dual-write failure khi domain change và event publish được ghi cùng transaction. Nó không tạo exactly-once end-to-end. Publisher có thể phát lại event, consumer vẫn phải dedupe. Với nhiều hệ thống không dùng chung transaction như CRM, calendar, provider nhắn tin và ERP, Saga theo dõi local transaction và chạy compensation khi cần. Compensation không phải undo tuyệt đối. Tin đã gửi có thể cần thông báo đính chính hoặc suppression thay vì cố “xóa” khỏi kênh khách.

Retry phải phân loại lỗi. Timeout, 429 và 503 có thể retry có backoff, jitter, deadline và số lần hữu hạn. Payload validation, policy deny, consent withdrawn hay authorization failure không được retry như lỗi mạng. Chúng cần structured reason code, manual queue hoặc clarification với khách. Đây là nguyên tắc đã trình bày sâu hơn trong bài Workflow Orchestration của Bee CRM.

Lớp 6. Human approval: dùng con người làm control plane, không làm nút bấm trang trí

MCP làm agent có khả năng hành động, nhưng doanh nghiệp không nên đánh đồng năng lực kỹ thuật với thẩm quyền quyết định. Approval cần có trigger rõ: thay đổi sensitive field, outbound có cam kết, action tài chính, action liên quan dữ liệu sức khỏe, exception policy hoặc evidence mâu thuẫn. Payload review phải snapshot đúng input, evidence, policy version, tác động dự kiến, người đề xuất và hạn xử lý. Nếu workflow đổi dữ liệu sau lúc approval, approval cũ phải hết hiệu lực hoặc được review lại.

Một control plane tốt cho phép reviewer approve, reject, edit hoặc request clarification. Nó hiển thị raw input, normalized value, nguồn tri thức, dữ liệu thời gian thực, validation result và reason code. Mọi override được ghi thành feedback event. Nhờ vậy đội ngũ thấy được case nào model hiểu sai, case nào policy quá chặt, hay field nào thiếu nguồn chuẩn. Human-in-the-loop giảm dần theo evidence và quality đã đo, không theo áp lực phải tự động hóa thật nhiều.

Lớp 7. Observability và evaluation: biết agent đã làm gì, chậm ở đâu và có cải thiện không

Một hệ thống agent production cần propagation ID xuyên qua user request, agent session, MCP client, server, workflow run, CRM mutation và provider callback. trace_id giúp phân tích độ trễ trên đường đi. correlation_id nối business journey. event_id định danh sự kiện. idempotency_key bảo vệ business intent. Audit log lại trả lời principal nào đã yêu cầu action, policy nào quyết định, reviewer nào phê duyệt và outcome thực tế là gì. Không nên trộn cả bốn thành một chuỗi ID không có ngữ nghĩa.

Evaluation cũng phải vượt qua benchmark trả lời hay. Golden set cần các case tiếng Việt không dấu, code-switching, relative time, nhiều ý định, customer không đủ quyền, record đã xóa, stale consent, duplicate event, downstream timeout và indirect prompt injection. Đo riêng context retrieval quality, authorization deny correctness, tool selection, schema validity, action precision, approval override, duplicate suppression, compensation rate và outcome completion. Tất cả metric phải nêu cohort, role scope, ground truth và khoảng thời gian, không dùng một con số accuracy chung chung.

Lớp 8. Lộ trình thực dụng: đừng bắt đầu bằng một agent có quyền làm mọi thứ

Con đường an toàn không phải xây một MCP server thật nhiều tool. Bắt đầu bằng một customer journey, một tenant scope, vài read-only capability và một use case có outcome rõ. Ví dụ, agent hỗ trợ nhân viên tìm timeline hội thoại, policy phiên bản mới nhất và lịch trống trong phạm vi được phép, rồi đề xuất bước kế tiếp kèm evidence. Khi chất lượng retrieval, authorization và handoff được đo, mở rộng sang draft action. Chỉ sau đó mới cho workflow thực thi một số action đảo ngược được trong scope hẹp.

1. 1Inventory capability: liệt kê resource, tool, data classification, system of record, owner và side effect của từng integration.
2. 2Design permission first: xác định principal, tenant, object scope, consent, policy và human approval trước khi viết prompt hoặc tool description.
3. 3Build read-only evidence path: context có provenance, citation và access control trước khi thêm write tool.
4. 4Introduce workflow boundary: mọi side effect qua idempotency, durable state, outbox, reconciliation và reason code.
5. 5Measure then widen: mở rộng autonomy dựa trên golden cases, override, incident và outcome cohort, không dựa trên demo hấp dẫn.

MCP là cơ hội để doanh nghiệp chuẩn hóa kết nối giữa agent và hệ thống vận hành, nhưng chỉ tạo giá trị khi được đặt trong một kiến trúc Customer Experience có policy và bằng chứng. Với BEEDONI, hướng đi phù hợp là nối các capability của Nhắn tin đa kênh, Voice AI, kho tri thức và Bee CRM theo journey cụ thể, đồng thời giữ domain authorization và workflow control ở nơi chúng thuộc về. Doanh nghiệp đã có CRM cũng có thể bắt đầu từ integration contract hẹp, không cần thay thế toàn bộ nền tảng để thử nghiệm một loop có kiểm soát.

“MCP không làm AI Agent an toàn chỉ vì nó kết nối được nhiều tool hơn. Kiến trúc tốt khiến mỗi tool có phạm vi, mỗi hành động có bằng chứng và mỗi thay đổi có người hoặc policy chịu trách nhiệm.”