Blog / Series AI Agents Thực Chiến

MCP là gì? “Tool calling” đang thay đổi cuộc chơi AI Agents ra sao

Vấn đề gốc: vì sao AI mạnh vẫn “không làm được việc”

Nhiều đội kỹ thuật lần đầu đưa LLM vào sản phẩm thường trải qua cùng một cảm giác: demo rất ấn tượng, nhưng khi nối vào quy trình thật thì agent trở nên khó tin cậy. Nó có thể giải thích khá mượt một quy trình bán hàng, nhưng lại không thể tự lấy dữ liệu khách hàng đúng cách. Nó có thể tóm tắt email hay, nhưng không biết mở ticket đúng hệ thống. Nó có thể đưa ra kế hoạch xử lý sự cố, nhưng không có cách gọi công cụ để thực thi từng bước với log rõ ràng.

Lý do nằm ở chỗ: mô hình ngôn ngữ không sống trong thế giới thật. Nó nhìn thấy token, không nhìn thấy khái niệm “đây là CRM production”, “đây là quyền xóa dữ liệu”, hay “đây là file nội bộ không được tiết lộ”. Nếu không có lớp kết nối được thiết kế tử tế, AI chỉ là một cỗ máy suy luận trong hộp kính: nói được rất nhiều, nhưng chạm vào hệ thống thật là bắt đầu lỗi. Đây cũng là điểm phân tách rõ nhất giữa một chatbot trả lời tốt và một AI agent có thể hoàn thành công việc.

Trước đây, rất nhiều nhóm xử lý khoảng trống này bằng cách tự viết tool wrappers, tự gắn schema cho từng API, và nhồi thật nhiều chỉ dẫn vào prompt để mô hình biết khi nào gọi gì. Cách tiếp cận này có liên hệ trực tiếp với chủ đề workflow và vận hành agent, vì càng nhiều bước thủ công, hệ thống càng khó mở rộng và khó debug. Cách đó có thể đủ cho một bản demo hoặc một use case hẹp. Nhưng khi số lượng công cụ tăng lên, nhiều nhóm user cùng sử dụng, và quyền truy cập bắt đầu nhạy cảm, cách làm này nhanh chóng lộ nhược điểm: khó mở rộng, khó kiểm soát quyền, khó audit, và đặc biệt là khó thay model hoặc thay agent framework.

MCP là gì, và nó khác gì so với việc tự nối API thủ công?

Nói ngắn gọn, MCP là một lớp chuẩn để model hoặc agent biết:

• Hiện có những công cụ nào đang khả dụng.
• Mỗi công cụ nhận đầu vào ra sao, trả đầu ra thế nào.
• Ngữ cảnh nào được phép truyền vào công cụ.
• Hệ thống bên ngoài nên trả metadata gì để agent có thể tiếp tục reasoning một cách nhất quán.

Điểm quan trọng nhất ở đây không phải là “gọi tool được”, vì chuyện đó ai cũng có thể tự làm. Điểm quan trọng là chuẩn hóa hợp đồng giữa model và môi trường thực thi. Một khi đã có lớp hợp đồng này, người triển khai có thể:

• đổi model mà không phải viết lại toàn bộ integration,
• thêm tool mới mà không phá logic cũ,
• ghi log mọi lời gọi ở dạng có cấu trúc,
• áp chính sách quyền theo tool, theo user, theo môi trường.

Nếu ví LLM là một CPU cho việc suy luận ngôn ngữ, thì MCP giống như bus giao tiếp chuẩn giữa CPU đó với thiết bị ngoại vi: ổ đĩa, màn hình, mạng, cảm biến, hay service nội bộ. Khi chưa có bus chuẩn, mỗi thiết bị dùng một dây nối riêng, chắp vá và khó sửa. Khi có bus chuẩn, cả hệ sinh thái bắt đầu mở rộng được.

Một use case thật: từ email khách hàng đến ticket hoàn chỉnh

Để thấy MCP hữu ích thế nào, hãy lấy một use case nhiều công ty SaaS rất quan tâm: tự động triage email hỗ trợ khách hàng.

Giả sử hệ thống nhận được một email với nội dung gần như thế này:

Một agent “chỉ biết chat” có thể tóm tắt khá hay: khách hàng bị double charge, mức ưu tiên cao, liên quan billing. Nhưng để thật sự hữu ích, hệ thống cần đi xa hơn:

1. Đọc email mới từ hộp thư support.
2. Tìm tài khoản khách hàng trong CRM hoặc billing system.
3. Đối chiếu lịch sử giao dịch và gói dịch vụ.
4. Kiểm tra xem đã có ticket mở hay chưa.
5. Tạo ticket mới với đầy đủ metadata nếu chưa có.
6. Soạn draft phản hồi cho khách theo tone phù hợp.
7. Gắn mức ưu tiên cao nếu là enterprise hoặc có dấu hiệu charge duplication.

Đây là lúc MCP phát huy tác dụng. Thay vì prompt dạy mô hình “nếu thấy email thì gọi hàm A rồi hàm B rồi hàm C”, MCP cho agent một lớp công cụ có cấu trúc hơn:

• Email server: đọc thread, metadata, attachments.
• CRM server: tra khách hàng theo email/domain/account id.
• Billing server: đọc transaction và trạng thái thanh toán.
• Ticketing server: tìm hoặc tạo issue/support case.
• Policy layer: chặn hành động vượt quyền, ví dụ hoàn tiền tự động.

Giá trị ở đây không chỉ là “agent biết gọi nhiều công cụ”, mà là nó có thể gọi chúng trong một chuỗi reasoning quan sát được. Team vận hành có thể nhìn lại và biết chính xác: vì sao ticket được gắn priority high, vì sao draft phản hồi dùng wording đó, và vì sao hệ thống từ chối hành động refund tự động dù model “muốn” làm thế.

Kiến trúc MCP thực dụng cho production

Nhiều bài giới thiệu về AI agents thường dừng ở mức sơ đồ rất đẹp: người dùng → model → tool. Với production, sơ đồ đó là chưa đủ. Một kiến trúc MCP dùng được thật thường có ít nhất 5 lớp:

1) Lớp giao tiếp bên ngoài

Đây là nơi nhận yêu cầu từ người dùng hoặc hệ thống khác: chat app, email, dashboard nội bộ, webhook từ backend. Lớp này chịu trách nhiệm xác thực danh tính, gắn tenant, log request id và các thuộc tính quan trọng của phiên.

2) Orchestrator / agent runtime

Lớp này điều phối vòng lặp reasoning: nhận mục tiêu, lập kế hoạch các bước, gọi model, chọn tool, xử lý lỗi, quyết định khi nào retry và khi nào escalate sang người. Đây là nơi dễ phát sinh độ phức tạp nhất, vì nếu thiết kế mơ hồ thì hệ thống rất khó debug khi workflow dài bắt đầu lệch.

3) MCP servers theo miền nghiệp vụ

Thay vì một “siêu tool” biết làm mọi thứ, cách tốt hơn là chia server theo miền chức năng:

• một server cho dữ liệu khách hàng,
• một server cho tài liệu và knowledge base,
• một server cho email/lịch,
• một server cho browser automation hoặc desktop actions,
• một server cho tác vụ nội bộ như chạy script, deploy hoặc điều phối dữ liệu.

Thiết kế theo miền như vậy giúp dễ quản quyền, dễ audit và dễ scale từng phần độc lập.

4) Policy engine

Đây là lớp mà rất nhiều team bỏ qua ở giai đoạn đầu và trả giá ở giai đoạn sau. Policy engine là nơi quyết định: tool nào được dùng trong ngữ cảnh nào, user nào được yêu cầu hành động nào, data nào được phép xuất hiện trong output, và bước nào cần approval từ con người. Nếu muốn đào sâu góc nhìn này, phần Agent Security 2026 phân tích kỹ hơn về approval, least-privilege và prompt injection. Nếu không có lớp này, bạn đang giao quyền quyết định quá nhiều cho model.

5) Observability + audit

Một agent production phải để lại dấu vết tốt hơn một script thường, không phải tệ hơn. Anh cần biết:

• model đã nghĩ theo nhánh nào ở mức sự kiện,
• tool nào được gọi, với tham số nào,
• tool nào lỗi, lỗi ở bước nào,
• user nào kích hoạt workflow,
• và đầu ra cuối cùng có bị policy thay đổi hay không.

Khi không có audit tốt, mỗi lần agent làm sai sẽ biến thành một cuộc săn ma: ai cũng cảm thấy có gì đó sai, nhưng không ai biết sai ở đâu.

Những trade-off ít được nói tới

MCP thường được nhắc đến như một bước tiến gần như chỉ có mặt tốt. Thực ra không hẳn vậy. Chuẩn hóa luôn đi kèm đánh đổi.

Trade-off 1: Chuẩn hóa làm tăng độ nhất quán, nhưng cũng tăng độ cứng

Khi mọi công cụ đều phải đi qua một hợp đồng chuẩn, hệ thống trở nên dễ kiểm soát hơn. Nhưng cái giá là đội triển khai phải đầu tư vào thiết kế schema và semantics ngay từ đầu. Nếu schema quá sơ sài, model sẽ gọi tool lúng túng. Nếu schema quá chi tiết, tốc độ phát triển ban đầu bị chậm lại.

Trade-off 2: Tool calling mạnh hơn prompt-only, nhưng vòng lặp lỗi cũng đắt hơn

Một câu trả lời sai bằng text có thể chỉ làm người dùng khó chịu. Một lời gọi tool sai có thể ghi sai dữ liệu, tạo nhầm ticket, gửi nhầm email, hoặc tệ hơn là chạy hành động phá hủy. Vì vậy, mỗi bước tăng quyền cho agent phải đi kèm bước tăng mức kiểm chứng.

Trade-off 3: Càng nhiều tool, reasoning càng khó ổn định

Khi hệ thống có 5 tool, model vẫn chọn khá ổn. Khi có 50 tool, đặc biệt là các tool gần giống nhau, chất lượng lựa chọn bắt đầu giảm. Đây là lý do nhiều hệ production tốt không “show toàn bộ tool cho model”, mà dùng lớp routing ở giữa để chỉ lộ ra tập công cụ phù hợp với ngữ cảnh hiện tại.

Rủi ro bảo mật khi mở tool cho agent

Nói về MCP mà bỏ qua bảo mật thì gần như là thiếu một nửa bức tranh. Bởi vì trong phần lớn sự cố agent, vấn đề không đến từ model trả lời sai, mà đến từ việc model được trao quá nhiều quyền trên môi trường thật.

Có 3 nhóm rủi ro chính:

• Prompt injection: dữ liệu bên ngoài nhúng chỉ dẫn nhằm điều khiển agent gọi tool không mong muốn.
• Data exfiltration: agent có quyền đọc dữ liệu rộng hơn mức cần thiết, rồi lộ ra trong output.
• Tool abuse: một lời gọi sai hoặc một workflow không chặn đúng lúc gây ra hành động có chi phí hoặc tác động lớn.

Nguyên tắc nền tảng ở đây vẫn là nguyên tắc cũ của security engineering, chỉ là bây giờ áp vào thế giới AI:

• least privilege cho từng tool,
• segmentation theo môi trường và miền dữ liệu,
• approval gates cho hành động nhạy cảm,
• redaction + output filtering cho dữ liệu nhạy cảm,
• full audit trail cho mọi bước quan trọng.

Điều thú vị là: càng chuẩn hóa giao tiếp kiểu MCP, đội triển khai càng dễ áp các nguyên tắc trên một cách nhất quán. Không phải vì MCP tự nó làm hệ thống an toàn, mà vì nó cho đội triển khai một điểm bám để cài an toàn.

Checklist triển khai trong doanh nghiệp

Nếu đội triển khai đang cân nhắc triển khai MCP hoặc một lớp tool calling tương tự, đây là lộ trình thực dụng hơn nhiều so với việc “nối hết mọi thứ rồi demo cho đã mắt”:

1. Bắt đầu bằng use case có ROI rõ: triage ticket, hỗ trợ sales, tóm tắt vận hành, hoặc trợ lý nội bộ đọc tài liệu.
2. Chỉ mở tool read-only ở giai đoạn đầu: đọc dữ liệu trước, chưa cho ghi/xóa/sửa.
3. Thiết kế schema cho công cụ đủ rõ nhưng không thừa: input/output phải bám ngôn ngữ nghiệp vụ thật.
4. Bổ sung policy layer trước khi mở quyền mạnh: đừng để approval là thứ nghĩ sau cùng.
5. Đo task success rate thay vì chỉ nghe user khen “nó trả lời hay”.
6. Gắn log và trace ngay từ ngày đầu: về sau đội triển khai sẽ cảm ơn quyết định này.

Thực tế, thứ làm một agent sống được trong doanh nghiệp không phải là benchmark demo đẹp hơn đối thủ 5 điểm, mà là khả năng vận hành ổn định trong 90 ngày liên tục mà không tạo ra một mớ hỗn độn về dữ liệu và niềm tin.

Kết luận

MCP đáng chú ý không phải vì nó “thần thánh hóa” AI agents, mà vì nó kéo cả cuộc chơi về đúng bản chất kỹ thuật của nó: chuẩn giao tiếp, ngữ cảnh có cấu trúc, quyền hạn rõ ràng và khả năng quan sát hệ thống. Một khi bài toán chuyển từ “chat sao cho thông minh” sang “làm sao để tác vụ hoàn tất an toàn và đo được”, những lớp như MCP gần như không còn là tùy chọn xa xỉ nữa.

Nếu nhìn dài hạn, rất có thể sự khác biệt giữa một agent chỉ để demo và một agent đủ sức chạy trong vận hành hằng ngày sẽ không nằm ở prompt đẹp hay model mới nhất, mà nằm ở cách đội ngũ thiết kế lớp kết nối giữa AI và thế giới thật. MCP chính là một trong những viên gạch quan trọng nhất của lớp kết nối đó.