Tại sao AI Agent của bạn không nên kết nối với tất cả các công cụ MCP?

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Việc phơi bày quá nhiều công cụ cấp thấp (low-level tools) khiến AI Agent bị quá tải trong việc ra quyết định, dẫn đến các lỗi logic và xung đột dữ liệu.
• Thay vì kết nối trực tiếp, hãy xây dựng một tầng trừu tượng hóa (abstraction layer) để nhóm các tác vụ lặp lại thành các công cụ cấp cao (high-level domain tools).
• Mục tiêu là để LLM chỉ xử lý các quyết định cần tư duy, còn các quy trình nghiệp vụ cố định nên được xử lý bởi mã nguồn (code) thay vì prompt.

Sự bùng nổ của các khung làm việc AI Agent và giao thức Model Context Protocol (MCP) đã tạo ra một ảo tưởng nguy hiểm: nếu một khả năng có thể kết nối được, thì LLM nên nhìn thấy nó như một công cụ. Thực tế, việc để AI Agent của bạn đối thoại trực tiếp với mọi API, database hay MCP server không khác gì việc yêu cầu một nhân viên mới phải tự tìm hiểu toàn bộ sơ đồ tổ chức phức tạp của công ty chỉ để trả lời một câu hỏi đơn giản. Điều này không chỉ gây lãng phí tài nguyên mà còn tạo ra những điểm mù trong logic vận hành.

Khi kết nối công cụ trở thành gánh nặng cho LLM

Khi bạn phơi bày quá nhiều chi tiết triển khai cấp thấp cho mô hình ngôn ngữ, bạn đang vô tình mở rộng bề mặt quyết định (decision surface) của Agent. Với mỗi công cụ mới được thêm vào, mô hình phải tự đặt ra hàng loạt câu hỏi: Tôi nên dùng công cụ nào? Thứ tự gọi ra sao? Tham số nào là cần thiết? Kết quả này có đủ tin cậy không?

Sự phức tạp này dẫn đến các lỗi dự đoán (predictable failure modes) mà chúng ta thường thấy trong các hệ thống Agentic hiện nay:

Việc này tương tự như những thách thức trong Chiến lược kiểm thử SaaS toàn diện, nơi mà việc quản lý quá nhiều biến số dẫn đến sự mất kiểm soát trong hệ thống. Thay vì để Agent tự mày mò, chúng ta cần một kiến trúc thông minh hơn.

Xây dựng tầng trừu tượng hóa công cụ

Thay vì để LLM orchestrate (điều phối) mọi thứ từ đầu, hãy chuyển các quy trình lặp lại xuống tầng mã nguồn (code-based orchestration). Hãy xem xét ví dụ về việc điều tra đơn hàng bị chậm. Thay vì cung cấp 9 công cụ riêng lẻ như get_orders, get_shipment, check_refund_eligibility, hãy tạo ra một công cụ duy nhất: investigate_delivery_issue(customer_id, order_id).

Công cụ này sẽ thực hiện các bước logic bên dưới:

1. Truy xuất dữ liệu đơn hàng và vận chuyển.
2. Kiểm tra các sự cố từ phía nhà vận chuyển.
3. Áp dụng các quy tắc hoàn tiền/đổi trả dựa trên chính sách hiện hành.
4. Trả về kết quả đã được cấu trúc hóa (structured evidence).

Mẹo hay: Việc đóng gói logic nghiệp vụ vào các hàm cấp cao giúp hệ thống trở nên Idempotent và dễ kiểm soát hơn, tương tự như cách chúng ta Xây dựng Email Agent Idempotent để tránh rủi ro từ các sự kiện trùng lặp.

Kiến trúc hệ thống tối ưu

Kiến trúc truyền thống thường để LLM đứng ở trung tâm và kết nối trực tiếp với mọi thứ. Kiến trúc hiện đại mà chúng ta hướng tới là:

[LLM] ---> [High-level Domain Tool] ---> [Internal Orchestration] ---> [API/Database/MCP]

Cách tiếp cận này không chỉ giúp giảm thiểu số lượng lời gọi (round-trips) mà còn giúp Agent tập trung vào việc xử lý các tình huống cần sự thấu cảm hoặc suy luận của con người, thay vì phải làm những công việc của một lập trình viên backend. Điều này cũng tương tự như việc Tối ưu hóa quy trình lập trình bằng cách loại bỏ các thao tác dư thừa.

Đánh giá & Lời khuyên Thực tiễn

Từ góc độ của một Senior Tech Lead, việc trừu tượng hóa công cụ là bắt buộc đối với các hệ thống Production.

• Ưu điểm: Giảm thiểu đáng kể tỷ lệ lỗi (hallucination), tăng tốc độ phản hồi và dễ dàng debug hơn nhờ các contract rõ ràng giữa LLM và hệ thống.
• Nhược điểm: Tốn thêm thời gian phát triển và bảo trì tầng orchestration. Bạn cần phải viết unit test cho các công cụ này thay vì chỉ dựa vào khả năng suy luận của LLM.
• Lưu ý: Đừng tạo ra các "monster tools" (công cụ quá ôm đồm). Một công cụ tốt phải có phạm vi (bounded domain) rõ ràng. Nếu bạn thấy mình đang viết một hàm xử lý mọi thứ, đó là dấu hiệu của việc thiết kế sai.

Khi triển khai, hãy luôn tự hỏi: "LLM có thực sự cần biết sự tồn tại của công cụ này không?". Nếu câu trả lời là không, hãy giấu nó đi. Điều này cũng giúp ích trong việc Tối ưu hóa quy trình tự động hóa trong các hệ thống phức tạp.

Câu hỏi thường gặp (FAQ)

Tại sao tôi không nên cho LLM tự quyết định mọi thứ?

LLM rất giỏi trong việc suy luận, nhưng lại kém trong việc duy trì trạng thái (state) và tính nhất quán trong các quy trình dài hơi. Việc để LLM tự gọi quá nhiều công cụ dẫn đến xác suất sai sót tích lũy theo từng bước.

Khi nào thì nên kết nối trực tiếp công cụ với LLM?

Bạn chỉ nên kết nối trực tiếp khi tập công cụ nhỏ, rõ ràng, hoặc khi tác vụ mang tính chất khám phá (exploratory) và không có quy trình cố định.

Làm sao để biết công cụ của tôi đã đủ trừu tượng hóa chưa?

Nếu kết quả trả về của công cụ là một cấu trúc dữ liệu gọn gàng, chứa đựng đầy đủ thông tin để LLM đưa ra quyết định cuối cùng mà không cần gọi thêm bất kỳ công cụ nào khác, thì bạn đã làm tốt.

Kết luận

Việc xây dựng AI Agent không phải là cuộc đua xem ai kết nối được nhiều công cụ nhất, mà là cuộc đua về chất lượng ra quyết định. Bằng cách đặt các logic lặp lại vào tầng mã nguồn và chỉ để LLM xử lý những gì cần tư duy, bạn sẽ xây dựng được những hệ thống bền vững và đáng tin cậy. Hãy bắt đầu refactor lại các công cụ của bạn ngay hôm nay để tối ưu hóa hiệu suất. Nếu bạn quan tâm đến việc xây dựng các hệ thống AI chuyên sâu, đừng quên theo dõi hi_dev để cập nhật những kiến trúc mới nhất.