3 framework tác nhân điện thoại mã nguồn mở: chọn cách triển khai

Chọn framework theo việc cần làm

Nếu bạn đang tìm framework tác nhân điện thoại mã nguồn mở, đừ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. Với môi trường có nhiều máy, chọn đúng thiết bị và kiểm tra cấu hình sau nâng cấp cũng quan trọng như chọn mô hình.

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ị đám mây, bảo trì, nhật ký 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: runtime của framework, 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 kho mã 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.

Hãy đối chiếu tệp giấy phép của bản mã bạn triển khai, đồng thời đọc điều kiện riêng của mô hình, SDK và dịch vụ đám mây liên quan. Với tác vụ nghiêm túc, bạn còn phải tính chi phí API, thiết bị, thời gian vá thay đổi giao diện, dữ liệu thử, lưu trace và cách phục hồi khi ứng dụng 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 tác nhân đọ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 thử nghiệm, 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 suy luận 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 suy luận, bạn phải lo máy chủ mô hình, GPU nếu cần, độ trễ, bảo mật endpoint và tương thích với vòng lặp hành động.

Open-AutoGLM cũng nêu xác nhận cho thao tác nhạy cảm và bàn giao cho người dùng khi đăng nhập hoặc captcha. Đây là điểm quan trọng: tác nhân điện thoại không nên coi mọi màn hình là có thể tự vượt qua. Nếu quy trình 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: cây trợ năng, ảnh chụp màn hình, lựa chọn nhà cung cấp mô hình, kết quả có cấu trúc và trace để xem tác nhân đã quyết định gì. Tài liệu Mobilerun mô tả framework chạy tác nhân trên máy của bạn, chuẩn bị Android bằng ADB, USB debugging và dịch vụ trợ năng Portal.

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ý riêng: có thể hỗ trợ điện thoại cục bộ đã kết nối hoặc thiết bị ảo/vật lý được lưu trữ từ xa cho quy trình 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.

Bản phát hành ngày 14/10/2026 theo UTC, tương ứng ngày 15/10 theo giờ Trung Quốc, thay đổi cách mobilerun run chọn máy: ưu tiên -d, tiếp đến ANDROID_SERIAL, rồi mới dùng thiết bị duy nhất đang trực tuyến. Nếu có nhiều máy mà chưa chọn, lệnh báo lỗi thay vì lấy máy đầu tiên. Vì vậy, trước mỗi lần chạy, xem danh sách thiết bị kết nối và chủ động chỉ định máy thử mong muốn.

FastAgent chỉ xử lý khối function_calls đầu tiên trong phản hồi và bỏ qua các khối sau. Khi một lời gọi thất bại, phần còn lại của khối đó bị bỏ qua. Hãy dừng, kiểm tra những gì thực sự đã xảy ra trên máy và sửa nguyên nhân trước khi thử lại; hành vi này không bảo đảm hoàn tác tự động hoặc cho phép chạy lại cả chuỗi một cách an toàn.

Với cấu hình cũ, thay đổi app card ngày 5/10/2026 yêu cầu đặt tệp tại app_cards_dir/android/app_cards.json hoặc app_cards_dir/ios/app_cards.json. Tệp app_cards.json đặt trực tiếp trong app_cards_dir bị bỏ qua. Khi chuyển cấu hình, phân loại đúng định danh ứng dụng Android và iOS. Thiết lập cài bản Portal được ghim phù hợp với Mobilerun và giữ nguyên Portal mới hơn đang có; không tự chọn một số phiên bản tương thích theo phỏng đoán.

Trong lúc chạy, Portal có thể được bật lại dịch vụ trợ năng và khôi phục bàn phím Portal. Nếu muốn thu hồi quyền, dừng tác nhân trước rồi kiểm tra trạng thái dịch vụ, quyền và bàn phím thực tế. Không tắt cơ chế bảo vệ để ép chạy. Với Cloud SDK, tương thích cây giao diện và thay đổi không thử lại thao tác chạm/nhập cũng là điểm cần kiểm tra khi bảo trì, không phải bằng chứng mọi thiết bị đều hoạt động thành công.

Trace qua Arize Phoenix hoặc Langfuse và bản ghi quỹ đạo giúp xem từng bước. Đổi lại, bạn phải duy trì Portal, cấu hình mô hình, quản lý nhật ký và kiểm tra khi giao diện thay đổi. Với iOS, hãy đi theo thiết lập 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ụ giao diện di động 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, hướng dẫn khởi đầu bằng Docker 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 tự động hóa di động đ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 ứng dụng thiếu thông tin cây trợ năng. Điều này thực tế: nhiều tác nhân giao diện dựa vào cây trợ năng, ảnh màn hình hoặc cả hai. Nếu ứng dụng mục tiêu vẽ giao diện trong canvas hoặc bộ máy game, 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 chỉ bằng lời quảng bá hoặc benchmark chung. Một phép thử đề xuất dựa trên thiết lập trong tài liệu là: mở một ứng dụng ít nhạy cảm đã chọn trên điện thoại thử thuộc quyền quản lý của bạn, xác nhận màn hình chính rồi dừng. Đây không phải kết quả thử nghiệm của chúng tôi; mục tiêu là giúp bạn quan sát cùng một tác vụ trên từng lựa chọn, không gửi tin nhắn hay thanh toán.

1. Ghi trạng thái ban đầu: thiết bị, hệ điều hành, ứng dụng, mạng, nhà cung cấp mô hình và quyền đã cấp. Kiểm tra danh sách máy kết nối; với Mobilerun, chọn rõ máy bằng -d hoặc ANDROID_SERIAL.
2. Đối chiếu cấu hình trước khi chạy. Nếu nâng cấp Mobilerun, kiểm tra app card đã nằm đúng thư mục nền tảng và Portal sẵn sàng trên đúng máy.
3. Chỉ yêu cầu mở ứng dụng đã chọn. Theo dõi đầu vào màn hình, kế hoạch của mô hình và thao tác thực thi; dừng ngay nếu nhầm thiết bị hoặc một bước thất bại.
4. Kiểm tra trực tiếp màn hình cuối trên máy dự định dùng. Đối chiếu với trace hoặc kết quả trả về, không chỉ dựa vào thông báo hoàn tất.
5. Trước khi thử lại, xác định bước nào đã chạy và sửa nguyên nhân. Với FastAgent, không coi phần bị bỏ qua sau lỗi là đã thực hiện, cũng không giả định các bước trước đã được hoàn tác.

Nếu cần kiểm tra việc thu hồi quyền, hãy dừng tác nhân rồi quan sát trạng thái quyền và dịch vụ. Riêng Portal có cơ chế khôi phục trong lúc chạy, nên tắt dịch vụ khi tác nhân vẫn hoạt động không phải phép kiểm tra đầy đủ rằng quyền đã được thu hồi.

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 mức hoàn thành tác vụ, an toàn, độ lặp lại và phục hồi. Còn khi vấn đề chính là chọn mô hình thay vì 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, dịch vụ trợ năng, endpoint mô hình, máy chủ trace 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ợ, không phải một framework mã nguồn mở.

Trong FoneClaw, mô hình được cấu hình hỗ trợ suy luận và lập kế hoạch; công cụ đã bật thực thi theo quyền Android thực tế cùng chính sách phê duyệt áp dụng. Cách này hợp với người muốn mở ứng dụng, kiểm tra thông tin hoặc thực hiện tác vụ được hỗ trợ mà không tự xây bộ thực thi. Không phải mọi thao tác đều luôn hỏi lại, và việc dùng FoneClaw không tạo kết nối tích hợp sẵn với ba framework trong bài.

FoneClaw vẫn có ranh giới: công cụ chạy trên điện thoại không có nghĩa mọi suy luận đều ở lại trên máy; nhà cung cấp mô hình tùy chọn có điều kiện riêng; khả năng thực thi phụ thuộc công cụ, quyền và chính sách thực tế. Đây không phải quyền điều khiển mọi ứng dụng hoặc giao mọi hành động Android cho một quy trình 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 bài 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à phê duyệt phối hợp trong một quy trình trên điện thoại.