เปิดตัว WebMCP (Web Model Context Protocol)

 (developer.chrome.com)
42 คะแนน โดย xguru 2026-02-11 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • WebMCP เป็นมาตรฐานที่เสนอขึ้นมาเพื่อให้ เว็บไซต์สามารถเปิดเผยเครื่องมือแบบมีโครงสร้างให้ AI agent ภายในเบราว์เซอร์ได้โดยตรง
  • แทนที่จะใช้การสแครปหน้าจอหรืออนุมานจาก DOM แบบเดิม เว็บสามารถให้ข้อมูลอย่างชัดเจนว่า “หน้านี้ทำอะไรได้บ้าง” พร้อมอินพุตและเอาต์พุตในรูปแบบของ สัญญาอย่างชัดแจ้ง
  • รองรับตั้งแต่งานที่อิงกับฟอร์ม HTML ไปจนถึง การโต้ตอบ JavaScript ที่ซับซ้อน ผ่าน Declarative API และ Imperative API
  • เป็นโครงสร้างสัญญา(contract) ที่ให้ agent สามารถ ค้นพบ(Discovery) เครื่องมือของหน้า ระบุอินพุต/เอาต์พุตด้วย JSON Schema และ แชร์สถานะ(State) ของหน้าปัจจุบัน ร่วมกัน
  • ถูกรวมอยู่ใน Chrome เวอร์ชัน 146 ในฐานะ early preview โดยหากต้องการทดลองใช้งานล่วงหน้าต้องสมัคร Chrome built-in AI Early Preview Program
  • ต่างจาก MCP เดิมที่เป็นโปรโตคอลฝั่งเซิร์ฟเวอร์ โดย WebMCP เป็นโปรโตคอลสำหรับ AI agent ฝั่งไคลเอนต์ภายในเบราว์เซอร์

ร่างเอกสารสเปก: WebMCP Early Preview

ที่มาของ WebMCP

  • ในสภาพแวดล้อมเว็บสำหรับ agent นั้น AI กำลังมีบทบาทมากขึ้นในการทำงานจริงแทนผู้ใช้ เช่น การจอง การส่งแบบฟอร์ม การเปลี่ยนการตั้งค่า และการนำทาง
  • เว็บแบบเดิมถูกออกแบบโดยตั้งต้นว่ามีมนุษย์เป็นผู้ใช้ ทำให้ agent ต้อง อนุมาน ความหมายของปุ่มหรือโครงสร้างของฟอร์ม
  • ส่งผลให้เกิดปัญหาซ้ำๆ เช่น การกรอกข้อมูลผิด การแมปฟิลด์ผิด และ ความเปราะบาง จากการเปลี่ยนแปลงของ UI
  • WebMCP ถูกเสนอขึ้นเพื่อแก้ปัญหาเหล่านี้ โดยนำ สัญญาการโต้ตอบอย่างชัดแจ้ง(contract) มาไว้ระหว่างเว็บกับ agent
  • แทนที่ agent จะต้องเดาจุดประสงค์ของปุ่มหรือโครงสร้างของฟอร์ม เว็บไซต์จะ เปิดเผยอินเทอร์เฟซของตนอย่างชัดเจน
  • สัญญานี้ประกอบด้วย 3 องค์ประกอบหลัก:
    • Discovery: ให้ agent ตรวจดูเครื่องมือที่หน้ารองรับได้ในรูปแบบมาตรฐาน (เช่น checkout, filter_results)
    • JSON Schema: นิยามอินพุตและเอาต์พุตที่คาดหวังอย่างชัดเจน เพื่อลด hallucination หรือความเข้าใจผิด
    • State: ความเข้าใจร่วมกันเกี่ยวกับบริบทของหน้าปัจจุบัน ทำให้ agent มองเห็นทรัพยากรที่ใช้งานได้แบบเรียลไทม์

แนวคิดหลักของ WebMCP

  • การเปิดเผยเครื่องมือแบบมีโครงสร้าง

    • เว็บไซต์สามารถประกาศความสามารถที่ตนมีในรูปแบบของ เครื่องมือ(tool)
    • เครื่องมือแต่ละตัวกำหนดชื่อ คำอธิบาย สคีมาอินพุต (JSON Schema) และผลลัพธ์การทำงานไว้อย่างชัดเจน
    • agent จึงรับรู้ได้อย่างแม่นยำว่า “ควรเรียกใช้อะไร” โดยไม่ต้องตีความ DOM

  • จากการอนุมานสู่สัญญา

    • แทนที่จะต้องเดาความหมายของปุ่มหรือวิเคราะห์ UI ปฏิทิน เว็บจะ เปิดเผยเจตนาและกฎโดยตรง
    • รูปแบบอินพุตและเอาต์พุตถูกกำหนดตายตัว จึงช่วย ลด hallucination และการทำงานผิดพลาด
    • แม้ UI จะเปลี่ยนไป หากสัญญาของเครื่องมือยังคงเดิม พฤติกรรมของ agent ก็ยังคงเสถียร

API สองรูปแบบ

  • Declarative API

    • เพิ่มแอตทริบิวต์ให้กับองค์ประกอบ HTML <form> ก็สามารถแปลงเป็นเครื่องมือได้
    • ใช้แอตทริบิวต์ toolname, tooldescription เพื่อประกาศความหมายของเครื่องมือ
    • ฟิลด์ในฟอร์มจะกลายเป็นพารามิเตอร์อินพุตของเครื่องมือโดยตรง
    • เบราว์เซอร์จะแปลงสิ่งเหล่านี้เป็น JSON Schema ให้อัตโนมัติ
    • เหมาะกับงานที่เรียบง่าย ทำซ้ำบ่อย และ UI เดิมที่อิงฟอร์ม

  • Imperative API

    • ลงทะเบียนเครื่องมือได้โดยตรงผ่าน JavaScript
    • มี API เช่น registerTool, provideContext, unregisterTool
    • เหมาะกับลอจิกที่ซับซ้อน การแตกแขนงตามเงื่อนไข การประมวลผลแบบ asynchronous และการทำงานที่อิงสถานะ
    • ใช้ประโยชน์ได้มากใน SPA หรือเว็บแอปพลิเคชันขั้นสูง

วิธีโต้ตอบกันระหว่างเบราว์เซอร์กับ agent

  • เมื่อ agent เรียกใช้เครื่องมือ เบราว์เซอร์จะ โฟกัสและกรอกข้อมูลใน UI ที่เกี่ยวข้องโดยอัตโนมัติ
  • สามารถแยกได้ว่าฟอร์มถูกเรียกโดย agent หรือไม่ด้วยแฟลก agentInvoked
  • เมื่อสำเร็จหรือยกเลิก จะเกิดอีเวนต์ toolactivated, toolcancel
  • มี visual feedback ผ่าน CSS pseudo-class (:tool-form-active, :tool-submit-active)
  • สามารถรวมโฟลว์การใช้งานของมนุษย์และ agent ให้อยู่บน โมเดลสถานะ UI เดียวกัน ได้

ตัวอย่างสถานการณ์การใช้งาน

  • หากเว็บไซต์สายการบินมีเครื่องมือ book_flight agent ก็สามารถ ส่งข้อมูลผู้โดยสารแบบมีโครงสร้างได้โดยตรง โดยไม่ต้องตีความ UI ปฏิทิน
  • ในพอร์ทัลด้านการแพทย์หรือกฎหมาย สามารถใช้เครื่องมือ submit_application เพื่อสื่อความหมายของแต่ละฟิลด์ได้อย่างชัดเจน
  • ในหน้าการตั้งค่าสำหรับนักพัฒนา สามารถเปิดเผยเครื่องมืออย่าง run_diagnostics เพื่อ เรียกเมนูที่ซ่อนอยู่โดยอัตโนมัติ
  • มีประสิทธิภาพเป็นพิเศษในงานอย่างฝ่ายสนับสนุนลูกค้า อีคอมเมิร์ซ และบริการท่องเที่ยว ที่ ต้องการความน่าเชื่อถือสูงในการป้อนข้อมูล

ความแตกต่างระหว่าง WebMCP กับ MCP

  • MCP (Model Context Protocol) เป็น โปรโตคอลฝั่งเซิร์ฟเวอร์ ซึ่งต้องมีการติดตั้งเซิร์ฟเวอร์แยกต่างหาก
  • WebMCP ทำงาน ภายในเบราว์เซอร์ และผสานรวมเข้ากับเว็บแอปที่มีอยู่ได้โดยตรง
  • สามารถมอบความสามารถฝั่งไคลเอนต์ให้ agent ได้โดยไม่ต้องมีเซิร์ฟเวอร์
  • จุดต่างสำคัญคือเป็น แนวทางที่เน้นฝั่งฟรอนต์เอนด์ ภายใต้สมมติฐานของ agent browser

สถานะปัจจุบันและข้อจำกัด

  • ใช้งานได้เมื่อเปิดแฟลกใน Chrome 146 ขึ้นไป
  • ไม่ทำงานในสภาพแวดล้อมแบบ headless และ ต้องมี browsing context ที่มองเห็นได้
  • ยังไม่มีกลไกสำหรับค้นหาเว็บไซต์ที่ให้เครื่องมือเหล่านี้โดยอัตโนมัติ
  • นักพัฒนายังคงต้องรับผิดชอบการซิงก์สถานะของ UI เอง
  • ยังอยู่ในช่วงพรีวิวระยะแรก จึงมีความเป็นไปได้ที่ API จะเปลี่ยนแปลงและยังมีแรงเสียดทานในการนำไปใช้

บทความที่เกี่ยวข้อง

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

 
crawler 2026-02-11

ถ้า Chrome เป็นผู้ผลักดันหลัก ก็คงจะเข้ามาในเบราว์เซอร์อื่นได้อย่างรวดเร็วเหมือนกัน
 
parkindani 2026-02-11

เหมือน Swagger สำหรับ agent เลยนะ