Phone Agent yang Meningkatkan Diri: Versi Skill, Pengujian, dan Rollback

Apa arti phone agent yang meningkatkan diri?

Phone agent yang meningkatkan diri adalah agent yang menggunakan hasil pelaksanaan tugas dan jejak kegagalan untuk memperbaiki cara merencanakan, memilih alat, memverifikasi hasil, memulihkan kesalahan, dan memakai skill berulang. Perubahan tersebut tetap dibatasi oleh bukti, pengujian, persetujuan, catatan versi, serta kemampuan Android yang didukung.

Istilah self-evolving AI agent sering menimbulkan kesan bahwa agent menulis ulang kecerdasannya sendiri. Dalam arsitektur yang terkelola, ada empat bagian yang perlu dipisahkan. Bobot model menentukan kemampuan dasar model. Harness atau kerangka pengoperasian mengatur prompt, alat, runtime, verifikasi, orkestrasi, dan pemulihan. Skill menyimpan prosedur yang dapat dipakai kembali. Pelaksana Android menjalankan tindakan nyata sesuai izin serta keadaan perangkat.

Dengan pemisahan ini, self-improvement tidak berarti model harus dilatih ulang. Agent dapat membaik ketika prompt lebih jelas, alat dipilih lebih tepat, hasil diperiksa dengan aturan baru, atau pemulihan kegagalan ditambahkan. Model dasarnya dapat tetap sama.

Pembentukan skill dari contoh merupakan tahap lain dalam siklus hidup. Artikel Mengajari Phone Agent lewat Demonstrasi: Rekaman Layar, Skill, dan Keamanan Android membahas pembuatan skill dari demonstrasi. Halaman ini berfokus pada cara skill yang sudah digunakan diperbaiki setelah menghasilkan bukti di lapangan.

Pelajaran Self-Harness: ubah kerangka, bukan bobot model

Bisakah agent membaik saat model dasarnya tidak berubah? Makalah Self-Harness menjawab pertanyaan tersebut melalui siklus tiga tahap: menambang kelemahan dari jejak eksekusi, menyusun usulan perubahan harness yang dibatasi, lalu memvalidasi usulan sebelum diterima.

Tahap pertama mencari bukti kegagalan nyata. Jejak dapat menunjukkan bahwa agent memilih alat yang salah, berhenti terlalu dini, salah membaca hasil, mengulang tindakan tanpa perubahan, atau tidak memakai prosedur pemulihan yang tersedia. Bukti tersebut lebih berguna daripada pernyataan umum bahwa agent “kurang pintar” karena menunjuk bagian alur yang dapat diperbaiki.

Tahap kedua menghasilkan perubahan sekecil mungkin. Harness didefinisikan secara luas dalam makalah tersebut sebagai prompt, alat, mekanisme runtime, aturan verifikasi, logika orkestrasi, dan prosedur pemulihan kegagalan. Usulan dapat berupa pemeriksaan tambahan setelah tindakan, aturan pemilihan alat yang lebih spesifik, atau batas percobaan ulang yang lebih baik.

Tahap ketiga menguji perubahan pada contoh yang tidak dipakai untuk menyusun perbaikan. Penulis Self-Harness melaporkan peningkatan tingkat kelulusan pada data uji terpisah di Terminal-Bench-2.0 untuk tiga model dasar yang tetap. Hasil tersebut berasal dari evaluasi penelitian dan menunjukkan kemungkinan memperbaiki harness tanpa mengubah bobot model, bukan jaminan hasil yang sama pada setiap phone agent Android.

Pembahasan Salesforce mengenai agent yang meningkatkan diri menempatkan kemampuan belajar dari pengalaman sebagai arah penting untuk sistem agent. Dalam konteks ponsel, pengalaman harus diterjemahkan menjadi perubahan yang dapat ditinjau. Tindakan nyata membawa keadaan aplikasi, akun, izin, dan konsekuensi pengguna yang tidak cukup diwakili oleh satu skor benchmark.

Pelatihan model dalam lingkungan simulasi memiliki tujuan berbeda. Untuk konteks tersebut, baca PhoneBuddy-4B dan pelatihan Phone Agent: mengapa Mock-App RL penting untuk Android Agent.

Cara FoneClaw meningkatkan perencanaan dan skill secara terkelola

Apakah FoneClaw merupakan phone agent yang meningkatkan diri? Ya. FoneClaw adalah phone agent yang meningkatkan diri melalui hasil pelaksanaan tugas, jejak kegagalan, perubahan terukur pada harness, dan pembaruan skill yang dapat digunakan ulang. Setiap perubahan mengikuti pengujian, persetujuan, pencatatan versi, peluncuran bertahap, pemantauan, dan rollback.

Pengguna tetap memilih serta mengonfigurasi model yang menggerakkan pemahaman bahasa dan perencanaan dalam alur FoneClaw. FoneClaw tidak melatih ulang atau menulis ulang bobot model tersebut. Area peningkatannya berada pada cara agent memakai kemampuan model: cara tujuan diuraikan, tindakan dipilih, hasil diverifikasi, kegagalan ditangani, dan prosedur berulang disimpan sebagai skill.

Misalnya, suatu skill gagal karena tombol yang dicari tidak tersedia pada keadaan aplikasi tertentu. Jejak eksekusi dapat menunjukkan bahwa alur langsung mengulang pencarian tanpa memeriksa apakah pengguna sudah masuk akun. Perbaikannya bukan memberi izin lebih luas. Perubahan minimal dapat menambahkan pemeriksaan status akun, menghentikan pengulangan yang tidak produktif, dan menawarkan fallback yang sesuai.

FoneClaw tetap menjadi pelaksana tindakan Android yang didukung. Hasil ditampilkan kepada pengguna, izin diperiksa dalam konteks tugas, dan langkah penting membutuhkan konfirmasi. Ketika skill diperbarui, mekanisme tersebut tetap berlaku. Versi baru tidak memperoleh akses baru hanya karena menghasilkan tingkat keberhasilan yang lebih tinggi pada pengujian.

Perbaikan juga dapat menyentuh perencanaan. Jika jejak menunjukkan bahwa model sering menggabungkan dua tujuan yang seharusnya dipisahkan, harness dapat meminta rencana dengan kondisi selesai yang lebih jelas. Jika hasil akhir sering tidak diverifikasi, skill dapat menambahkan pemeriksaan keadaan. Semua usulan dinilai terhadap manfaat, perubahan izin, dan potensi regresi.

Skill yang berjalan tetap memerlukan pemeriksaan izin pada saat digunakan. Prinsip ini dijelaskan lebih rinci dalam Keamanan Skill AI Agent: Mengapa Phone Agent Perlu Cek Izin Saat Berjalan.

Dari jejak eksekusi hingga peluncuran bertahap dan rollback

Bagaimana perubahan phone agent bergerak dari gagasan ke penggunaan nyata? Siklus yang sehat tidak langsung memasang perbaikan setelah satu kegagalan. Ia menghubungkan bukti dengan perubahan minimal, pengujian, persetujuan, dan jalan kembali yang telah disiapkan.

1. Kumpulkan bukti: simpan hasil, keadaan aplikasi, langkah yang dipilih, izin, konfirmasi, kegagalan, dan pemulihan.
2. Kelompokkan masalah: bedakan kesalahan rencana, perubahan antarmuka, kegagalan jaringan, sesi akun, izin, dan hasil yang salah dibaca.
3. Usulkan perubahan minimal: ubah bagian terkecil pada prompt, skill, pemilihan alat, verifikasi, atau fallback.
4. Jalankan pengujian regresi: uji kasus yang gagal, kasus yang sebelumnya berhasil, variasi perangkat, bahasa, keadaan akun, serta izin.
5. Bandingkan izin: periksa apakah versi baru membaca data, membuka aplikasi, atau meminta kemampuan tambahan.
6. Minta persetujuan: perubahan penting ditinjau sebelum masuk ke alur penggunaan nyata.
7. Beri nomor versi: simpan definisi skill, harness, pengujian, kebutuhan izin, dan catatan perubahan.
8. Luncurkan bertahap: mulai pada cakupan kecil atau mode observasi sebelum memperluas penggunaan.
9. Pantau hasil: ukur keberhasilan, kegagalan, pembatalan, waktu, percobaan ulang, serta koreksi pengguna.
10. Lakukan rollback: kembalikan versi sebelumnya ketika indikator memburuk atau perilaku baru tidak sesuai.

Perbandingan izin merupakan titik kendali yang berdiri sendiri. Sebuah perbaikan dapat meningkatkan keberhasilan dengan meminta akses tambahan, tetapi akses tersebut belum tentu diperlukan. Versi seharusnya menjelaskan kebutuhan izin serta alasan perubahan agar manfaat tidak diperoleh dengan memperluas kewenangan secara tersembunyi.

Peluncuran bertahap mengurangi dampak kesalahan. Versi baru dapat terlebih dahulu menyusun rencana tanpa menjalankan tindakan, lalu diuji pada lingkungan terbatas. Setelah hasil stabil, cakupan dapat diperluas. Pada setiap tahap, konfirmasi Android dan kontrol pengguna tetap aktif.

Catatan versi perlu menghubungkan siapa yang menyetujui, pengujian yang lulus, izin yang berubah, dan versi sebelumnya yang dapat dipulihkan. Pembahasan lebih luas mengenai identitas serta audit tersedia dalam Identitas, izin, dan audit trail AI agent: lapisan keamanan untuk agen ponsel.

Perbaikan semu, solusi terlalu sempit, dan perubahan izin

Mengapa peningkatan otomatis dapat menghasilkan perilaku yang lebih buruk? Makalah Phantom Guardrails pada Juli 2026 menunjukkan risiko bahwa pengoptimal dapat menciptakan gambaran kegagalan yang sebenarnya tidak ada, lalu menambahkan guardrail yang tidak diperlukan. Jika penerimaan hanya menilai apakah gejala yang diciptakan itu menghilang, perubahan buruk dapat terlihat berhasil.

Risiko ini disebut kegagalan semu. Agent dapat menyimpulkan bahwa suatu alat berbahaya atau tidak andal berdasarkan jejak yang salah dibaca, kemudian memblokir alur yang sebenarnya valid. Karena itu, bukti awal harus dapat direproduksi. Pengujian juga perlu memastikan bahwa guardrail baru memecahkan masalah nyata tanpa menutup kemampuan yang sah.

Solusi terlalu sempit muncul ketika perbaikan menghafal satu contoh. Tombol tertentu mungkin ditemukan pada satu ukuran layar tetapi gagal pada perangkat lain. Label dalam bahasa Indonesia dapat berbeda dari bahasa lain. Urutan dialog dapat berubah setelah pembaruan aplikasi. Skill yang hanya diuji pada tampilan lama akan memperoleh skor bagus tanpa menjadi lebih tangguh.

Perubahan keadaan akun juga dapat menciptakan regresi. Alur yang berhasil saat pengguna sudah masuk mungkin gagal pada sesi yang kedaluwarsa. Demikian pula, izin yang pernah diberikan dapat dicabut. Agent perlu mengenali keadaan tersebut, bukan menganggap aplikasi rusak atau mencoba memperluas akses.

Benchmark yang tidak berubah tidak cukup untuk menguji agent yang terus berkembang. Perbaikan dapat menyesuaikan diri secara berlebihan terhadap kumpulan tugas yang sama. Tambahkan kasus baru, variasi bahasa, perubahan tata letak, data kosong, jaringan lambat, dialog izin, dan kegagalan sebagian. Pertahankan pula kasus yang sebelumnya berhasil agar peningkatan satu alur tidak merusak alur lain.

Sandbox dapat membatasi lingkungan pengujian, tetapi tidak menggantikan izin pada ponsel nyata. Perbedaannya dibahas dalam Sandbox AI Agent vs Izin Ponsel: Mengapa Batas Tetap Penting.

Daftar periksa sebelum perubahan dipakai pada Android nyata

Kapan versi skill atau harness baru siap digunakan? Jawabannya memerlukan bukti di beberapa dimensi, bukan hanya kenaikan tingkat keberhasilan. Gunakan daftar berikut sebelum menyetujui perubahan untuk alur Android nyata.

Rollback bukan sekadar mengembalikan berkas skill. Sistem perlu memulihkan prompt, aturan alat, kebutuhan izin, konfigurasi verifikasi, dan prosedur pemulihan yang terkait dengan versi stabil sebelumnya. Tugas yang sedang berlangsung harus dihentikan atau diselesaikan pada batas yang aman sebelum pergantian versi.

Indikator rollback sebaiknya ditentukan lebih dahulu, misalnya lonjakan kegagalan, percobaan ulang berulang, pembatalan pengguna, kebutuhan izin tak terduga, atau hasil yang tidak sesuai. Dengan ambang yang jelas, tim tidak perlu menunggu dampak meluas untuk mengambil tindakan.

FoneClaw menggabungkan pembelajaran dari hasil eksekusi dengan tata kelola perubahan tersebut. Model yang dikonfigurasi terus menyediakan pemahaman serta perencanaan, sedangkan FoneClaw meningkatkan harness dan skill untuk menjalankan tindakan Android yang didukung secara lebih andal. Versi, pengujian, izin, konfirmasi, pemantauan, fallback, dan rollback menjaga setiap peningkatan tetap dapat diperiksa serta dipulihkan.