OpenChrome - เซิร์ฟเวอร์ MCP สำหรับระบบอัตโนมัติแบบขนานบนเบราว์เซอร์ Chrome

Playwright เป็นเครื่องมือเว็บอัตโนมัติที่มีประโยชน์สำหรับการควบคุมแอ็กชันต่าง ๆ บนเบราว์เซอร์ เช่น การคลิก เมื่อต้องการทำครอว์ลิงไม่ทางใดก็ทางหนึ่ง
หรือต้องการทำ E2E testing ในสภาพแวดล้อมโปรดักชัน

แม้จะเปิดตัวมาตั้งแต่ปี 2020
แต่ก็ยังเป็นเครื่องมือที่นักพัฒนาส่วนใหญ่ใช้งานกันอยู่
อย่างไรก็ตาม แค่เปิดหนึ่งเซสชันก็ใช้ RAM เกิน 2GB แล้ว ทั้งหนัก ช้า และล่มได้ง่าย

ในยุค AI เครื่องมือนี้จำเป็นต้องมีนวัตกรรมใหม่
โดยเฉพาะเครื่องมือ browser automation ที่ทำงานได้เสถียรแม้ในงานแบบขนาน
เราไม่อยากมานั่งทำ QA เองหรือไล่เดินวนอยู่ในเว็บไซต์อีกต่อไป

OpenChrome คือโปรเจ็กต์ที่เริ่มต้นจากความตั้งใจจะแก้ปัญหานี้
มันคือเซิร์ฟเวอร์ MCP ที่ทำ browser automation แบบขนานได้อย่างรวดเร็วและชาญฉลาด
และยังเป็นเครื่องมือที่ผมใช้บ่อยที่สุดในงานส่วนตัวช่วงหลังด้วย

มันใช้การล็อกอินของเบราว์เซอร์ Chrome
หากใช้หลายบัญชี ก็เพียงระบุชื่อบัญชีที่ต้องการใช้ตอนสั่งงาน
โดยพื้นฐานจะทำงานอ้างอิงจาก Chrome ที่ล็อกอินไว้อยู่แล้ว

รองรับการทำงานแบบขนานบนเบราว์เซอร์มากกว่า 20 ตัว และลดการใช้ RAM ลงเหลือราว 300MB ทำงานในสถานะที่ล็อกอิน Chrome ไว้แล้ว จึงแทบจะทำให้การตรวจจับบอตใช้ไม่ได้ผลโดยสิ้นเชิง และยังเชื่อมต่อกับ Openclaw ได้ด้วย

ตัวอย่างการใช้งานมีดังนี้

"ช่วยครอว์ลโพสต์ล่าสุดของคนดังบน Twitter 20 คนด้วย oc"
(อ้างอิงจาก benchmark บน claude code ใช้เวลา 3 นาที 30 วินาที - ส่วนใหญ่เป็นเวลาในการอนุมานของ LLM)

จริง ๆ แล้วปัญหาเรื้อรังของ playwright คือการ "เดินมั่วของ LLM"
แม้จะสั่งให้ทำงานอย่างการล็อกอิน มันก็มักจะคลำทางอยู่ในเว็บ ลองโน่นลองนี่ไปเรื่อย ๆ
และสุดท้ายก็มักแจ้งว่าล้มเหลวหลังจากใช้เวลาเกิน 30 นาที

Openchrome แก้ปัญหานี้ด้วยแนวทาง Guided ไม่ใช่การคาดเดา
มันล็อกอินเข้า Chrome ได้ทันที และถ้าให้ลิงก์มาก็จะเข้าไปที่ลิงก์นั้นทันที
ถ่ายสกรีนช็อตให้น้อยที่สุด และจับตำแหน่งของปุ่มต่าง ๆ ได้อย่างรวดเร็ว
หากเกิดปัญหาระหว่างทำงาน มันจะทบทวนความจำและไม่ทำผิดพลาดซ้ำแบบเดิม

เนื่องจากเป็นเซิร์ฟเวอร์ MCP จึงสามารถใช้แทน Playwright เดิมได้ทันทีในทุกสภาพแวดล้อม
ไม่ว่าจะเป็นงานพัฒนาบน MAC-claude code หรือระบบปฏิบัติการอื่นอย่าง Windows, Linux
รวมถึงใช้งานบน codex cli, cursor และอื่น ๆ ได้ด้วย

ติดตั้ง:
npx openchrome-mcp setup

สำหรับการใช้งานระดับโปรดักชันขนาดใหญ่ที่ซับซ้อนมากและใช้ทรัพยากรสูง ยังจำเป็นต้องมีการตรวจสอบเพิ่มเติมด้านเสถียรภาพ
หากมีฟีดแบ็กหรือข้อเสนอแนะ กรุณาเปิดไว้ใน GitHub Issues แล้วผมจะนำไปสะท้อนในโปรเจ็กต์ทันที
ขอบคุณครับ

• GitHub: https://github.com/shaun0927/openchrome

[coremaker]

หมายความว่าให้ AI จัดการและรันโค้ดทดสอบด้วยตัวเอง โดยไม่ใช้โซลูชัน E2E แบบเดิมใช่ไหม?

[shaun0927]

ถ้า playwright แบบเดิมเข้าถึงเว็บไซต์ด้วยวิธีการที่ค่อนข้างตายตัวจนสิ้นเปลืองโทเคนมาก
ก็อาจมองว่า openchrome ใช้แนวทางที่เป็นมิตรกับ LLM มากกว่า ทำให้ LLM เข้ามาควบคุมการทำงานของเว็บไซต์ได้อย่างรวดเร็วโดยตรง คุณสามารถรันโซลูชัน e2e ได้เอง

ตัวอย่างเช่น ในโปรดักชันที่ต้องล็อกอิน Google คุณสามารถให้มันทำงาน QA ขณะล็อกอินด้วยบัญชีผู้ดูแลระบบอยู่ได้ ไม่ว่าจะเป็นการเลื่อนหน้า ปล่อยให้มันคลิกเคสขอบต่าง ๆ ได้เอง ฯลฯ งานส่วนใหญ่ที่คุณนึกออกล้วนทำได้ทั้งหมด เพราะมันไม่ใช่การปล่อยให้ playwright ทำงานอัตโนมัติแบบทื่อ ๆ เอง แต่เป็นวิธีที่ให้ LLM เข้ามาแทรกแซงและควบคุมพฤติกรรมได้ทันที

[coremaker]

ถ้าดูแค่ปริมาณการใช้โทเค็น วิธีที่เป็นรูปแบบตายตัวก็น่าจะใช้โทเค็นน้อยกว่าไม่ใช่หรือครับ เพราะสามารถรันเคสทดสอบ E2E ได้โดยไม่ต้องให้ LLM เข้ามาเกี่ยวข้อง

ในแนวทางการทดสอบ นอกจาก TC แล้วก็ยังรวมถึงการที่ QA ทดสอบแบบอิสระด้วย
ถ้าตัดสินว่าประสิทธิภาพในส่วนนั้นดี แบบนี้จะถือว่าโอเคไหมครับ?

[shaun0927]

ถ้าจะตอบในเชิงเทคนิคให้ชัดเจนขึ้น

MCP ของ Playwright แบบเดิมทำงานด้วยการนามธรรม 3 ชั้นดังนี้:
LLM → MCP server → Playwright Node.js server → CDP/Juggler → browser

ในทางกลับกัน OpenChrome ทำงานด้วยการนามธรรมเพียง 1 ชั้นดังนี้:
LLM → MCP server → CDP → browser

ยิ่งมี abstraction layer น้อย ก็ยิ่งเร็วและควบคุมได้ละเอียดกว่า
Playwright เป็นเครื่องมืออเนกประสงค์ ขณะที่ OpenChrome ใช้เครื่องมือที่ออกแบบมาเฉพาะทาง
ถ้าเปรียบเป็นโจทย์คณิตศาสตร์ ก็เหมือนย่อขั้นตอนวิธีทำจาก 20 บรรทัดให้เหลือ 4 บรรทัด

Playwright รับ feedback ผ่านวิธีแบบข้อความที่เรียกว่า accessibility tree
(ในทางทฤษฎีถือว่าดีมาก แต่ก็เป็นเหตุผลว่าทำไมมันถึงพังกับเว็บไซต์ส่วนใหญ่)
จึงมีข้อจำกัดมากในการทำความเข้าใจบริบท

ดังนั้นกับเว็บไซต์ที่ทำ accessibility มาอย่างดี (เช่น Google และโดเมนดังอื่น ๆ) Playwright ก็ยังมีประโยชน์อยู่
แต่สำหรับเว็บไซต์ส่วนใหญ่หรือใน production นั้น OpenChrome เหนือกว่ามาก

อีกทั้ง "ความหนาแน่นของการออกแบบเครื่องมือ" และ "การลดโอกาสที่ LLM จะทำพลาด" คือสิ่งที่กำหนดประสิทธิภาพในการใช้งานจริงในท้ายที่สุด
ดังนั้นจึงควรวัดด้วย real-world task มากกว่าประสิทธิภาพในเชิงทฤษฎี

[coremaker]

ขอบคุณครับ/ค่ะ เหมือนผม/ฉันยังอ่านเนื้อหาหลักไม่ละเอียดพอ
ผม/ฉันมองข้ามประเด็นที่ระบุว่าออกแบบมาสำหรับสภาพแวดล้อมโปรดักชันไป

เดี๋ยวผม/ฉันจะลองใช้ดูแน่นอนครับ/ค่ะ
ขอบคุณที่ตอบคำถามที่ไม่ถูกต้องของผม/ฉันอย่างละเอียดนะครับ/คะ~

[shaun0927]

ไม่ใช่เลยครับ เป็นคำถามที่ดีมาก ขอบคุณครับ ผมเองก็ได้จัดระเบียบความคิดของตัวเองไปด้วยระหว่างอธิบาย

[ld4004]

เร็วและดีแน่นอนครับ
แต่พอมี alert เด้งขึ้นมาก็หยุดเลยครับ

[shaun0927]

จะรีบปรับปรุงเนื้อหาส่วนนี้ให้ดีขึ้นครับ

[qurare]

อยากรู้เหมือนกันว่าเมื่อเทียบกับ Chrome DevTools MCP แล้วเป็นอย่างไรบ้าง!

[shaun0927]

จากที่เคยลองใช้มา รู้สึกว่า playwright ยังดีกว่า chrome devtools mcp เสียอีก ไว้ถ้ามีโอกาสจะลองเพิ่มผลเบนช์มาร์กภายหลังครับ

[qurare]

chrome devtools mcp ไม่ขึ้นคำเตือนเรื่อง large context และรู้สึกว่าประสิทธิภาพก็ใกล้เคียงกัน เลยใช้ตัวนี้อยู่ครับ! รอผลเบนช์มาร์กอย่างคาดหวังเลย :D

[hmmhmmhm]

โอ้ การใช้โทเค็นก็ลดลงด้วยเหรอครับ? ขอบคุณมากครับ!!

[shaun0927]

พูดได้ว่าเมื่อมันลดการลองผิดลองถูกลงได้ การใช้โทเคนก็จะลดลงตามไปด้วย