Benchmark Phone Agent Android: Cara Mengevaluasi AI Agent Mobile 2026
Panduan benchmark phone agent Android untuk 2026: lanskap B-MoCA, MobileWorld, KnowU-Bench, PhoneHarness, metrik keandalan, approval, recovery, dan matriks FoneClaw.
- Benchmark phone agent Android perlu menilai hasil yang benar, proses yang terkendali, approval yang tepat, side effect yang diverifikasi, dan recovery ketika tugas terputus.
- B-MoCA, MobileWorld, KnowU-Bench, dan PhoneHarness menyorot celah berbeda: variasi konfigurasi, long-horizon workflow, personalisasi, consent, action surface, dan trace eksekusi.
- Tingkat keberhasilan saja memberi gambaran awal; evaluasi mobile agent juga memerlukan metrik partial checkpoint, wrong side effect, intervensi manusia, recovery, latency, biaya, dan kualitas audit.
- Untuk FoneClaw, matriks evaluasi yang sehat memakai tugas Android saat ini seperti layar terlihat, DND, volume, Bluetooth, screenshot, memo, messaging, tasks, workflows, permission recovery, stopping, dan approval.
Apa yang harus diukur benchmark phone agent Android
Benchmark phone agent Android yang berguna harus mengukur dua hal sekaligus: hasil yang benar dan proses yang terkendali. Dari pengalaman kami membangun FoneClaw, tap yang terlihat masuk akal belum cukup. Agent bisa menekan tombol yang benar secara visual, tetapi hasil akhir tetap perlu diverifikasi: pesan tersimpan sebagai draf, Do Not Disturb benar-benar aktif, volume berubah sesuai permintaan, atau pengingat muncul di tempat yang tepat.
Evaluasi mobile agent juga harus menilai otoritas. Apakah agent memakai izin yang sesuai? Apakah tindakan berdampak meminta approval pada momen yang tepat? Apakah pengguna dapat menghentikan proses? Apakah recovery membawa tugas kembali ke langkah yang dapat dilanjutkan? Phone agent bekerja di perangkat pribadi, sehingga “berhasil” berarti tujuan pengguna tercapai tanpa efek samping yang merusak.
Kerangka kami dimulai dari empat bukti: pemahaman tujuan, side effect yang benar, kontrol pengguna, dan verifikasi hasil. Jika salah satu hilang, skor task success menjadi rapuh. Untuk tim yang ingin menghubungkan benchmark dengan siklus peningkatan produk, Phone Agent yang Meningkatkan Diri: Versi Skill, Pengujian, dan Rollback membahas harness, versi kemampuan, dan rollback sebagai lapisan lanjutan.
Lanskap benchmark mobile agent pada 2026
Benchmark AI agent 2026 tidak bisa dibaca sebagai satu leaderboard universal. Setiap benchmark menekan sisi berbeda dari masalah phone agent: variasi perangkat, panjang workflow, personalisasi, consent, action surface, atau audit trace. Skor sebaiknya dibaca di dalam setting masing-masing, lalu diterjemahkan ke test suite produk yang sesuai.
| Benchmark | Fokus | Pelajaran untuk phone agent Android |
|---|---|---|
| B-MoCA | Paper PMLR Benchmarking Mobile Device Control Agents across Diverse Configurations mendefinisikan 131 tugas Android harian dan merandomisasi konfigurasi perangkat seperti layout UI dan bahasa. | Agent perlu diuji pada variasi konfigurasi, bukan satu emulator yang rapi. Tugas sederhana dan tugas kompleks perlu dipisahkan. |
| MobileWorld | Paper ACL 2026 MobileWorld berisi 201 tugas di 20 aplikasi, rata-rata 27,8 langkah, dan 62,2% multi-app. Paper itu melaporkan 51,7% untuk framework agentic terbaik dan 20,9% untuk model end-to-end terbaik dalam setting mereka. | Long-horizon dan cross-app workflow perlu metrik sendiri. Angka step dan multi-app membuat tugas lebih dekat ke kehidupan Android nyata. |
| KnowU-Bench | Preprint KnowU-Bench mencakup 42 tugas GUI umum, 86 tugas personal, dan 64 tugas proaktif. Profil pengguna disembunyikan, sementara behavioral logs diekspos. | Personalisasi, klarifikasi, proactive consent, dan restraint setelah penolakan harus masuk skor keselamatan. |
| PhoneHarness | Preprint PhoneHarness menggabungkan GUI, CLI, dan host-side tool actions, menilai side effects yang dapat diamati, dan merekam trace eksekusi yang dapat diaudit. | Benchmark perlu memisahkan harness eksekusi dari kumpulan tugas, lalu membuktikan side effect dengan trace yang jelas. |
Untuk FoneClaw, kami membaca lanskap ini sebagai bahan desain test suite. B-MoCA mengingatkan kami pada variasi konfigurasi. MobileWorld mengingatkan kami pada workflow panjang. KnowU-Bench mengingatkan kami pada consent dan personalisasi. PhoneHarness mengingatkan kami pada side-effect verification dan trace. Evaluasi resource dan tool discovery juga menjadi bagian penting; Agentic Resource Discovery: ai-catalog.json, Verifikasi, dan Batas Otorisasi Phone Agent memperdalam sisi kepercayaan kemampuan.
Enam dimensi untuk test suite phone agent Android
Test suite phone agent Android perlu memvariasikan dimensi secara independen. Jika semua tugas memakai bahasa yang sama, aplikasi yang sama, izin yang sama, dan layar yang sama, skor akan tampak lebih stabil daripada produk di dunia nyata. Kami memakai enam dimensi saat merancang evaluasi mobile agent.
| Dimensi | Contoh variasi | Apa yang diukur |
|---|---|---|
| Konfigurasi perangkat | Bahasa, ukuran layar, layout OEM, mode gelap, izin awal. | Generalisasi terhadap perangkat Android yang berbeda. |
| Horizon tugas | Satu langkah, beberapa langkah, tugas panjang lintas aplikasi. | Kemampuan menjaga state dan urutan tindakan. |
| Kejelasan niat | Perintah eksplisit, perintah samar, konflik preferensi. | Klarifikasi, asumsi, dan kemampuan menahan aksi. |
| Action surface | GUI, structured tool, host-side action, atau kombinasi. | Pemilihan jalur eksekusi yang paling tepat. |
| Dampak tindakan | Read-only, reversible, external effect, destructive. | Approval, permission, dan kontrol risiko. |
| Gangguan dan recovery | Layar berubah, izin dicabut, jaringan turun, pengguna menekan stop. | Pemulihan, audit, dan konsistensi status tugas. |
Lebih banyak langkah tidak selalu berarti lebih sulit. Tiga langkah yang menyentuh pesan pribadi dan approval bisa lebih sensitif daripada sepuluh langkah read-only. Karena itu setiap dimensi perlu ditandai di dataset. Dengan begitu, hasil benchmark menunjukkan kelemahan yang dapat diperbaiki: apakah masalahnya konfigurasi, long-horizon, intent ambiguity, action routing, side effect, atau recovery.
Metrik keandalan di luar task success rate
Task success rate berguna sebagai angka awal, tetapi metrik keandalan phone agent harus lebih rinci. Kami membedakan verified pass, partial checkpoint, wrong side effect, unnecessary action, human intervention, recovery success, latency, cost, dan trace quality. Denominator dan kebijakan retry harus tetap, karena retry bebas dapat membuat hasil terlihat lebih baik daripada pengalaman pengguna sebenarnya.
Verified pass berarti keadaan akhir terbukti benar: setting berubah, draf terlihat, file dibuat, atau reminder tersimpan. Partial checkpoint berarti agent mencapai langkah penting tetapi belum menyelesaikan side effect. Wrong side effect perlu diberi bobot berat: salah kontak, salah aplikasi, salah SIM, atau perubahan setting yang tidak diminta. Human intervention dicatat ketika pengguna harus mengambil alih, dan recovery success dicatat ketika agent membawa pengguna kembali ke jalur yang benar.
LLM judge dapat membantu menilai alasan atau ringkasan, tetapi side effect Android perlu bukti dari perangkat, trace, atau pemeriksaan state. Di sinilah PhoneHarness menarik: preprint itu menekankan observable side effects dan auditable execution traces. Untuk desain jejak izin, persetujuan, dan tindakan, Identitas Agen AI: Izin, Persetujuan per Alat, dan Jejak Audit Phone Agent memberi kerangka keamanan yang lebih dalam.
Menguji approval, permission, restraint, dan stopping
Benchmark AI agent 2026 perlu menjadikan perilaku keselamatan sebagai skor, bukan catatan samping. Agent yang menyelesaikan tugas dengan cepat tetapi melewati klarifikasi, memakai izin berlebihan, atau melanjutkan setelah pengguna menolak harus mendapat penalti. KnowU-Bench berguna di sini karena menguji clarification, proactive consent, dan restraint setelah rejection.
Kami membagi tes keselamatan menjadi lima kategori. Pertama, least required authority: agent memakai izin yang sesuai dengan tugas. Kedua, approval timing: approval muncul sebelum external effect, bukan setelahnya. Ketiga, clarification: agent bertanya saat target atau preferensi tidak jelas. Keempat, restraint: agent menghormati penolakan dan tidak mencari jalur lain untuk efek yang sama. Kelima, stopping: pengguna dapat menghentikan tugas dan melihat status akhir.
Approval bukan sekadar tombol “ya”. Approval yang baik menampilkan target, alasan, konsekuensi, dan bukti secukupnya. Karena itu kami merutekan pembahasan desain interaksi approval ke UX Persetujuan Agen AI di Ponsel: Keyakinan, Alasan, dan Kontrol Pengguna. Dalam benchmark, setiap approval harus dicatat: apa yang diminta, kapan muncul, apakah pengguna bisa menolak, dan apa yang terjadi setelah penolakan.
Cara kami mengevaluasi tugas FoneClaw saat ini
Berdasarkan informasi terbaru yang tersedia sejauh ini, FoneClaw memberi kemampuan yang dapat diuji untuk matriks evaluasi saat ini: floating assistant, current-screen attachment, task continuity, approvals, stopping, permission recovery, DND, volume, meeting-mode, screenshot reliability, dan quick actions. Kemampuan yang tersedia saat ini dapat dicoba melalui halaman Download FoneClaw. Artikel ini menyusun metode dan matriks; angka hasil harus berasal dari run terkontrol yang terpisah.
Kelas tugas pertama adalah read-only dan observation freshness. Contoh: lampirkan layar saat ini, baca status yang terlihat, atau ringkas konteks layar. Yang dinilai: apakah agent membaca layar terbaru, apakah konteks cukup, dan apakah ia menahan tindakan saat hanya diminta menjelaskan. Kelas kedua adalah reversible device control: DND, volume, Bluetooth, meeting mode, dan screenshot. Yang dinilai: approval sesuai risiko, verifikasi state akhir, dan recovery jika izin belum siap.
Kelas ketiga adalah external-effect tasks seperti messaging, calendar, memo, tasks, workflows, dan shortcuts. Di sini metrik utama adalah target benar, isi lengkap, approval terlihat, side effect diverifikasi, dan trace dapat diaudit. Kelas keempat adalah interruption and recovery: pengguna menekan stop, izin dicabut, aplikasi berpindah, atau layar berubah di tengah jalan. Yang dinilai bukan hanya penyelesaian, tetapi kemampuan menjaga task state dan membawa pengguna ke langkah berikutnya.
Cakupan kemampuan yang tersedia dapat dilihat di halaman fitur FoneClaw, termasuk 100+ built-in tools untuk workflow Android terkelola. Untuk skenario pengguna yang konkret, Pemeriksaan Kesehatan Ponsel Android dengan AI: Izin Sensitif, Akses Khusus, dan Aplikasi Tersembunyi memberi contoh audit izin yang bisa diterjemahkan menjadi test case praktis.
Membangun protokol benchmark phone agent yang dapat diulang
Protokol benchmark yang dapat diulang harus mencatat lingkungan dengan ketat. Simpan versi agent, perangkat, Android build, locale, aplikasi yang terpasang, status login, izin awal, jaringan, retry policy, dan expected state. Tanpa catatan ini, dua run yang tampak sama bisa sebenarnya berbeda.
- Bekukan environment: perangkat, bahasa, aplikasi, izin, dan data awal.
- Tentukan initial state dan expected state untuk setiap tugas.
- Randomisasi satu axis saja pada satu batch, misalnya bahasa atau layout.
- Rekam rencana, tool call, approval, stop, dan intervensi manusia.
- Verifikasi side effect dari perangkat, bukan hanya dari jawaban agent.
- Klasifikasikan failure: pemahaman, permission, UI, action routing, side effect, atau recovery.
- Publikasikan batas setting uji agar pembaca tahu konteks skor.
Tes awal yang reversible bisa dimulai dari DND, volume, atau screenshot reliability, lalu naik ke draf pesan dan memo. Setelah itu, tambahkan long-horizon workflow dan permission-loss scenario. Scorecard minimum berisi verified pass, partial checkpoint, wrong side effect, recovery, human intervention, latency, cost, dan trace quality.
Tujuan benchmark phone agent Android bukan mencari angka yang paling indah, melainkan menemukan perilaku yang dapat diperbaiki. Jika test suite menunjukkan bahwa approval muncul terlambat, recovery lemah, atau agent rapuh pada bahasa tertentu, produk punya arah kerja yang jelas. Itulah cara kami ingin menghubungkan riset benchmark 2026 dengan pembangunan FoneClaw sehari-hari: metode yang dapat diulang, bukti yang dapat diperiksa, dan peningkatan yang dapat dirilis.
Sumber: paper PMLR B-MoCA, paper ACL MobileWorld, preprint KnowU-Bench, preprint PhoneHarness, halaman Download FoneClaw, dan halaman fitur FoneClaw.