Định tuyến mô hình cho tác nhân điện thoại: Kimi, DeepSeek, GLM và FoneClaw
Cách chọn mô hình cho tác nhân Android theo độ tin cậy gọi công cụ, độ trễ, chi phí LLM, ngữ cảnh, quyền riêng tư, fallback và bằng chứng hành động trong FoneClaw.
- Định tuyến mô hình cho tác nhân điện thoại là chọn mô hình theo từng tác vụ Android, không chọn một người thắng cố định theo bảng xếp hạng.
- Năm tín hiệu bền vững hơn tên model là độ tin cậy gọi công cụ, độ trễ, chi phí LLM, độ dài ngữ cảnh và ranh giới riêng tư.
- Kimi, DeepSeek và GLM là các ứng viên đáng đưa vào chính sách routing hiện tại, nhưng mỗi lựa chọn cần được kiểm thử trong vòng hành động Android thật.
- Trong FoneClaw, mô hình dẫn dắt hiểu yêu cầu và lập kế hoạch; FoneClaw giữ lớp thực thi Android có quản trị với 100+ built-in tools, phê duyệt, trạng thái hiển thị, dừng và phục hồi quyền.
Chọn tuyến mô hình, không chọn một nhà vô địch cố định
Định tuyến mô hình cho tác nhân điện thoại là cách chọn mô hình AI theo từng loại tác vụ Android: tác vụ nào cần tốc độ, tác vụ nào cần ngữ cảnh dài, tác vụ nào cần lập kế hoạch ổn định, tác vụ nào cần chi phí thấp, và tác vụ nào cần đường xử lý riêng tư hơn. Với phone agent, câu hỏi đúng không phải “mô hình nào mạnh nhất?”, mà là “tuyến mô hình nào đủ tin cậy cho tác vụ này trên thiết bị này?”.
Một bảng xếp hạng mô hình có thể hữu ích để đọc xu hướng, nhưng nó không đo trọn vòng hành động trên điện thoại. Mô hình có thể trả lời hay mà vẫn tạo đối số công cụ sai, nhầm tên liên hệ, không biết hỏi lại khi thiếu quyền, hoặc lập kế hoạch quá dài cho một thao tác cần phản hồi nhanh. Ngược lại, một mô hình nhỏ hơn có thể phù hợp cho tác vụ ngắn, lặp lại, ít rủi ro nếu nó ổn định và tiết kiệm.
Chúng tôi nhìn model routing trong FoneClaw như một quyết định sản phẩm, không phải cuộc đua tên tuổi. Mô hình chịu trách nhiệm hiểu yêu cầu, suy luận và chuẩn bị kế hoạch. Lớp thực thi Android là chuyện riêng: FoneClaw phải kiểm tra công cụ được hỗ trợ, quyền thiết bị, trạng thái app, điểm phê duyệt và kết quả hiển thị. Nếu bạn cần phần thiết lập endpoint chi tiết, bài Kết nối API mô hình AI với tác nhân Android trong FoneClaw đi sâu hơn vào cách nối một tuyến mô hình tương thích với phone agent.
Ví dụ, yêu cầu “mở bản đồ về nhà” ưu tiên độ trễ và định vị tác vụ rõ. Yêu cầu “đọc tài liệu này rồi chuẩn bị email trả lời” cần ngữ cảnh dài và chất lượng lập luận. Yêu cầu “chuẩn bị tin nhắn cho mẹ, để tôi xem trước” cần tiếng Việt tự nhiên, chọn đúng liên hệ và bước xác nhận. Ba tác vụ đó không cần cùng một tuyến mô hình.
Định tuyến theo độ tin cậy, độ trễ, chi phí, ngữ cảnh và riêng tư
Một chính sách định tuyến mô hình AI bền vững nên bắt đầu bằng năm tín hiệu: độ tin cậy gọi công cụ, độ trễ, chi phí LLM, ngữ cảnh và quyền riêng tư. Những tín hiệu này giữ giá trị lâu hơn tên model, vì model availability, giá và hành vi đầu ra thay đổi thường xuyên. Với tác nhân Android, năm tín hiệu còn phải được đo trong tác vụ thật, không chỉ trong hộp chat.
| Tín hiệu routing | Điều cần đo | Ảnh hưởng tới tác nhân điện thoại |
|---|---|---|
| Độ tin cậy gọi công cụ | Mô hình có tạo đúng schema, đúng đối số, đúng thứ tự và biết hỏi lại khi thiếu dữ liệu không? | Quyết định tác vụ Android có đi tới công cụ đúng hay dừng ở câu trả lời đẹp. |
| Độ trễ | Thời gian từ yêu cầu đến kế hoạch có đủ nhanh cho thao tác điện thoại không? | Mở app, chuẩn bị tin nhắn, tạo nhắc việc và kiểm tra trạng thái cần phản hồi ngắn. |
| Chi phí LLM | Chi phí có phù hợp với số lần chạy hằng ngày, tác vụ nền và fallback không? | Một tuyến rẻ hơn có thể dành cho việc lặp lại nếu vẫn qua được ngưỡng tin cậy. |
| Ngữ cảnh | Mô hình giữ được màn hình, tài liệu, lịch sử yêu cầu và kết quả công cụ đến đâu? | Tác vụ dài cần context lớn; tác vụ ngắn có thể lãng phí nếu dùng mô hình quá nặng. |
| Riêng tư và triển khai | Dữ liệu đi qua online route, on-device route hay provider nào? | Tác vụ có dữ liệu nhạy cảm cần đường xử lý, phê duyệt và lưu vết phù hợp hơn. |
Độ tin cậy gọi công cụ là tín hiệu đầu tiên vì phone agent sống bằng tool contract. Một mô hình tốt cho văn bản chưa chắc ổn định với schema công cụ. Nó phải tạo đối số đúng kiểu, chọn công cụ đúng phạm vi và tránh bịa tham số khi thiếu dữ liệu. Với các bước có tác động như gửi tin, gọi điện, cập nhật lịch hoặc đổi cài đặt, mô hình cũng phải biết khi nào cần dừng để người dùng phê duyệt.
Độ trễ và chi phí đi cùng nhau. Tác vụ điện thoại thường xảy ra trong khoảnh khắc ngắn: bạn đang cầm máy, muốn mở đúng nơi, tạo nhắc việc, kiểm tra trạng thái hoặc chuẩn bị một đoạn trả lời. Nếu tuyến mô hình quá chậm, trải nghiệm mất cảm giác điều khiển. Nếu tuyến mô hình quá đắt, các workflow lặp lại sẽ khó dùng thường xuyên. Bài 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 phân tích sâu hơn phần chi phí khi một phần công việc được xử lý bằng công cụ và trạng thái thiết bị thay vì đổ hết vào token.
Ngữ cảnh lớn hữu ích khi đọc tài liệu dài hoặc giữ một chuỗi thao tác, nhưng không phải lúc nào cũng tốt hơn. Context quá rộng có thể làm tăng chi phí, độ trễ và rủi ro nhiễu thông tin. Chính sách routing nên đặt ngưỡng: tác vụ nào cần context dài, tác vụ nào chỉ cần màn hình hiện tại và một đoạn hội thoại gần nhất. Riêng tư cũng vậy: tác vụ thông thường có thể dùng tuyến online nhanh, còn tác vụ chứa dữ liệu nhạy cảm nên có phê duyệt rõ và cân nhắc route được cấu hình phù hợp.
Kimi, DeepSeek và GLM trong chính sách routing hiện tại
Kimi, DeepSeek và GLM là các ứng viên đáng theo dõi trong chính sách routing hiện tại, nhưng chúng nên được xem như tuyến khả dĩ chứ không phải câu trả lời cố định. thông báo GitHub Changelog về Kimi K3 trong GitHub Copilot cho thấy Kimi K3 đã xuất hiện như một mô hình có thể chọn trong một sản phẩm lập trình chính thống. Đây là tín hiệu khả dụng quan trọng, nhưng khả dụng trong coding không tự chứng minh độ tin cậy gọi công cụ Android.
Với Kimi, giả thuyết routing hợp lý là đưa vào nhóm tác vụ cần lập luận dài, phân tích ngữ cảnh hoặc viết kế hoạch phức tạp, rồi kiểm tra lại bằng tác vụ điện thoại cụ thể. Nếu mô hình giúp hiểu màn hình, tài liệu hoặc workflow nhiều bước tốt hơn, nó có giá trị trong lớp suy luận. Nếu nó chậm hoặc tạo đối số công cụ thiếu ổn định, tuyến đó nên được giới hạn ở tác vụ cần chiều sâu hơn là thao tác tức thời.
DeepSeek thường được nhắc tới trong bối cảnh chi phí và năng lực kỹ thuật. Với phone agent, câu hỏi thực tế là chi phí thấp hơn có giữ được chất lượng lập kế hoạch, tính nhất quán schema và hành vi hỏi lại khi thiếu dữ liệu hay không. Một mô hình rẻ hơn không tự làm giảm độ tin cậy; nó chỉ cần vượt qua ngưỡng chất lượng của tác vụ. Nếu dùng cho việc lặp lại, checklist, tóm tắt ngắn hoặc routing sơ bộ, DeepSeek có thể là ứng viên đáng kiểm tra.
GLM lại phù hợp để xem xét trong nhóm open-weight hoặc các kịch bản cần kiểm soát triển khai sâu hơn. Khi một tổ chức muốn cân bằng latency, quyền riêng tư, chi phí vận hành và khả năng tùy biến, route GLM có thể được kiểm thử cạnh các tuyến online. Nhưng nguyên tắc vẫn giữ nguyên: không lấy tuyên bố benchmark làm bằng chứng hành động Android. Mỗi model phải đi qua cùng một bộ test: hiểu yêu cầu, tạo kế hoạch, gọi công cụ đúng, hiển thị kết quả và phục hồi khi thiếu điều kiện.
Nhóm model này cũng nhắc chúng ta rằng routing phải sống cùng thị trường. Hôm nay Kimi, DeepSeek và GLM là ví dụ nổi bật; ngày mai danh sách có thể thay đổi. Chính sách tốt không khóa vào tên model. Nó khóa vào tiêu chí, ngưỡng kiểm thử và fallback.
Đổi giá API và khả dụng mà không làm hỏng tác vụ
Giá API, quota, vùng triển khai và khả dụng provider có thể thay đổi nhanh hơn vòng đời một bài viết. Vì vậy chính sách độ tin cậy gọi công cụ phải có cơ chế đổi tuyến mà không phá tác vụ. bài Google Developers về API thống nhất cho model routing cho thấy nhu cầu hạ tầng đang đi theo hướng nhiều provider qua một bề mặt quản lý. Đây là tín hiệu hạ tầng, không phải bằng chứng rằng mọi provider đều phù hợp với FoneClaw, nhưng nó phản ánh đúng nhu cầu thực tế: model route cần thay đổi được.
Khi chi phí LLM tăng, đừng chuyển mọi tác vụ sang tuyến rẻ nhất ngay. Hãy phân nhóm. Tác vụ đọc trạng thái, tạo bản nháp ngắn, phân loại yêu cầu hoặc gợi ý bước tiếp theo có thể dùng route tiết kiệm hơn nếu vẫn đạt ngưỡng schema. Tác vụ nhiều bước, có dữ liệu nhạy cảm hoặc dễ gây hậu quả nên giữ tuyến ổn định hơn và yêu cầu phê duyệt rõ. Với phone agent, chi phí thấp chỉ có ý nghĩa khi không làm người dùng sửa lỗi nhiều hơn.
Fallback cũng cần minh bạch. Nếu tuyến chính lỗi, hết quota hoặc chậm, hệ thống có thể chuyển sang tuyến dự phòng cho tác vụ ít rủi ro. Với tác vụ nhạy cảm, việc đổi provider nên được hiển thị hoặc nằm trong cấu hình người dùng đã hiểu trước. FoneClaw ưu tiên để hành động có tác động đi qua phê duyệt, nên routing không trở thành đường tự động lặng lẽ cho việc gửi, gọi, xóa hoặc thay đổi cài đặt.
Sau mỗi thay đổi route, cần chạy lại test Android. Kiểm tra cùng một thiết bị, cùng quyền, cùng app và cùng yêu cầu. Đo thời gian phản hồi, đối số công cụ, số lần hỏi lại, kết quả hiển thị và cách phục hồi. Nếu route mới rẻ hơn nhưng thường xuyên chọn sai công cụ, nó chỉ chuyển chi phí từ API sang thời gian của người dùng.
Đo chất lượng mô hình trong vòng hành động Android
Định tuyến mô hình AI cho phone agent phải được đo trong vòng Android action loop. Vòng này gồm: người dùng đưa yêu cầu, mô hình hiểu ý định, agent chọn công cụ, đối số được kiểm tra, FoneClaw thực hiện tác vụ Android được hỗ trợ, kết quả hiển thị, người dùng phê duyệt khi cần, rồi hệ thống xác nhận hoặc phục hồi. Một câu trả lời đúng ở bước đầu vẫn có thể thất bại nếu các bước sau không ổn.
Hãy bắt đầu bằng một tác vụ có thể đảo ngược: tạo ghi chú từ nội dung màn hình, chuẩn bị lời nhắc, mở một app, hoặc soạn bản nháp tin nhắn để xem lại. Chạy cùng tác vụ qua hai hoặc ba tuyến model. Ghi lại mô hình nào hiểu tiếng Việt tự nhiên hơn, mô hình nào hỏi lại đúng lúc, mô hình nào tạo đối số công cụ sạch hơn, và mô hình nào phản hồi nhanh enough để người dùng không rời flow.
Tiếp theo, cố tình tạo một vài điều kiện lỗi. Thu hồi quyền danh bạ, dùng tên liên hệ mơ hồ, tắt mạng, mở app đích ở trạng thái chưa đăng nhập, hoặc đưa màn hình có nhiều thông tin tương tự nhau. Một mô hình phù hợp với tác nhân Android không chỉ thành công ở đường dễ; nó phải biết dừng, hỏi lại hoặc để runtime phục hồi khi trạng thái thiết bị khác kế hoạch.
Đừng chỉ ghi “trả lời đúng” hay “trả lời sai”. Ghi failure mode: sai intent, sai công cụ, sai tham số, thiếu phê duyệt, chậm quá ngưỡng, không phục hồi khi thiếu quyền, hoặc kết quả không hiển thị. Bài Benchmark phone agent Android: cách đánh giá mobile agent đáng tin cậy năm 2026 cung cấp khung đo rộng hơn nếu bạn muốn biến những bài test này thành benchmark thực thi.
Cấu hình mô hình suy luận, để FoneClaw quản trị thực thi Android
Trong FoneClaw, chúng tôi tách rõ mô hình suy luận và lớp thực thi Android. Người dùng có thể bắt đầu với mô hình mặc định miễn phí, hoặc cấu hình route online tương thích hay route on-device được hỗ trợ. Mô hình giúp hiểu yêu cầu, chọn hướng lập kế hoạch và chuẩn bị lời gọi công cụ. FoneClaw cung cấp runtime thực thi với 100+ built-in tools, quyền Android, trạng thái hiển thị, phê duyệt, dừng và phục hồi quyền.
Cách tách lớp này giúp model routing trở nên thực dụng. Nếu một tuyến Kimi phù hợp với phân tích dài, người dùng có thể dùng nó cho tác vụ nhiều ngữ cảnh. Nếu một tuyến DeepSeek đạt ngưỡng tốt cho tác vụ lặp lại với chi phí thấp hơn, nó có thể được kiểm thử cho nhóm việc ít rủi ro. Nếu một tuyến GLM phù hợp với ràng buộc triển khai, nó có thể được đánh giá bằng cùng bộ tác vụ. Dù route nào được chọn, FoneClaw vẫn giữ hành động Android trong hợp đồng công cụ được hỗ trợ.
Chúng tôi cũng xây capability routing như một chuỗi có kiểm soát. AutoAttach giúp phát hiện khi ngữ cảnh có thể hỗ trợ yêu cầu, Suggest đưa ra hướng hành động phù hợp, và Fallback giúp người dùng đi tiếp khi điều kiện chưa đủ. Những lớp này không bỏ qua phê duyệt. Capability matching chỉ giúp chọn đường; execution approval quyết định bước có tác động có được tiếp tục hay không.
Ví dụ, người dùng yêu cầu “dựa trên màn hình này, tạo một ghi chú ngắn và nhắc tôi xem lại tối nay”. Mô hình cần hiểu nội dung và thời gian. FoneClaw cần biết công cụ ghi chú hoặc tác vụ nào được hỗ trợ, quyền nào cần có, nội dung ghi chú sẽ hiển thị ra sao, và bước nào cần người dùng duyệt. Nếu thiếu quyền hoặc model trả về kế hoạch không khớp schema, FoneClaw dừng lại với trạng thái rõ thay vì cố đoán.
Với chúng tôi, một mô hình cho tác nhân Android không được đánh giá bằng vẻ thuyết phục của câu trả lời. Nó được đánh giá bằng việc nó làm cho FoneClaw hoàn tất một workflow Android được hỗ trợ chính xác hơn, nhanh hơn, tiết kiệm hơn và dễ phục hồi hơn. Khi cần xem phạm vi người dùng hiện có thể kiểm tra, hãy bắt đầu từ trang tính năng FoneClaw, rồi chọn một tác vụ nhỏ để so sánh hai tuyến model trên cùng một thiết bị. Bài Điều khiển điện thoại bằng AI agent trên Android cũng giúp đặt phần routing này vào toàn bộ vòng hành động Android.
Playbook định tuyến mô hình cho phone agent
Một playbook routing tốt bắt đầu bằng phân loại tác vụ. Tác vụ hỏi đáp hoặc tóm tắt ngắn có thể ưu tiên chi phí và tốc độ. Tác vụ đọc tài liệu dài cần ngữ cảnh. Tác vụ nhiều công cụ cần độ tin cậy gọi công cụ. Tác vụ chứa dữ liệu riêng tư cần route, phê duyệt và chính sách lưu dữ liệu phù hợp. Tác vụ có hậu quả bên ngoài cần ngưỡng chất lượng cao hơn và fallback thận trọng hơn.
- Xác định tác vụ Android cụ thể: mở app, chuẩn bị tin nhắn, tạo nhắc việc, đọc màn hình, tìm đường, cập nhật lịch hay xử lý tài liệu.
- Đặt quality floor: intent đúng, schema đúng, hỏi lại khi thiếu dữ liệu, kết quả hiển thị và phục hồi khi lỗi.
- Đặt cost ceiling: tuyến nào đủ rẻ cho tần suất sử dụng thực tế mà không làm tăng lỗi người dùng phải sửa.
- Chọn latency target: thao tác nhanh cần route nhanh; tác vụ dài có thể chấp nhận chờ lâu hơn.
- Quy định fallback: route dự phòng dùng cho lỗi quota, timeout hoặc provider unavailable; tác vụ nhạy cảm cần phê duyệt rõ trước khi tiếp tục.
- Chạy reversible test trên đúng thiết bị, đúng quyền, đúng app và cùng một câu lệnh.
- Ghi failure mode, không chỉ ghi điểm hài lòng chung.
Khi nào nên đổi mô hình? Khi route hiện tại vượt trần chi phí, chậm hơn ngưỡng, mất ổn định schema, không hiểu tốt ngôn ngữ người dùng, thiếu context cho tác vụ mới, hoặc provider thay đổi khả dụng. Sau khi đổi, hãy chạy lại bài test Android thay vì chỉ đọc thông báo model mới.
Kết luận thực tế: Kimi, DeepSeek, GLM và các model tiếp theo đều là ứng viên, không phải đích đến cuối cùng. Phone agent cần một chính sách routing có thể kiểm tra. Trong FoneClaw, mô hình lập luận; FoneClaw quản trị hành động Android được hỗ trợ. Khi hai lớp này được đo cùng nhau, người dùng có thể đổi model mà không đánh đổi sự rõ ràng của tác vụ trên điện thoại.