—·
Rubrik praktis untuk membandingkan agen perangkat Xiaomi MiMo miclaw dengan tumpukan tool OpenAI, Claude, dan Gemini—lengkap dengan kasus eval yang bisa dijalankan.
Di sebuah smartphone, perbedaan antara “asisten” dan “pengendali perangkat” langsung terasa begitu perintah “nyalakan lampu” pertama kali dilontarkan—dan respons itu sama ada bekerja dengan benar, atau justru macet, salah, atau diblokir. Pada 6 Maret 2026, Xiaomi memulai uji terbatas Xiaomi miclaw, dengan menyebutnya sebagai asisten AI tingkat sistem di smartphone yang dapat melakukan aksi perangkat dan smart-home setelah pengguna memberikan izin. (gizmochina.com)
Perubahan ke “eksekusi aksi” ini krusial, karena keberhasilan tidak lagi bisa diukur hanya sebagai respons yang terdengar meyakinkan. Ini berubah menjadi persoalan rekayasa: apakah sistem benar-benar mengambil aksi yang tepat, pada izin yang benar, dalam batas latensi dan biaya yang masih dapat diterima—terhubung melalui lapisan perangkat pintar Mi Home dari Xiaomi? (news.cgtn.com, gizmochina.com)
Barisan MiMo v2 dari Xiaomi diposisikan sebagai lapisan model di balik perilaku ini. Repositori MiMo-V2-Flash dan penulisan teknisnya menjelaskan arsitektur Mixture-of-Experts (MoE) (artinya hanya subset “pakar” sub-model yang aktif per token), dengan 309B total parameter dan 15B aktif, serta klaim konteks panjang hingga 256K. (github.com, arxiv.org) Model ini juga mendokumentasikan “Multi-Token Prediction (MTP),” yang dipakai untuk mempercepat decoding dengan memprediksi beberapa token masa depan. (github.com, arxiv.org)
Namun, kisah miclaw tetaplah kisah sistem: model yang cepat, antarmuka tool menuju perangkat, serta lapisan permissions/guardrails. Evaluasi harus mencakup ketiganya—bukan hanya “kecerdasan” model.
Perbandingan “agentic tooling” lintas keluarga tidak perlu mengandalkan slogan kemampuan. Ukur lima sifat eksekusi—langsung selaras dengan workflow pengendalian perangkat yang sedang diuji oleh miclaw. (Pengujian dapat dijalankan di staging dengan harness yang aksesnya dikunci oleh izin.)
Keandalan tool-calling menanyakan: ketika model memutuskan menggunakan tool, apakah ia menghasilkan pemanggilan yang sesuai skema, dan apakah lapisan orkestrasi mengeksekusinya secara deterministik?
Kegagalan tool-calling tidak selalu berakar pada “kecerdasan.” Tool API mensyaratkan output terstruktur tertentu. Dokumentasi OpenAI menyatakan bahwa Structured Outputs dapat memaksa keselarasan dengan JSON schema jika strict: true diaktifkan. (help.openai.com) Dokumentasi penggunaan tool dari Anthropic juga menyoroti peringatan tentang mismatch format, seperti “tool_use ids… found without tool_result blocks.” (docs.anthropic.com)
Untuk miclaw MiMo secara spesifik, dokumentasi publik terbatas. Meski demikian, laporan menyebut miclaw dapat mengendalikan perangkat smart-home yang didukung melalui Mi Home dan fungsi tingkat sistem, hanya setelah izin pengguna diberikan. (gizmochina.com) Karena itu, uji keandalan sebaiknya memasukkan dua jenis skenario: “happy path” untuk tool call yang jelas, serta prompt “batas skema” (nama perangkat ambigu, waktu yang hanya sebagian ditentukan, dan banyak kemungkinan aksi).
Jika tool call gagal 1–3% dari waktu, automasi perangkat horizon panjang akan turun tajam. Alasan sederhana: percobaan ulang menambah latensi, dan memicu prompt izin berulang. Kebenaran terhadap skema tool seharusnya menjadi metrik pengunci sebelum menguji tahap “penalaran” yang lebih dalam.
Dekomposisi tugas multi-langkah mengecek apakah agen memecah permintaan menjadi urutan yang tepat dari tool call dan validasi (baca state → pilih aksi → verifikasi hasil → lanjut atau berhenti).
Stack agen berbeda-beda, meskipun berbagi kemampuan inti LLM yang mirip. Pada orkestrasi produksi, tim sering menginginkan langkah perencanaan yang eksplisit, disertai verifikasi berbasis tool. Dokumentasi Anthropic tentang tool use menjelaskan mode di mana model memutuskan kapan memanggil tool dan bagaimana hasil tool dipakai untuk melanjutkan. (docs.anthropic.com) Stack ala OpenAI lazimnya memakai enforcement skema dan pencatatan tracing eksekusi tool agar dekomposisi tetap berakar pada kenyataan.
Untuk agen pengendali perangkat di konteks Tiongkok, dekomposisi juga harus menerjemahkan bahasa natural menjadi semantik tingkat perangkat. Misalnya, mengubah “redupkan lampu agar terasa hangat yang nyaman” menjadi kombinasi brightness plus rentang color temperature. Perilaku otomasi Mi Home terdokumentasi pada materi privasi dan IoT milik Xiaomi di tingkat platform (termasuk izin yang diperlukan untuk pemindaian perangkat dan interaksi). (trust.mi.com)
Agar pengujian dekomposisi bisa dibandingkan lintas vendor, jangan hanya memverifikasi bahwa banyak langkah terjadi. Ukur apakah loop verifikasi muncul karena alasan yang benar. Terapkan skor dekomposisi dengan tiga komponen yang terukur:
Secara konkret, jalankan satu set tugas tetap dengan urutan tool yang diharapkan bersifat deterministik. Untuk setiap tugas, catat tool calls dan snapshot state, lalu hitung:
Latensi bukan hanya kecepatan model. Agent yang terorkestrasi menambah overhead untuk perencanaan, pemanggilan tool berulang, dan kemungkinan reranking atau self-check.
Laporan teknis MiMo-V2-Flash menjelaskan percepatan decoding menggunakan MTP dan melaporkan perilaku acceptance-length serta peningkatan decoding speed (dicatat hingga 2,6x pada bagian hasil eksperimen dalam paper). (arxiv.org) Interpretasikan dengan hati-hati: latensi end-to-end bergantung pada serving stack serta jumlah tool calls, bukan sekadar token/detik.
Di sisi OpenAI, pola tool calling sering memisahkan generasi model dari eksekusi tool. Anggaran latensi menjadi: (waktu perencanaan LLM) + (waktu eksekusi tool) + (kelanjutan LLM kedua). Dokumentasi function calling OpenAI menyoroti structured outputs, yang secara tidak langsung mengurangi siklus yang terbuang akibat tool calls yang salah format. (help.openai.com)
Ukur latensi pada lapisan orkestrasi: p50 dan p95 untuk (1) aksi tool tunggal dan (2) sekuens perangkat 3–6 langkah. Model yang “cepat” bisa kalah dari model yang lebih lambat jika perlu lebih banyak retry akibat error tool-call.
Kegagalan yang paling menyakitkan secara operasional adalah penolakan izin. Ketika agen perangkat diblokir (izin ditolak pengguna, OS menolak, API menolak), respons yang benar bukan “terus mencoba selamanya.” Sistem semestinya gagal dengan aman (fail safely) disertai penjelasan yang dapat ditindaklanjuti—dan idealnya beralih ke aksi alternatif yang diizinkan.
Dokumentasi developer Claude menjelaskan pola penanganan input pengguna yang eksplisit: Claude meminta input pengguna ketika membutuhkan izin untuk memakai tool, dan dapat mengembalikan hasil penolakan ketika izin tidak diberikan. (platform.claude.com) Dokumentasi tool-use juga mencatat error saat urutan tool tidak diformat dengan benar, yang bisa tampak seperti “kegagalan di bawah denial” dalam log. (docs.anthropic.com)
Untuk miclaw Xiaomi, pelaporan publik menyatakan miclaw dapat mengendalikan perangkat dan tool sistem “selama pengguna mengizinkannya,” dengan informasi sensitif diproses secara lokal melalui deskripsi “edge-cloud privacy computing.” (gizmochina.com, gizmochina.com) Ini mengisyaratkan desain yang “permission-gated”—dan justru perilaku inilah yang harus diuji secara keras.
Sinyal paralel datang dari gelombang besar OpenClaw. Liputan keamanan menyebut pemerintah Tiongkok mengeluarkan peringatan terkait risiko adopsi OpenClaw, termasuk bahwa instalasi yang tidak semestinya dan operasi agen secara otonom dengan izin sistem tinggi dapat meningkatkan dampak penyalahgunaan. (techradar.com) Ini bukan bukti spesifik miclaw, tetapi memperkuat model kegagalan umum: penolakan izin + aksi otonom yang dapat gagal secara berbahaya jika tidak ditangani.
Kegagalan izin punya bentuk, sehingga harness sebaiknya memberi penilaian yang granular. Bangun matriks denial:
Lalu beri skor tiga outcome untuk setiap percobaan:
Terakhir, waspadai pola “permission retry loop”: pemanggilan tool berulang ke endpoint yang sama yang ditolak tanpa mengubah parameter. Catat percobaan tool call per kejadian denial dan tetapkan batas keras (mis. maksimum 1 retry).
Grounding multibahasa mengukur apakah agen memetakan perintah dalam berbagai bahasa secara tepat ke entitas yang benar dan parameter aksi yang tepat.
Evaluasi harus memasukkan variasi frasa yang dilokalkan (sinonim, slang, transliterasi) serta mismatch dalam penamaan perangkat. MiMo-V2-Flash mengklaim konteks panjang dan diposisikan untuk penalaran dan coding serta pemanfaatan “agentic foundation” dalam materi Xiaomi. (github.com, arxiv.org) Namun akurasi perintah multibahasa tidak bisa dijamin hanya oleh panjang konteks. Dibutuhkan uji level perintah, seperti: “set lampu ruang tamu ke 30% dalam bahasa Jepang,” “set ‘warm mode’ dalam bahasa Inggris,” lalu verifikasi bahwa agen memanggil perangkat yang benar dan menggunakan rentang numerik yang benar.
Bagi pengguna nonspesialis, grounding multibahasa berarti model “menempelkan” kata-kata dalam suatu bahasa ke kontrol perangkat yang nyata (device IDs, brightness, temperature)—bukan sekadar mendeskripsikannya secara kabur.
Jalankan set aksi yang sama dalam setidaknya dua bahasa yang akan dipakai pengguna target, lalu nilai pada ketepatan parameter serta ketepatan pemilihan perangkat.
MiMo-V2-Flash tidak dipresentasikan sebagai model chatbot-only. Repositori MiMo-V2-Flash memposisikannya sebagai foundation yang efisien untuk penalaran/coding/agentic use, sekaligus menyertakan modul Multi-Token Prediction yang dijelaskan dalam dokumentasi. (github.com) Laporan teknis arXiv membahas speculative decoding melalui MTP dan memberikan angka speedup decoding yang dilaporkan. (arxiv.org)
Miclaw Xiaomi dilaporkan sebagai aplikasi tingkat sistem pada closed beta dengan lebih dari 50 kapabilitas, termasuk membaca/menulis pesan teks dan file serta mengendalikan perangkat smart home melalui Mi Home ketika diizinkan. (news.cgtn.com, gizmochina.com) Karena detail implementasi tidak sepenuhnya publik, rencana uji sebaiknya berfokus pada perilaku black-box: output tool call, hasil aksi, dan prompt izin.
Gunakan angka-angka berikut untuk membantu pembenaran anggaran rekayasa dan ruang lingkup:
Karena ini adalah workflow agen, jangan terlalu mengunci diri pada angka. Klaim itu menggambarkan efisiensi generasi pada kondisi tertentu; latensi orkestrasi tetap mencakup eksekusi tool dan alur izin pengguna.
Untuk agen perangkat ala miclaw, risiko produksi awal biasanya berupa error skema tool, penargetan perangkat yang keliru, dan “stuck loops” setelah denial. Speedup baru bermakna setelah kebenaran (correctness) dan stop condition sudah terbukti.
Perbandingan arsitektur internal secara langsung antara miclaw Xiaomi dan “OpenAI-class,” “Claude-class,” serta “Gemini-class” tidak bisa dilakukan hanya dari sumber publik. Namun, ada yang bisa dibandingkan: kontrak orkestrasi tool yang mereka tampilkan dan pola kegagalan operasional yang lazim.
Dokumentasi function calling OpenAI menekankan structured outputs dan schema strictness untuk mencegah penyimpangan argumen. Structured Outputs dengan strict: true ditujukan untuk menjamin keselarasan dengan JSON schema. (help.openai.com) Jika diimplementasikan dengan benar, hal ini menurunkan kegagalan reliabilitas yang berasal dari argumen yang salah format—yang bisa menjadi sumber error dominan dalam automasi perangkat.
Dalam praktik, lakukan “uji jarak dekat” dengan sengaja memakai identifier perangkat yang hampir benar (“living rm lamp” vs “living room lamp”) lalu amati apakah enforcement skema yang ketat mencegah agen memanggil argumen tool yang keliru—atau justru meningkatkan hasil “denied action” yang memerlukan klarifikasi.
Anthropic menyediakan panduan implementasi tool use sekaligus menegaskan persyaratan urutan pesan untuk tool calls dan tool results. (docs.anthropic.com) Dokumentasi Claude’s Agent SDK juga menjelaskan bagaimana sistem meminta input pengguna saat membutuhkan izin, serta bagaimana hasil denial harus ditangani. (platform.claude.com)
Implikasi pengujian: pada aksi yang ditolak, stack ala Claude sering menyediakan jalur terstruktur untuk “minta pertanyaan ke pengguna” atau “permission result deny.” Ukur apakah agen mengubah “tidak” menjadi langkah berikutnya yang spesifik—misalnya, “tidak dapat mengubah pengaturan sistem tanpa izin, tetapi dapat menyarankan jalan pintas yang diizinkan.”
Thread forum developer publik menunjukkan praktisi mengalami masalah kualitas/performa tool calling dengan Gemini function calling—sering kali membutuhkan debugging dengan menyederhanakan tool set dan menambahkan argumen secara bertahap. (discuss.ai.google.dev, discuss.ai.google.dev) Ini laporan anekdot, bukan benchmark terkontrol, tetapi mempertegas realitas praktis: reliabilitas tool sangat bergantung pada wrapper orkestrasi dan desain skema tool.
Pada produksi untuk device agents, “nilai agen” tampak dalam kontrak eksekusi. Investasi terbaik biasanya pada skema tool dan penanganan izin—lebih daripada sekadar mengejar nama model.
Pola kasus mengungkap kegagalan yang konsisten—pakai itu untuk menyempurnakan evaluasi.
Entitas: Xiaomi miclaw (agen smartphone tingkat sistem berbasis MiMo)
Outcome: uji internal terbatas/closed beta dimulai setelah pengumuman dan digambarkan permission-gated untuk device control serta integrasi Mi Home. (gizmochina.com, news.cgtn.com)
Timeline: pengumuman dan laporan uji terbatas sekitar 6 Maret 2026. (gizmochina.com)
Yang dipelajari: permission gating dan klaim penanganan lokal membantu, tetapi tidak cukup. Tetap dibutuhkan log end-to-end: tool apa yang dicoba, apa yang ditolak, dan perubahan apa yang benar-benar terjadi.
Entitas: OpenClaw, agen otonom yang populer di pasar Tiongkok
Outcome: otoritas keamanan memperingatkan risiko instalasi yang tidak tepat dan menyoroti bagaimana agen yang beroperasi dengan izin sistem tinggi dapat meningkatkan dampak penyalahgunaan. (techradar.com)
Timeline: peringatan dilaporkan pertengahan Maret 2026 (mis. 13–15 Maret dalam pemberitaan). (techradar.com)
Yang dipelajari: perlakukan penanganan denial dan verifikasi tool sebagai “security primitives.” “Agen melakukan sesuatu” tidak sama dengan “agen melakukan hal yang benar secara aman.”
Entitas: OpenClaw di lingkungan pemerintahan
Outcome: pemberitaan menyebut Tiongkok memperingatkan perusahaan/lembaga negara agar tidak menginstal OpenClaw di komputer kantor dan mengacu pada pedoman keamanan serta standar kredibilitas. (tomshardware.com)
Timeline: dilaporkan sekitar 13 Maret 2026. (tomshardware.com)
Yang dipelajari: konteks lingkungan (kantor vs telepon pribadi) mengubah perhitungan risiko. Uji failure-mode harus spesifik pada lingkungan.
Entitas: Inisiatif Xiaomi dan Huawei terkait AI agents
Outcome: pemberitaan membingkai gelombang deploy yang lebih luas dan menyebut miclaw mulai uji terbatas, sambil menguraikan kemampuan tingkat sistem dan model izin pengguna. (caixinglobal.com)
Timeline: dipublikasikan 12 Maret 2026. (caixinglobal.com)
Yang dipelajari: ketika banyak vendor merilis agen tingkat sistem dengan cepat, celah reliabilitas tool menjadi terlihat di dunia nyata. Pembeda berasal dari disiplin evaluasi—bukan kecepatan integrasi.
Pada produksi, harapkan perlombaan kapabilitas melampaui verifikasi eksekusi. Harness pengujian menjadi penyeimbang.
Pilihan model-agent yang tepat bergantung pada horizon workload.
Chat-with-tools berarti agent memanggil tool terutama untuk memperkaya jawaban (pencarian, lookup database, ringkasan), sementara tugas utama model adalah memberi respons. Dalam kasus ini, keandalan tool terutama berdampak pada “kebenaran jawaban,” bukan perubahan fisik.
Pilih stack yang mendukung schema strictness dan parsing hasil tool yang baik. Pedoman Structured Outputs dari OpenAI relevan karena mengurangi argumen tool yang salah format. (help.openai.com) Dokumentasi Claude tentang tool use membantu memastikan kontrak urutan yang benar. (docs.anthropic.com)
Optimalkan untuk kebenaran dan iterasi cepat. Risiko terbesar sering tersembunyi pada masalah formatting tool call yang diam-diam menurunkan kualitas jawaban.
Autonomous micro-actions adalah rangkaian singkat dengan cakupan terbatas: “nyalakan lampu meja,” “setel timer,” “tambahkan pengingat berdasarkan sebuah pesan.” Di sini dibutuhkan dekomposisi, verifikasi, dan penanganan denial.
Di sinilah posisi miclaw paling relevan: miclaw digambarkan sebagai agen tingkat sistem yang mampu membaca/menulis konten dan mengendalikan perangkat smart-home ketika diizinkan. (gizmochina.com, news.cgtn.com)
Jalankan skenario berbasis skenario dengan denial paksa terhadap izin, lalu verifikasi bahwa “tidak” berubah menjadi safe stop yang aman sekaligus alternatif yang membantu.
Long-horizon automation adalah kategori paling berat: rencana multi-hari, pelacakan state, rangkaian aksi lintas perangkat, dan sesekali perencanaan ulang ketika dunia berubah.
Di sini kecepatan model dan dukungan long-context jadi bermakna secara operasional—tetapi hanya jika orkestrasi mampu mempertahankan audit logs dan stop conditions. Klaim konteks 256K dan percepatan decoding dari MiMo-V2-Flash relevan langsung untuk jendela perencanaan panjang, sementara paper membahas speculative decoding speedups. (github.com, arxiv.org) Tetap saja, sistem “agen untuk device control” harus menangani tool denial dan mismatch state tanpa memperparah kesalahan.
Perlakukan eksekusi tool sebagai workflow dengan checkpoints. Wajibkan “read-back verification” setelah setiap aksi yang mengubah state.
Jika evaluasi dilakukan terhadap agen pengendali perangkat ala miclaw dibanding stack tool OpenAI-, Claude-, dan Gemini-class, jangan debat tentang kualitas model. Jalankan permission-denied device control harness yang menilai: keandalan tool-calling, dekomposisi multi-langkah, latensi/biaya di bawah orkestrasi, kegagalan mode aksi yang ditolak, serta akurasi perintah multibahasa.
Wajibkan tim produk menerapkan audit-ready tool traces dan least-privilege tool allowlist sebelum memperluas dari micro-actions ke long-horizon automation. Letakkan ini pada engineering quality gate yang dimiliki oleh CTO/Head of Platform Engineering, bukan oleh penyedia model. Basis pembuktian bersifat pragmatis: kontrak tool-calling dan permission gates sudah terdokumentasi (OpenAI schema strictness, Anthropic tool sequencing dan permission handling), sementara pengalaman ekosistem yang lebih luas tentang autonomous agents menunjukkan bagaimana permission dan akses sistem memperbesar risiko. (help.openai.com, docs.anthropic.com, platform.claude.com, techradar.com)
Pada saat denial izin bisa dihentikan secara andal, dijelaskan, dan di-audit, agen tidak lagi terasa “autonomous”—melainkan benar-benar tepercaya.
Prakiraan (90 hari ke depan): Pada Juni 2026, mayoritas tim yang mengintegrasikan device-control agents diperkirakan menggeser penekanan dari “agent prompt quality” ke orchestration correctness: schema tool yang lebih ketat, perilaku stop yang lebih baik saat permission ditolak, serta langkah verifikasi yang lebih deterministik. Alasannya bersifat operasional: agen tingkat sistem sudah masuk siklus uji terbatas dan deploy, sementara peringatan ekosistem tentang autonomous tooling berizin tinggi mendorong implementer ke pola eksekusi yang lebih aman. (gizmochina.com, techradar.com)