Paul Klein IV เล่าว่า browser agents อาจทำงานได้ครั้งหนึ่งแล้วสะดุดในรอบถัดไป เมื่อหน้าเว็บเปลี่ยน ข้อมูลบนหน้ามากเกินจำเป็น หรือสภาพแวดล้อมของ browser ไม่สม่ำเสมอ การประเมินงานจึงต้องดูระบบรอบ model ด้วย
ในการบรรยายบนช่อง AI Engineer ผู้ก่อตั้ง Browserbase เสนอว่า ปัญหาของ browser agents ไม่ได้อยู่ที่ model เพียงอย่างเดียว แต่อยู่ที่ระบบที่โอบล้อม model ตั้งแต่เครื่องมือ ความจำ ข้อมูลที่ป้อนให้ ความสม่ำเสมอของ browser ไปจนถึงสิทธิ์และความน่าเชื่อถือของ agent
สำหรับธุรกิจไทย มุมคิดนี้นำมาลองกับงานหลังบ้านที่ยังต้องเปิดเว็บเดิม คัดลอกข้อมูลเดิม และกรอกฟอร์มเดิมได้ ตัวอย่างและรายการนำไปใช้ต่อในบทความนี้เป็นข้อเสนอประยุกต์จากการบรรยาย ไม่ใช่ผลทดสอบในธุรกิจไทยของผู้เขียน
เปลี่ยนคำถามจาก AI เก่งพอหรือยัง เป็นระบบพร้อมหรือยัง
Paul อธิบายว่าเว็บส่วนใหญ่ถูกออกแบบให้มนุษย์ใช้งาน การทำ automation จึงอาจสะดุดเมื่อหน้าเว็บเปลี่ยนโครงสร้าง ข้อมูลบนหน้ามากเกินจำเป็น browser ทำงานไม่เหมือนเดิม หรือมีขั้นตอนยืนยันตัวตนที่ agent จัดการเองไม่ได้
เขามองว่า model สำหรับ computer use พัฒนาไปมาก แต่การนำความสามารถนั้นมาทำงานธุรกิจซ้ำได้ยังต้องอาศัยงานวิศวกรรม เขาเรียกช่องว่างนี้ว่า capabilities overhang
มุมนี้ช่วยให้เราเลิกตั้งโครงการ AI ด้วยคำถามว่า “เลือก model ตัวไหน” แล้วเริ่มจากคำถามที่มีผลต่อธุรกิจมากกว่า เช่น งานไหนทำซ้ำมากที่สุด งานไหนมีขั้นตอนชัดเจน และงานไหนหากผิดพลาดแล้วมีคนตรวจทานก่อนส่งผลกระทบได้
ตัวอย่างที่อาจนำมาทดลองในธุรกิจไทยคือ ทีมจัดซื้อเช็กราคาจาก portal ผู้ขาย ทีมแอดมินกรอกคำสั่งซื้อเข้าระบบคู่ค้า หรือทีมบัญชีดาวน์โหลดเอกสารจากเว็บไซต์ที่มีสิทธิ์เข้าถึง เลือก workflow แคบๆ แล้ววัดผลก่อนตัดสินว่าระบบพร้อมใช้งานจริงหรือยัง
สร้าง harness เพื่อเปลี่ยน model ให้เป็นผู้ปฏิบัติงาน
Harness คือชั้นระบบที่จัดเตรียมเครื่องมือ กติกา ความจำ และข้อมูลที่เหมาะสมให้ model ใช้ทำงาน ไม่ใช่การสั่ง prompt ยาวๆ แล้วหวังให้ AI จัดการทุกอย่างเอง
Paul ยกตัวอย่างเครื่องมือเขียนโค้ดเพื่ออธิบายว่า แม้ใช้ model เดียวกัน การจัดข้อมูลและเครื่องมือใน harness ก็อาจทำให้ผลลัพธ์ต่างกันได้ เขาจึงเสนอให้วัดผลของ harness เทียบกับการใช้ model เป็นฐาน
เมื่อนำแนวคิด harness มาประยุกต์กับ browser agent ลองใช้รายการออกแบบระบบ 5 ข้อนี้เป็นจุดเริ่มต้น แล้วทดสอบกับงานจริงของทีม
- กำหนดเป้าหมายที่ชัดเจน เช่น ตรวจสอบสถานะคำสั่งซื้อ 50 รายการ ไม่ใช่สั่งว่าให้จัดการคำสั่งซื้อทั้งหมด
- แบ่งขั้นตอน แยกค้นหา เปิดรายการ ตรวจข้อมูล บันทึกผล และส่งต่อคนอนุมัติ
- ให้เครื่องมือถูกจังหวะ เช่น browser, การค้นหา, การดึงข้อมูล หรือการรัน script
- เก็บ memory และ skills เพื่อไม่ต้องค้นพบวิธีใช้งานเว็บไซต์เดิมใหม่ทุกครั้ง
- ตั้งกติกาหยุดและส่งต่อ หากเจอข้อมูลผิดปกติ เงิน หรือการอนุมัติสำคัญ ต้องหยุดให้คนตัดสินใจ
ข้อควรระวังคือ harness ไม่ใช่การสร้างระบบใหญ่ก่อนพิสูจน์คุณค่า ธุรกิจขนาดเล็กควรเริ่มจาก workflow เดียวที่มีปริมาณงานจริง วัดผลได้ และยอมรับการตรวจทานโดยคนได้ก่อน
เลือกวิธีทำงานแบบ multimodal ไม่ยึดติดกับการคลิกหน้าจอ
Paul เสนอให้ browser agent ใช้เครื่องมือหลายแบบร่วมกัน ทั้งการอ่านหน้าจอ การเขียนโค้ด และการเรียกเครื่องมือที่เหมาะกับงาน ในการนำไปใช้ควรเลือกเฉพาะช่องทางที่เว็บไซต์และเจ้าของข้อมูลอนุญาตให้เข้าถึง และหยุดเมื่อสิทธิ์ไม่ครอบคลุม
ในคำอธิบายของ Paul แนวทาง multimodal คือการใช้หลาย model และหลายวิธีทำงานร่วมกัน งานซับซ้อนอาจต้องใช้ model ที่มีความสามารถสูงกว่า ส่วนงานง่ายอาจทดลอง model ที่เล็กกว่าได้ ความเหมาะสมและต้นทุนต้องวัดใน workflow นั้น
ความหมายในเชิงธุรกิจคือ เราไม่ควรวัดโครงการจากความสามารถในการเลียนแบบคนคลิกเมาส์อย่างเดียว ควรวัดจาก ต้นทุนต่อรายการ ความถูกต้อง ระยะเวลาทำงาน และความสามารถในการทำซ้ำ
สมมติทีมต้องตรวจสถานะพัสดุ 500 รายการต่อวัน การคลิกทีละรายการอาจใช้ทดลองกระบวนการได้ หากผู้ให้บริการมี API หรือเครื่องมือที่อนุญาตให้ใช้งาน ก็ควรเปรียบเทียบกับวิธีผ่านหน้าจอ ตัวเลขนี้เป็นตัวอย่างวางแผน ไม่ใช่ผลใช้งานจากการบรรยาย
อีกจุดที่ Paul ให้ความสำคัญคือการจัด context ให้เหมาะกับงาน สำหรับทีมที่ทดลองใช้งาน ลองคัดข้อมูลที่จำเป็น เช่น ตารางคำสั่งซื้อ ช่องสถานะ และปุ่มที่เกี่ยวข้อง แล้ววัดต้นทุน เวลา และความถูกต้องเทียบกับการส่งข้อมูลทั้งหน้า
ทำให้ agent จำงานเดิมและรักษาสภาพแวดล้อมให้คงที่
งานที่ทำซ้ำควรกลายเป็น skill ไม่ใช่โจทย์ใหม่ทุกครั้ง เช่น วิธีค้นหาเลขคำสั่งซื้อใน portal ของผู้ขาย วิธีดาวน์โหลดใบกำกับ หรือวิธีตรวจสถานะใบอนุญาต ข้อมูลเหล่านี้ควรถูกเก็บเป็นคำสั่งมาตรฐานพร้อมเงื่อนไขที่ชัดเจน
Paul เสนอให้เก็บ memory และ skills เพื่อไม่ต้องค้นพบวิธีใช้เว็บไซต์เดิมใหม่ทุกครั้ง สิ่งที่ต้องทดสอบต่อคือวิธีนี้ช่วยลดขั้นตอน เวลา หรือ token ในงานของทีมได้เท่าไร และ skill ยังใช้ได้หรือไม่เมื่อหน้าเว็บเปลี่ยน
เขายกตัวอย่างความคงที่ของ infrastructure ว่า ถ้ารอบแรกเห็น desktop layout แต่รอบถัดไปเห็น mobile layout agent จะเจอองค์ประกอบคนละแบบ จึงควรรักษาหน้าและขนาดการแสดงผลให้สม่ำเสมอเท่าที่ระบบรองรับ
ในการทดลองของทีม ให้บันทึกขนาดหน้าจอ ภาษา เขตเวลา และ session เป็นตัวแปรที่ตรวจสอบได้ เพื่อแยกสาเหตุเมื่อผลลัพธ์เปลี่ยน
Paul เล่าถึงคนที่รัน agent บน Mac mini ที่บ้าน และตั้งข้อสังเกตว่าเขายังไม่เห็นการจัดการลักษณะนี้ในระดับองค์กรตามโจทย์ SOC 2 ที่เขากล่าวถึง ข้อสังเกตของเขาไม่ใช่ผลตรวจรับรองเครื่องใดเครื่องหนึ่ง บทเรียนที่นำมาใช้ได้คือถามว่าทีมควบคุมสิทธิ์ ดูแลเครื่อง และรับมือเมื่อระบบหยุดอย่างไร
เตรียมเว็บไซต์และสิทธิ์ให้ agent ทำงานอย่างปลอดภัย
การสร้าง agent เก่งอย่างเดียวไม่พอ เว็บเองต้องช่วยให้ agent เข้าใจและเข้าถึงได้ด้วย Paul Klein ยก 3 หัวข้อที่เว็บต้องปรับ คือ accessibility, authentication และ trust
Accessibility คือโครงสร้างที่อ่านรู้เรื่อง
Paul เสนอว่า accessibility tree และ ARIA labels ช่วยให้ agent อ่านหน้าที่ของปุ่ม ฟอร์ม และองค์ประกอบบนเว็บได้ชัดขึ้น การออกแบบให้คนเข้าถึงได้จึงเป็นจุดที่ควรตรวจเมื่อต้องการให้ agent ทำงานกับเว็บไซต์ด้วย
ทีมที่ดูแลเว็บไซต์หรือระบบภายในอาจเริ่มตรวจว่าปุ่มและฟอร์มมีป้ายกำกับชัดหรือไม่ และทดสอบทั้งกับผู้ใช้และ agent สำหรับอ่านต่อเรื่อง accessibility ต้นฉบับมีลิงก์ WCAG ของ W3C
Authentication ต้องใช้สิทธิ์เท่าที่จำเป็น
Paul เสนอให้พิจารณา service account และสิทธิ์ที่จำกัด แทนการมอบรหัสผ่านหลักให้ agent ทุกอย่าง ตัวอย่างประยุกต์คือให้อ่านข้อมูลได้แต่ส่งคำสั่งซื้อไม่ได้ หรือสร้างรายการร่างได้แล้วส่งให้คนยืนยัน ทั้งนี้ต้องเป็นวิธีที่ระบบปลายทางรองรับและอนุญาต
สำหรับงานที่มีผลผูกพันทางการเงิน เปลี่ยนข้อมูลลูกค้า หรือส่งเอกสารออกนอกองค์กร ทีมควรกำหนดจุดอนุมัติและผู้รับผิดชอบตามความเสี่ยงของงานนั้น Paul เสนอ human-in-the-loop เป็นหนึ่งในวิธีจัดการสิทธิ์และการยืนยันตัวตน
Trust คือโจทย์ที่ยังไม่มีคำตอบสมบูรณ์
ในมุมมองของ Paul ระบบป้องกัน bot ต้องแยกการโจมตีออกจาก agent ที่เจ้าของมอบหมายให้ทำงาน เขามองว่า CAPTCHA เพียงอย่างเดียวไม่ตอบโจทย์นี้ จึงเสนอให้พัฒนาวิธียืนยันตัวตนและความน่าเชื่อถือของ agent การใช้งานจริงยังต้องเคารพข้อจำกัดของเว็บไซต์
เขาพูดถึงมาตรฐานยืนยัน agent ในฐานะโจทย์ที่ต้องพัฒนาต่อ ระหว่างประเมินเครื่องมือ ทีมอาจเริ่มจากบัญชีที่มีสิทธิ์ชัด บันทึกการทำงาน และกระบวนการอนุมัติที่ตรวจย้อนหลังได้
เลือก platform จากความสามารถในการควบคุม ไม่ใช่แค่เดโมที่ดูฉลาด
เมื่อจำเป็นต้องใช้ browser agent จริง สิ่งที่ควรถามผู้ให้บริการหรือทีมภายในไม่ใช่แค่ “AI ทำงานนี้ได้ไหม” แต่คือ “หากมันทำผิด เราตรวจรู้และแก้ได้ไหม”
Paul เสนอคุณสมบัติของ platform ที่ควรพิจารณา 4 ด้าน
- รองรับการขยายงาน เริ่มจาก agent เดียวได้ และขยายเมื่อมีปริมาณงานเพิ่มขึ้น
- ไม่ล็อกกับ model เดียว เพราะ model เปลี่ยนเร็ว ธุรกิจควรสลับทางเลือกได้เมื่อราคา ความสามารถ หรือข้อกำหนดเปลี่ยน
- มี identity ของ agent เพื่อระบุว่าใครเป็นผู้สั่งงาน agent และ agent มีสิทธิ์แค่ไหน
- มี observability ได้แก่ log, ภาพหน้าจอ การบันทึกขั้นตอน และกิจกรรม network เพื่อหาสาเหตุเมื่อผลลัพธ์ผิดปกติ
Observability คือหัวใจของการพัฒนาต่อเนื่อง ทุกครั้งที่ agent ล้มเหลวควรได้ข้อมูลกลับมาเพื่อปรับ skill, prompt หรือกติกา ไม่ใช่เพียงให้ทีมแก้ปัญหาเฉพาะรอบแล้วเริ่มใหม่จากศูนย์
เริ่มจากงานเศรษฐกิจจริง ไม่ใช่งานโชว์เดโม
จุดที่น่าสนใจที่สุดของแนวคิดนี้คือโอกาสไม่ได้จำกัดอยู่ในบริษัท AI รายใหญ่ แต่เกิดในธุรกิจที่ยังทำงานผ่านฟอร์มเก่า เว็บไซต์ภายใน หรือ portal คู่ค้าที่พนักงานต้องกดซ้ำทุกวัน
หากคลังสินค้า โรงงาน ทีมโลจิสติกส์ หรือสำนักงานบัญชีของเราเจองานกรอกข้อมูลและคัดลอกข้ามระบบซ้ำๆ ลองเลือกจุดที่วัดผลได้ เช่น เวลาตรวจเอกสาร เวลาคีย์ข้อมูล และงานแก้มือ ตัวอย่างนี้เป็นแนวทางเลือกโจทย์ ไม่ใช่ข้อมูลว่าธุรกิจไทยทุกกลุ่มมีงานเหล่านี้เท่ากัน
มุมที่ต้องเห็นต่างกับกระแส agent คือ ไม่ใช่ทุก workflow ควรถูกทำอัตโนมัติทันที หากขั้นตอนยังไม่ชัด มีข้อยกเว้นมาก ข้อมูลต้นทางไม่สะอาด หรือไม่มีเจ้าของกระบวนการที่รับผิดชอบ การใส่ AI เข้าไปอาจทำให้ปัญหาเร็วขึ้นแต่ไม่ได้ดีขึ้น
หลักคิดที่ปลอดภัยคือ ทำให้กระบวนการชัดก่อน แล้วใช้ agent เร่งส่วนที่ทำซ้ำ ไม่ใช่ใช้ agent แทนการจัดระเบียบงานที่ยุ่งเหยิง
แนวทางเริ่มลงมือสำหรับเจ้าของธุรกิจและคนทำงาน
- เลือกงานเดียวก่อน เลือกงานบนเว็บที่เกิดอย่างน้อยทุกสัปดาห์ มีขั้นตอนซ้ำ และใช้เวลาคนมากพอที่จะวัดผลได้
- เขียน SOP แบบละเอียด ระบุข้อมูลเข้า ขั้นตอน เงื่อนไขผิดปกติ ผลลัพธ์ที่ต้องการ และจุดที่ต้องให้คนอนุมัติ
- แยกสิทธิ์ของ agent ใช้บัญชีเฉพาะ ไม่ใช้รหัสผ่านส่วนบุคคล และให้สิทธิ์เท่าที่ต้องใช้
- วัดผลก่อนขยาย เก็บอัตราสำเร็จ เวลาเฉลี่ย ต้นทุนต่อรายการ และจำนวนครั้งที่คนต้องแก้
- บันทึกทุกการทำงาน เก็บ log และหลักฐานของผลลัพธ์ โดยเฉพาะงานที่เกี่ยวกับลูกค้า เงิน หรือข้อมูลสำคัญ
ตรวจปัญหา เมื่อ browser agent ทำงานไม่ตรงแผน
- หาก agent ทำได้วันแรกแต่พังวันถัดไป ให้ตรวจว่า layout และสภาพ browser เปลี่ยนหรือไม่ บันทึกขนาดหน้าจอ ภาษา และ session แล้วทดลองจุดส่งต่อเมื่อหาองค์ประกอบไม่เจอ อย่าสรุปสาเหตุจากอาการเพียงอย่างเดียว
- หาก agent กดผิดช่องหรือกรอกข้อมูลผิด ลองตรวจข้อมูลที่ส่งเข้า model และความชัดเจนของคำสั่ง ระบุฟิลด์กับรูปแบบผลลัพธ์ให้ชัด และตรวจข้อมูลก่อนส่ง จากนั้นทดสอบว่าการเปลี่ยนนี้ช่วยได้จริงหรือไม่
- หากล็อกอินไม่ผ่านหรือเจอ CAPTCHA ให้ตรวจสิทธิ์ บัญชี และข้อจำกัดของเว็บไซต์ ใช้ service account เฉพาะเมื่อระบบรองรับ และส่งต่อผู้มีสิทธิ์เมื่อจำเป็นต้องยืนยันตัวตน ไม่ใช้การข้ามข้อจำกัดเป็นทางแก้
- หากงานเสร็จแต่ทีมไม่เชื่อผลลัพธ์ ให้ตรวจว่ามี log ภาพหน้าจอ และผลลัพธ์รายขั้นตอนพอให้ทบทวนหรือไม่ แล้วใช้หลักฐานข้อผิดพลาดปรับ workflow
- หากค่าใช้จ่ายสูง ให้เทียบ model ที่ใช้ ปริมาณ context และขั้นตอนที่ต้องทำซ้ำ ลองใช้ model ตามความยากกับ skill สำหรับงานเดิม แล้ววัดต้นทุนและความถูกต้องร่วมกัน
การต่อยอดหลังจาก workflow แรกเริ่มนิ่ง
- สร้างคลัง skills ขององค์กร: เก็บวิธีทำงานกับ portal ผู้ขาย ระบบราชการ หรือระบบภายใน เพื่อไม่ให้ความรู้ติดอยู่กับพนักงานคนเดียว
- เชื่อม agent กับระบบแจ้งเตือน: ให้ agent สรุปเฉพาะกรณีผิดปกติ เช่น สถานะล่าช้า ราคาเปลี่ยน หรือเอกสารไม่ครบ แล้วส่งต่อให้ทีมตัดสินใจ
- ยกระดับเว็บไซต์ของเราเอง: ปรับ accessibility, ฟอร์ม และขั้นตอนล็อกอิน เพื่อให้ทั้งลูกค้า พนักงาน และ agent ใช้งานได้ชัดเจนขึ้น
ข้อเสนอจากการบรรยายคือเริ่มออกแบบระบบรอบ agent ควบคู่กับการเลือก model เลือกงานแคบที่มีสิทธิ์ทำ เก็บหลักฐาน และวัดผลซ้ำก่อนขยาย การทำให้ระบบตรวจสอบได้เป็นงานที่ทีมเริ่มลงมือได้ โดยยังต้องพิสูจน์ความเหมาะสมกับ workflow ของตน
แหล่งที่มา: Bringing agents onto the world wide web — Paul Klein IV, Browserbase โดย AI Engineer · อัปโหลด 14/08/2026 (เวลาไทย 22:00:31 น.) วันที่นี้เป็นวันอัปโหลดต้นฉบับ ไม่ใช่วันที่จัดงานหรือวันที่เผยแพร่บทความนี้
