Sự tiến hóa của việc sử dụng công cụ AI: MCP đã đi chệch hướng

Tóm tắt nhanh: Tôi từng rất thích MCP, nhưng đó là trước khi tôi phát hiện ra một nửa cửa sổ ngữ cảnh của mình đã biến mất trước cả khi tôi nhập một lệnh nào. Hóa ra MCP đã giải quyết đúng vấn đề (sử dụng công cụ linh hoạt, năng động) nhưng cách tiếp cận lại có những sai sót cơ bản. Cloudflare và Anthropic đã công bố các bài viết giải thích vấn đề và những gì đang thay thế nó: môi trường thực thi mã và khám phá công cụ theo kiểu tải lười (lazy-loaded). Tôi chia sẻ cách mình đã thích nghi với thế giới mới này như một ví dụ. Việc sử dụng công cụ AI vẫn rất quan trọng, nhưng MCP chỉ là một chặng dừng trên hành trình, không phải là đích đến.

Đôi khi chúng ta học hỏi theo những cách kỳ lạ. Một ngày nọ, khi đang sử dụng Claude Code và muốn thực hiện lệnh /compact, tôi đã vô tình gõ nhầm thành /con. Đó là cách tôi phát hiện ra lệnh /context. Hay thật! Nó hiển thị những gì có trong cửa sổ ngữ cảnh. Tôi đã ghi nhớ điều đó để dùng sau.

Vì vậy, lần tiếp theo khi khởi động Claude Code, tôi đã gõ /context và mong rằng nó gần như trống rỗng. Thay vào đó, nó trông như thế này:

Đó là một khoảnh khắc đứng hình thực sự. Tôi chưa hề đưa ra một lệnh nào. Và một nửa cửa sổ ngữ cảnh của tôi đã biến mất? Không phải là tôi đang chạy 50 máy chủ MCP. Tôi chỉ đang chạy hai cái: cầu nối đa tác tử PAL (một công cụ cho phép Claude nói chuyện với các mô hình AI khác) và Chrome DevTools để kiểm thử frontend. Tôi đã đốt token cho những chi phí vô hình trước cả khi tôi bắt đầu làm việc.

Tóm lại, đây chính là lỗ hổng cấu trúc của MCP.

Phình to ngữ cảnh

Khi bản thân các mô hình trở nên thông minh hơn (Opus 4.5 và Gemini 3.0 Pro), chúng đã phơi bày mức độ ngữ cảnh bị mất đi trong quá trình nén (compaction). Hãy tưởng tượng việc nén này giống như cơ chế thu gom rác (garbage collection) của LLM, chỉ khác là nó gây mất mát dữ liệu một cách đau đớn và mất vài phút dài đằng đẵng.

Các mô hình có cửa sổ ngữ cảnh giới hạn (đủ cho khoảng 20.000 dòng mã). Thỉnh thoảng khi thực hiện các tác vụ lập trình, chúng phải nén những gì đã xảy ra để có thêm không gian. Nhưng quá trình nén đó làm mất thông tin, biến trợ lý tài ba của bạn thành một lập trình viên junior hay quên. Và việc duyệt qua tất cả các token đó từ đầu đến cuối cũng mất một lúc.

MCP chính là nguyên nhân gây ra cái được gọi là phình to ngữ cảnh. Tôi thực sự yêu thích những gì MCP làm: mở rộng đáng kể khả năng của AI. Tôi đã viết về việc nó sẽ làm cho AI tốt hơn như thế nào, và nó đã thành công ở một mức độ nào đó, nhưng giờ đây nó lại buộc tôi phải chờ đợi qua những phút giây vô ích thường xuyên hơn nhiều.

Vài ngày trước đó, tôi đã tình cờ đọc được một bài viết từ Cloudflare về việc MCP đã bị hỏng. Tôi đã nghĩ họ chỉ đang cố tỏ ra khác người và thậm chí không thèm đọc nó.

Rồi tôi thấy cửa sổ ngữ cảnh bị ăn mất một nửa. Cú sốc đó đã khiến tôi phải quay lại đọc bài viết của Cloudflare. Sau đó, Anthropic tung ra bài viết của họ về việc thực thi mã với MCP. Tôi nhận ra chính mình mới là người đã trở nên thiển cận.

Vậy những bài viết này nói gì? Các cách tiếp cận này bổ sung cho nhau, mỗi cách giải quyết một phần khác nhau của vấn đề.

Cloudflare: "Tất cả chúng ta đã sử dụng MCP sai cách"

Bài viết của Cloudflare chỉ trích sâu cay: LLM thực ra rất tệ trong việc gọi công cụ (tool calling). Các token đặc biệt được sử dụng trong các lệnh gọi công cụ là những thứ mà LLM chưa bao giờ thấy trong thực tế. Họ so sánh việc này giống như “bắt Shakespeare tham gia một lớp học tiếng Quan Thoại trong một tháng rồi yêu cầu ông viết một vở kịch bằng thứ tiếng đó”.

Sự chênh lệch về dữ liệu huấn luyện là rất lớn. LLM đã gặp nhiều ví dụ về mã nguồn thực tế hơn rất nhiều so với các ví dụ gọi công cụ được dàn dựng. Vì vậy, khi bạn trình bày các công cụ dưới dạng các lệnh gọi hàm, bạn đang yêu cầu mô hình hoạt động ở chế độ yếu nhất của nó.

Giải pháp của họ? Chuyển đổi các công cụ MCP thành các API TypeScript. Thay vì hiển thị trực tiếp các công cụ, tác tử (agent) nhận được một công cụ duy nhất: một hàm thực thi mã. LLM sẽ viết mã TypeScript để gọi các API. Mã chạy trong các V8 isolate (môi trường JavaScript sandbox nhẹ), và các máy chủ MCP trở thành các binding cung cấp quyền truy cập cô lập mà không để lộ khóa API.

Điều này phát huy thế mạnh của mô hình thay vì chống lại chúng.

Anthropic: Thực thi mã với MCP

Sau đó vài ngày, Anthropic (những người phát minh ra MCP) đã công bố bài viết của riêng họ xác định hai vấn đề nghiêm trọng:

Đầu tiên, chi phí định nghĩa công cụ. Các client MCP tải tất cả các định nghĩa công cụ ngay từ đầu. Với hàng nghìn công cụ được kết nối, các tác tử phải xử lý hàng trăm nghìn token trước khi đọc một yêu cầu nào. Trong thử nghiệm của Anthropic, một thiết lập khiêm tốn với năm máy chủ và 58 công cụ đã tiêu thụ khoảng 55K token trước cả khi cuộc trò chuyện bắt đầu. Thêm một vài máy chủ nữa và bạn sẽ nhanh chóng tiến tới mức chi phí hơn 100K token. Anthropic báo cáo đã thấy các thiết lập mà chỉ riêng các định nghĩa công cụ đã tiêu thụ 134K token, tức là khoảng một nửa toàn bộ cửa sổ ngữ cảnh của Claude đã biến mất trước khi bạn kịp hỏi một câu nào.

Thứ hai, sự trùng lặp kết quả trung gian. Kết quả đi qua mô hình nhiều lần. Một bản ghi được lấy từ Google Drive và đính kèm vào Salesforce sẽ đi qua ngữ cảnh hai lần, có khả năng thêm hơn 50.000 token cho các tài liệu dài.

Giải pháp của họ tương tự như của Cloudflare: trình bày các máy chủ MCP dưới dạng API mã nguồn thông qua cấu trúc dựa trên hệ thống tệp. Mỗi công cụ trở thành một tệp TypeScript với các giao diện được định nghĩa. Các tác tử chỉ tải các định nghĩa mà chúng cần cho tác vụ hiện tại.

Kết quả? Giảm 98,7% token (từ 150.000 xuống còn 2.000 token) trong phần trình diễn của họ.

Đòn chí mạng: Công cụ tìm kiếm công cụ

Dựa trên phương pháp thực thi mã, Anthropic cũng tấn công vào vấn đề khám phá. Nếu các định nghĩa công cụ không thể nằm trong cửa sổ ngữ cảnh, làm thế nào mô hình biết được những công cụ nào tồn tại?

Câu trả lời của họ là công cụ tìm kiếm công cụ (vâng, một công cụ để tìm kiếm các công cụ khác). Thay vì tải tất cả các định nghĩa ngay từ đầu, Claude khám phá các công cụ theo yêu cầu. Hãy coi nó như là tải lười (lazy-loading) cho các công cụ: mô hình chỉ tra cứu hướng dẫn sử dụng khi nó quyết định cần một khả năng cụ thể.

Sự cải thiện về độ chính xác rất ấn tượng: Opus 4 cải thiện từ 49% lên 74%, và Opus 4.5 tăng từ 79,5% lên 88,1%. Đó là mức giảm 85% lượng token sử dụng trong khi vẫn duy trì quyền truy cập vào toàn bộ thư viện công cụ của bạn.

Tôi đã giải quyết vấn đề này như thế nào

Một trong những dự án của tôi, codev, sử dụng rất nhiều máy chủ MCP “cầu nối mô hình” PAL. Việc nhiều mô hình làm việc cùng nhau là cốt lõi của codev, vì vậy tôi phải giải quyết vấn đề này.

Tôi bắt đầu suy nghĩ: thay vì Claude Code nói chuyện với Gemini thông qua MCP, tại sao Claude không gọi trực tiếp Gemini CLI? Tôi đã tạo một script consult về cơ bản là một lớp vỏ mỏng bao quanh các CLI của Claude, Gemini và Codex. Không có schema công cụ nào được tải, vì vậy ngữ cảnh khởi động vẫn ở mức tối thiểu. Giờ đây Claude Code có thể gọi Gemini. Hoặc Claude Code có thể gọi chính Claude Code (điều này thực sự có ích).

Về cơ bản, đây là một phiên bản thô, không an toàn của mô hình thực thi mã: cho phép mô hình thực thi trực tiếp các lệnh CLI để tiết kiệm ngữ cảnh. Nó hoạt động, nhưng thiếu các cơ chế an toàn mà thế hệ sandbox tiếp theo sẽ cần cung cấp.

Tôi không phải là người duy nhất thích ứng. Tác giả của PAL cũng đối mặt với vấn đề tương tự và đã tạo ra clink (“CLI link”) làm một việc tương tự, cho phép một CLI tạo ra một CLI khác như một tác tử con (subagent) trong khi vẫn giữ cho cửa sổ ngữ cảnh của phiên chính không bị ảnh hưởng.

Hướng đi tiếp theo?

Việc sử dụng công cụ sẽ không biến mất. Đó vẫn là một khả năng quá mạnh mẽ để có thể từ bỏ. Một cách hiểu về những gì đã xảy ra là MCP đã trở thành nạn nhân của chính thành công của nó: mọi người thích sử dụng các công cụ đến mức nó bắt đầu ngốn sống cửa sổ ngữ cảnh của họ.

Nhưng phía trước là những thời điểm khó khăn. Chúng ta đã đi từ các giao diện đẹp đẽ, được định nghĩa rõ ràng với những rào cản an toàn của MCP sang sự lộn xộn của việc viết và thực thi mã tùy ý. Đây là lý do tại sao các môi trường sandbox cho AI sẽ trở nên quan trọng hơn.

Thế giới gọn gàng của “đây là một công cụ, đây là schema của nó, hãy gọi nó với các tham số này” đang nhường chỗ cho “đây là một môi trường thực thi mã, tự tìm cách đi”. Điều đó mạnh mẽ hơn, nhưng cũng nguy hiểm hơn và khó suy luận hơn. Hãy tưởng tượng một tác tử quyết định “tối ưu hóa” bằng cách xóa các tệp mà nó cho là không cần thiết.

MCP đã giải quyết đúng vấn đề. Chỉ có điều giải pháp đó lại tạo ra những vấn đề mới, theo một số cách, còn tồi tệ hơn. Sự tiến hóa tiếp theo của việc sử dụng công cụ AI sẽ cần phải cân bằng giữa sức mạnh và hiệu quả, sự linh hoạt và an toàn.

Những cơ chế bảo vệ nào sẽ giữ cho các sandbox thực thi mã được an toàn mà không làm chúng bị bó buộc? Đó là câu hỏi mà ngành công nghiệp cần phải trả lời tiếp theo.

---

Bài viết này đã được scrape và chuyển đổi sang định dạng Markdown.