- MCP-B: โปรโตคอล AI automation แบบเนทีฟสำหรับเบราว์เซอร์
- ไม่ใช่วิธีจับภาพหน้าจอและคลิกแบบเดิม แต่เป็น browser context protocol ที่ เข้าถึง API ของเว็บไซต์ได้โดยตรง เพื่อให้ AI ทำงานอัตโนมัติได้เร็วและแม่นยำขึ้น 1,000 เท่า
- เพียงเพิ่มโค้ด ประมาณ 50 บรรทัด ก็เชื่อมต่อ AI ได้ทันทีด้วยข้อมูลยืนยันตัวตนภายในเว็บไซต์ โดยไม่ต้องมี OAuth, API key หรือการตั้งค่าที่ซับซ้อน
- ใช้ browser session และระบบยืนยันตัวตนเดิม ทำให้เริ่มทำงานได้ทันทีโดยไม่ต้องตั้งค่าการยืนยันตัวตนหรือสิทธิ์ใหม่ และยังคงเคารพนโยบายความปลอดภัย API ของแต่ละเว็บแอปตามเดิม
- ผ่านส่วนขยาย ทำให้ AI assistant สามารถข้ามไปมาระหว่างหลายแท็บและหลายแอปเพื่อดึงข้อมูลและทำงานได้โดยตรง โดยมีประสิทธิภาพเหนือกว่าระบบอัตโนมัติแบบเดิมอย่างมากทั้งด้านความเร็ว (ทำงานได้ภายในไม่กี่ ms) และความน่าเชื่อถือ
- เนื่องจากเป็น การเข้าถึง API แบบมีโครงสร้าง จึงไม่ต้องกังวลกับปัญหาการเปลี่ยนแปลง UI, ความผิดพลาดจากสกรีนช็อต หรือการจัดการ selector ที่ซับซ้อน ทั้งการติดตั้งและการใช้งานทำได้ง่ายมาก
ภาพรวมของ MCP-B
- MCP-B (Machine Context Protocol for Browsers) คือ model context protocol สำหรับเบราว์เซอร์ ที่มอบมาตรฐานสำหรับการควบคุมและโต้ตอบกับสภาพแวดล้อมเบราว์เซอร์ในลักษณะคล้ายกับระบบอัตโนมัติบนเทอร์มินัลที่ขับเคลื่อนด้วย AI
- โปรโตคอลนี้กำหนดการสื่อสารระหว่าง เบราว์เซอร์กับ AI engine ไว้อย่างชัดเจน ทำให้สามารถจัดโครงสร้างงานอัตโนมัติและการโต้ตอบกับโมเดลในรูปแบบต่าง ๆ ได้
จุดต่างจากวิธีเดิม
- ระบบอัตโนมัติบนเบราว์เซอร์แบบดั้งเดิม: วิเคราะห์สกรีนช็อต, คลิกองค์ประกอบ, เปราะบางต่อการเปลี่ยน UI, ช้าและไม่เสถียร (10~20 วินาทีต่อหนึ่งงาน, ค่าใช้จ่าย $4~5)
- MCP แบบเดิม: ต้องใช้ API key และการยืนยันตัวตนที่ซับซ้อน ทำให้การตั้งค่าเริ่มต้นมีอุปสรรคสูง
- MCP-B: ใช้ browser session, เข้าถึง API โดยตรง, ทำงานได้ทันทีโดยไม่ต้องมีการยืนยันตัวตนหรือการตั้งค่าที่ซับซ้อน
หลักการและโครงสร้างสำคัญ
- MCP server แยกตามแท็บ: แต่ละเว็บแอปรัน MCP server ของตัวเองบน TypeScript (ส่งข้อมูลภายในหน่วยความจำ และนำ cookie/JWT เดิมกลับมาใช้ซ้ำ)
- ส่วนขยาย MCP-B: ส่วนขยายสำหรับ Chrome/Edge/Firefox (content script สื่อสารกับ tab server ผ่าน
postMessage) รวมเครื่องมือและ API ของทุกแท็บไว้ในที่เดียว
- การเชื่อมต่อกับ AI assistant: ทำ browser automation ผ่าน MCP-B ได้จาก Native Bridge และไคลเอนต์หลากหลายประเภท (เช่น Claude Desktop, Cursor IDE)
วิธีใช้งานและการนำไป deploy
- นักพัฒนา: 1) ติดตั้งแพ็กเกจ 2) เพิ่มโค้ด MCP server 3) deploy เสร็จ → ไม่ต้องมี API key, OAuth หรือการตั้งค่าซับซ้อนเพิ่มเติม
- ผู้ใช้: ติดตั้งส่วนขยายแล้วใช้งานได้ทันที เปิดใช้ระบบอัตโนมัติได้เลยด้วยการตั้งค่า AI เท่านั้น
ข้อดีที่เห็นผลจริง
- การยืนยันตัวตน: ใช้ข้อมูลล็อกอินและ session ของเว็บไซต์เดิมได้ทันที ไม่ต้องมี OAuth 2.1/การยืนยันตัวตนแยก
- ประสิทธิภาพ: เรียก API โดยตรง ทำงานเสร็จในระดับ ms (ดีขึ้น 10,000 เท่าเมื่อเทียบกับเดิม)
- ความปลอดภัย: ทำงานภายในแอปพลิเคชัน และยังคงปฏิบัติตามการควบคุมการเข้าถึงและนโยบายสิทธิ์เดิมทั้งหมด
- การขยายตัว: เว็บแอปหลายตัว, หลายแท็บ และเครื่องมือ AI สามารถจัดการรวมศูนย์ผ่าน MCP-B ได้
- การตั้งค่า: เพียงโค้ดราว 50 บรรทัดก็พร้อมสำหรับระบบอัตโนมัติ
สรุปการเปรียบเทียบ
| วิธีการ |
การยืนยันตัวตนและการตั้งค่า |
วิธีทำงาน |
ประสิทธิภาพและความน่าเชื่อถือ |
| ระบบอัตโนมัติแบบเดิม |
การยืนยันตัวตนซับซ้อน, API key |
สแครปหน้าจอ, คลิก |
ช้าและไม่เสถียร (10~20 วินาที) |
| MCP แบบเดิม |
ต้องมี API key, OAuth |
เข้าถึง API |
อุปสรรคเริ่มต้นสูง |
| MCP-B |
ไม่ต้องตั้งค่า ใช้ browser session |
เรียก API โดยตรง |
ระดับ ms, เร็วมาก/เสถียรสูง |
บทสรุป: ระบบอัตโนมัติด้วย AI บนเบราว์เซอร์ยุคถัดไป
- MCP-B คือโปรโตคอลระบบอัตโนมัติด้วย AI ที่ออกแบบมาเหมาะกับสภาพแวดล้อมเบราว์เซอร์ และถือเป็นนวัตกรรมในทุกด้านทั้งการยืนยันตัวตน, ความปลอดภัย, การขยายตัว และประสิทธิภาพ
- สามารถสร้างระบบอัตโนมัติด้วย AI ในระดับขนาดใหญ่ได้ผ่านการเรียก API โดยตรงบนเบราว์เซอร์ โดยไม่ต้องมีการยืนยันตัวตนเพิ่มเติมหรือการตั้งค่าที่ซับซ้อน
- ใช้ไลเซนส์ MIT, ขับเคลื่อนโดยชุมชน และรองรับเบราว์เซอร์หลักทั้งหมด
2 ความคิดเห็น
วิสัยทัศน์หลักของเทคโนโลยี MCP-B อาจมองได้ว่าเป็นดังนี้
"ผ่านตัวกลางที่เชื่อถือได้อย่าง Chrome Extension โดยใช้ข้อมูลผู้ใช้ที่เบราว์เซอร์จัดการไว้อย่างปลอดภัยอยู่แล้ว (คุกกี้, เซสชัน, การยืนยันตัวตน ฯลฯ)
เพื่อเรียกใช้และควบคุม 'เครื่องมือ (Tools)' ที่นักพัฒนากำหนดไว้ล่วงหน้าบนหน้าเว็บ จากหน้าต่างแชต AI ด้วยคำสั่งภาษาธรรมชาติ"
แต่ผมรู้สึกว่า "ดูไม่มีช่องทางที่จะขยายต่อได้" และคิดว่าเหตุผลมีดังนี้
หากความสะดวกที่เทคโนโลยีนี้มอบให้ไม่ได้เหนือกว่าความกังวลนั้นอย่างชัดเจน ผู้ใช้ก็จะลังเลที่จะติดตั้ง
หากประโยชน์ที่ได้จากการที่เทคโนโลยีนี้ถูกนำไปใช้อย่างแพร่หลายไม่ได้มากพอ นักพัฒนาก็คงไม่อยากทุ่มแรงซ้ำซ้อนโดยไม่จำเป็น
ความซับซ้อนลักษณะนี้ทำให้บริษัทต่าง ๆ ไม่อยากนำเทคโนโลยีมาใช้
สรุปคือ
แม้แนวคิดของ MCP-B เองจะน่าสนใจและมีนวัตกรรมอย่างมากในเชิงเทคนิค แต่ดูเหมือนว่าจะยังไม่สามารถให้คำตอบที่ชัดเจนต่อคำถามพื้นฐานสำหรับทั้งผู้ใช้และนักพัฒนาว่า "แล้วทำไมต้องใช้วิธีนี้ด้วย?" ได้ เมื่อเทียบกับแนวทาง API แบบเดิม ข้อดีที่ได้รับยังไม่ชัดเจน ขณะที่ข้อเสียอย่างความกังวลด้านความปลอดภัยและความซับซ้อนในการพัฒนากลับชัดเจน
ดังนั้น ในตอนนี้เทคโนโลยีนี้อาจถูกนำไปใช้เชิงทดลองในหมู่ผู้ที่ชื่นชอบเฉพาะทางหรือนักพัฒนาที่มีวัตถุประสงค์เฉพาะบางกลุ่มได้ แต่หากจะขยายไปสู่ระบบนิเวศเว็บโดยรวม ก็ดูเหมือนว่ายังมีอุปสรรคอยู่อีกมาก
ความคิดเห็นจาก Hacker News
คาดว่าน่าจะเดินตามรอยเดียวกับ RSS บริษัทต่าง ๆ มักไม่ชอบให้ผู้ใช้ควบคุมวิธีใช้ข้อมูลของตัวเองได้
REST API ก็คล้ายกัน ครั้งหนึ่งเคยถูกคาดหวังว่าจะเป็นอนาคตของการทำบริการอัตโนมัติและการเชื่อมต่อร่วมกัน พร้อมกับกระแสการออกแบบแบบ 'API-first' แต่ธุรกิจก็ตระหนักได้อย่างรวดเร็วว่าการมอบความสามารถแบบนี้เป็นภัยต่อโครงสร้างรายได้ของตัวเอง จึงรีบเปลี่ยนทิศทาง สุดท้ายก็กลับมาตระหนักอีกครั้งว่าแหล่งรายได้ทั้งหมดขึ้นอยู่กับการไม่ปล่อยให้ผู้ใช้มีอำนาจแบบนี้
ผมคิดว่า RSS ไม่ได้ล้มเหลว ตรงกันข้ามมันประสบความสำเร็จอย่างมาก หลังจาก Google Reader หายไป ผมก็ย้ายไปใช้รีดเดอร์ตัวอื่น และ RSS feed ก็ยังทำงานได้ดีไม่มีปัญหามากว่า 20 ปีแล้ว แทบไม่เคยเจอเว็บไซต์ที่ไม่รองรับ RSS เลย
เว็บไซต์ส่วนใหญ่ยังคงรองรับ RSS และบางแห่งถึงแม้ไม่แสดงบนหน้าเว็บก็ยังมี feed อยู่ตามปกติ แม้บางแห่งจะไม่เปิดข้อความเต็มทั้งหมด แต่ก็ยังมีคุณค่ามากทั้งในฐานะการแจ้งเตือนอัปเดตหรือทริกเกอร์สำหรับงานอัตโนมัติ RSS ยังมีชีวิตอยู่และมีประโยชน์มาก ราวกับไมโครเวฟที่มีอยู่จนกลายเป็นเรื่องปกติ
โครงสร้างตลาดเปลี่ยนไป ตอนนี้บริษัทใหญ่ ๆ สนใจ 'ชั้น intelligence' มากกว่าตัวคอนเทนต์เอง คอนเทนต์กำลังกลายเป็นสินค้าโภคภัณฑ์มากขึ้นเรื่อย ๆ Google จำเป็นต้องครอบครองสายตา ความสนใจของผู้ใช้ และเทคโนโลยีอัจฉริยะที่ดึงพวกเขาไว้ เพื่อจะขายโฆษณาต่อได้ เหตุผลที่ Google ไม่ต้องการ RSS ก็เพราะ RSS สามารถข้าม Google Search ได้
ถ้า AI มีความสามารถคลิกและเลื่อนหน้าจอได้เหมือนมนุษย์ในไม่ช้า ก็จะเกิดการแข่งขันไร้ขีดจำกัดขึ้นอีกครั้ง
ประวัติการมีส่วนร่วมของโปรเจกต์บน Github น่าสนใจมาก (อ้างอิง ลิงก์ โดยตรง) MiguelsPizza คอมมิต 3 ครั้ง Claude 2 ครั้ง แต่ปริมาณโค้ดที่ Claude เปลี่ยนแปลงนั้นแทบจะท่วมท้นกว่าอย่างชัดเจน
มีการตั้งส่วนขยายเป็น private ชั่วคราวและปรับ git history เลยทำให้ต่างจากประวัติจริงเล็กน้อย ถึงอย่างนั้นก็ยังเป็นความจริงว่า Claude เขียนโค้ดประมาณ 85% ของทั้งหมด
ต่อไปน่าจะเห็นรูปแบบนี้มากขึ้นเรื่อย ๆ (การมีส่วนร่วมเขียนโค้ดขนาดใหญ่โดย AI)
กราฟคอมมิตของ Claude มีลักษณะเฉพาะมาก ดูเหมือนว่า Claude Code จะคอมมิตเองโดยตรง แต่จริง ๆ แล้วแทบไม่ค่อยเป็นแบบนั้น ดู โปรไฟล์ claude ประกอบ
ถ้าดูรายการคอมมิตจริงจะเห็นว่าทั้งหมดเป็นชื่อของ MiguelsPizza / Alex Nahas (ลิงก์) มันดูแปลก ๆ อยู่
มีการยกข้อความตัดตอนจากบล็อกมาพูดถึงปัญหาการยืนยันตัวตนของ MCP โดยมองว่า OAuth2.1 ก็ใช้ได้ดีในระยะยาว แต่ตอนนี้กลับอยู่ในสถานการณ์ที่ต้องคิดค้นระบบยืนยันตัวตนใหม่ให้เหมาะกับเอเจนต์ที่ทำงานแทนผู้ใช้ ความเสี่ยงข้อมูลรั่วไหลในแอปแบบหลายผู้เช่ายังไม่ได้รับการแก้ไข
การจำกัดขอบเขตความเสียหายและข้อมูลที่โมเดลเข้าถึงได้อาจเป็นข้อดีสำคัญของ MCP เพราะคาดว่า client-side API ของแอปแบบหลายผู้เช่าก็น่าจะถูกจำกัดในขอบเขตของผู้ใช้อยู่แล้ว ดังนั้นถ้าให้โมเดลเข้าถึงแค่นั้น ความเสียหายก็คงไม่มากนัก และยังมีการพูดถึงปัญหาความเข้ากันได้ระหว่างระบบยืนยันตัวตนภายในของ Amazon กับ OAuth2.1 ด้วย (ที่ Amazon ใช้วิธียืนยันตัวตนต่างออกไป)
สงสัยว่าฟีเจอร์บางส่วนของ OAuth2.1 ถูกพูดถึงไว้แล้วใน RFC 8693 เรื่อง delegation vs impersonation หรือไม่
ขอบเขตที่โมเดลเข้าถึงได้สุดท้ายก็เหมือนกับผู้ใช้อยู่ดี ดังนั้นการทำระบบความปลอดภัยให้แน่นหนาจึงเป็นความรับผิดชอบของผู้ดูแลเว็บไซต์
คิดว่ากรณีตัวอย่างของ Amazon ที่ OAuth ถูกใช้งานไม่เหมาะสมไม่ใช่ประเด็นหลัก การเข้าถึงแบบ backdoor ที่เกินขอบเขตสิทธิ์ของผู้ใช้นั้นอันตรายมาก ถ้าการกระทำทั้งหมดของแอป MCP ถูกบันทึกอยู่ในหมวดเดียวกับการเข้าถึงของผู้ใช้ ก็อาจเกิดประเด็นด้าน compliance ตามมามากมาย มุมนี้น่าสนใจมาก แต่ในแง่ความปลอดภัยก็ดูมีช่องให้กลายเป็นทางเลี่ยงที่มีปัญหาได้
มีการเสนอไอเดียว่าถ้าเปิดเผยสเปก Swagger(OpenAPI) แล้วมีเพียง generic swagger mcp client ก็อาจแทนการทำทั้งหมดนี้ได้เกือบหมดหรือไม่ แค่ให้ผู้ใช้เปิด authenticated session ด้วยตัวเองแบบแมนนวลก็น่าจะพอ มีการเสนอว่า Claude น่าจะอ่าน API key จากพรอมป์หรือการตั้งค่าได้ดี และใช้ API client ที่อิง swagger ก็ไม่น่าต่างกัน
นี่เป็นแนวทางที่ทุกคนนึกถึงก่อนเป็นอันดับแรกตอน MCP เพิ่งออกมา แต่ในทางปฏิบัติกลับพบว่ามีเครื่องมือมากเกินไปจนทำงานได้ไม่ดี ถึงอย่างนั้นก็ยังมีความพยายามสนุก ๆ ในด้านนี้ต่อเนื่อง
มีคำเตือนว่าอย่าใส่ API key ลงไปในพรอมป์
แค่ใส่ลิงก์ swagger.json ไว้ใน CLAUDE.md ก็ทำให้ Claude Code ทดสอบ API ได้สะดวกมากจริง ๆ
มีการชวนให้ลองทำด้วยตัวเอง
ไม่ค่อยแน่ใจว่าใครคือผู้ใช้เป้าหมาย สำหรับการทดสอบฟรอนต์เอนด์ หาก UI เปลี่ยนมากแล้วเทสต์พัง กลับเป็นเรื่องที่มีประโยชน์ด้วยซ้ำ ส่วนถ้าเป็นงานอัตโนมัติแบบอื่น ก็คิดว่าการมี API จริงให้ใช้น่าจะดีกว่า
มีคนตั้งข้อสงสัยกับอุปมาว่า "ถ้าจะทำโต๊ะที่ Home Depot มันจะยิ่งยากกว่าเดิม" โดยชี้ว่า Home Depot ก็มีไม้เต็มไปหมด
ที่ Home Depot ก็ขายโต๊ะที่ทำเสร็จแล้วเหมือนกัน
Home Depot ยังมีทั้งเครื่องมือความแม่นยำสูงที่ดีกว่าเดิม และมีผู้เชี่ยวชาญอยู่ด้วย จนอาจทำให้งานง่ายขึ้นด้วยซ้ำ
มีมุกว่าความหมายแฝงคือ 'ไม้เป็นสิ่งที่คุณต้องจินตนาการขึ้นมาเองแล้วสร้างมัน'
เจ้าตัวบอกว่าได้แก้ข้อความให้สะท้อนข้อสังเกตนี้แล้ว
แม้จะยังไม่เคยใช้ MCP โดยตรง แต่ในมุมของคนพิการ มองว่า MCP น่าจะมีประโยชน์ด้าน Accessibility สำหรับการทำงานอัตโนมัติบนเบราว์เซอร์และสมาร์ตโฟนอย่างมาก เพียงแต่ก็สงสัยว่าเทคโนโลยีแบบนี้อาจถูกผู้ไม่หวังดีนำไปใช้ในทางที่ผิด จนไม่แน่ใจว่าเว็บหรือแอประดับใหญ่จะนำไปใช้จริงหรือไม่ และอยากรู้ว่ามีกรณีใช้งานจริงเพื่อปรับปรุง Accessibility บ้างไหม
รู้สึกขอบคุณที่ MCP-B ถูกปล่อยเป็นโอเพนซอร์ส แม้ว่างานส่วนใหญ่จะเกิดขึ้นในเบราว์เซอร์ แต่ MCP มีสมมติฐานต่างออกไปเล็กน้อยคือให้ AI client เป็นผู้ลงมือทำงาน เลยสงสัยว่าโดยพื้นฐานแล้ว MCP-B ต่างจากการเชื่อม JS API ของเว็บแอปเข้ากับ LLM server โดยตรงเพื่อใช้งานอย่างไร สุดท้ายแล้วมันคือสิ่งเดียวกันหรือมีภาพใหญ่กว่านั้น
แค่อ่านหน้าโฮมเพจก็ยังไม่ค่อยเข้าใจ เลยมองว่ามันเหมือน Selenium เวอร์ชันสำหรับเบราว์เซอร์แล้วถามต่อ
คาดว่าถ้าการทำ browser automation ผ่าน MCP เริ่มแพร่หลายไปถึงผู้ใช้ LLM ฟรี ในอนาคตแม้แต่โมเดลฟรีก็อาจต้องเจอ captcha ปัญหาคือ captcha ไม่ได้มีประสิทธิภาพกับ LLM มากนัก สุดท้ายอาจกลายเป็นยุคสงครามหุ่นยนต์ประหลาดที่ LLM ต้องสู้กันเองเพื่อกัน LLM ฝ่ายทำ automation ออกไป