Perutean Kemampuan Agen AI Android: AutoAttach, Suggest, Fallback, dan FoneClaw

Dari Permintaan Android ke Kandidat Kemampuan

Bayangkan pengguna berkata kepada agen ponsel: “siapkan mode rapat, kecilkan volume, dan buat catatan bahwa saya tidak bisa diganggu satu jam.” Permintaan itu terlihat sederhana, tetapi agen Android perlu mengubahnya menjadi beberapa kandidat kemampuan: cek status volume, ubah ringer mode, buka atau atur Do Not Disturb bila izin tersedia, buat memo, mungkin membuat shortcut rapat untuk dipakai lagi. Perutean kemampuan agen AI adalah proses memilih kandidat yang paling relevan sebelum tindakan apa pun dijalankan.

Agen tidak perlu memuat semua tool, Skill, Workflow, dan Plugin ke setiap konteks. Ponsel memiliki layar kecil, izin berbeda, aplikasi yang berubah, dan tugas yang sering berjalan sambil pengguna melakukan hal lain. Router kemampuan harus mempersempit ruang pilihan: apa niat utama pengguna, konteks apa yang tersedia, kemampuan mana yang relevan, apa risikonya, dan hasil akhir apa yang bisa diperiksa.

Peringkat kandidat tidak cukup berdasar kemiripan kata. “Mode rapat” bisa berarti volume, Do Not Disturb, kalender, memo, pesan status, atau kombinasi beberapa langkah. Karena itu, pencocokan kemampuan kontekstual perlu membaca metadata tugas: kategori tindakan, aplikasi target, izin yang dibutuhkan, apakah tindakan berdampak, apakah ada hasil terlihat, dan apakah rute itu pernah gagal pada kondisi serupa. Semantik membantu menemukan kandidat; otorisasi, approval, dan eksekusi berada di tahap berikutnya.

Memilih AutoAttach, Suggest, atau Fallback

Setelah kandidat terbentuk, router perlu memilih cara membantu pengguna. Di FoneClaw, kami melihat tiga pola utama: AutoAttach, Suggest, dan Fallback. Ketiganya bukan tingkat izin yang sama. AutoAttach membantu membawa konteks atau metadata relevan ke percakapan. Suggest menampilkan pilihan yang dapat ditinjau pengguna. Fallback menjaga tugas tetap bergerak saat kecocokan utama belum tersedia, ambigu, atau membutuhkan kondisi tambahan.

AutoAttach cocok ketika konteks lokal sangat mungkin diperlukan dan risikonya rendah. Misalnya pengguna berkata, “jelaskan layar ini” dari asisten mengambang. Router dapat melampirkan informasi layar yang diminta pengguna agar model memahami konteks visual. AutoAttach juga bisa menambahkan metadata kemampuan yang relevan, seperti kandidat tool yang cocok dengan kategori tugas. Yang penting: AutoAttach menambah konteks, bukan menjalankan tool berdampak.

Suggest dipakai ketika ada lebih dari satu kandidat masuk akal atau tindakan membutuhkan pilihan pengguna. Pada permintaan “siapkan mode rapat”, Suggest dapat menampilkan opsi: kecilkan volume saja, aktifkan Do Not Disturb bila izin tersedia, buat memo rapat, atau simpan Workflow untuk dipakai ulang. Pilihan terlihat membuat pengguna memahami arah eksekusi sebelum tindakan bergerak ke approval.

Fallback dipakai saat rute langsung belum sehat. Mungkin izin DND belum aktif, Plugin yang relevan belum diaktivasi, Skill masih berupa draft, atau target aplikasi tidak jelas. Fallback bukan jalur pintas melewati kebijakan. Fallback adalah kelanjutan aman: buka pengaturan izin, tawarkan draf manual, pakai built-in tool yang lebih sempit, atau hentikan tindakan dengan status yang dapat dipahami.

Pemisahan ini membuat agen lebih mudah dipercaya. Pengguna tidak perlu menebak apakah sebuah saran berarti tindakan sudah berjalan. Setiap status punya makna yang berbeda: konteks ditambahkan, pilihan ditampilkan, cadangan dipakai, atau tindakan benar-benar dieksekusi.

Pisahkan Discovery, Attachment, Activation, Approval, dan Execution

Kesalahan terbesar dalam perutean alat agen Android adalah mencampur status. Discovery berarti kemampuan ditemukan sebagai kandidat. Attachment berarti konteks atau metadata ditambahkan ke percakapan. Activation berarti kemampuan, Plugin, atau Skill masuk ke status siap digunakan sesuai aturan. Approval berarti pengguna menyetujui tindakan yang berdampak. Execution berarti tool benar-benar dijalankan. Result dan recovery menyusul setelahnya.

Ekosistem agent makin bergerak ke arah paket kemampuan yang lebih terstruktur. Google Developers menjelaskan Agent Plugins sebagai spesifikasi terbuka untuk mengemas Agent Skills dan MCP servers, dengan metadata paket bersama. Bagi router kemampuan, metadata seperti ini membantu discovery dan pencocokan. Namun paket yang ditemukan tetap perlu melalui trust, dependensi, activation, dan kebijakan lokal sebelum dipakai dalam tindakan nyata.

Contoh lain datang dari dunia developer. GitHub Changelog tentang Agent finder menjelaskan pencarian dan pemeringkatan resource yang relevan sesuai tugas, sambil tetap menghormati registry dan managed settings yang dikonfigurasi. Kami memakai pola ini sebagai analogi desain: menemukan kemampuan yang cocok adalah tahap awal, bukan pemasangan diam-diam dan bukan izin eksekusi.

Dalam agen ponsel, state machine yang sehat terlihat seperti ini: temukan kandidat, lampirkan konteks yang tepat, periksa activation, minta approval bila tindakan berdampak, jalankan tool yang didukung, tampilkan hasil, lalu pulihkan bila status berbeda dari rencana. Untuk glossary lapisan kemampuan yang lebih umum, seperti Tools, Plugin, Skill, dan Workflow, kami menaruh pembahasan terpisah di Tools, Plugin, Skill, Workflow FoneClaw: Panduan Memilih Lapisan Kemampuan. Halaman ini fokus pada mekanik perpindahan status saat satu permintaan berjalan.

Memakai Manifest, Dependensi, Metadata Konteks, dan Confidence

Router yang andal membutuhkan input yang lebih kaya daripada nama tool. Manifest memberi identitas kemampuan, jenis tugas, versi kontrak, izin yang mungkin dibutuhkan, dan cara kemampuan dipanggil. Dependensi menjelaskan apa yang harus tersedia sebelum activation: aplikasi target, layanan, akun, izin Android, model, atau Plugin pendukung. Metadata konteks membantu mencocokkan permintaan dengan keadaan perangkat, seperti layar aktif, bahasa, lokasi yang diizinkan, waktu perangkat, dan status aplikasi.

Dependensi perlu selesai sebelum kemampuan dianggap siap. Jika sebuah Plugin membutuhkan layanan tambahan atau izin khusus, router perlu menandainya sebagai kandidat yang belum siap, bukan kandidat siap eksekusi. Atomic capability snapshot juga penting: saat refresh kemampuan gagal sebagian, runtime harus mempertahankan set kemampuan terakhir yang diterima secara utuh agar pengguna tidak masuk ke keadaan aktif yang separuh lengkap.

Confidence membantu memilih antara AutoAttach, Suggest, dan Fallback. Confidence tinggi untuk konteks rendah risiko dapat memakai AutoAttach. Confidence sedang lebih cocok masuk Suggest agar pengguna memilih. Confidence rendah harus mendorong Fallback atau pertanyaan klarifikasi. False positive adalah risiko besar: router menempelkan kemampuan yang tampak cocok tetapi sebenarnya salah target. No-match juga perlu diuji: router harus memberi jalur berguna ketika tidak ada kemampuan yang cocok.

Metadata tidak membuat ekstensi otomatis terpercaya. Ia membantu runtime memahami klaim kemampuan, tetapi trust datang dari review, sumber, izin, dependensi, dan perilaku saat dijalankan. Untuk pembaca yang ingin mendalami discovery registry dan batas otorisasi, Agentic Resource Discovery: ai-catalog.json, Verifikasi, dan Batas Otorisasi Phone Agent membahas sisi registri yang memang terpisah dari halaman ini.

Pemulihan Saat Kemampuan Hilang, Usang, Ditolak, atau Ambigu

Routing yang baik diukur dari cara ia gagal. Kemampuan bisa hilang karena tool dinonaktifkan, Plugin belum diaktivasi, Skill belum disetujui, atau aplikasi target tidak tersedia. Dalam kondisi seperti ini, agen perlu menunjukkan kandidat yang gagal beserta alasannya, lalu menawarkan tindakan yang aman: pakai kemampuan bawaan yang lebih sempit, minta pengguna mengaktifkan kemampuan, atau simpan tugas sebagai draft.

Dependensi usang menghasilkan masalah berbeda. Misalnya metadata Plugin menyebut kemampuan yang pernah tersedia, tetapi snapshot terbaru belum menerima pembaruan itu. Router harus memakai snapshot aktif yang utuh, bukan mencampur keadaan lama dan baru. Jika izin ditolak, pemulihan izin menjadi jalur khusus. Model retry tidak menyelesaikan izin Android; pengguna perlu melihat layar izin, memahami alasan, lalu memilih sendiri.

Target ambigu juga sering terjadi. “Kirim pesan ke Budi” bisa berarti beberapa kontak. “Buka aplikasi bank” bisa berarti beberapa aplikasi. “Catat ini” bisa berarti memo, task, kalender, atau dokumen. Dalam kasus seperti ini, Suggest lebih sehat daripada eksekusi langsung. Router menampilkan kandidat dan meminta pilihan. Jika tidak ada kandidat yang cukup kuat, Fallback dapat menyiapkan teks manual atau meminta detail tambahan.

Pemulihan berbeda dari pengulangan tanpa batas. Agen tidak perlu mencoba terus menerus saat state perangkat tidak memenuhi syarat. Ia perlu berhenti pada titik yang jelas, menjaga konteks tugas agar bisa dilanjutkan, dan menampilkan status akhir. Untuk risiko izin pada Skill dan tindakan runtime, baca Keamanan Skill AI Agent: Mengapa Phone Agent Perlu Cek Izin Saat Berjalan.

• Kemampuan hilang: tampilkan kandidat yang gagal dan tawarkan kemampuan bawaan atau aktivasi yang terlihat.
• Dependensi usang: pertahankan snapshot kemampuan aktif yang utuh dan minta refresh yang aman.
• Izin ditolak: arahkan ke pemulihan izin, bukan retry model.
• Target ambigu: tampilkan pilihan, jangan memilih penerima atau aplikasi secara sembarang.
• No-match: tawarkan draft, instruksi, atau task lanjutan tanpa mengarang kemampuan.

Perutean Kemampuan Terkelola di FoneClaw

Di FoneClaw, kami membangun perutean kemampuan sebagai bagian dari runtime agen ponsel Android. Pengguna memberi permintaan dalam bahasa natural. FoneClaw membaca konteks yang relevan, mencocokkan kandidat dari 100+ built-in tools, Skills, Workflows, dan Plugins yang telah melalui statusnya masing-masing, lalu memilih apakah konteks perlu AutoAttach, pilihan perlu Suggest, atau rute perlu Fallback.

Ambil contoh permintaan “siapkan mode rapat”. FoneClaw dapat mengangkat kandidat seperti status volume, ringer mode, Do Not Disturb, memo, dan shortcut. Jika layar saat ini membantu memahami konteks, AutoAttach dapat membawa informasi yang diminta pengguna. Jika ada beberapa cara yang masuk akal, Suggest menampilkan rencana yang bisa dipilih: hanya kecilkan volume, aktifkan Do Not Disturb bila izin siap, buat memo, atau simpan Workflow rapat. Jika izin DND belum tersedia, Fallback membawa pengguna ke pemulihan izin atau menawarkan rute yang tidak membutuhkan izin tersebut.

Plugin activation kami perlakukan sebagai tahap yang terlihat. Plugin yang cocok sebagai kandidat tetap melewati activation review. Skill learning juga memakai preview dan confirmation sebelum draft nonaktif disimpan. Dengan pola ini, pengguna bisa melihat kemampuan yang sedang dibentuk tanpa membuatnya langsung aktif untuk tindakan sensitif. Routing membantu menemukan jalan; approval tetap menentukan kapan tindakan berdampak dijalankan.

AutoAttach, Suggest, dan Fallback kami desain agar tidak melewati approval. Ketika tindakan menyentuh setelan sistem, komunikasi, kalender, file, atau data pribadi, FoneClaw menampilkan rencana dan hasil yang akan terjadi. Setelah pengguna menyetujui, tool dijalankan dan hasil diperiksa. Jika perangkat berubah, izin belum siap, atau aplikasi target tidak cocok, FoneClaw berhenti pada recovery yang bisa dipahami.

Informasi kemampuan publik FoneClaw dapat dilihat di halaman Features FoneClaw. Dari sisi produk, arah yang kami bangun adalah router yang semakin baik mengenali konteks tanpa mengambil alih keputusan pengguna: kandidat lebih tepat, saran lebih jelas, fallback lebih berguna, dan approval tetap menjadi batas sebelum tindakan berdampak.

Tujuh Cek untuk Mendesain Router Kemampuan

Gunakan tujuh cek ini saat mendesain atau mengevaluasi router kemampuan. Pertama, uji kualitas kandidat: apakah permintaan menghasilkan kemampuan yang relevan dan urutannya masuk akal? Kedua, uji false positive: berikan permintaan mirip tetapi berbeda, lalu pastikan router tidak menempelkan kemampuan yang salah. Ketiga, uji no-match: pastikan agen memberi jalur cadangan ketika tidak ada kemampuan yang cocok.

Keempat, uji dependensi. Matikan izin, nonaktifkan Plugin, atau gunakan aplikasi yang belum tersedia, lalu lihat apakah router menandai kandidat sebagai belum siap. Kelima, uji batas attachment. AutoAttach harus membawa konteks yang diperlukan tanpa berubah menjadi eksekusi. Keenam, uji approval. Tindakan berdampak perlu rencana, alasan, dan konsekuensi yang terlihat. Untuk desain approval yang lebih rinci, UX Persetujuan Agen AI di Ponsel: Keyakinan, Alasan, dan Kontrol Pengguna memberi kerangka yang lebih dalam.

Ketujuh, uji recovery. Jalankan satu permintaan dengan match jelas dan satu permintaan ambigu. Catat apakah router bisa berhenti, meminta klarifikasi, membuka pemulihan izin, atau menyimpan draft untuk dilanjutkan. Evaluasi perutean kemampuan tidak cukup memakai akurasi pencocokan. Yang perlu dicatat adalah seluruh perjalanan: kandidat, context attachment, activation, approval, eksekusi, hasil, dan pemulihan.

1. Uji kandidat relevan untuk satu permintaan Android nyata.
2. Uji false positive dengan permintaan yang mirip tetapi targetnya berbeda.
3. Uji no-match dan pastikan ada fallback yang berguna.
4. Uji dependensi yang belum siap sebelum activation.
5. Uji AutoAttach agar hanya menambah konteks atau metadata.
6. Uji approval untuk tindakan berdampak.
7. Uji recovery saat izin ditolak, target ambigu, atau aplikasi tidak tersedia.

Sumber: Google Developers tentang Agent Plugins, GitHub Changelog tentang Agent finder, dan halaman Features FoneClaw.