Agent cần “bảng xăng” và “phanh”: Một bài báo, bóc trần “bức tranh mơ hồ” của Agent

null

Hãy tưởng tượng cảnh này:

Bạn nhờ AI Agent giúp sửa một lỗi trong mã. Nó mở dự án, đọc 20 tệp, chỉnh sửa, chạy thử nghiệm, không qua, lại chỉnh sửa, chạy lại, vẫn không qua… lặp đi lặp lại hơn chục vòng, cuối cùng—vẫn chưa sửa xong.

Bạn tắt máy tính, thở phào nhẹ nhõm. Rồi nhận được hóa đơn API.

Những con số trên có thể khiến bạn hít một hơi lạnh—Việc AI Agent tự sửa lỗi trong API chính thức ở nước ngoài, mỗi lần chưa sửa xong thường tiêu tốn hơn triệu Token, chi phí có thể lên tới vài chục đến hơn một trăm đô la.

Vào tháng 4 năm 2026, một bài nghiên cứu do Stanford, MIT, Đại học Michigan và các tổ chức khác phối hợp công bố, lần đầu tiên hệ thống hóa “Hộp đen tiêu thụ” của AI Agent trong các nhiệm vụ mã—tiêu tiền rốt cuộc đã đi đâu, có đáng không, có thể dự đoán trước được không, câu trả lời khiến người ta sốc.

Phát hiện thứ nhất: Tốc độ tiêu tiền của Agent viết mã gấp 1000 lần so với đối thoại AI thông thường

Mọi người có thể nghĩ: Cho AI giúp viết mã và để AI trò chuyện về mã, chi phí chắc cũng gần như nhau?

Bài báo so sánh cho thấy:

Lượng Token tiêu thụ trong nhiệm vụ mã của Agentic là khoảng 1000 lần so với hỏi đáp và suy luận mã thông thường.

Chênh lệch đúng ba cấp số nhân.

Tại sao lại như vậy? Bài báo chỉ ra một thực tế—tiền không tiêu vào “viết mã”, mà tiêu vào “đọc mã”.

“Đọc” ở đây không phải là con người đọc mã, mà là trong quá trình làm việc, Agent liên tục cần “cho” mô hình toàn bộ ngữ cảnh dự án, lịch sử thao tác, thông báo lỗi, nội dung tệp—tất cả cùng một lúc. Mỗi vòng hội thoại, ngữ cảnh này lại dài hơn một chút; còn mô hình thì tính phí theo số Token—bạn cho nhiều, trả nhiều hơn.

Ví dụ: giống như mời thợ sửa chữa, mỗi lần hắn động chổi, bạn phải đọc toàn bộ bản vẽ của tòa nhà—đọc bản vẽ tốn kém hơn nhiều so với vặn vít.

Bài báo tóm tắt hiện tượng này bằng một câu: Chi phí của Agent bị đẩy lên bởi sự tăng trưởng theo cấp số nhân của Token đầu vào, chứ không phải Token đầu ra.

Phát hiện thứ hai: Cùng một lỗi, chạy hai lần, chi phí có thể chênh gấp đôi—và lỗi càng đắt, càng không ổn định

Thêm phần khó chịu là tính ngẫu nhiên.

Các nhà nghiên cứu cho một Agent chạy cùng một nhiệm vụ 4 lần, kết quả phát hiện:

Trong các nhiệm vụ khác nhau, nhiệm vụ đắt nhất tiêu tốn khoảng 7 triệu Token nhiều hơn nhiệm vụ rẻ nhất (Hình 2a)

Trong cùng một mô hình, cùng một nhiệm vụ, lần chạy đắt nhất gấp khoảng 2 lần lần rẻ nhất (Hình 2b)

Và nếu so sánh giữa các mô hình khác nhau cho cùng một nhiệm vụ, chênh lệch tiêu thụ cao tới 30 lần

Con số cuối cùng đặc biệt đáng chú ý: Điều này có nghĩa là, sự khác biệt về chi phí giữa chọn đúng và chọn sai mô hình không phải là “đắt hơn chút”, mà là “đắt gấp một cấp số nhân”.

Thêm phần đau lòng nữa—tiêu nhiều không có nghĩa là làm tốt hơn.

Bài báo phát hiện ra một “đường cong hình chữ U”:

Mức chi phí và độ chính xác có xu hướng thấp khi chi phí thấp (có thể do chưa đầu tư đủ), độ chính xác trung bình thường cao, còn chi phí cao thì không tăng nữa mà còn giảm—vào “khu vực bão hòa”.

Tại sao lại như vậy? Bài báo phân tích các thao tác cụ thể của Agent để đưa ra câu trả lời—

Trong các hoạt động tiêu tốn nhiều chi phí, Agent dành phần lớn thời gian cho “làm đi làm lại”.

Nghiên cứu cho thấy, trong các hoạt động tiêu tốn nhiều chi phí, khoảng 50% các thao tác xem và chỉnh sửa tệp là lặp lại—tức là, Agent lặp đi lặp lại đọc cùng một tệp, chỉnh sửa cùng một dòng mã, giống như người đi vòng quanh phòng, càng đi vòng càng chóng mặt, càng chóng mặt càng đi vòng.

Tiền không tiêu vào giải quyết vấn đề, mà tiêu vào “lạc đường”.

Phát hiện thứ ba: Hiệu quả năng lượng của các mô hình khác nhau rõ rệt—GPT-5 tiết kiệm nhất, có mô hình tiêu tốn tới 1,5 triệu Token

Trong thử nghiệm trên SWE-bench Verified tiêu chuẩn ngành (500 vấn đề thực tế trên GitHub), các mô hình lớn tiên tiến nhất được kiểm tra hiệu suất của Agent. Chuyển đổi ra đô la, mô hình hiệu quả cao về Token có thể tiêu tốn ít hơn vài chục đô cho mỗi nhiệm vụ. Trong ứng dụng doanh nghiệp—chạy vài trăm nhiệm vụ mỗi ngày—chênh lệch này là tiền thật.

Phát hiện thú vị hơn nữa: Hiệu quả Token là “tính cách cố hữu” của mô hình, chứ không phải do nhiệm vụ gây ra.

Các nhà nghiên cứu so sánh tất cả các mô hình đã thành công giải quyết 230 nhiệm vụ và thất bại trong 100 nhiệm vụ, thấy thứ hạng của các mô hình gần như không thay đổi.

Điều này cho thấy: Một số mô hình vốn đã “nói nhiều”, không liên quan nhiều đến độ khó của nhiệm vụ.

Một phát hiện đáng suy ngẫm nữa: Các mô hình thiếu “ý thức dừng lại”.

Trong các nhiệm vụ khó mà tất cả các mô hình đều không thể giải quyết, lý tưởng là Agent nên từ bỏ sớm, chứ không phải cứ tiếp tục tiêu tiền. Nhưng thực tế, các mô hình thường tiêu nhiều Token hơn trong các nhiệm vụ thất bại—chúng không “nhận thua”, chỉ tiếp tục khám phá, thử lại, đọc lại ngữ cảnh, giống như chiếc ô tô không có đèn báo nhiên liệu, chạy đến khi chết máy.

Phát hiện thứ tư: Người dùng nghĩ nhiệm vụ khó, Agent không nhất thiết nghĩ đắt—nhận thức về độ khó hoàn toàn lệch lạc

Bạn có thể nghĩ: ít nhất tôi có thể dự đoán chi phí dựa trên độ khó của nhiệm vụ?

Các bài báo mời các chuyên gia đánh giá độ khó của 500 nhiệm vụ, rồi so sánh với lượng Token thực tế tiêu thụ của Agent—

Kết quả: mối liên hệ yếu ớt.

Nói đơn giản: nhiệm vụ mà con người nghĩ là cực kỳ khó, Agent có thể dễ dàng làm mà không tốn nhiều tiền; nhiệm vụ nhỏ mà con người nghĩ là dễ, Agent có thể tiêu tốn đến mức nghi ngờ.

Lý do là, con người và AI “nhìn” độ khó theo cách khác nhau:

Con người xem xét: độ phức tạp logic, độ khó thuật toán, yêu cầu hiểu biết nghiệp vụ

AI xem xét: quy mô dự án, số tệp cần đọc, chiều dài khám phá, có thể sửa đi sửa lại cùng một chỗ không

Một chuyên gia nghĩ “chỉ cần sửa một dòng” là lỗi, nhưng Agent có thể phải đọc hiểu toàn bộ cấu trúc mã để xác định dòng đó—chỉ “đọc” thôi đã tiêu tốn lượng Token lớn. Trong khi một người nghĩ “thuật toán phức tạp”, thì AI có thể biết ngay giải pháp tiêu chuẩn, làm nhanh gọn.

Điều này dẫn đến thực tế khó xử: nhà phát triển gần như không thể dự đoán trực quan chi phí chạy của Agent.

Phát hiện thứ năm: Ngay cả mô hình cũng không thể tự tính chính xác chi phí của chính mình

Vì con người còn không đoán chính xác, vậy để AI tự dự đoán thì sao?

Các nhà nghiên cứu thiết kế một thí nghiệm tinh vi: để Agent trước khi bắt đầu sửa lỗi, “kiểm tra” kho mã, rồi dự đoán xem mình sẽ tiêu tốn bao nhiêu Token—nhưng không thực hiện sửa.

Kết quả thế nào?

Tất cả các mô hình đều thất bại hoàn toàn.

Chỉ số dự đoán tốt nhất là của Claude Sonnet-4.5 về mối liên hệ giữa dự đoán Token đầu ra và thực tế—0.39 (tối đa 1.0). Phần lớn các mô hình chỉ đạt từ 0.05 đến 0.34, Gemini-3-Pro thấp nhất, chỉ 0.04—gần như đoán mò.

Thậm chí còn tệ hơn: tất cả các mô hình đều đánh giá thấp lượng Token của chính mình. Trong biểu đồ scatter của Hình 11, hầu hết các điểm nằm dưới “đường dự đoán hoàn hảo”—mô hình nghĩ mình tiêu ít hơn, thực tế lại tiêu nhiều hơn. Và sự đánh giá thấp này còn nặng hơn khi không có ví dụ minh họa.

Điều trớ trêu hơn nữa: việc dự đoán cũng tốn tiền.

Dự đoán của Claude Sonnet-3.7 và Sonnet-4 thậm chí còn tốn gấp hơn 2 lần chi phí nhiệm vụ. Nghĩa là, để chúng “ước lượng giá”, còn đắt hơn làm luôn.

Kết luận của bài báo rất rõ ràng:

Hiện tại, các mô hình tiên tiến không thể dự đoán chính xác lượng Token của chính mình. Nhấn “Chạy Agent” giống như mở hộp bí ẩn—hóa đơn mới biết đã tiêu bao nhiêu.

Sau khoản “bất minh” này, còn ẩn chứa một vấn đề lớn hơn của ngành

Bạn có thể hỏi: Những phát hiện này có ý nghĩa gì với doanh nghiệp?

1. Mô hình định giá theo tháng, dựa trên “đặt hàng”, đang bị Agent xé toạc

Bài báo chỉ ra, lý do ChatGPT Plus và các dịch vụ đăng ký khác khả thi là vì lượng Token tiêu thụ trong đối thoại thông thường khá kiểm soát được, dự đoán được. Nhưng nhiệm vụ của Agent hoàn toàn phá vỡ giả định này—một nhiệm vụ có thể bị vòng lặp làm tiêu tốn hàng triệu Token.

Điều này có nghĩa, mô hình định giá theo gói cố định có thể không còn phù hợp cho các trường hợp Agent, còn tính phí theo lượng tiêu thụ (Pay-as-you-go) vẫn là lựa chọn khả thi trong thời gian dài. Nhưng vấn đề là—việc sử dụng không thể dự đoán trước.

2. Hiệu quả Token nên trở thành “thước đo thứ ba” khi chọn mô hình

Thông thường, doanh nghiệp chọn mô hình dựa trên hai tiêu chí: năng lực (có làm được không) và tốc độ (làm nhanh hay chậm). Bài báo đề xuất thêm một tiêu chí quan trọng không kém: Hiệu quả năng lượng (tiêu bao nhiêu để làm xong).

Một mô hình có năng lực hơi kém hơn nhưng hiệu quả gấp 3 lần có thể mang lại giá trị kinh tế lớn hơn trong quy mô lớn.

3. Agent cần “bảng đồng hồ nhiên liệu” và “phanh”

Bài báo đề cập một hướng phát triển tiềm năng—Chính sách sử dụng công cụ “nhận thức ngân sách” (Budget-aware tool-use policies). Nói đơn giản, trang bị cho Agent một “bảng đồng hồ nhiên liệu”: khi tiêu thụ Token gần đến giới hạn, buộc nó dừng khám phá vô ích, chứ không cứ chạy đến cùng.

Hiện tại, hầu hết các framework Agent đều thiếu cơ chế này.

Vấn đề “tiêu tiền” của Agent không phải là lỗi, mà là thử thách tất yếu của ngành

Bài báo này không chỉ tiết lộ một điểm yếu của một mô hình nào đó, mà còn là thách thức mang tính cấu trúc của toàn bộ mô hình Agent—khi AI tiến từ “hỏi đáp” sang “lập kế hoạch tự chủ, thực thi nhiều bước, điều chỉnh liên tục”, tính không dự đoán của tiêu thụ Token gần như là điều tất yếu.

Tin vui là, đây là lần đầu tiên có ai đó hệ thống tính toán rõ ràng khoản “bất minh” này. Với dữ liệu này, nhà phát triển có thể chọn mô hình sáng suốt hơn, thiết lập ngân sách hợp lý, thiết kế cơ chế dừng phù hợp; các nhà cung cấp mô hình cũng có hướng tối ưu mới—không chỉ làm mạnh hơn, mà còn tiết kiệm hơn.

Dù sao, trước khi AI Agent thực sự đi vào sản xuất trong hàng nghìn ngành nghề, việc tiêu tiền rõ ràng, minh bạch còn quan trọng hơn việc viết từng dòng mã đẹp đẽ.