AI agent token cost: vì sao xử lý tác vụ trên điện thoại có thể tiết kiệm hơn

Chi phí token không dừng ở một câu trả lời

Khi một người hỏi “AI agent token cost là bao nhiêu?”, câu trả lời dễ bị kéo về bảng giá model. Bảng giá đúng là điểm bắt đầu: các nhà cung cấp như OpenAI công bố giá API theo model và lượng token, còn Google Cloud Vertex AI cũng tính chi phí AI tạo sinh theo model, phương thức xử lý và khối lượng đầu vào, đầu ra. Nhưng với một agent làm việc trên điện thoại, khoản tốn kém thường không nằm ở một lượt hỏi đáp gọn gàng. Nó nằm ở cả chuỗi: hiểu yêu cầu, đọc ngữ cảnh, chọn bước tiếp theo, gọi công cụ, báo trạng thái, chờ người dùng xác nhận, rồi thử lại nếu màn hình hoặc app không phản hồi như dự kiến.

Ví dụ, lệnh “nhắn cho Minh là tôi đến muộn 15 phút, rồi mở bản đồ đến quán cà phê gần công ty” không giống một câu hỏi kiến thức. Agent phải nhận ra người nhận, soạn nội dung, kiểm tra app nhắn tin phù hợp, có thể cần người dùng xác nhận trước khi gửi, sau đó chuyển sang điều hướng. Nếu tất cả đều được mô tả, phân tích và sửa lỗi bằng một model đám mây qua nhiều vòng, token tăng lên ở từng bước nhỏ. Một tác vụ tưởng như đơn giản có thể trở thành nhiều lượt hội thoại nội bộ mà người dùng không nhìn thấy.

Với FoneClaw, chúng tôi nhìn chi phí theo kết quả trên điện thoại, không chỉ theo lượng chữ đi qua model. FoneClaw là Android phone AI agent cho các hành động được hỗ trợ; nghĩa là chúng tôi không đặt mục tiêu để model “suy nghĩ lại toàn bộ thế giới” mỗi lần người dùng muốn làm một việc quen thuộc. Bài Tự động hóa tác vụ Android nhiều bước bằng một lệnh thoại giải thích rõ hơn vì sao một lệnh tự nhiên cần được biến thành chuỗi thao tác có giới hạn, thay vì một cuộc trò chuyện kéo dài mãi.

Token bị hao hụt ở đâu trong một tác vụ điện thoại

Phần rò rỉ đầu tiên là ngữ cảnh. Agent càng không chắc mình đang ở đâu, nó càng cần nhiều mô tả: người dùng đang dùng app nào, màn hình có những nút gì, thông báo nào quan trọng, quyền nào đã được cấp, bước nào vừa thất bại. Nếu mỗi lượt đều phải gửi lại lịch sử dài, ảnh chụp màn hình, mô tả công cụ và phần sửa lời nhắc, chi phí không tăng tuyến tính theo “một yêu cầu”, mà tăng theo số lần agent phải tự định vị.

Phần thứ hai là thử lại. Một agent có thể hiểu đúng mục tiêu nhưng bấm sai vị trí, gặp hộp thoại bất ngờ, thiếu quyền, hoặc mở nhầm cuộc trò chuyện có tên giống nhau. Mỗi lần đó thường sinh thêm token: agent giải thích lỗi, đọc lại trạng thái, đề xuất cách khác, hỏi người dùng xác nhận, rồi chạy lại. Từ góc nhìn người dùng, đó là vài giây chờ. Từ góc nhìn sản phẩm, đó là chi phí model cộng với chi phí hỗ trợ, mất niềm tin và khả năng người dùng bỏ cuộc.

Phần thứ ba là xác nhận và ghi nhận kết quả. Xác nhận là cần thiết, nhất là với tin nhắn, cài đặt, chia sẻ dữ liệu hoặc bất kỳ bước nào có thể gây hậu quả thật. Nhưng nếu hệ thống xác nhận kém thiết kế, agent sẽ hỏi quá nhiều câu mơ hồ: “Bạn có chắc không?”, “Bạn muốn tiếp tục không?”, “Bạn muốn dùng app nào?”. Mỗi câu như vậy vừa làm phiền người dùng vừa tăng lượng token. Thiết kế tốt phải hỏi đúng thời điểm, đúng nội dung và cho người dùng thấy chính xác điều gì sắp xảy ra.

Chúng tôi xem chi phí này như một vấn đề thiết kế, không chỉ là vấn đề mua model rẻ hơn. Nếu bước nào có thể được chuẩn hóa thành hành động Android được hỗ trợ, có quyền rõ và có kết quả kiểm tra được, thì không nên để model suy đoán lại từ đầu. Cách nhìn này cũng liên quan tới niềm tin: trong bài Niềm tin AI agent: Android cục bộ hay đám mây, chúng tôi phân tích vì sao vị trí xử lý, quyền người dùng và khả năng xem lại kết quả đều ảnh hưởng trực tiếp đến mức độ tin cậy.

Giới hạn tốn kém của agent chỉ chạy trên đám mây

Agent chỉ chạy trên đám mây rất mạnh khi cần đọc tài liệu, viết nội dung, phân tích dữ liệu hoặc tổng hợp thông tin từ dịch vụ được kết nối. Vấn đề xuất hiện khi tác vụ thật nằm trên điện thoại: mở đúng app, chọn đúng cuộc trò chuyện, đổi một thiết lập, phản hồi một thông báo, chụp màn hình, hoặc chuyển từ app này sang app khác. Nếu agent chỉ có thể nói người dùng nên làm gì, nó vẫn tốn token để lập kế hoạch nhưng không trực tiếp giảm được số lần chạm trên thiết bị.

Một ví dụ thường gặp là xử lý thông báo. Người dùng không muốn nghe một bài tóm tắt dài về mọi thông báo; họ muốn biết tin nào cần trả lời, tin nào có thể bỏ qua và tin nào cần mở ngay. Agent đám mây có thể phân loại nếu được cung cấp đủ nội dung, nhưng để thực sự mở đúng app, chuẩn bị phản hồi và chờ xác nhận gửi, hệ thống vẫn phải có cách tương tác an toàn với điện thoại. Nếu thiếu phần này, agent có thể tiêu tốn nhiều token mô tả kế hoạch mà kết quả cuối cùng vẫn phụ thuộc vào người dùng tự thao tác.

Cloud-only còn dễ tạo chi phí ẩn ở bước “dịch” trạng thái thiết bị sang văn bản. Màn hình điện thoại vốn là môi trường nhiều biến động: app cập nhật giao diện, nút đổi vị trí, pop-up hiện bất ngờ, mạng chập chờn, quyền chưa được cấp. Khi mọi thứ phải được gửi lên để model diễn giải, token không chỉ dùng cho ý định của người dùng mà còn dùng để kể lại toàn bộ trạng thái giao diện. Với một số tác vụ, đó là cách hợp lý. Với các thao tác lặp lại hằng ngày, đó là khoản chi không cần thiết nếu thiết bị có thể xử lý phần hành động được hỗ trợ một cách rõ ràng hơn.

Điều này không có nghĩa mọi thứ nên tách khỏi đám mây. Có những yêu cầu cần năng lực ngôn ngữ mạnh, tri thức rộng hoặc phân tích phức tạp. Điểm chúng tôi nhấn mạnh là không nên dùng model đám mây như cách duy nhất để điều khiển từng bước nhỏ trên điện thoại. Chi phí tốt hơn thường đến từ việc phân vai: model hiểu ý định và xử lý phần cần suy luận; điện thoại đảm nhận các thao tác được hỗ trợ, có quyền và có trạng thái rõ.

Xử lý gần điện thoại tiết kiệm ở phần nào

“Local AI agent cost” không nên được hiểu là miễn phí hoặc luôn rẻ hơn trong mọi trường hợp. Điện thoại vẫn có giới hạn phần cứng, pin, quyền truy cập và khả năng xử lý. Một số tác vụ vẫn cần cloud intelligence để hiểu nội dung dài, dịch ngôn ngữ, so sánh dữ liệu hoặc tạo câu trả lời chất lượng cao. Nhưng khi tác vụ là mở app, đi tới đúng màn hình, thao tác theo lệnh đã được hỗ trợ, kiểm tra trạng thái và trả kết quả, xử lý gần thiết bị có thể giảm bớt các vòng mô tả, gửi lại ngữ cảnh và thử lại không cần thiết.

Giá trị tiết kiệm rõ nhất nằm ở các chuỗi quen thuộc. Nếu người dùng thường nói “mở bản đồ về nhà”, “soạn tin nhắn cho An”, “bật chế độ im lặng trong một giờ”, hoặc “mở app cần dùng cho cuộc họp”, hệ thống không cần đối xử với mỗi lần như một bài toán mới hoàn toàn. Một phone agent tốt nên nhận ra mẫu tác vụ, kiểm tra điều kiện hiện tại, yêu cầu quyền khi cần, rồi thực hiện trong phạm vi đã hỗ trợ. Khi trạng thái được xử lý trên thiết bị, model không phải tiêu tốn nhiều token để đọc lại toàn bộ câu chuyện.

Tuy nhiên, tiết kiệm không được đánh đổi bằng quyền kiểm soát. Tài liệu Android về quyền riêng tư và bảo mật cho thấy các quyền trên thiết bị là một phần quan trọng của cách Android bảo vệ người dùng. Vì vậy, một agent chạy gần điện thoại vẫn phải tôn trọng quyền mà người dùng cấp, không vượt qua cơ chế bảo vệ của hệ điều hành và không tự ý làm việc nhạy cảm. Với chúng tôi, chi phí thấp nhưng thiếu xác nhận không phải là tối ưu; đó là rủi ro được che bằng trải nghiệm nhanh.

Doanh nghiệp cũng nhìn thấy bài toán tương tự ở quy mô lớn. Nếu mỗi nhân viên dùng agent cho nhiều tác vụ nhỏ trong ngày, vòng lặp lỗi và xác nhận kém có thể biến thành chi phí vận hành đáng kể. Bài Bảo mật AI agent cho doanh nghiệp trên điện thoại đi sâu hơn vào phần kiểm soát và quản trị, nhưng nguyên tắc chi phí cũng giống nhau: càng ít mơ hồ ở bước hành động, càng ít phải dùng token và thời gian con người để sửa sai.

Cách FoneClaw nhìn chi phí của phone agent

Trong FoneClaw, chúng tôi không xem phone agent như một chatbot được gắn thêm vài nút bấm. Nếu người dùng đã nói rõ mục tiêu và tác vụ nằm trong danh sách được hỗ trợ, phần hành động nên có tính ổn định: biết cần quyền nào, biết khi nào phải hỏi, biết trạng thái hoàn tất trông như thế nào và biết khi nào nên dừng. Cách này giúp giảm chi phí vì hệ thống không phải lập kế hoạch lại từ đầu cho những việc vốn đã có quy trình.

Ví dụ, với một lệnh nhắn tin, phần cần suy luận là hiểu người nhận, ý định và nội dung. Phần cần kiểm soát là chọn đúng kênh, hiển thị bản nháp, yêu cầu xác nhận trước khi gửi nếu cần. Nếu agent cứ mỗi lần lại phân tích toàn bộ giao diện như chưa từng biết loại tác vụ này, chi phí sẽ phình lên. Ngược lại, nếu hành động được thiết kế thành chuỗi có giới hạn, token chỉ nên tập trung vào phần ngôn ngữ, ngoại lệ và quyết định thật sự cần model.

Chúng tôi cũng không hứa FoneClaw điều khiển mọi app hoặc bỏ qua quyền hệ thống. Đó không phải là cách xây dựng sản phẩm bền vững. Những hành động nhạy cảm phải được phân biệt với tác vụ thấp rủi ro; những bước có hậu quả phải có xác nhận; kết quả cần hiển thị để người dùng biết agent đã làm gì. Khi một tác vụ không đủ rõ, không được hỗ trợ hoặc thiếu quyền, cách đúng là hỏi lại hoặc dừng, không phải tiếp tục tiêu token để đoán.

Cách tiếp cận này làm chi phí dễ dự báo hơn. Với cloud-only agent, mỗi thất bại có thể kéo theo một chuỗi hội thoại mới. Với phone agent có hành động được giới hạn, nhiều lỗi có thể được phát hiện sớm: thiếu quyền, không tìm thấy app, tên liên hệ không rõ, trạng thái màn hình không phù hợp. Dừng sớm đôi khi là quyết định tiết kiệm nhất, vì nó tránh một vòng thử sai dài và giữ người dùng trong vùng kiểm soát.

Cách tự ước tính tổng chi phí của một AI agent

Nếu bạn đang xây hoặc mua một AI agent, đừng chỉ hỏi “mỗi triệu token giá bao nhiêu?”. Hãy hỏi tác vụ hoàn chỉnh cần bao nhiêu vòng để đi từ ý định đến kết quả. Một agent rẻ trên bảng giá nhưng thường xuyên phải hỏi lại, gửi ảnh màn hình, chạy thử rồi sửa sai có thể đắt hơn một hệ thống dùng model mạnh hơn nhưng có phần thao tác rõ ràng và ít vòng lặp.

Có thể đánh giá theo năm nhóm chi phí. Thứ nhất là token đầu vào và đầu ra: yêu cầu người dùng, lịch sử, ngữ cảnh thiết bị, mô tả công cụ, phản hồi và bản ghi trạng thái. Thứ hai là chi phí thao tác: agent có thực sự làm được việc trên thiết bị hay chỉ hướng dẫn người dùng tự làm. Thứ ba là số lần thử lại: mỗi lỗi giao diện, thiếu quyền hoặc hiểu nhầm đều tạo thêm chi phí. Thứ tư là thời gian kiểm tra của con người: nếu người dùng phải đọc lại quá nhiều, lợi ích tự động hóa giảm mạnh. Thứ năm là gánh nặng hỗ trợ: tác vụ sai, gửi nhầm, mở nhầm app hoặc không rõ đã hoàn tất hay chưa đều tạo chi phí sau đó.

Một checklist thực tế nên gồm các câu hỏi sau: tác vụ này có lặp lại đủ nhiều để đáng chuẩn hóa không; phần nào thật sự cần model suy luận; phần nào có thể chạy bằng hành động Android được hỗ trợ; bước nào cần xác nhận của người dùng; lỗi nào phải dừng ngay; kết quả có được hiển thị rõ không; và có cách xem lại điều gì đã xảy ra không. Nếu một sản phẩm không trả lời được các câu hỏi này, bảng giá token thấp chưa đủ để kết luận nó rẻ.

Quan điểm của chúng tôi là chi phí tốt nhất đến từ sự rõ ràng. Cloud AI rất hữu ích cho suy luận, viết và hiểu ngôn ngữ. Điện thoại lại là nơi nhiều tác vụ cá nhân thật sự diễn ra: tin nhắn, thông báo, app, cài đặt và trạng thái thiết bị. FoneClaw được xây theo hướng kết nối hai phần đó trong phạm vi được hỗ trợ: dùng AI để hiểu ý định, dùng quyền người dùng cấp để thao tác đúng nơi cần thiết, hỏi trước hành động nhạy cảm và trả lại kết quả có thể kiểm tra. Khi agent làm ít việc mơ hồ hơn, người dùng tiết kiệm thời gian, đội sản phẩm tiết kiệm chi phí và trải nghiệm cũng đáng tin hơn.