สอน AI ควบคุมเบราว์เซอร์แทนคนไปคลิกกรอกและดึงข้อมูลเว็บเอง

ทีมพัฒนาหลายทีมเจอสถานการณ์ที่อยากให้ AI ช่วยทำงานบนเว็บไซต์ที่ไม่มี API ให้เรียกใช้โดยตรง เช่น เว็บของ Supplier ที่ต้อง Login เข้าไปดึงราคาสินค้า หรือระบบภายในองค์กรเก่าที่ไม่เคยเปิด API ไว้เลย งานแบบนี้เดิมทีต้องให้คนนั่งคลิกเองทีละขั้นตอน

Browser Agent คือคำตอบของปัญหานี้ เพราะแทนที่จะพึ่งพา API ที่อาจไม่มีอยู่จริง Agent จะควบคุมเบราว์เซอร์เหมือนคนใช้งานเว็บจริง เปิดหน้า อ่านเนื้อหา คลิกปุ่ม กรอกฟอร์ม และดึงข้อมูลออกมา แต่การทำงานแบบนี้ก็มาพร้อมความท้าทายที่ต่างจาก Agent ที่เรียก API ตรง ๆ อย่างสิ้นเชิง

บทความนี้จะอธิบายว่า Browser Agent ทำงานอย่างไร ต่างจาก Agent แบบ Tool Calling ทั่วไปตรงไหน และจุดไหนที่ทีมต้องระวังเป็นพิเศษก่อนปล่อยให้ Agent ควบคุมเบราว์เซอร์บนเว็บไซต์จริง

Browser Agent คืออะไร ทำงานต่างจาก Agent ทั่วไปตรงไหน

Browser Agent คือ AI Agent ที่ควบคุมเบราว์เซอร์จริงผ่านเครื่องมือ Automation เช่น Playwright, Puppeteer หรือ Selenium โดยโมเดลภาษาเป็นตัวตัดสินใจว่าควรทำ Action อะไรต่อบนหน้าเว็บ ณ ขณะนั้น เช่น คลิกปุ่มไหน กรอกช่องไหน หรือเลื่อนหน้าจอลงไปดูส่วนไหนเพิ่ม

ต่างจาก Agent แบบ Tool Calling ทั่วไปที่เรียก API ที่มี Schema ชัดเจนตายตัว Browser Agent ต้องรับมือกับหน้าเว็บที่เปลี่ยนแปลงได้ตลอดเวลา โครงสร้าง HTML ที่ซับซ้อน และ Element ที่อาจเปลี่ยนตำแหน่งหรือชื่อได้ทุกครั้งที่เว็บไซต์อัปเดต ความไม่แน่นอนนี้ทำให้ Browser Agent ออกแบบยากกว่า Agent ที่เรียก API ที่มีสัญญาชัดเจน

จุดแข็งของ Browser Agent คือใช้ได้กับเว็บไซต์ใดก็ได้ที่คนเข้าถึงผ่านเบราว์เซอร์ได้ ไม่จำเป็นต้องมี API เปิดให้เรียกใช้ ทำให้ครอบคลุมงานได้กว้างกว่า Agent ที่ผูกกับ API เฉพาะทาง แต่ต้องแลกกับความเสถียรที่ต่ำกว่าและความซับซ้อนในการดูแลรักษาที่สูงกว่า

Browser Agent 'เห็น' หน้าเว็บได้อย่างไร

Browser Agent มีสองแนวทางหลักในการรับรู้เนื้อหาหน้าเว็บ แนวทางแรกคือการอ่าน DOM หรือ Accessibility Tree ของหน้าเว็บ ซึ่งเป็นโครงสร้างข้อความที่บอกว่าหน้านั้นมี Element อะไรบ้าง แต่ละ Element อยู่ตรงไหน และมี Label หรือ Role อะไรกำกับไว้

แนวทางที่สองคือการใช้ Vision Model วิเคราะห์ Screenshot ของหน้าเว็บโดยตรง เหมือนที่คนมองหน้าจอแล้วตัดสินใจว่าจะคลิกตรงไหน วิธีนี้ทำให้ Agent จัดการกับเว็บที่มีโครงสร้าง DOM ซับซ้อนหรือใช้ Canvas/Custom Component ได้ดีกว่า แต่ต้นทุนการประมวลผลสูงกว่าและอาจตีความตำแหน่งผิดได้ถ้าภาพไม่ชัดหรือ Layout เปลี่ยนบ่อย

ระบบที่ทำงานได้ดีในทางปฏิบัติมักผสมทั้งสองแนวทางเข้าด้วยกัน ใช้ DOM/Accessibility Tree เป็นข้อมูลหลักเพราะแม่นยำและประมวลผลเร็วกว่า แล้วใช้ Screenshot เป็นข้อมูลเสริมเมื่อ DOM ไม่ชัดเจนพอ หรือใช้ตรวจสอบผลลัพธ์หลังทำ Action เสร็จว่าหน้าเว็บเปลี่ยนไปตามที่คาดไว้จริงหรือไม่

เปรียบเทียบ Browser Agent กับ Agent ที่เรียก API ตรง ๆ

การเลือกระหว่างสองแนวทางนี้ไม่ใช่เรื่องแนวทางไหนดีกว่าเสมอไป แต่ขึ้นกับว่างานนั้นมี API ให้ใช้หรือไม่ และความเสถียรที่ต้องการสูงแค่ไหน

Action ที่ Browser Agent ทำได้บนหน้าเว็บมีอะไรบ้าง

• Navigate: เปิด URL ใหม่ กดปุ่มย้อนกลับ หรือรีเฟรชหน้า
• Click: คลิกปุ่ม ลิงก์ หรือ Element ที่กำหนดตำแหน่งได้จาก DOM หรือ Screenshot
• Type: กรอกข้อความลงในช่อง Input, Textarea หรือ Search Box
• Scroll: เลื่อนหน้าจอเพื่อดูเนื้อหาที่ยังไม่ปรากฏในมุมมองปัจจุบัน
• Extract: ดึงข้อความ ตาราง หรือ Attribute ของ Element ออกมาเป็นข้อมูลที่ใช้ต่อได้
• Wait: รอให้ Element ปรากฏหรือหน้าโหลดเสร็จก่อนทำ Action ถัดไป เพราะหน้าเว็บสมัยใหม่มักโหลดข้อมูลแบบ Asynchronous

งานแบบไหนที่เหมาะกับ Browser Agent จริง ๆ

Browser Agent เหมาะกับงานที่เว็บไซต์เป้าหมายไม่มี API เปิดให้ใช้ หรือมี API แต่ไม่ครอบคลุมสิ่งที่ต้องการทำ เช่น การดึงข้อมูลราคาจากเว็บ Supplier หลายเจ้าที่แต่ละเจ้าไม่มี API มาตรฐานเดียวกัน หรือการทดสอบว่าเว็บไซต์ของตัวเองทำงานถูกต้องจากมุมมองผู้ใช้จริง ไม่ใช่แค่ทดสอบ API เบื้องหลัง

อีกกลุ่มงานที่ใช้กันมากคือ Research ที่ต้องเข้าเว็บหลายแห่งเพื่อรวบรวมข้อมูล เช่น เปรียบเทียบข้อมูลสินค้าจากหลายเว็บ หรือติดตามการเปลี่ยนแปลงเนื้อหาของหน้าเว็บคู่แข่งเป็นระยะ งานเหล่านี้ต้องอ่านและตีความหน้าเว็บที่มีโครงสร้างต่างกันไปในแต่ละเว็บ ซึ่งเป็นจุดที่ Browser Agent ทำได้ดีกว่าการเขียน Script ตายตัวสำหรับแต่ละเว็บ

งานที่ไม่เหมาะกับ Browser Agent คืองานที่เว็บไซต์เป้าหมายมี API ที่เสถียรและครอบคลุมอยู่แล้ว เพราะการเรียก API ตรงให้ผลลัพธ์ที่เสถียรกว่า เร็วกว่า และดูแลรักษาง่ายกว่าการควบคุมเบราว์เซอร์มาก

ความท้าทายเรื่องความเสถียรที่ Browser Agent ต้องเจอ

ปัญหาที่พบบ่อยที่สุดของ Browser Agent คือเว็บไซต์เป้าหมายเปลี่ยน Layout หรือชื่อ Element โดยไม่แจ้งล่วงหน้า ทำให้ Selector หรือวิธีระบุตำแหน่งที่เคยใช้ได้จู่ ๆ ก็ใช้ไม่ได้ นี่คือเหตุผลที่ Browser Agent ที่พึ่งพา Vision Model ร่วมกับ DOM มักทนทานกว่าตัวที่พึ่ง Selector ตายตัวเพียงอย่างเดียว

อีกความท้าทายคือหน้าเว็บสมัยใหม่จำนวนมากโหลดข้อมูลแบบ Asynchronous ทำให้ Content ที่ Agent ต้องการอาจยังไม่ปรากฏในขณะที่ Agent พยายามอ่าน ถ้าไม่มีกลไกรอที่เหมาะสม Agent อาจสรุปผิดว่าข้อมูลไม่มี หรือคลิกไปยัง Element ที่ยังไม่พร้อมใช้งานจริง

เว็บไซต์บางแห่งยังมีระบบตรวจจับ Automation โดยเฉพาะ เช่น CAPTCHA หรือการตรวจ Pattern การใช้งานที่ผิดปกติ ทีมที่ใช้ Browser Agent ต้องเข้าใจว่าบางเว็บไม่อนุญาตให้ Automation เข้าถึงตาม Terms of Service และต้องตรวจสอบเงื่อนไขการใช้งานของเว็บเป้าหมายก่อนทำ Automation จริงเสมอ

ความปลอดภัยของ Browser Agent เมื่อต้อง Login และทำ Action จริง

เมื่อ Browser Agent ต้อง Login เข้าระบบด้วยบัญชีจริงเพื่อทำงาน ความเสี่ยงจะสูงขึ้นทันทีเพราะ Agent มีสิทธิ์เท่ากับผู้ใช้ที่ Login อยู่ ถ้า Agent ตีความหน้าเว็บผิดพลาดแล้วคลิกปุ่มที่ไม่ควรคลิก เช่น ยืนยันคำสั่งซื้อ หรือลบข้อมูลในระบบ ความเสียหายจะเกิดขึ้นจริงเหมือนคนคลิกเองผิดพลาด

แนวทางที่ปลอดภัยกว่าคือการจำกัดขอบเขตที่ Browser Agent เข้าถึงได้ตั้งแต่ระดับบัญชีผู้ใช้ ให้สิทธิ์เท่าที่จำเป็นต่องานนั้นจริง และตั้งจุดให้คนอนุมัติก่อนสำหรับ Action ที่ย้อนกลับไม่ได้หรือมีมูลค่าสูง เช่น การยืนยันคำสั่งซื้อหรือการเปลี่ยนแปลงข้อมูลสำคัญ หลักการเลือกจุดอนุมัติแบบนี้อธิบายไว้ละเอียดกว่าที่ แนวทางออกแบบ Human in the Loop สำหรับ AI Agent

นอกจากนี้ควรมีชั้นตรวจสอบก่อนที่ Agent จะทำ Action สำคัญ เช่น ตรวจว่าหน้าเว็บที่กำลังจะคลิกตรงกับที่คาดไว้จริงหรือไม่ ไม่ใช่เชื่อคำตัดสินใจของโมเดลทันทีโดยไม่มีการยืนยันซ้ำ ซึ่งเป็นหลักการเดียวกับการวาง Guardrails หลายชั้นสำหรับ AI Agent ทั่วไป ดูรายละเอียดเพิ่มเติมได้ที่ แนวทางออกแบบ AI Guardrails

ทดสอบและ Monitor Browser Agent อย่างไรก่อนใช้งานจริง

การทดสอบ Browser Agent ต่างจากการทดสอบ Agent ที่เรียก API ตรงตรงที่ต้องทดสอบกับหน้าเว็บจริงหรือหน้าจำลองที่ใกล้เคียงของจริงมากที่สุด เพราะพฤติกรรมของ Agent ขึ้นกับ Layout และโครงสร้างหน้าเว็บที่เปลี่ยนแปลงได้ตลอด การทดสอบด้วยข้อมูลจำลองอย่างเดียวมักไม่ครอบคลุมปัญหาที่เกิดกับเว็บจริง

ทีมที่ดูแลระบบควรบันทึก Screenshot และ Log ของทุก Action ที่ Browser Agent ทำ ไม่ใช่แค่บันทึกผลลัพธ์สุดท้าย เพราะเมื่อเกิดปัญหาการมี Log ขั้นตอนละเอียดช่วยให้ตามรอยได้ว่า Agent ตัดสินใจผิดตรงจุดไหน เข้าใจหน้าเว็บผิดตรงไหน ซึ่งช่วยลดเวลา Debug ได้มาก

ควรตั้ง Monitoring แยกสำหรับกรณีที่เว็บไซต์เป้าหมายเปลี่ยน Layout จนอัตราความสำเร็จของ Agent ลดลงผิดปกติ เพราะเหตุการณ์แบบนี้มักเกิดแบบไม่มีสัญญาณเตือนล่วงหน้า และถ้าไม่มี Monitoring ทีมอาจไม่รู้ตัวจนกว่าจะมีคนสังเกตว่าผลลัพธ์ที่ได้ผิดปกติไปนานแล้ว

ข้อผิดพลาดที่ทีมมักทำเมื่อเริ่มใช้ Browser Agent

ทำแบบนี้แล้วพัง เพราะพึ่ง Selector ตายตัวเพียงอย่างเดียวโดยไม่มีกลไกสำรอง พอเว็บไซต์เป้าหมายอัปเดต Layout เพียงเล็กน้อย Agent ก็หา Element ไม่เจอทันทีและงานทั้งหมดหยุดทำงาน

ทำแบบนี้แล้วพัง เพราะให้ Browser Agent ใช้บัญชีที่มีสิทธิ์กว้างเกินความจำเป็นของงาน ทำให้เมื่อ Agent ตัดสินใจผิดพลาด ความเสียหายกระทบกว้างกว่าที่ควรจะเป็นมาก

ทำแบบนี้แล้วพัง เพราะไม่มีจุดให้คนตรวจสอบก่อน Action ที่มีมูลค่าสูงหรือย้อนกลับไม่ได้ ปล่อยให้ Agent ตัดสินใจและลงมือทำเองทั้งหมดโดยไม่มีการยืนยันซ้ำเลย

ทำแบบนี้แล้วพัง เพราะใช้ Browser Agent กับเว็บไซต์ที่มี API เปิดให้ใช้อยู่แล้ว ทำให้ต้องแบกรับความไม่เสถียรและต้นทุนประมวลผลที่สูงกว่าโดยไม่จำเป็น ทั้งที่เรียก API ตรงจะได้ผลลัพธ์ที่ดีกว่าในทุกมิติ

สรุป

Browser Agent เปิดโอกาสให้ AI ทำงานบนเว็บไซต์ใดก็ได้ที่คนเข้าถึงผ่านเบราว์เซอร์ได้ ไม่จำกัดแค่เว็บที่มี API เปิดให้ใช้ ทำให้ครอบคลุมงานได้กว้างกว่า Agent แบบ Tool Calling ทั่วไป แต่ต้องแลกกับความเสถียรที่ต่ำกว่าเพราะหน้าเว็บเปลี่ยนแปลงได้ตลอดเวลาโดยไม่แจ้งล่วงหน้า

ทีมที่นำ Browser Agent ไปใช้จริงต้องออกแบบทั้งกลไกรับรู้หน้าเว็บที่ทนทาน จุดให้คนอนุมัติก่อน Action สำคัญ และ Monitoring ที่จับสัญญาณเมื่อเว็บไซต์เป้าหมายเปลี่ยนจนอัตราความสำเร็จลดลง ไม่ใช่ปล่อยให้ Agent ทำงานอัตโนมัติเต็มรูปแบบโดยไม่มีการตรวจสอบใด ๆ

• Browser Agent ควบคุมเบราว์เซอร์จริงผ่าน DOM/Accessibility Tree หรือ Vision Model แทนการเรียก API ตรง เหมาะกับเว็บที่ไม่มี API เปิดให้ใช้
• ความเสี่ยงหลักคือ Selector ที่พังเมื่อเว็บเปลี่ยน Layout และความเสียหายจริงเมื่อ Agent ตีความหน้าเว็บผิดขณะ Login ด้วยบัญชีจริง
• Action ที่มูลค่าสูงหรือย้อนกลับไม่ได้ต้องมีจุดให้คนอนุมัติก่อนเสมอ ไม่ควรปล่อยให้ Browser Agent ตัดสินใจและลงมือทำเองทั้งหมด

คำถามที่พบบ่อย