3 framework mã nguồn mở cho AI agent điện thoại: chọn theo cách triển khai
So sánh Open-AutoGLM, Mobilerun và Minitap mobile-use theo thiết bị, runtime, mô hình, giấy phép, quan sát lỗi và chi phí vận hành; thêm lựa chọn FoneClaw nếu không muốn tự triển khai.
- Open-AutoGLM hợp khi bạn muốn nghiên cứu phone agent thị giác trên Android qua ADB, có xác nhận thao tác nhạy cảm và có thể dùng dịch vụ mô hình do nhà cung cấp vận hành hoặc inference do bạn tự triển khai.
- Mobilerun phù hợp khi bạn cần framework Python/CLI có cây accessibility, ảnh chụp màn hình, kết quả có cấu trúc và tracing; Mobilerun Cloud là đường vận hành riêng, không nên gộp với framework mã nguồn mở.
- Minitap mobile-use hợp với tác vụ mobile UI có cấu trúc, có nhà cung cấp LLM cấu hình được; Android dùng ADB, iOS trong README là simulator trên macOS và chưa hỗ trợ thiết bị iOS vật lý.
- FoneClaw là ứng dụng Android dùng sẵn của chúng tôi cho người muốn chạy tác vụ được hỗ trợ với mô hình cấu hình được, quyền và phê duyệt rõ mà không tự duy trì runtime.
Chọn framework theo việc cần làm
Nếu bạn đang tìm framework mã nguồn mở cho AI agent điện thoại, đừng bắt đầu bằng câu hỏi “framework nào mạnh nhất?”. Câu hỏi thực tế hơn là bạn muốn điều khiển loại thiết bị nào, quan sát lỗi ra sao, tự quản lý mô hình đến mức nào và có chấp nhận chi phí bảo trì hạ tầng hay không.
| Lựa chọn | Hợp nhất khi | Cần kiểm tra trước |
|---|---|---|
| Open-AutoGLM | Bạn nghiên cứu agent thị giác trên Android, muốn luồng ADB và có cơ chế xác nhận thao tác nhạy cảm. | ADB, bàn phím ADB, endpoint mô hình, quyền thiết bị và cách xử lý đăng nhập/captcha. |
| Mobilerun Framework | Bạn cần runtime Python/CLI, cây accessibility, screenshot, kết quả có cấu trúc và tracing để kiểm tra tác vụ. | Portal accessibility service, ADB, nhà cung cấp mô hình và nơi lưu trace. |
| Minitap mobile-use | Bạn muốn tự động hóa UI mobile bằng ngôn ngữ tự nhiên với tác vụ có cấu trúc và nhà cung cấp LLM cấu hình được. | ADB cho Android; iOS simulator trên macOS nếu dùng iOS; thiết bị iOS vật lý chưa được README hỗ trợ. |
Ba lựa chọn này là framework hoặc runtime để bạn tự triển khai. Chúng không phải bảng xếp hạng mô hình, cũng không phải danh sách ứng dụng tiêu dùng. Mã nguồn mở giúp bạn xem và sửa lớp điều phối, nhưng cuộc gọi mô hình, máy chủ, thiết bị cloud, bảo trì, logging và kiểm thử vẫn có chi phí riêng.
So sánh thiết lập, thực thi, mô hình và giấy phép
Cách đọc đúng là tách bốn lớp: framework runtime, mô hình suy luận, bộ thực thi trên điện thoại và môi trường quan sát lỗi. Một repo có giấy phép mở không làm cho mọi mô hình hoặc dịch vụ liên quan miễn phí. Một framework chạy trên máy của bạn cũng không đồng nghĩa suy luận chạy cục bộ; nhiều cấu hình vẫn gọi dịch vụ mô hình bên ngoài.
| Tiêu chí | Open-AutoGLM | Mobilerun | Minitap mobile-use |
|---|---|---|---|
| Thiết bị chính | Android qua ADB; tài liệu cũng nêu HDC cho HarmonyOS và iOS qua WebDriverAgent riêng. | Android qua ADB và Portal accessibility service; iOS có luồng Portal riêng. | Android thiết bị thật hoặc emulator qua ADB; iOS simulator trên macOS. |
| Runtime | Framework phone-agent thị giác trong repo Open-AutoGLM. | CLI/Python trong repo Mobilerun, trước đây được biết đến từ DroidRun. | Automation mobile UI bằng ngôn ngữ tự nhiên trong repo Minitap mobile-use. |
| Mô hình | Dùng endpoint mô hình; có đường dịch vụ mô hình do nhà cung cấp vận hành hoặc inference do bạn tự triển khai. | Cho chọn nhà cung cấp mô hình; local runtime không tự biến thành local inference. | Cấu hình nhà cung cấp LLM; phù hợp khi bạn muốn tách task script khỏi model provider. |
| Quan sát lỗi | Có xác nhận thao tác nhạy cảm và chuyển cho người dùng khi đăng nhập/captcha. | Có saved trajectories và tracing qua Arize Phoenix hoặc Langfuse. | Có structured extraction; cần kiểm tra thêm với app thiếu accessibility tree, nhất là game. |
| Giấy phép repo | Apache-2.0. | MIT. | Apache-2.0. |
Với tác vụ phone agent nghiêm túc, giấy phép chỉ là một phần. Bạn còn phải tính chi phí API mô hình, cloud device nếu dùng, thời gian vá thay đổi UI, quyền thiết bị, dữ liệu test, lưu trace và cơ chế phục hồi khi app không ở trạng thái mong muốn.
Khi nào nên chọn Open-AutoGLM
Chọn Open-AutoGLM khi bạn muốn nghiên cứu một agent đọc màn hình điện thoại và thực hiện thao tác qua lớp thiết bị. Tài liệu chính thức mô tả Android qua ADB, yêu cầu bật chế độ nhà phát triển, USB debugging và ADB Keyboard. Đây là đường phù hợp cho nhóm kỹ thuật muốn kiểm soát thiết bị thật hoặc môi trường lab, thay vì chỉ gọi một API chat rồi hy vọng điện thoại tự chạy.
Điểm đáng chú ý là Open-AutoGLM tách mô hình khỏi framework. Bạn có thể dùng dịch vụ mô hình do nhà cung cấp vận hành hoặc triển khai inference trên hạ tầng của mình. Vì vậy, không cần xem “mã nguồn mở” là “mọi thứ chạy miễn phí trên máy cá nhân”. Nếu tự triển khai inference, bạn phải lo phần máy chủ mô hình, GPU nếu cần, độ trễ, bảo mật endpoint và tương thích với action loop.
Open-AutoGLM cũng nêu xác nhận cho thao tác nhạy cảm và human takeover cho đăng nhập hoặc captcha. Đây là điểm quan trọng: agent điện thoại không nên coi mọi màn hình là có thể tự vượt qua. Nếu workflow của bạn gồm đăng nhập, thanh toán, xóa dữ liệu hoặc gửi thông tin ra ngoài, hãy thiết kế điểm dừng trước khi thử framework trên tài khoản thật.
Khi nào chọn Mobilerun Framework hoặc Cloud
Mobilerun đáng chọn khi bạn cần một framework có thể quan sát được: accessibility tree, ảnh chụp màn hình, lựa chọn provider mô hình, kết quả có cấu trúc và trace để xem agent đã quyết định gì. Tài liệu Mobilerun mô tả framework chạy agent trên máy của bạn, chuẩn bị Android bằng ADB, USB debugging và Portal accessibility service.
Cần phân biệt rõ Mobilerun Framework và Mobilerun Cloud. Framework là phần mã nguồn mở để bạn tự chạy, tự nối thiết bị, tự chọn mô hình và tự lưu dữ liệu vận hành. Cloud là dịch vụ quản lý khác: có thể hỗ trợ điện thoại local đã kết nối hoặc thiết bị hosted virtual/physical cho workflow API. Hai đường này khác nhau về chi phí, dữ liệu, độ sẵn sàng thiết bị và trách nhiệm vận hành.
Mobilerun phù hợp nếu bạn muốn biết tại sao tác vụ lỗi, không chỉ biết tác vụ đã fail. Trace qua Arize Phoenix hoặc Langfuse và saved trajectories giúp xem từng bước. Đổi lại, bạn phải duy trì Portal, cấu hình model provider, quản lý log và kiểm tra khi giao diện app thay đổi. Với iOS, hãy đi theo setup riêng của dự án thay vì giả định ngang bằng Android.
Khi nào Minitap mobile-use phù hợp
Minitap mobile-use hợp với tác vụ mobile UI có cấu trúc, nơi bạn muốn mô tả mục tiêu bằng ngôn ngữ tự nhiên và lấy kết quả theo dạng có thể xử lý tiếp. README của mobile-use nêu Android thiết bị thật hoặc emulator qua ADB, Docker quickstart dành cho Android, và cấu hình được nhiều nhà cung cấp LLM.
Điểm cần đọc kỹ là iOS. Dù phần mô tả rộng có thể nhắc tới mobile automation đa nền tảng, hướng dẫn thiết bị thủ công của dự án liệt kê iOS simulator trên macOS và nói rõ thiết bị iOS vật lý chưa được hỗ trợ. Vì vậy, nếu mục tiêu là iPhone thật, hãy xem đây là điều kiện chặn hoặc ít nhất là một hạng mục phải xác minh trước khi chọn.
mobile-use cũng ghi nhận giới hạn với game hoặc app thiếu accessibility-tree information. Điều này thực tế: nhiều agent UI dựa vào cây accessibility, ảnh màn hình hoặc cả hai. Nếu app mục tiêu vẽ UI trong canvas/game engine, framework có thể thấy ít cấu trúc hơn và phải dựa nhiều hơn vào thị giác, tọa độ hoặc chiến lược riêng.
Thử một tác vụ có thể đảo ngược
Đừng chọn framework bằng lời quảng bá hoặc benchmark chung. Hãy tạo một phép thử nhỏ, có thể đảo ngược, rồi chạy cùng điều kiện trên từng lựa chọn. Mục tiêu là xem framework ghi nhận trạng thái, gọi mô hình, thực thi thao tác và phục hồi lỗi như thế nào, không phải tạo một bảng xếp hạng giả.
- Chọn tác vụ ít rủi ro: mở một app, đọc màn hình, tạo một ghi chú nháp hoặc đi tới trang cài đặt không thay đổi dữ liệu.
- Ghi lại trạng thái ban đầu: thiết bị, OS, app, tài khoản thử, mạng, model provider và quyền đã cấp.
- Quan sát từng lớp: framework nhận gì từ màn hình, mô hình trả kế hoạch gì, executor bấm hoặc nhập gì, kết quả cuối có xác minh được không.
- Cố tình tạo lỗi nhẹ: rút quyền, đổi màn hình, mở sai tab hoặc yêu cầu thao tác cần xác nhận.
- Đánh giá phục hồi: framework có dừng, hỏi lại, lưu trace và tránh báo hoàn tất sai không.
Nếu bạn cần một quy trình đánh giá sâu hơn, bài Benchmark phone agent Android: cách đánh giá mobile agent đáng tin cậy năm 2026 giúp thiết kế phép thử theo task success, an toàn, độ lặp lại và phục hồi. Còn khi vấn đề chính là chọn model thay vì chọn framework, bài Chọn mô hình AI cho tác nhân Android: 6 lựa chọn theo tác vụ tách riêng endpoint, khả năng gọi công cụ và chi phí suy luận.
Chọn đường Android dùng sẵn thay vì framework
Nếu bạn không muốn tự duy trì ADB, accessibility service, model endpoint, trace server và thiết bị thử nghiệm, hãy chọn một sản phẩm Android dùng sẵn thay vì framework mã nguồn mở. FoneClaw là ứng dụng Android của chúng tôi cho các tác vụ điện thoại được hỗ trợ, với mô hình mặc định miễn phí, đường cấu hình mô hình tương thích, quyền, phê duyệt và trạng thái kết quả rõ ràng.
Đường này hợp với người muốn mở app, kiểm tra thông tin, xử lý SMS, ghi chú, memo hoặc tác vụ điện thoại được hỗ trợ mà không tự xây executor. FoneClaw vẫn có ranh giới: công cụ Android chạy trên máy không có nghĩa mọi suy luận đều ở lại trên máy; provider tùy chọn có điều kiện riêng; và tác vụ có tác động cần quyền hoặc phê duyệt phù hợp. Các tự động hóa chạy nền hiện không phải cách để giao mọi hành động Android không giám sát.
Bạn có thể xem các tính năng FoneClaw để biết phạm vi hiện hành và dùng AI agent điều khiển điện thoại Android: từ ý định đến hành động để hiểu cách ý định, công cụ, quyền và xác nhận phối hợp trong một workflow trên điện thoại.