3 คะแนน โดย GN⁺ 2026-03-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เซิร์ฟเวอร์ Chrome DevTools MCP ได้รับการปรับปรุงให้เอเจนต์เขียนโค้ดสามารถ เชื่อมต่อกับเซสชันเบราว์เซอร์ที่กำลังใช้งานอยู่ได้โดยตรง
  • ฟีเจอร์นี้ทำให้เอเจนต์สามารถ นำเซสชันที่ล็อกอินอยู่กลับมาใช้ซ้ำ หรือ เข้าถึงเซสชันดีบักที่กำลังทำงานอยู่ของ DevTools ได้
  • ใน Chrome M144 (เบต้า) เมื่อใช้ ออปชัน --autoConnect เซิร์ฟเวอร์ MCP จะเชื่อมต่อกับอินสแตนซ์ Chrome ที่กำลังทำงานอยู่โดยอัตโนมัติ
  • ทุกครั้งที่มีการเชื่อมต่อ จะมี หน้าต่างโต้ตอบขอการอนุมัติจากผู้ใช้ แสดงขึ้น และระหว่างดีบักจะมีแบนเนอร์ “กำลังถูกควบคุมโดยซอฟต์แวร์ทดสอบอัตโนมัติ” แสดงอยู่
  • สามารถ สลับระหว่างการดีบักด้วยตนเองและการดีบักที่มี AI ช่วย ได้อย่างอิสระ ช่วยเพิ่มประสิทธิภาพการพัฒนา

ภาพรวมการปรับปรุงเซิร์ฟเวอร์ Chrome DevTools MCP

  • Chrome DevTools MCP server ได้รับการอัปเดตให้ เอเจนต์เขียนโค้ดสามารถเชื่อมต่อกับเซสชันเบราว์เซอร์ที่กำลังใช้งานอยู่ได้โดยตรง
    • ผู้ใช้สามารถนำเซสชันที่ล็อกอินอยู่กลับมาใช้ซ้ำได้ จึงดีบักต่อได้โดยไม่ต้องล็อกอินเพิ่ม
    • สามารถสั่งให้เอเจนต์ตรวจสอบรายการที่เลือกไว้ใน แผง Network หรือ แผง Elements ของ DevTools UI ได้
  • วิธีการเชื่อมต่อแบบเดิมยังคงรองรับอยู่เช่นเดิม โดยสามารถใช้โปรไฟล์เฉพาะสำหรับ MCP server, เชื่อมต่อผ่านพอร์ต remote debug และรันหลายอินสแตนซ์บนโปรไฟล์ชั่วคราวได้

วิธีการทำงาน (How it works)

  • Chrome M144 (ปัจจุบันเป็นเบต้า) ได้เพิ่ม ฟังก์ชันขอเชื่อมต่อ remote debugging
    • เมื่อรัน MCP server ด้วยออปชัน --autoConnect ระบบจะเชื่อมต่อกับอินสแตนซ์ Chrome ที่กำลังใช้งานอยู่โดยอัตโนมัติและส่งคำขอเซสชัน remote debugging
  • เพื่อเสริมความปลอดภัย Chrome จะแสดง หน้าต่างโต้ตอบขอการอนุมัติจากผู้ใช้ ทุกครั้งที่มีคำขอ และจะอนุญาตการเชื่อมต่อหลังจากได้รับการยืนยันเท่านั้น
  • เมื่อเซสชันดีบักถูกเปิดใช้งาน จะมีแบนเนอร์ “Chrome is being controlled by automated test software” แสดงที่ด้านบนของเบราว์เซอร์

เริ่มต้นใช้งาน (Get started)

  • หากต้องการใช้ฟังก์ชัน remote debugging แบบใหม่ ต้องเปิดใช้งาน remote debugging ใน Chrome และตั้งค่า MCP server

Step 1: ตั้งค่า remote debugging ใน Chrome

  • ไปที่ chrome://inspect/#remote-debugging เพื่อเปิดใช้งาน remote debugging
  • เลือกว่าจะอนุญาตการเชื่อมต่อดีบักหรือไม่ผ่านหน้าต่างโต้ตอบ

Step 2: ตั้งค่าการเชื่อมต่ออัตโนมัติของ MCP server

  • เมื่อรันเซิร์ฟเวอร์ chrome-devtools-mcp ให้เพิ่มอาร์กิวเมนต์ --autoConnect
  • ตัวอย่างการตั้งค่า (gemini-cli):
    {
       "mcpServers": {
        "chrome-devtools": {
          "command": "npx",
          "args": [
            "chrome-devtools-mcp@latest",
            "--autoConnect",
            "--channel=beta"
          ]
        }
      }
    }
    
    • จำเป็นต้องระบุ --channel=beta จนกว่า Chrome M144 จะเข้าสู่ stable channel

Step 3: ทดสอบการตั้งค่า

  • รันคำสั่งต่อไปนี้ใน gemini-cli:
    Check the performance of https://developers.chrome.com
    
  • Chrome จะแสดงหน้าต่างโต้ตอบเพื่อถามผู้ใช้ว่า อนุญาตเซสชัน remote debugging หรือไม่
  • เมื่อคลิก Allow MCP server จะเปิดเว็บไซต์และทำ performance tracing

การดีบักแบบผสานรวมกับเอเจนต์เขียนโค้ด

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

1 ความคิดเห็น

 
GN⁺ 2026-03-16
ความคิดเห็นจาก Hacker News
  • ฉันใช้ Playwright ดักทุก request และ response แล้วบันทึกทราฟฟิกที่เกี่ยวข้องไว้ระหว่างที่ Claude Code ท่องเว็บอย่าง YouTube พร้อมทั้งคลิกและพิมพ์ข้อมูล
    จากข้อมูลที่เก็บได้แบบนี้ ก็สามารถสร้าง API แบบ strong-typed อัตโนมัติ เพื่อให้โต้ตอบกับเว็บไหนก็ได้ผ่าน internal API
    แน่นอนว่าอาจเข้าข่ายละเมิดข้อกำหนดการให้บริการ แต่ข้อดีก็คือไม่ต้องโหลดโฆษณา รูปภาพ หรือมาร์กอัปทั้งหมด
    ถ้ามีคนสนใจ ฉันวางแผนจะปล่อยภายในสัปดาห์นี้

    • น่าสนใจที่ HN ชอบไอเดียนี้
      จริง ๆ แล้วนี่คือวิธีที่บริษัททำ LLM อย่าง Anthropic หรือ OpenAI ใช้กันมานานแล้ว
      เวลาพวกเขาข้ามโฆษณาหรือดาวน์โหลดงานที่มีลิขสิทธิ์ มันถูกเรียกว่า ‘ของขวัญจากพระเจ้า’ แต่ถ้า Zuck ทำแบบเดียวกันกลับถูกเรียกว่า ‘คำสาปจากปีศาจ’ ซึ่งก็น่าขันดี
    • ฉันก็ใช้งานคล้าย ๆ กันอยู่
      ส่วนใหญ่เอาไว้สร้าง layout และ style ของหน้าเว็บกลับขึ้นมาใหม่จากบางจุดใน DOM tree หรือใช้จับพฤติกรรม responsive แบบอัตโนมัติ
      ปรับความกว้างหน้าจอด้วย Playwright เพื่อติดตามการเปลี่ยนแปลงของ style แล้วบันทึก สกรีนช็อตและข้อมูลลำดับชั้นของ style ไว้ด้วยกัน
      ถึงจะมีเครื่องมือ inspect แบบแมนนวล แต่ช้าและไม่มีประสิทธิภาพเกินไป
      สำหรับฉัน การทำ custom CLI เองมีประสิทธิภาพกว่า MCP มาก
      ให้ AI เข้าถึงโดยตรงแล้วใช้งานผ่าน ‘skill’ นี่แหละทรงพลังจริง
    • สงสัยว่าทำไมต้องใช้ Playwright ด้วย
      รู้สึกว่าแค่มี agent-browser Claude ก็น่าจะสร้าง deterministic code ได้ทันทีแล้ว
    • หวังว่าจะปล่อยออกมาจริง ๆ อยากรู้ว่าอันนี้ทำเป็น agent skill หรือเปล่า
    • ถ้าใช้วิธีนี้ จะดาวน์โหลดวิดีโอ YouTube ได้โดยตรงเหมือน yt-dlp โดยไม่ต้องคอยอัปเดตตลอดหรือเปล่า
  • โปรเจกต์ DevTools MCP เพิ่งออก CLI แบบ standalone มาไม่นานนี้
    ดูจากเอกสาร chrome-devtools-cli จะเห็นว่ารวมอยู่ในเวอร์ชัน v0.20.0
    นี่น่าจะเป็นข่าวดีสำหรับคนที่กังวลเรื่อง ต้นทุนโทเค็น ของ MCP
    (อ้างอิงว่าเมื่อก่อนฉันเคยทำงานในทีม DevTools และตอนนี้ก็ยังทำอยู่)

    • ตอนนี้ด้วย Tool Search เลยทำให้ MCP ไม่เสียค่าใช้จ่ายใน CC แล้ว
  • ช่วงไม่กี่เดือนมานี้ฉันใช้ TideWave อยู่
    tidewave.ai เดิมทีทำมาสำหรับ Elixir/LiveView แต่ตอนนี้รองรับทั้ง JS framework และ RoR แล้ว
    เครื่องมือนี้ไม่ได้เข้าถึงแค่เบราว์เซอร์ แต่เข้าถึง runtime ของแอป ได้ด้วย
    กล่าวคือเอเจนต์เข้าถึงฐานข้อมูลและ endpoint ได้โดยตรง ทำให้ทรงพลังมาก

  • Google ตามหลังมากในเรื่อง agentic CLI coding
    Gemini CLI แย่มากจนชัดเจนว่าคนข้างในเองก็ไม่ใช้
    ฉันคิดว่า MCP เป็นเทคโนโลยีที่ตายแล้ว เครื่องมือแบบ CLI ทั้งเร็วกว่า ยืดหยุ่นกว่า และยังมีสภาพแวดล้อมที่เทรนไว้พร้อมใช้อยู่มากมาย
    ถ้าเป็นนักพัฒนาจริงจัง ก็ควรใช้ Playwright กับ headless Chromium
    MCP มีเสน่ห์แค่สำหรับมือใหม่เท่านั้น

    • ฉันทำงานใน สภาพแวดล้อมระดับองค์กร ขนาดใหญ่ ซึ่งเรื่องอย่าง authentication, RBAC, rate limiting และการปฏิบัติการทำให้ MCP ยังมีประโยชน์อยู่
      ถ้าใช้แค่ CLI อย่างเดียว ความซับซ้อนด้านความปลอดภัยและการดูแลระบบจะสูงเกินไป
      แต่ก็เห็นด้วยว่า Gemini CLI แย่มาก
    • เห็นด้วยกับคำพูดที่ว่า MCP ตายแล้ว
      แม้ Anthropic จะพยายามปรับปรุง แต่ปัญหา context บวม ก็ยังอยู่
      ต่อให้ไม่ใช้งาน MCP server มันก็ยังกิน context
      ตอนนี้ควรเปลี่ยนไปใช้ agent skill แล้ว
    • เผื่อเป็นข้อมูล Gemini CLI ถูกใช้จริงอย่างแพร่หลายภายใน Google
      มีการใช้บริการ MCP สำหรับค้นหาโค้ด เข้าถึงเอกสาร ดูบั๊ก และเชื่อมต่อฐานข้อมูล RAG
      (ฉันได้ยินเรื่องนี้จากคนใน Google โดยตรง)
    • ถ้า MCP ตายแล้ว งั้นจะใช้ CLI ตัวไหนสำหรับ เปิด Chrome กดปุ่ม และอ่านเอาต์พุตจากคอนโซล?
      ถ้า MCP กิน context แล้ว CLI skill ฟรีหรือเปล่าก็น่าสงสัยเหมือนกัน
  • มี agent skill ที่ทำฟีเจอร์นี้ได้อยู่แล้ว
    ฉันใช้ chrome-cdp-skill ทุกวัน และมันยอดเยี่ยมมาก
    ตัวอย่างเช่น ใช้ codex จัดการไลบรารีเพลงในเครื่อง เปิดแท็บ YT Music ค้นหาอัลบั้ม แล้วส่ง URL ต่อให้ yt-dlp
    แต่ตอนนี้รองรับเฉพาะ Chrome ถ้าจะใช้กับเบราว์เซอร์อื่นต้องแก้ path ของไบนารีเอง

    • เดโมเจ๋งก็จริง แต่ฉันว่ามันน่ากลัวที่แค่ prompt injection ครั้งเดียวก็อาจเปิดทางให้เข้าถึงข้อมูลทั้งหมดได้
    • นี่ไม่ใช่ skill สำหรับ DevTools MCP แต่เป็น โปรเจกต์อิสระ
      ตอนนี้ตลาดด้าน browser automation + agent แข่งขันกันดุเดือดอยู่แล้ว
      DevTools MCP กับ CLI ใหม่ดูน่าจะเสถียรกว่า เพราะดูแลโดยทีม Chrome DevTools & Puppeteer
      ถึงอย่างนั้นก็ดีที่ การแข่งขันโอเพนซอร์ส สร้างนวัตกรรม
    • สงสัยว่ามีคนใช้ skill แบบเฉพาะหน้าแบบนี้จริงไหม
      ฉันว่าใช้เครื่องมือที่เสถียรกว่าอย่าง playwriter.dev น่าจะดีกว่า
  • ฉันทำ WebSocket proxy + ส่วนขยาย Chrome เพื่อให้เอเจนต์ควบคุม DOM ได้
    ตั้งค่าให้เข้าถึงผ่าน browserbox โดยอนุญาต session cookie
    ตอนนี้ใช้เป็น middleware สำหรับงานวิจัยเพื่อเพิ่ม อัตราความสำเร็จของการใช้เครื่องมือของเอเจนต์

  • ฉันใช้ MCP นี้มาค่อนข้างนานแล้ว และพบว่าเสถียรที่สุดเมื่อใช้ร่วมกับ codex on opencode
    โดยเฉพาะตอนเอาไปใช้เป็น SVG editing REPL มันสร้างไอคอนแบบคัสตอมสวย ๆ ให้อัตโนมัติจนทึ่งมาก
    และยังเหมาะกับงาน reverse engineering หรือขยายความสามารถใน แอป Electron ด้วย

  • ฉันลองใช้ playwriter แล้ว วิธีเชื่อมต่อเข้ากับ session เดิมทำงานได้ดีจนน่าประหลาดใจ

  • ฉันก็เคยทำอะไรคล้าย ๆ กันด้วย Playwright
    เมื่อก่อนมันสิ้นเปลืองโทเค็นมากจนมีค่าใช้จ่ายสูง แต่แก้ได้ด้วยการทำ wrapper ที่บันทึกผลลัพธ์ลงดิสก์แล้วให้เอเจนต์คิวรีทีหลัง
    ดูได้ที่ uisnap.dev
    เลยสงสัยว่าโปรเจกต์นี้แก้ ปัญหาการใช้โทเค็นสิ้นเปลือง ได้หรือยัง

    • น่าจะแก้ได้เกือบหมดแล้ว ดู playwright-cli ได้
    • ฉันใช้งาน wrapper MCP server ที่สรุป page snapshot ด้วย Claude Haiku อยู่
      ดูได้ที่ playwright-slim-mcp
  • ฉันลองใช้ firefox-devtools-mcp แล้ว พบว่ามันเร็วและมีประสิทธิภาพกว่าตัว Chrome MCP พื้นฐานมาก