Bergabunglah dengan uji coba asal WebMCP

Setelah Chrome 149 mulai menyediakan uji coba asal WebMCP, hubungan antara halaman web dan proxy akan menjadi lebih langsung: halaman tidak lagi hanya menampilkan DOM dan salinan yang terlihat untuk ditebak oleh mesin, kontrol itu sendiri juga dapat mendeklarasikan tujuan, status, dan batasan yang dapat dieksekusi. Perubahan ini tampak seperti uji coba API, namun sebenarnya lebih seperti mengangkat “niat antarmuka” dari informasi implisit ke protokol eksplisit.

Nilai dari sesuatu seperti WebMCP bukanlah untuk menambahkan lapisan terminologi ke halaman web, tetapi untuk memperketat ketidakpastian yang paling ditakuti oleh para agen. Apakah tombol untuk mengirimkan, mengalihkan, mengonfirmasi, atau sekadar membuka lapisan pop-up; apakah kotak input berupa tanggal, istilah pencarian, atau waktu janji temu yang memerlukan format khusus. Di masa lalu, informasi ini terutama disimpulkan dari teks, struktur, dan konteks. Inferensi berfungsi, tetapi begitu halaman menjadi rumit, agen mulai salah mengira “sepertinya” sebagai “adalah”.

Bagi manusia, kesalahan membaca ini biasanya hanyalah sebuah kesalahan klik. Bagi agen, kesalahan pembacaan berubah menjadi jalur kesalahan yang terus-menerus. Ini akan terus dijalankan dengan pemahaman yang salah hingga menemui verifikasi, rollback, atau efek samping, yang menunjukkan bahwa langkah sebelumnya telah tersesat. Setelah WebMCP menjadikan lapisan semantik ini eksplisit, agen tidak perlu menebak halaman sebagai peta visual murni, dan halaman web juga dapat dengan jelas menjelaskan tanggung jawab permukaan interaksi utama.

Hal ini paling cocok untuk antarmuka yang sulit dijelaskan dengan copywriting HTML murni, seperti kalender, reservasi, aplikasi izin, panel pengaturan, atau kumpulan halaman yang terlihat seperti kotak masukan biasa tetapi sebenarnya memiliki arti bisnis yang berbeda. Ketika hanya mengandalkan label dan placeholder, agen sering kali harus berkeliling halaman dan mencoba lagi dan lagi; setelah halaman dapat menyatakan “inilah pilihan tanggal” “inilah tindakan konfirmasi” dan “status di sini hanya dapat berubah ke arah ini”, biaya integrasi akan langsung berkurang.

Namun uji coba asal juga menimbulkan masalah lain: lapisan semantik ini perlu dipertahankan. Struktur halaman akan berubah, salinan tombol akan berubah, dan status bisnis akan berubah. Jika lapisan niat yang benar-benar diandalkan oleh agen tidak diperbarui bersama dengan komponennya, lapisan tersebut akan segera hilang. Pada saat itu, keadaan yang paling berbahaya bukanlah “tidak dapat digunakan sama sekali” tetapi “masih dapat berjalan, tetapi kadang-kadang melakukan kesalahan, dan kesalahan tersebut wajar”.

Oleh karena itu, WebMCP lebih seperti kontrak dengan halaman web itu sendiri, daripada kartu pengingat yang dikirimkan ke agen. Hal ini memerlukan front end untuk menuliskan batasan interaksi ke dalam implementasi, ke dalam pengujian, dan ke dalam pemeriksaan regresi. Selama lapisan kontrak ini masih dalam tahap demonstrasi, yang dapat dipahami oleh agen hanyalah kasus yang berhasil; ketika masuk ke halaman sebenarnya, yang sebenarnya perlu ditangani adalah kompatibilitas versi, jalur downgrade dan solusi setelah deklarasi menjadi tidak valid.

Saya lebih suka menganggap uji coba asal ini sebagai sinyal arah. Browser mulai secara serius mempertimbangkan cara agen membaca halaman web, yang berarti bahwa front end tidak hanya memformat untuk manusia, tetapi juga menentukan tindakan untuk mesin. Semakin kompleks halamannya, semakin bernilai lapisan definisi ini; semakin sering halaman diubah, semakin besar biaya pemeliharaan lapisan definisi ini. Warisan terakhir dari kemampuan seperti WebMCP bukanlah istilah baru, namun istilah untuk penyelarasan berkelanjutan antara front end dan agen.