เมื่อระบบอัตโนมัติที่ใช้ Agent เริ่มหยุดหรือผิดพลาดหลังขยายขนาด ปัญหามักไม่ได้อยู่ที่โมเดลหรือสคริปต์ แต่อยู่ที่ชั้นสภาพแวดล้อมเบราว์เซอร์ บทความนี้อธิบายความล้มเหลว 4 รูปแบบที่พบบ่อย สัญญาณที่สังเกตได้ และแนวทางวิศวกรรมสำหรับรับมือ
การสร้าง Agent ด้วย LangChain, AutoGen หรือ CrewAI แล้วให้มันควบคุมเว็บไซต์ผ่าน Playwright หรือ Puppeteer ไม่ใช่เรื่องยากมาก ส่วนที่ยากคือทำให้มันทำงานต่อเนื่องได้อย่างเสถียร
ช่วงแรกหลังนำขึ้นใช้งาน ปัญหามักยังไม่ชัดเจน แต่เมื่อปริมาณงานเพิ่มขึ้น ความผิดปกติจะเกิดถี่ขึ้น เช่น งานถูกเว็บไซต์บล็อก สถานะล็อกอินของบัญชีหมดอายุกะทันหัน หรือ Agents หลายตัวที่ทำงานพร้อมกันรบกวนกันเอง ปฏิกิริยาแรกของหลายคนคือย้อนกลับไปตรวจโค้ด ก่อนจะพบในท้ายที่สุดว่าโค้ดไม่ได้มีปัญหา
สาเหตุมักอยู่ที่ชั้นสภาพแวดล้อมเบราว์เซอร์ สำหรับโปรเจกต์ที่รันงานจำนวนมาก รูปแบบความล้มเหลวจริง ๆ มักวนอยู่ไม่กี่ประเภท เมื่อจำแนกได้แล้ว การรับมือก็ไม่ได้ซับซ้อนมาก
เริ่มทำงานก่อนที่สภาพแวดล้อมจะพร้อม
หากนำสภาพแวดล้อมเบราว์เซอร์ที่เพิ่งสร้างไปใช้กับงานทันที ผลที่พบบ่อยคือเข้าสู่ระบบไม่ได้ องค์ประกอบของหน้าโหลดไม่ครบ หรือเจอการยืนยันตัวตนตั้งแต่ขั้นตอนแรก เหตุผลไม่ซับซ้อน: สภาพแวดล้อมนี้ยังไม่มีประวัติการเข้าชม ไม่มี Cookie และไม่มีร่องรอยการใช้งานเบราว์เซอร์ สำหรับแพลตฟอร์มแล้วจึงดูเหมือนอุปกรณ์ใหม่ที่ไม่คุ้นเคย ทำให้ระดับความน่าเชื่อถือเริ่มต้นต่ำ
สัญญาณที่สังเกตได้คือความล้มเหลวมักกระจุกอยู่ในงานไม่กี่งานแรกหลังสร้างสภาพแวดล้อม หากย้ายงานเดียวกันไปยังสภาพแวดล้อมที่ใช้งานมาระยะหนึ่ง งานมักจะจบได้ตามปกติ
แนวทางที่เหมาะสมคือกำหนด “ความพร้อมของสภาพแวดล้อม” ให้เป็นสถานะที่ชัดเจน แทนที่จะถือว่าใช้งานได้ทันทีโดยอัตโนมัติ หลังสร้างสภาพแวดล้อม ให้มีช่วงการท่องเว็บแบบความเข้มต่ำก่อน และค่อยส่งงานจริงเมื่อสถานะนิ่งแล้ว Scheduler ควรตรวจขั้นตอนความพร้อมนี้ก่อนแจกจ่ายงาน ไม่ใช่รับสภาพแวดล้อมมาแล้วใช้ทันที
หลายงานแย่งใช้สภาพแวดล้อมเดียวกัน
เมื่อเพิ่มการทำงานพร้อมกัน อาการที่เห็นชัดที่สุดคือจำนวน process เพิ่มขึ้น หน่วยความจำถูกใช้จนเต็ม และระบบช้าลง ปัญหาที่ซ่อนอยู่ยิ่งรับมือยากกว่า เช่น สองงานใช้ Cookie และ local storage ชุดเดียวกันต่อเนื่องกัน สถานะล็อกอินของ A ไปแทนที่ของ B และใน log ดูเหมือนมีงานสุ่มบางงานล้มเหลวเป็นครั้งคราว จึงหาสาเหตุได้ยาก
ในกรณีนี้ควรมองสภาพแวดล้อมเบราว์เซอร์เป็นทรัพยากรที่สามารถขอใช้และคืนได้ เมื่อเริ่มงานให้จองสภาพแวดล้อมหนึ่งชุด และคืนเมื่อจบงาน โดยให้งานกับสภาพแวดล้อมจับคู่กันแบบหนึ่งต่อหนึ่ง พื้นที่จัดเก็บของแต่ละสภาพแวดล้อมไม่ควรมองเห็นกัน ทำให้สถานะล็อกอินของงานหนึ่งไม่รั่วไปสู่อีกงาน เมื่อขยายเป็น Agents หลายสิบตัวที่ทำงานขนานกัน ความแตกต่างจากการ “เปิด browser process จำนวนมากจากในสคริปต์เอง” จะเห็นได้ชัดมาก
หากกรณีใช้งานมีหลายบัญชี การแยกต้องเข้มงวดยิ่งขึ้น: หนึ่งบัญชีใช้สภาพแวดล้อมประจำหนึ่งชุด และ fingerprint parameters รวมถึง storage ไม่ซ้ำกับบัญชีอื่น PurpleMark ให้ความสามารถด้านการแยกสภาพแวดล้อมและการจัดตารางแบบรวมศูนย์ เพื่อคงความสัมพันธ์หนึ่งต่อหนึ่งระหว่างบัญชีกับสภาพแวดล้อมอย่างเสถียร
Session หมดอายุแต่ไม่มีใครสังเกต
ความล้มเหลวประเภทนี้มองข้ามได้ง่าย เพราะอาจไม่มี error เลย งานยังทำต่อและ log ยังถูกเขียน แต่ข้อมูลที่ได้จริงกลับเป็นหน้าเข้าสู่ระบบหรือข้อมูลว่าง กว่าจะพบปัญหาก็ตอนที่ผลลัพธ์เข้าสู่ data pipeline แล้ว ทำให้ต้องไล่ตรวจย้อนกลับจาก downstream และมีต้นทุนสูง
วิธีรับมือคือทำให้สถานะล็อกอินเป็นเงื่อนไขก่อนเริ่มงานที่ต้องตรวจอย่างชัดเจน ก่อนเริ่ม task ให้ยืนยันว่า session ปัจจุบันยังใช้ได้ หากหมดอายุแล้วให้รันขั้นตอนล็อกอินแบบเต็ม แทนที่จะปล่อยให้งานเดินต่อด้วยสถานะที่ใช้ไม่ได้ ตัวสถานะควรอยู่ในชั้นสภาพแวดล้อม โดยเก็บ Cookie, local storage และประวัติการท่องเว็บไว้ในสภาพแวดล้อม และกู้คืนได้ครบเมื่อเปิดใหม่ เพื่อไม่ต้องเริ่มต้นใหม่ทุกครั้งสำหรับงานของบัญชี
ข้อสังเกตจากการใช้งานจริงคือ สำหรับบัญชีที่ทำงานระยะยาว การเปลี่ยนสถานะล็อกอินบ่อย ๆ อาจถูกแพลตฟอร์มมองว่าเป็นสัญญาณผิดปกติและทำให้ต้องยืนยันเพิ่มเติม ดังนั้นควรหลีกเลี่ยงการล็อกอินใหม่โดยไม่จำเป็น
ถูกบล็อกครั้งเดียวแล้วทั้งชุดหยุดทำงาน
อีกความล้มเหลวหนึ่งเกิดขึ้นแบบเป็นกลุ่มอย่างฉับพลัน โดยงานจำนวนมากส่งผลลัพธ์ไม่ได้พร้อมกัน เว็บไซต์ไม่จำเป็นต้องตอบกลับด้วยการปฏิเสธที่ชัดเจน บ่อยครั้งจะส่งเนื้อหาที่ลดทอนลงหรือหน้าเปล่า และ Agent ยังคงทำงานต่อด้วยข้อมูลที่ไม่มีความหมาย จนปัญหาไปปรากฏในขั้นตอนข้อมูลภายหลัง
เมื่อเกิดกรณีนี้ สิ่งแรกคือต้องแยกให้ออกว่าถูกบล็อกหรือเป็นความผิดพลาดทั่วไป หากสภาพแวดล้อมกลุ่มเดียวกันเริ่มผิดปกติพร้อม ๆ กันในช่วงเวลาใกล้เคียง มีความเป็นไปได้สูงว่าปัญหาอยู่ที่ชั้นสภาพแวดล้อม การ retry ต่อไปจะยิ่งขยายผลกระทบ จึงควรหยุดและแยกสภาพแวดล้อมชุดนั้นก่อน แล้วค่อยย้อนหาสาเหตุที่กระตุ้น
จุดกระตุ้นที่พบบ่อยมีสามทิศทาง: หลายสภาพแวดล้อมใช้ fingerprint configuration ที่ซ้ำกันมาก เช่น WebGL, Canvas, รายการฟอนต์ หรือเวอร์ชัน engine แทบเหมือนกัน; exit IP, เขตเวลา และภาษาไม่สอดคล้องกัน เช่น ใช้ IP สหรัฐฯ แต่ตั้งเขตเวลาเอเชีย; หรือช่วงห่างของการทำงานสม่ำเสมอเกินไปจนจังหวะเองกลายเป็นลักษณะเฉพาะ ควรตรวจให้ค่าต่าง ๆ สอดคล้อง ควบคุมจังหวะ และเก็บ log ทั้งสถานะสภาพแวดล้อมกับผลลัพธ์ของงาน เพื่อให้เห็นสัญญาณก่อนความล้มเหลวจะลามทั้งชุด
แยกชั้นนี้ออกมาต่างหาก
โปรเจกต์ที่มีความพร้อมสูงมักแยกสภาพแวดล้อมเบราว์เซอร์ออกจาก Agent และจัดการเป็นอีกชั้นหนึ่ง: Agent รับผิดชอบการวางแผนและการตัดสินใจ ชั้นสภาพแวดล้อมรับผิดชอบตัวตนและสถานะ ส่วนชั้น execution ยังคงใช้ Playwright หรือ Puppeteer เมื่อแยกแล้ว ก็มีจุดจัดการที่ชัดเจนว่าสถานะตัวตนน่าเชื่อถือหรือไม่ กู้คืนสถานะได้หรือไม่ และงานแต่ละงานถูกแยกจากกันจริงหรือไม่
เมื่อมองย้อนกลับ ความล้มเหลวทั้งสี่ประเภทมีจุดร่วมเดียวกัน คือไม่ได้อยู่ในโมเดลและไม่ได้อยู่ในตรรกะของสคริปต์ แน่นอนว่าโมเดลและโค้ดยังต้องปรับปรุงต่อไป แต่สิ่งที่ตัดสินว่าระบบอัตโนมัติจะทำงานได้เสถียรในระยะยาวหรือไม่ มักเป็นชั้นที่อยู่ลึกลงมานี้
เนื้อหานี้มีไว้เพื่อแบ่งปันงานวิจัยทางเทคนิคและแนวปฏิบัติด้านการพัฒนา การใช้งานระบบอัตโนมัติควรเป็นไปอย่างถูกกฎหมายและสอดคล้องกับข้อกำหนด โดยปฏิบัติตามเงื่อนไขการให้บริการของแพลตฟอร์มเป้าหมายและกฎหมายหรือระเบียบท้องถิ่นที่เกี่ยวข้อง
