OpenChrome - Server MCP otomasi paralel untuk browser Chrome
(github.com/shaun0927)Playwright adalah alat otomasi web yang berguna untuk melakukan crawling atau menjalankan pengujian E2E di lingkungan produksi, dengan mengendalikan aksi seperti klik di browser.
Meski dirilis pada tahun 2020,
hingga kini alat ini masih digunakan oleh sebagian besar developer.
Namun, hanya dengan menyalakan satu sesi saja konsumsi RAM-nya bisa melebihi 2GB, berat, lambat, dan mudah rusak.
Di era AI, alat ini perlu berevolusi,
terutama dibutuhkan alat otomasi browser yang dapat berjalan stabil bahkan untuk pekerjaan paralel.
Kita tidak lagi ingin melakukan QA sendiri atau berkeliaran di dalam situs.
OpenChrome adalah proyek yang berangkat dari keinginan untuk menyelesaikan masalah ini.
Ini adalah server MCP yang mewujudkan otomasi browser paralel dengan cepat dan cerdas.
Ini juga merupakan alat yang belakangan paling sering saya gunakan dalam pekerjaan pribadi saya.
Menggunakan login browser Chrome,
dan jika memakai beberapa akun, Anda cukup memberi tahu nama akun yang akan dipakai saat menjalankan tugas.
Secara default, alat ini bekerja berdasarkan browser Chrome yang sudah login.
Pekerjaan paralel dimungkinkan di lebih dari 20 browser, dan penggunaan RAM telah dikurangi menjadi sekitar 300MB. Pekerjaan dijalankan dalam keadaan Chrome sudah login, sehingga pada praktiknya deteksi bot dapat dinonaktifkan sepenuhnya. Integrasi dengan Openclaw juga dimungkinkan.
Contoh penggunaannya adalah sebagai berikut.
"Tolong crawl postingan terbaru dari 20 tokoh terkenal di Twitter dengan oc."
(benchmark berdasarkan claude code memakan waktu 3 menit 30 detik - sebagian besar adalah waktu inferensi LLM)
Sebenarnya masalah kronis Playwright adalah "LLM yang berkeliaran" dan melakukan banyak tindakan sia-sia.
Bahkan jika Anda memberi instruksi untuk tugas seperti login, ia akan lama mengutak-atik situs sambil mencoba ini-itu,
dan pada akhirnya sering muncul notifikasi bahwa proses gagal setelah memakan waktu lebih dari 30 menit.
Openchrome menyelesaikan ini bukan dengan pendekatan tebak-tebakan, melainkan dengan pendekatan Guided.
Ia langsung login ke Chrome, dan jika diberi tautan maka langsung membuka tautan tersebut.
Screenshot diambil seminimal mungkin, dan posisi tombol serta elemen lain dideteksi dengan cepat.
Jika terjadi masalah dalam pekerjaan, ia mengingat kembali dan tidak mengulangi kesalahan yang sama.
Karena ini adalah server MCP, alat ini bisa langsung digunakan di semua lingkungan sebagai pengganti Playwright yang ada.
Tidak hanya untuk pengembangan MAC-claude code, tetapi juga di sistem operasi lain seperti Windows dan Linux,
serta berjalan di codex cli, cursor, dan lainnya.
Instalasi:
npx openchrome-mcp setup
Stabilitas untuk produksi berskala besar yang sangat kompleks dan mengonsumsi banyak sumber daya masih memerlukan verifikasi tambahan,
dan jika Anda memiliki masukan atau saran, silakan unggah ke GitHub Issues dan saya akan segera menindaklanjutinya.
Terima kasih.
13 komentar
Apakah ini berarti, tanpa menggunakan solusi E2E yang sudah ada, AI akan langsung mengelola dan menjalankan kode pengujian?
Jika Playwright sebelumnya mengakses situs web dengan metodologi yang kaku sehingga konsumsi token menjadi tinggi,
openchrome tampaknya bisa dipahami sebagai konsep yang mendekati secara ramah-llm sehingga LLM dapat dengan cepat terlibat langsung dalam mengendalikan perilaku situs web. Solusi e2e dapat dijalankan secara langsung.
Sebagai contoh, di lingkungan production yang memerlukan login Google, Anda bisa meminta pekerjaan QA dilakukan dalam keadaan sudah login dengan akun admin. Mulai dari melakukan scroll, mengklik edge case yang diperlukan, dan sebagainya, sebagian besar pekerjaan yang Anda bayangkan semuanya memungkinkan. Ini karena alih-alih membiarkan Playwright secara otonom melakukan pekerjaan bodoh, LLM ikut campur secara langsung untuk mengendalikan perilakunya.
Kalau hanya melihat penggunaan token, bukankah cara yang terstruktur justru lebih hemat karena menjalankan test case E2E tanpa campur tangan LLM?
Dalam metodologi pengujian, selain TC juga termasuk pengujian yang dilakukan QA secara mandiri,
jadi kalau dinilai bagian itu efisien, apakah itu bisa dianggap baik?
Kalau menjawab pertanyaan Anda secara lebih spesifik dan teknis,
playwright MCP yang ada saat ini bekerja dengan abstraksi 3 tahap berikut: LLM → server MCP → server Playwright Node.js → CDP/Juggler → browser
Sebaliknya, OpenChrome bekerja dengan abstraksi 1 tahap berikut: LLM → server MCP → CDP → browser
Semakin sedikit lapisan abstraksi, semakin cepat dan semakin presisi kontrolnya, dan sementara playwright adalah alat serbaguna, openchrome menggunakan alat yang lebih terspesialisasi. Kalau dianalogikan ke soal matematika, rasanya seperti memadatkan proses penyelesaian 20 baris menjadi 4 baris.
playwright menerima umpan balik melalui metode berbasis teks yang disebut accessibility tree (secara teori unggul, tetapi inilah alasan mengapa pada kebanyakan situs metode ini gagal) sehingga kemampuan memahami konteks juga sangat terbatas.
Karena itu, pada situs yang implementasi aksesibilitasnya baik (seperti Google dan domain terkenal lainnya), playwright tetap berguna, tetapi untuk sebagian besar situs atau lingkungan production, openchrome jauh lebih unggul.
Selain itu, karena "kepadatan desain alat" dan "mengurangi peluang LLM melakukan kesalahan" pada akhirnya menentukan performa di lapangan, saya rasa yang tepat adalah mengukurnya dengan real-world task, bukan performa teoretis.
Terima kasih. Sepertinya saya belum membaca isi artikelnya dengan cukup saksama.
Saya melewatkan bagian bahwa ini ditujukan untuk lingkungan produksi.
Saya juga pasti akan mencobanya.
Terima kasih sudah menjawab pertanyaan saya yang keliru dengan sangat baik~
Bukan, pertanyaan yang bagus, terima kasih. Saya juga jadi bisa merapikannya sendiri sambil menjelaskan.
Memang cepat dan bagus.
Tapi kalau muncul alert, jadi berhenti.
Kami akan berupaya memperbaiki bagian ini dengan cepat.
Saya juga penasaran dengan perbandingannya dengan Chrome DevTools MCP!
Saat saya mencobanya, saya ingat Playwright justru terasa lebih baik daripada chrome devtools mcp, tetapi nanti akan saya coba tambahkan benchmark.
chrome devtools mcptidak memunculkan peringatan large context, tetapi rasanya performanya kurang lebih mirip, jadi saya selama ini memakai yang ini! Hasil benchmark-nya jadi bikin penasaran ya :DOh, apakah penggunaan token juga berkurang? Terima kasih!!
Bisa dibilang, semakin sedikit salah langkah, semakin sedikit juga konsumsi token.