Kacamata Livis AI OpenClaw: model handoff dari kacamata ke agen ponsel

Apa yang benar-benar disebut dalam laporan OTA Livis Juli

Jawaban langsungnya: laporan 25 Juli 2026 yang dipublikasikan Sina Finance dari IT Home mengatakan pembaruan OTA Livis menambahkan koneksi langsung dari kacamata ke terminal OpenClaw pribadi. Laporan yang sama juga menyebut akses Xiaohongshu Agent, peningkatan kecepatan respons percakapan AI, dan kebutuhan memperbarui Li Auto app ke versi 2.6.0 untuk memakai fungsi terbaru. Itu adalah fakta yang bisa dipakai untuk menjawab pencarian kacamata Livis AI OpenClaw.

Yang belum dijelaskan oleh laporan itu sama pentingnya. Laporan tersebut tidak mendokumentasikan langkah setup lengkap, daftar perintah yang didukung, wilayah ketersediaan, cara progres ditampilkan, format hasil akhir, atau kemampuan kontrol ponsel. Karena itu, artikel ini memisahkan dua hal: pertama, fakta laporan bahwa Livis disebut dapat tersambung ke terminal OpenClaw pribadi; kedua, rancangan arsitektur yang masuk akal jika sebuah kacamata AI menjadi pintu masuk ke agen pribadi dan, pada tahap terpisah, ke aksi Android.

Untuk pembaca yang ingin menilai produk semacam ini, pertanyaan utamanya bukan hanya “bisa tersambung atau tidak”. Pertanyaan yang lebih praktis adalah: di mana tugas berjalan, siapa memegang kredensial, permukaan mana yang menampilkan konfirmasi, apa yang terjadi bila suara salah dikenali, dan apakah tindakan ponsel punya izin serta approval sendiri. Di sinilah handoff kacamata pintar ke agen ponsel perlu dirancang sebagai rantai keputusan, bukan satu tombol ajaib.

Mengapa kacamata AI adalah permukaan kontrol, bukan seluruh agen

Kacamata AI kuat sebagai permukaan kontrol karena berada dekat dengan mata, telinga, dan suara pengguna. Ia dapat menangkap perintah lisan, memberi petunjuk singkat, membaca konteks visual tertentu bila ada kamera, dan membuat interaksi terasa lebih cepat daripada membuka ponsel. Namun permukaan kontrol bukan berarti seluruh agen berjalan di kacamata. Banyak tugas membutuhkan penalaran panjang, akses akun, koneksi jaringan, terminal pribadi, atau runtime dengan tool yang jauh lebih luas daripada perangkat wearable.

Situs resmi OpenClaw menggambarkan OpenClaw sebagai proyek open source yang berjalan di mesin pengguna. OpenClaw juga menjelaskan request yang dapat dimulai melalui WhatsApp, Telegram, atau aplikasi chat lain, dengan contoh pekerjaan seperti inbox, email, kalender, dan check-in penerbangan. Fakta ini membantu memahami konsep “terminal pribadi”: tugas dapat dimulai dari permukaan komunikasi ringan, sementara runtime utama tetap berada di mesin pengguna.

Jika kacamata Livis berperan sebagai salah satu permukaan masuk, perannya dapat disejajarkan dengan chat atau voice entry point: ia menerima niat, meneruskan request, lalu menunggu status. Itu tidak berarti Livis menjalankan OpenClaw secara lokal di kacamata, dan tidak berarti setiap kacamata AI memiliki sensor, layar, atau kemampuan feedback yang sama. Arsitektur yang baik memisahkan input wearable, runtime agen, dan target tindakan sejak awal.

Arsitektur praktis dari kacamata ke agen lalu ke ponsel

Bayangkan contoh rendah risiko: pengguna memakai kacamata AI dan berkata, “ingatkan saya membalas email ini nanti malam.” Kacamata menangkap perintah suara dan mungkin konteks visual singkat. Agen pribadi mengubahnya menjadi niat: membuat pengingat atau menyiapkan follow-up. Jika tindakan akhirnya berada di ponsel Android, masih dibutuhkan lapisan aksi ponsel yang mendukung pengingat, notifikasi, aplikasi kalender, atau workflow terkait. Koneksi ke terminal pribadi tidak otomatis memberi wewenang ke ponsel.

Model handoff yang dapat dipercaya memisahkan setiap lapisan dengan input, output, dan batas gagal yang jelas:

Untuk kerangka handoff lintas perangkat yang lebih umum, Agen AI Lintas Perangkat Membutuhkan Handoff yang Berpusat di Ponsel menjelaskan mengapa ponsel sering menjadi titik keputusan yang lebih kaya daripada wearable. Di artikel ini, fokusnya lebih sempit: bagaimana request dari kacamata dapat melewati agen pribadi tanpa membawa wewenang tak terbatas ke perangkat Android.

Di mana progres, konfirmasi, dan hasil sebaiknya muncul

Laporan Livis tidak menjelaskan protokol lengkap untuk progres dan hasil. Karena itu, desain yang dibahas di sini adalah model evaluasi, bukan daftar fitur Livis. Dalam handoff yang sehat, pengguna perlu melihat setidaknya lima keadaan: request diterima, tugas sedang berjalan, agen menunggu informasi, tindakan membutuhkan konfirmasi, dan hasil sudah selesai atau gagal. Tanpa status seperti ini, pengguna sulit membedakan antara agen yang bekerja, tersangkut, atau mengambil langkah yang salah.

Kacamata cocok untuk acknowledgement cepat: “saya terima” atau “saya butuh detail lagi”. Untuk konfirmasi yang membawa konsekuensi, ponsel biasanya menjadi permukaan yang lebih masuk akal karena layar lebih besar, target bisa diperiksa, dan pengguna dapat melihat detail seperti penerima pesan, aplikasi, waktu pengingat, atau isi draft. Suara dapat membantu, tetapi tidak perlu menjadi satu-satunya jalur persetujuan untuk semua tindakan.

Hasil akhir juga perlu punya rumah yang jelas. Jika tindakan kecil selesai, ringkasan pendek di kacamata cukup. Jika hasilnya sensitif atau perlu ditinjau, ponsel sebaiknya menampilkan bukti dan opsi koreksi. Desain ini menjaga kacamata AI sebagai antarmuka kontrol agen yang cepat, sementara ponsel tetap menjadi tempat konfirmasi, pemulihan, dan review saat tugasnya lebih berat.

Batas kamera, mikrofon, akun, terminal, dan wewenang ponsel

Wearable menambah lapisan privasi karena kamera dan mikrofon berada di tubuh pengguna. Request suara dapat berisi nama kontak, lokasi, agenda, atau konteks kerja. Jika request itu diteruskan ke terminal pribadi, terminal memiliki batas sendiri: akses file, akun email, kalender, browser, atau tool lain yang dikonfigurasi pengguna. Jika kemudian tugas menyentuh ponsel, Android permissions dan approval tindakan menjadi lapisan terpisah lagi.

Panduan runtime permission Android menekankan bahwa izin sebaiknya diminta dalam konteks saat fitur membutuhkannya, dan aplikasi tetap bertanggung jawab menangani izin yang ditolak. Prinsip ini cocok untuk handoff kacamata pintar ke agen ponsel. Persetujuan memakai mikrofon kacamata tidak memberi izin lokasi Android. Koneksi ke terminal OpenClaw pribadi tidak memberi hak mengirim pesan dari ponsel. Izin Android untuk satu fitur juga tidak otomatis menyetujui target bisnis, seperti siapa penerima pesan atau akun mana yang dipakai.

Peta wewenang yang praktis dapat dibaca seperti ini: kacamata memiliki izin sensor dan akun perangkatnya sendiri; runtime OpenClaw memiliki akses mesin pengguna dan kredensial yang dikonfigurasi di sana; phone agent memiliki tool Android yang didukung, izin sesuai konteks, dan policy approval; aplikasi target memiliki akun dan batas internalnya sendiri. Setiap lapisan perlu titik cabut akses, bukan satu persetujuan besar yang menjalar ke seluruh rantai.

Untuk pembaca yang ingin memahami risiko deployment OpenClaw secara lebih luas, Risiko Keamanan OpenClaw dan Batas Agen Ponsel yang Lebih Aman membahas batas terminal, skill, dan otoritas tanpa mengubah artikel ini menjadi audit keamanan OpenClaw.

Cara menghentikan, mencabut, dan memulihkan handoff yang gagal

Handoff yang baik harus mudah dihentikan. Pengguna perlu tahu cara membatalkan request dari kacamata, menghentikan tugas di runtime agen, mencabut akses akun, menolak izin Android, dan membatalkan tindakan di aplikasi target. Jika satu lapisan gagal, sistem tidak boleh diam-diam berpindah ke target lain atau memperluas scope tanpa sepengetahuan pengguna.

1. Mulai dengan tugas rendah risiko, misalnya membuat draft atau pengingat yang belum dikirim.
2. Pastikan ada acknowledgement: kacamata atau ponsel memberi tahu request diterima.
3. Tetapkan timeout untuk tugas yang menunggu terminal atau jaringan.
4. Jika target ambigu, minta klarifikasi sebelum memakai kontak, akun, file, atau aplikasi.
5. Untuk tindakan eksternal, tampilkan konfirmasi pada permukaan yang memadai.
6. Sediakan stop dari kacamata dan ponsel, lalu catat status terakhir.
7. Siapkan revokasi per lapisan: sensor kacamata, sesi terminal, izin Android, dan akses aplikasi.
8. Jika gagal, tampilkan penyebab yang berguna: izin ditolak, terminal offline, target tidak jelas, atau tindakan tidak didukung.

Daftar ini bukan klaim bahwa Livis atau OpenClaw sudah mengekspos semua kontrol tersebut. Ini adalah standar evaluasi pembeli dan builder. Agen AI pribadi dengan perintah suara terasa praktis hanya jika pengguna tetap tahu apa yang berjalan, di mana berhentinya, dan bagaimana memulihkan alur tanpa membuka akses yang lebih luas.

Bagaimana FoneClaw dapat menjadi lapisan aksi Android yang terkelola

Setelah lapisan kacamata dan runtime pribadi jelas, barulah FoneClaw relevan sebagai contoh lapisan aksi Android. FoneClaw adalah runtime phone agent Android yang digerakkan oleh model kompatibel yang dikonfigurasi pengguna. Model membantu memahami tujuan dan menyusun rencana; FoneClaw memanggil tool Android yang didukung, menampilkan hasil, memandu izin saat dibutuhkan, menerapkan approval, dan menangani pemulihan saat alur gagal.

Berdasarkan data rilis FoneClaw yang tersedia pada 1 Agustus 2026, versi 0.1.0 menambahkan pencarian per-tool, kontrol enable, approval override, kontrak yang lebih aman, pemulihan izin, dan penanganan kegagalan yang lebih kuat. Katalog tool publik FoneClaw pada tanggal yang sama berisi 118 built-in tools dalam 11 kategori dengan label risiko dan approval. Dalam penjelasan yang tahan waktu, kami menyebutnya 100+ built-in tools karena katalog berkembang.

Dalam model handoff, request dari wearable tidak menjadi perintah ponsel otomatis. Ia perlu diterjemahkan menjadi tindakan yang didukung, misalnya membaca layar, membuka aplikasi, menyiapkan komunikasi, menjalankan workflow, atau memakai plugin yang dikelola secara terpisah. Built-in tools dan plugin bukan hal yang sama; keduanya perlu jalur kontrol yang terlihat. Prioritas interaksi FoneClaw juga cocok dengan konteks wearable: suara sebagai jalur pertama, tombol sebagai jalur kedua, dan sentuhan sebagai jalur ketiga saat pengguna perlu memeriksa detail.

Kami tidak mengklaim integrasi Livis, OpenClaw, dan FoneClaw saat ini. Peran FoneClaw di sini adalah menunjukkan bagaimana lapisan phone action yang governed seharusnya bekerja setelah sebuah agen menyusun rencana. Untuk model eksekusi Android yang lebih lengkap, Kontrol Ponsel dengan AI Agent: Cara Kerja, Batas, dan Keamanan Android menjelaskan alur niat, tool, izin, approval, dan hasil pada ponsel.

Checklist menilai kacamata AI yang terhubung ke agen

Saat menilai kacamata AI yang mengklaim dukungan agen, pisahkan fakta produk dari rancangan ideal. Pertama, cari sumber yang menyebut tanggal, versi aplikasi, perangkat yang didukung, dan fitur yang benar-benar diumumkan. Kedua, identifikasi lokasi runtime: di kacamata, di ponsel, di cloud, atau di mesin pribadi seperti terminal OpenClaw. Ketiga, tanyakan apakah request hanya masuk melalui suara atau juga bisa dilihat, dikoreksi, dan dihentikan.

Checklist ringkasnya: apakah koneksi ke agen punya akun yang jelas; apakah sensor kacamata bisa dimatikan; apakah runtime jarak jauh punya log; apakah tindakan ponsel memakai izin Android sesuai konteks; apakah konfirmasi muncul di tempat yang cukup detail; apakah hasil bisa diperiksa; apakah akses bisa dicabut per lapisan; dan apakah tugas pertama dapat diuji dengan aksi rendah risiko. Jangan mulai dari pesan, pembayaran, penghapusan file, atau perubahan pengaturan.

Jika yang Anda butuhkan adalah perbandingan produk kacamata AI dengan phone agent Android, Meta Ray-Ban AI vs FoneClaw: pilih kacamata AI atau agent AI ponsel? memberi sudut pandang pembelian tanpa mengubah artikel arsitektur ini menjadi ranking. Kesimpulan praktisnya: kacamata dapat menjadi pintu masuk yang sangat nyaman, tetapi ponsel tetap tempat yang kuat untuk konfirmasi, otorisasi, hasil, dan pemulihan.