Hãy tưởng tượng tình huống này:
Bạn yêu cầu một tác nhân AI sửa lỗi mã. Nó mở dự án, đọc 20 tệp, thực hiện một số thay đổi, chạy thử nghiệm, thất bại, thực hiện thêm thay đổi, chạy lại, vẫn thất bại... Sau khi trải qua quá trình này hơn mười lần, cuối cùng—nó vẫn không sửa được lỗi.
Bạn tắt máy tính và thở phào nhẹ nhõm. Rồi bạn nhận được hóa đơn API.
Những con số trên có thể khiến bạn sụp đổ– khi một tác nhân AI tự động sửa lỗi trên các API chính thức ở nước ngoài, lần một nhiệm vụ chưa được sửa lỗi cũng có thể tiêu tốn hàng triệu token, với chi phí dao động từ vài chục đến hơn một trăm đô la Mỹ.
Vào tháng 4 năm 2026, một bài nghiên cứu được công bố chung bởi Stanford, MIT, Đại học Michigan và các trường khác đã lần hé mở một cách có hệ thống "hộp đen" về mức tiêu thụ của các tác nhân AI trong nhiệm vụ lập trình — chính xác thì tiền được chi tiêu vào đâu, liệu có đáng giá hay không, và liệu có thể dự đoán trước được hay không. Câu trả lời thật đáng kinh ngạc.
Phát hiện 1: Tốc độ mà các tác nhân xử lý mã lệnh nhanh hơn 1000 lần so với tốc độ hội thoại thông thường của trí tuệ nhân tạo.
Có lẽ bạn nghĩ rằng chi phí để AI viết mã hộ bạn và để AI thảo luận với bạn về mã nguồn sẽ xấp xỉ nhau, đúng không?
Bài báo trình bày một sự so sánh cho thấy:
Lượng token tiêu thụ cho nhiệm vụ mã hóa tự động cao gấp khoảng 1.000 lần so với nhiệm vụ trả lời câu hỏi mã hóa và suy luận mã hóa thông thường.
Sự khác biệt lên tới ba bậc độ lớn.
Tại sao lại như vậy? Bài báo chỉ ra một thực tế — tiền không được chi cho việc “viết mã”, mà là cho việc “đọc mã”.
"Việc đọc" ở đây không đề cập đến việc con người đọc mã, mà là việc Agent liên tục cung cấp cho mô hình toàn bộ ngữ cảnh dự án, lịch sử hoạt động, thông báo lỗi và nội dung tệp trong suốt quy trình làm việc. Mỗi vòng đối thoại bổ sung sẽ mở rộng ngữ cảnh này; và mô hình được tính phí dựa trên số lượng token — bạn cung cấp càng nhiều, bạn càng phải trả nhiều tiền.
Để dễ hình dung hơn: điều này giống như việc thuê một thợ sửa chữa mà anh ta bắt bạn đọc toàn bộ bản vẽ thiết kế của tòa nhà trước khi anh ta bắt đầu động tay vào việc — chi phí đọc bản vẽ đắt hơn nhiều so với chi phí siết chặt một con ốc vít.
Bài báo tóm tắt hiện tượng này trong một câu: điều thúc đẩy chi phí của Agent là sự tăng trưởng theo cấp số nhân của các token đầu vào, chứ không phải token đầu ra.
Phát hiện 2: Đối với cùng một lỗi, việc chạy lỗi đó lần có thể dẫn đến sự khác biệt về chi phí lên đến 100%—và lỗi càng tốn kém thì độ ổn định càng thấp.
Điều đáng lo ngại hơn nữa là tính ngẫu nhiên.
Các nhà nghiên cứu đã chạy cùng một tác nhân trên cùng một nhiệm vụ bốn lần và nhận thấy rằng:
- Trong số nhiệm vụ khác nhau, nhiệm vụ tốn kém nhất tiêu tốn nhiều hơn khoảng 7 triệu token so với nhiệm vụ rẻ nhất (Hình 2a).
- Trong lần lần chạy cùng một mô hình và cùng một nhiệm vụ , lần chạy tốn kém nhất có chi phí xấp xỉ gấp đôi so với lần chạy rẻ nhất (Hình 2b).
- Tuy nhiên, khi so sánh cùng một nhiệm vụgiữa các mô hình khác nhau , mức tiêu thụ tài nguyên cao nhất và thấp nhất có thể chênh lệch tới 30 lần.
Con số cuối cùng đặc biệt đáng chú ý: nó có nghĩa là sự khác biệt về chi phí giữa việc chọn đúng mô hình và chọn sai mô hình không phải là "đắt hơn một chút", mà là "đắt hơn gấp nhiều lần".
Điều đáng thất vọng hơn nữa là chi tiêu nhiều không nhất thiết đồng nghĩa với việc làm tốt công việc.
Bài báo đã phát hiện ra một đường cong hình chữ U sụp đổ:
Xu hướng độ chính xác dựa trên mức chi phí: Chi phí thấp: Độ chính xác thấp (có thể do đầu tư không đủ) ; Chi phí trung bình: Độ chính xác cao (thường là cao nhất); Chi phí cao: Độ chính xác giảm thay vì tăng, đạt đến "mức bão hòa".
Tại sao điều này lại xảy ra? Bài báo đưa ra câu trả lời bằng cách phân tích các hoạt động cụ thể của tác nhân—
Trong hoạt động tốn kém của mình, người đại lý dành lượng lớn thời gian cho "công việc lặp đi lặp lại".
Nghiên cứu đã chỉ ra rằng trong các hoạt động có chi phí cao, khoảng 50% các thao tác xem và chỉnh sửa tập tin là lặp đi lặp lại — nghĩa là, tác nhân liên tục đọc cùng một tập tin và liên tục chỉnh sửa cùng một dòng mã, giống như một người đang quay tròn trong phòng, càng ngày càng chóng mặt, và càng chóng mặt thì càng quay mạnh hơn.
Số tiền đó không được dùng để giải quyết vấn đề, mà lại được dùng để "lạc lối".
Phát hiện 3: "Tỷ lệ hiệu quả năng lượng" thay đổi rất lớn giữa các mô hình — GPT-5 là mô hình tiết kiệm năng lượng nhất, trong khi một số mô hình khác tiêu tốn nhiều hơn 1,5 triệu token.
Bài báo đã kiểm tra hiệu suất của tám mô hình quy mô lớn tiên tiến trên bộ dữ liệu chuẩn ngành SWE-bench Verified (500 vấn đề thực tế trên GitHub). Quy đổi sang đô la Mỹ, sự khác biệt giữa một mô hình dựa trên token hiệu quả hơn và một mô hình kém hiệu quả hơn chỉ là vài chục đô la cho mỗi nhiệm vụ. Trong các ứng dụng cấp doanh nghiệp—chạy hàng trăm nhiệm vụ mỗi ngày—sự khác biệt này sẽ tạo ra lợi nhuận đáng kể.
Một phát hiện thậm chí còn thú vị hơn là hiệu quả của token là một "đặc tính vốn có" của mô hình, chứ không phải là kết quả của nhiệm vụ.
Các nhà nghiên cứu đã so sánh nhiệm vụ mà tất cả các mô hình đều giải quyết thành công (230 nhiệm vụ) với nhiệm vụ mà tất cả các mô hình đều thất bại (100 nhiệm vụ), và nhận thấy rằng thứ hạng tương đối của các mô hình hầu như không thay đổi.
Điều này cho thấy một số mô hình vốn dĩ "thích nói", và điều này hầu như không liên quan gì đến độ khó nhiệm vụ.
Một phát hiện đáng suy ngẫm khác là mô hình này thiếu "nhận thức về lệnh dừng lỗ".
Khi đối diện một nhiệm vụ khó khăn mà không mô hình nào có thể giải quyết được, một tác nhân lý tưởng nên từ bỏ càng sớm càng tốt, thay vì tiếp tục lãng phí tiền bạc. Nhưng trên thực tế, các mô hình thường tiêu tốn nhiều token hơn cho nhiệm vụ thất bại — chúng không "từ bỏ", mà chỉ tiếp tục khám phá, thử lại và đọc lại ngữ cảnh, giống như một chiếc xe không có đèn báo nhiên liệu, cứ thế chạy cho đến khi hỏng.
Phát hiện 4: Những gì con người thấy khó khăn, các tác nhân không nhất thiết thấy tốn kém — một sự sai lệch hoàn toàn trong nhận thức về độ khó.
Bạn có thể nghĩ: Ít nhất tôi cũng có thể ước tính chi phí dựa trên độ khó của nhiệm vụ, phải không?
Bài báo đã yêu cầu các chuyên gia đánh giá độ khó của 500 nhiệm vụ, sau đó so sánh kết quả với lượng token mà tác nhân thực tế đã tiêu thụ.
Kết quả: Giữa hai yếu tố này chỉ có mối tương quan yếu.
Nói một cách đơn giản: nhiệm vụ mà con người thấy vô cùng khó khăn thì các tác nhân có thể dễ dàng xử lý với chi phí tối thiểu; nhiệm vụ con người cho là dễ như ăn bánh lại có thể khiến các tác nhân tiêu tốn rất nhiều tiền và tự đặt câu hỏi về sự tồn tại của chính mình.
Điều này là do độ khó của những gì con người và trí tuệ nhân tạo "nhìn thấy" là khác nhau về bản chất:
- Con người xem xét : độ phức tạp logic, độ khó của thuật toán và ngưỡng hiểu biết về việc kinh doanh.
- Tác nhân sẽ xem xét : quy mô của dự án, số lượng tệp cần đọc, độ dài của đường dẫn tìm kiếm và liệu cùng một tệp có bị sửa đổi nhiều lần hay không.
Một lỗi mà chuyên gia con người cho rằng có thể được khắc phục bằng cách "thay đổi một dòng mã" có thể đòi hỏi một hệ thống tự động phải hiểu toàn bộ cấu trúc mã nguồn để xác định chính xác dòng mã đó — và chỉ việc "đọc" mã nguồn thôi cũng đã tiêu tốn lượng lớn token. Mặt khác, một vấn đề thuật toán mà con người cho là "phức tạp về mặt logic" có thể được giải quyết bởi một hệ thống tự động biết được giải pháp chuẩn, cho phép khắc phục lỗi nhanh chóng.
Điều này dẫn đến một thực tế khó xử: hầu như không thể nào các nhà phát triển có thể ước tính một cách trực quan chi phí vận hành của một tác nhân.
Phát hiện 5: Ngay cả bản thân mô hình cũng không thể tính toán chính xác chi phí.
Vì con người không thể dự đoán chính xác, tại sao không để trí tuệ nhân tạo tự đưa ra dự đoán?
Các nhà nghiên cứu đã thiết kế một thí nghiệm thông minh: trước khi thực sự bắt đầu sửa lỗi, tác nhân "kiểm tra" mã nguồn và ước tính số lượng token cần tiêu thụ — nhưng không thực sự thực hiện việc sửa lỗi.
Kết quả là gì?
Tất cả các mô hình đều bị xóa sổ.
Kết quả tốt nhất thuộc về Claude Sonnet-4.5, với độ chính xác dự đoán là 0,39 (trên thang điểm 1,0) cho mã thông báo đầu ra. Hầu hết các mô hình có độ chính xác dự đoán nằm trong khoảng từ 0,05 đến 0,34, với Gemini-3-Pro có độ chính xác thấp nhất chỉ ở mức 0,04 — về cơ bản là một phỏng đoán.
Điều nực cười hơn nữa là tất cả các mô hình đều đánh giá thấp một cách có hệ thống mức tiêu thụ token của họ. Trong biểu đồ phân tán ở Hình 11, hầu hết các điểm dữ liệu đều nằm dưới "đường dự đoán hoàn hảo"—các mô hình cho rằng họ "sẽ không tiêu nhiều đến thế", trong khi thực tế họ đã tiêu nhiều hơn đáng kể. Hơn nữa, sai lệch do đánh giá thấp này thậm chí còn rõ rệt hơn nếu không có ví dụ minh họa .
Điều trớ trêu hơn nữa là chính việc dự đoán lại tốn tiền.
Chi phí dự đoán của Claude Sonnet-3.7 và Sonnet-4 thậm chí còn cao hơn gấp đôi chi phí thực tế của nhiệm vụ. Nói cách khác, việc nhờ họ "ước tính" chi phí còn tốn kém hơn cả việc thực sự làm công việc đó.
Kết luận của bài báo rất đơn giản:
Hiện tại, các mô hình tiên tiến nhất vẫn chưa thể dự đoán chính xác việc sử dụng token của chính chúng. Việc nhấn "Chạy Agent" giống như mở một chiếc hộp bí ẩn - bạn chỉ biết mình đã chi bao nhiêu khi nhận được hóa đơn.
Đằng sau những mánh khóe kế toán mờ ám này là một vấn đề lớn hơn nhiều của ngành.
Đọc đến đây, bạn có thể thắc mắc: Những phát hiện này có ý nghĩa gì đối với các doanh nghiệp?
1. Mô hình định giá "đăng ký hàng tháng" đang bị các đại lý bẻ khóa.
Bài báo chỉ ra rằng các mô hình đăng ký như ChatGPT Plus khả thi vì mức tiêu thụ token trong các cuộc hội thoại thông thường tương đối dễ kiểm soát và dự đoán. Tuy nhiên, nhiệm vụ của tác nhân lại hoàn toàn phá vỡ giả định này — một nhiệm vụ duy nhất có thể tiêu tốn một lượng token khổng lồ vì tác nhân bị kẹt trong một vòng lặp.
Điều này có nghĩa là mô hình định giá theo thuê bao thuần túy có thể không bền vững đối với các kịch bản sử dụng dịch vụ tổng đài , và mô hình trả tiền theo mức sử dụng sẽ vẫn là lựa chọn khả thi nhất trong một thời gian dài. Tuy nhiên, vấn đề với mô hình trả tiền theo mức sử dụng là việc sử dụng thực tế lại không thể dự đoán được.
2. Hiệu quả của token nên là "chỉ báo thứ ba" để lựa chọn mô hình.
Theo truyền thống, các công ty lựa chọn mô hình dựa trên hai khía cạnh: khả năng (liệu chúng có thể thực hiện được hay không) và tốc độ (chúng có thể thực hiện nhanh như thế nào). Bài báo này giới thiệu thêm một khía cạnh thứ ba quan trọng không kém: hiệu quả năng lượng (cần bao nhiêu nỗ lực để hoàn thành) .
Trong một kịch bản quy mô lớn, một mô hình có khả năng thấp hơn một chút nhưng hiệu quả gấp ba lần có thể có giá trị kinh tế cao hơn so với mô hình "mạnh nhất nhưng đắt nhất".
3. Đặc vụ cần cả "đồng hồ đo nhiên liệu" và "phanh".
Bài báo đề cập đến một hướng đi đáng chú ý trong tương lai — Chính sách sử dụng công cụ có tính đến ngân sách . Nói một cách đơn giản, đó là việc trang bị cho tác nhân một "đồng hồ đo nhiên liệu": khi mức tiêu thụ token gần đạt đến ngân sách, nó sẽ buộc tác nhân phải ngừng việc khám phá không hiệu quả thay vì đốt cháy tài nguyên.
Hiện nay, hầu hết các framework agent phổ biến đều thiếu cơ chế này.
Vấn đề "đốt tiền" của các đại lý không phải là lỗi phần mềm, mà là một khó khăn tất yếu trong quá trình phát triển của ngành.
Bài viết này không chỉ ra những thiếu sót của một mô hình cụ thể nào, mà tập trung vào những thách thức về cấu trúc của toàn bộ mô hình Tác nhân – khi AI phát triển từ "hỏi và đáp" sang "lập kế hoạch tự động, thực thi nhiều bước và gỡ lỗi lặp đi lặp lại", tính không thể dự đoán được của việc tiêu thụ token trở nên gần như không thể tránh khỏi.
Tin tốt là đây là lần đầu tiên có người đưa tình trạng phức tạp này ra ánh sáng và giải quyết nó một cách có hệ thống . Với dữ liệu này, các nhà phát triển có thể đưa ra những lựa chọn sáng suốt hơn về mô hình, lập ngân sách và thiết kế các cơ chế giảm thiểu tổn thất; các nhà sản xuất mô hình cũng có một hướng đi mới để tối ưu hóa—không chỉ làm cho chúng mạnh mẽ hơn mà còn tiết kiệm chi phí hơn.
Xét cho cùng, trước khi các tác nhân AI thực sự được ứng dụng vào hoàn cảnh sản xuất của nhiều ngành công nghiệp khác nhau, việc đảm bảo mọi khoản chi tiêu đều được thực hiện minh bạch quan trọng hơn việc viết từng dòng mã một cách hoàn hảo. (Bài viết này được đăng lần đầu trên ứng dụng TMTPost, tác giả: Silicon Valley Tech news, biên tập viên: Zhao Hongyu)
Lưu ý: Bài viết này dựa trên bài báo chưa được xuất bản *How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks* (Bai, Huang, Wang, Sun, Mihalcea, Brynjolfsson, Pentland, Pei) được đăng trên arXiv vào ngày 24 tháng 4 năm 2026. Các tác giả đến từ các tổ chức bao gồm Đại học Virginia, Đại học Stanford, MIT và Đại học Michigan. Nghiên cứu này chưa được bình duyệt.
