Thuế ngữ cảnh: 55.000 token công cụ đang ăn mòn ngân sách AI Agent

Tóm tắt cốt lõi: AI Agent có thể mất hàng chục nghìn token chỉ để nhìn thấy công cụ, trước khi xử lý yêu cầu thực tế. Đây không phải chi phí bắt buộc của MCP: cách client nạp schema, cơ chế cache và phạm vi công cụ quyết định mức lãng phí. Với SME, ưu tiên đo ngữ cảnh tĩnh, thử nạp công cụ theo nhu cầu và kiểm chứng độ chính xác định tuyến trước khi mua cửa sổ lớn hơn hoặc tự host mô hình.

Một agent chỉ cần tìm tệp trong repository nhưng được giới thiệu cả bộ công cụ quản lý issue, pull request, quyền truy cập và thông báo. Doanh nghiệp trả tiền để mô hình tiếp nhận một danh mục mà phần lớn tác vụ không dùng đến.

Tôi gọi phần tài nguyên này là thuế ngữ cảnh AI Agent: chi phí để hệ thống biết nó có thể làm gì, thay vì trực tiếp làm việc. Thuế xuất hiện ở hóa đơn đầu vào, dung lượng cửa sổ và đôi khi ở độ trễ, độ chính xác chọn công cụ.

Dưới góc nhìn vận hành của Cường Nguyễn, founder AI Ops Solutions và Verified n8n Creator, câu hỏi thực dụng không phải “kết nối được bao nhiêu server”, mà là: mỗi tác vụ phải mang theo bao nhiêu định nghĩa công cụ không liên quan?

Thuế ngữ cảnh AI Agent là gì, và 55.000 token có đáng lo không?

Trả lời nhanh: Thuế ngữ cảnh là phần token dành cho định nghĩa công cụ và thông tin điều phối, thay vì dữ liệu tác vụ. Với cửa sổ 200.000 token, 55.000 token chiếm 27,5%. Hãy đo phần còn lại cho dữ liệu, lịch sử và đầu ra trước khi quyết định tối ưu.

Có ba sổ chi phí cần tách riêng. Thứ nhất là tiền token được nhà cung cấp tính phí. Thứ hai là dung lượng context bị chiếm. Thứ ba là chi phí vận hành phát sinh khi agent chọn sai công cụ, gọi thừa hoặc phải khám phá lại.

Prompt caching có thể giảm giá phần đầu vào lặp lại, nhưng không đồng nghĩa nội dung đó biến mất khỏi cửa sổ. Ngược lại, giảm schema có thể giải phóng nhiều context nhưng chỉ tiết kiệm tiền vừa phải nếu phần schema trước đó chủ yếu được tính theo giá cache read.

Vì vậy, đừng dùng một biểu đồ tiền token để đại diện cho toàn bộ vấn đề. Cửa sổ lớn cũng không bảo đảm mô hình sử dụng mọi thông tin hiệu quả như nhau; ảnh hưởng của danh mục công cụ dài phải được kiểm tra trên tác vụ thực tế.

Bài phân tích chi phí AI theo kết quả được chấp nhận đặt bài toán ở cấp toàn workflow. Ở đây, chúng ta khoanh đúng một lớp: ngữ cảnh dành cho giao thức công cụ.

Giải phẫu 55.000 token: con số hữu ích, không phải định luật MCP

Hồ sơ nghiên cứu dẫn một trường hợp trên DEV Community: cấu hình GitHub MCP hiển thị khoảng 93 công cụ, với định nghĩa công cụ có thể chiếm khoảng 55.000 token. Đây là quan sát theo client và cấu hình cụ thể, không phải benchmark chuẩn cho mọi GitHub MCP server.

Cần kiểm tra ngay phép chia: 55.000 / 93 ≈ 591 token mỗi công cụ. Không thể vừa dùng bộ số này vừa khẳng định mọi công cụ trung bình tốn 1.000 token. Schema có thể rất ngắn hoặc rất dài, tùy mô tả, enum, tham số lồng nhau và dữ liệu mà client thực sự chuyển thành định nghĩa cho mô hình.

Ước tính cộng đồng về ba server chiếm 143.000 token trên cửa sổ 200.000 tương đương 71,5%. Phép tính đúng về số học, nhưng chưa đủ để dự báo hệ thống của bạn: phiên bản server, tập công cụ bật và chiến lược nạp có thể khác hoàn toàn.

Danh mục MCP và prompt của mô hình là hai lớp khác nhau

Đặc tả MCP về tools mô tả cơ chế khám phá qua tools/list, gọi công cụ và các annotation. Danh sách có thể được phân trang; việc khám phá danh mục không đồng nghĩa mọi schema phải nằm thường trực trong mọi lần gọi mô hình.

Client hoặc lớp điều phối quyết định phần nào được đưa vào model request. Vì vậy, cần phân biệt “server cung cấp danh mục lớn” với “client nhét toàn bộ danh mục vào prompt”. Bài viết này không dựa vào những khẳng định chưa đối chiếu về thay đổi đặc tả năm 2026 để suy ra rằng lazy loading phía server bị cấm.

Đo token công cụ thế nào trước khi tối ưu?

Trả lời nhanh: Đo payload thực sự gửi đến mô hình, không chỉ JSON từ tools/list. Ghi riêng token schema, registry, dữ liệu tác vụ và lịch sử; dùng tokenizer phù hợp với mô hình. Chạy cùng bộ yêu cầu trước và sau thay đổi, rồi so sánh thêm cache, độ trễ và lỗi chọn công cụ.

Với SME, phép đo đầu tiên không cần một nền tảng observability phức tạp. Một bản ghi request đã loại dữ liệu nhạy cảm và một bảng tổng hợp theo workflow đủ để xác định nơi lãng phí lớn nhất.

• Chụp danh mục: Lưu toàn bộ trang của tools/list, phiên bản server và tập công cụ được bật.
• Chụp payload mô hình: Kiểm tra client có đổi tên, bọc schema hoặc thêm hướng dẫn hay không. Đây mới là đầu vào cần đo.
• Đếm đúng tokenizer: Dùng tokenizer của mô hình khi có. tiktoken chỉ là phép đo phù hợp với các encoding được hỗ trợ, không phải chuẩn chung cho mọi nhà cung cấp.
• Đối chiếu usage: So sánh ước lượng cục bộ với input token, cache read và cache write do API báo cáo.

Nên theo dõi tỷ lệ ngữ cảnh tĩnh = token schema và registry / cửa sổ khả dụng. Đồng thời đo tỷ lệ công cụ thực sự được dùng trên toàn bộ công cụ được giới thiệu, độ chính xác chọn công cụ và thời gian từ yêu cầu đến kết quả.

Một tool hiếm dùng chưa chắc nên loại bỏ: nó có thể phục vụ tình huống quan trọng. Hãy phân nhóm theo tác vụ và hậu quả khi thiếu công cụ, thay vì tối ưu chỉ bằng tần suất gọi.

Lazy loading và Tool Search giảm được gì, phải trả thêm gì?

Lazy loading giữ schema chi tiết ngoài ngữ cảnh cho đến khi cần. Tool Search giúp mô hình tìm công cụ liên quan rồi nạp một tập nhỏ định nghĩa. Hai cách này chuyển chi phí từ “trả trước cho tất cả” sang “trả khi khám phá và sử dụng”.

Phân tích advanced tool use của Anthropic trình bày hướng tìm kiếm công cụ để tránh nạp trước toàn bộ định nghĩa. Tuy nhiên, khả năng hỗ trợ phụ thuộc sản phẩm, model và cấu hình; không nên suy ra mọi client MCP đều có cùng hành vi mặc định.

Theo số đo bên thứ ba được hồ sơ nghiên cứu dẫn từ Claude Fast, một cấu hình 73 công cụ giảm từ khoảng 39.800 xuống 5.000 token, tương đương 87,4%. Đây là kết quả minh họa, không phải cam kết hiệu năng cho mọi môi trường.

Cũng cần tránh trộn mẫu đo: giảm 34.800 token không tự giải thích được mức tăng context khả dụng từ 92.000 lên 195.000. Hai cặp số chỉ có thể so sánh trực tiếp khi biết chúng dùng cùng cấu hình, cùng nền và cùng cách tính.

Ngưỡng 10% cửa sổ được nguồn thứ ba đề cập nên được xem là hành vi cần xác nhận ở phiên bản client đang triển khai, không phải quy tắc MCP. Chi phí đổi lại gồm lượt tìm kiếm, token kết quả khám phá và nguy cơ không tìm ra công cụ đúng.

Kiến trúc registry, search_tools và gateway mỏng

Kiến trúc đề xuất gồm ba lớp: registry nhẹ để tìm đúng nhóm công cụ; cơ chế lấy schema chi tiết; gateway thực thi và kiểm tra. Không cần biến tất cả thành một nền tảng phức tạp ngay từ đầu.

Registry phải mô tả ranh giới sử dụng

Mỗi mục có thể gồm name, intent, use_when, avoid_when, replaces. Không đưa toàn bộ args vào registry nếu mục tiêu là giảm context. Tuy nhiên, registry cũng phải được đo: một nghìn mô tả “một dòng” vẫn có thể trở thành một danh mục tốn kém.

Ví dụ, công cụ tìm khách hàng nên ghi rõ “dùng khi cần đối chiếu email đã biết”, đồng thời “không dùng để tìm khách tiềm năng ngoài CRM”. Mô tả ranh giới này giúp giảm lỗi đúng công cụ, sai tình huống, thay vì chỉ rút ngắn câu chữ.

search_tools phải trả về đủ thông tin để quyết định

search_tools(intent) nên trả về một tập ứng viên nhỏ, tên định danh ổn định và schema phiên bản cụ thể. Nếu kết quả không đủ chắc chắn, hệ thống cần được phép tìm lại hoặc yêu cầu làm rõ, thay vì buộc agent chọn đại.

Gateway có thể giới thiệu 4–10 công cụ theo tác vụ như một cấu hình thử nghiệm, không phải giới hạn tối ưu phổ quát. Workflow đối soát hóa đơn và workflow hỗ trợ khách hàng không cần nhìn thấy cùng một danh mục.

Trong n8n, có thể đặt bước phân loại tác vụ trước nhánh agent, rồi cấp tập công cụ tương ứng. Với luồng xác định trước, bước tiếp theo thậm chí không cần agent: node xử lý gọi thẳng API theo đầu vào đã kiểm tra.

Đừng bắt mô hình học toàn bộ sơ đồ tích hợp của doanh nghiệp để hoàn thành một tác vụ nhỏ. Hãy để kiến trúc chọn phạm vi, rồi để mô hình giải quyết phần còn mơ hồ.

Cạm bẫy call_tool: tiết kiệm schema nhưng mất tín hiệu ở client

Một lối tắt phổ biến là chỉ đưa ra call_tool(name, args). Cửa sổ nhẹ hơn, nhưng nếu args chỉ là một object tùy ý, client không còn đủ schema để kiểm tra từng công cụ đích trước khi gửi.

Đây là đánh đổi kiến trúc, không phải bằng chứng generic dispatcher luôn sai. Backend có thể khôi phục kiểm soát bằng schema registry, validation và chính sách phê duyệt theo công cụ thực tế.

• Kiểm tra cấu trúc: Gateway tra schema đúng phiên bản, từ chối trường thiếu hoặc sai kiểu và không tự mở rộng quyền theo tên do mô hình cung cấp.
• Phân loại tác động: Tách đọc với ghi, đồng thời tách thao tác chỉ trong hệ thống với thao tác có tương tác bên ngoài. Đây là hai chiều khác nhau.
• Giữ phê duyệt cụ thể: Không phê duyệt chung cho dispatcher rồi coi mọi công cụ phía sau đều được chấp thuận.

readOnlyHint, destructiveHint và openWorldHint là các tín hiệu mô tả, không phải cơ chế cưỡng chế quyền. Nếu bị che sau một công cụ tổng quát, client có thể mất thông tin hữu ích cho giao diện và chính sách. Gateway phải bổ sung kiểm tra thực thi thay vì trông cậy vào annotation.

Mục tiêu ở đây không phải mở rộng sang một bài toán bảo mật khác, mà là tránh đổi vài nghìn token lấy một hợp đồng công cụ mơ hồ hơn.

Khi nào giữ MCP, khi nào gọi API hoặc CLI trực tiếp?

MCP đáng giá khi cần một giao diện công cụ dùng lại cho nhiều client, cơ chế khám phá thống nhất hoặc tích hợp với hệ thống xác thực của tổ chức. Nhưng giao thức không tự giải quyết toàn bộ quản lý người dùng, quyền hay vận hành.

Nếu workflow chỉ nhận mã đơn, lấy trạng thái và cập nhật một trường CRM, gọi API trực tiếp có thể đơn giản hơn việc đưa ba thao tác vào một agent đa công cụ. CLI cũng hữu ích với tác vụ hẹp, miễn đầu vào, đầu ra và môi trường thực thi được kiểm soát.

Đừng quên subagent fan-out. Nếu mỗi tác vụ con nhận cùng một danh mục lớn, chi phí schema có thể nhân theo số lần gọi. Ngược lại, không nên mặc định mọi runtime đều gửi lại toàn bộ: cần kiểm tra payload và cách cache thực tế.

Phân vai công cụ cho từng subagent thường hợp lý hơn việc cấp cho mọi agent cùng một “hộp đồ nghề doanh nghiệp”. Sự chuyên biệt phải thể hiện ở bề mặt công cụ, không chỉ ở system prompt.

Bài toán tiền: tối ưu schema trước khi tự host mô hình

Hãy dùng một ví dụ có giả định rõ ràng. Giảm schema từ 55.000 xuống 5.000 token tiết kiệm 50.000 token mỗi lần payload đó được gửi. Với 10.000 lượt gọi mô hình, chênh lệch là 500 triệu input token, không nhất thiết là 10.000 tác vụ người dùng.

Nếu giá đầu vào giả định là 3 USD/triệu token, số tiền tương ứng là 1.500 USD khi toàn bộ được tính giá thường. Nếu cả phần chênh lệch được hưởng giá cache read giả định 0,30 USD/triệu, phần tiết kiệm chỉ còn 150 USD. Đây là phép tính minh họa, không phải bảng giá hiện hành.

Cần trừ thêm chi phí discovery, cache write và công sức gateway. Không được lấy mức giảm token nhân giá đầu vào cao nhất rồi gọi đó là ROI chắc chắn.

Với self-host, token đầu vào không còn xuất hiện thành dòng phí API, nhưng vẫn tiêu thụ năng lực prefill và có thể tăng bộ nhớ KV cache, tùy kiến trúc phục vụ. Batching, prefix caching, lượng tải và độ dài đầu ra đều làm thay đổi hiệu quả.

Do đó, không có ngưỡng hòa vốn phổ quát như “một mô hình 27B sẽ rẻ hơn sau X request”. Phải so GPU, vận hành, dự phòng và công suất nhàn rỗi với chi phí API sau cache ở mức chất lượng chấp nhận được. Các báo giá phần cứng và API thứ cấp chưa kiểm chứng không đủ để chốt ngân sách.

Lộ trình 30 ngày cho SME: giảm context mà không làm agent kém đi

• Tuần 1 — Lập đường cơ sở: Kiểm kê server, chụp payload và chọn khoảng 50–100 tác vụ đại diện. Bộ mẫu này để khởi động, chưa đủ chứng minh độ tin cậy cho mọi tình huống hiếm.
• Tuần 2 — Thu hẹp phạm vi: Tắt công cụ không liên quan, chia theo workflow, viết lại use_when và avoid_when. Đo lại trước khi xây gateway.
• Tuần 3 — Thử nạp theo nhu cầu: Bật tính năng client hỗ trợ hoặc dựng registry nhỏ. Ghi nhận cả trường hợp tìm không thấy công cụ, không chỉ những ca thành công.
• Tuần 4 — Quyết định bằng dữ liệu: So sánh chất lượng chọn công cụ, số lần gọi, chi phí thực trả và độ trễ p95. Giữ đường quay lại cấu hình cũ.

Tiêu chí nghiệm thu nên là giảm context mà không làm giảm chất lượng tác vụ vượt mức chấp nhận. Mức giảm 80% token không có ý nghĩa nếu đội vận hành phải sửa thêm nhiều kết quả hoặc thời gian phản hồi vượt SLA.

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

Tool Search có phải là một phần bắt buộc của MCP không?

Không. MCP cung cấp cơ chế khám phá và gọi công cụ; Tool Search là khả năng của client hoặc lớp điều phối cụ thể. Một server có thể hoạt động với cả client nạp toàn bộ lẫn client nạp theo nhu cầu. Hãy kiểm tra phiên bản, model hỗ trợ và payload thực tế thay vì suy đoán từ nhãn “hỗ trợ MCP”.

Schema đã được cache thì còn cần tối ưu không?

Có thể vẫn cần. Cache giảm chi phí xử lý hoặc giá tính phí theo cơ chế nhà cung cấp, nhưng nội dung được cache thường vẫn thuộc ngữ cảnh logic của yêu cầu. Tuy nhiên, nếu schema nhỏ, cache ổn định và agent chọn công cụ tốt, xây thêm discovery có thể không đáng công.

Có nên đặt giới hạn cứng 5.000 token cho công cụ?

Không nên dùng một con số cho mọi workflow. Hãy phân bổ theo nhu cầu tài liệu, lịch sử và đầu ra. Một tác vụ ngắn có thể chịu được danh mục lớn; tác vụ đọc hợp đồng dài cần dành nhiều context hơn cho dữ liệu. Ngân sách schema nên là quyết định theo workload, có số đo đi kèm.

Gateway mỏng có tự động làm hệ thống nhanh hơn không?

Không. Nó giảm lượng schema mô hình phải tiếp nhận nhưng thêm bước định tuyến, tìm kiếm hoặc tải định nghĩa. Tổng độ trễ có thể tăng ở tác vụ đơn giản. Cần đo thời gian hoàn thành và p95, đồng thời kiểm tra liệu lợi ích tiết kiệm context có bù được lượt khám phá hay không.

Kết luận: ngân sách ngữ cảnh phải có chủ sở hữu

55.000 token là lời nhắc để kiểm tra kiến trúc, không phải lý do kết luận MCP đắt đỏ. Vấn đề nằm ở việc doanh nghiệp có biết mỗi lượt gọi đang mang theo những gì và vì sao hay không.

Hãy giao quyền sở hữu ngân sách schema cho người phụ trách workflow: đo trước, thu hẹp phạm vi, thử lazy loading rồi đánh giá cả chất lượng lẫn tiền. Công cụ tốt không chỉ gọi được; nó phải xuất hiện đúng lúc, với lượng ngữ cảnh vừa đủ.

Tác giả: Cường Nguyễn — Founder AI Ops Solutions | Verified n8n Creator. Kết nối: Facebook · LinkedIn · YouTube · TikTok