สามยุคของระบบอัตโนมัติบนเบราว์เซอร์: การจำลองอินพุต การควบคุมผ่านโปรโตคอล และการตัดสินใจของโมเดล

ระบบอัตโนมัติบนเบราว์เซอร์มีมานานกว่ายี่สิบปี และแนวทางหลักเปลี่ยนผ่านมาสามยุค จุดที่น่าสนใจคือแต่ละยุคแก้ปัญหาคนละประเภท และเมื่อแก้ปัญหาหนึ่งได้ คอขวดก็ย้ายไปอยู่ที่อื่นอีกครั้ง

ยุคแรก: จำลองว่ามีคนขยับเมาส์ในระดับระบบปฏิบัติการ

ระบบอัตโนมัติยุคแรกไม่ได้ทำงานอยู่ภายในเบราว์เซอร์จริง ๆ แต่ทำงานในระดับระบบปฏิบัติการ สคริปต์เป็นฝ่ายขยับเมาส์และกดแป้นพิมพ์ ส่วนเบราว์เซอร์เพียงรับอินพุตเหล่านั้นแบบไม่โต้ตอบ

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

ปัญหาที่เหลือจากยุคนี้พูดง่าย ๆ คือ มันมองไม่เห็นหน้าเว็บ

ยุคที่สอง: ข้ามหน้าจอและสื่อสารกับเบราว์เซอร์โดยตรง

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

ต่อมาโซลูชันที่อิง browser debugging protocol ทำให้แนวทางนี้สมบูรณ์ยิ่งขึ้น Puppeteer และ Playwright สื่อสารกับ browser engine โดยตรงและเข้าถึงสถานะภายในของหน้าได้ เช่น รอให้ element พร้อมโดยอัตโนมัติ ดักและแก้ไข request เชื่อมต่อกับ browser instance ที่เปิดอยู่แล้ว ทำงานแบบ headless และเปิดหลาย context พร้อมกัน ความสามารถจำนวนมากที่ทุกวันนี้ถือเป็นเรื่องปกติได้รับการเติมเต็มในช่วงนี้

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

ยุคที่สาม: คนไม่ต้องเขียนทุกขั้นตอน และปัญหาก็ย้ายตำแหน่งอีกครั้ง

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

ดังนั้นปัญหาจุกจิกในอดีต เช่น จะเขียน selector อย่างไรหรือควรรอนานแค่ไหน จึงค่อย ๆ สำคัญน้อยลง แต่ปัญหาใหม่ก็เกิดขึ้นทันที

ประเด็นสำคัญคือ ตัวโมเดลเองไม่ได้เข้าถึงหน้าเว็บ สิ่งที่เปิดหน้า โหลด resource และรักษาสถานะ login ยังคงเป็นเบราว์เซอร์ ดังนั้นเมื่อ task เริ่มไม่เสถียร สาเหตุมักไม่ได้มาจากโมเดลตัดสินใจผิด แต่อยู่ที่ execution environment ด้านล่าง เช่น หลาย task ใช้เบราว์เซอร์ร่วมกันจน cookies และ cache ปะปนกัน ลักษณะ fingerprint คล้ายกันมากจน platform มองว่าทุก task มาจากเครื่องเดียวกัน มีการใช้ account ข้าม task ทำให้ความผิดปกติหนึ่งครั้งกระทบหลายงาน หรือจำเป็นต้องสร้าง environment ชั่วคราวและคืนทรัพยากรหลังใช้งานแต่ไม่มีระบบ scheduling แบบรวมศูนย์ โมเดลแก้คำถามว่า “ทำอย่างไร” และทำให้คำถามว่า “ทำที่ไหน” กลายเป็นคอขวดใหม่

ชั้นที่เพิ่มขึ้นมาในสถาปัตยกรรม

เมื่อมองทั้งสามยุคร่วมกัน ความแตกต่างไม่ใช่เรื่องว่าใครล้ำหน้ากว่า แต่คือแต่ละยุคต้องรับช่วงสิ่งที่ยุคก่อนหน้ายังแก้ไม่ได้ ในสองยุคแรก environment ไม่ใช่ปัญหาใหญ่ เพราะใช้งานเบราว์เซอร์บนเครื่องของตัวเอง แต่ในช่วง Agent งานมีจำนวนมาก ทำพร้อมกัน และทำแบบไม่มีคนเฝ้า จึงต้องจัดการ environment อย่างชัดเจน แต่ละ task ทำงานใน environment แยกจากกัน fingerprint และ session ไม่ปะปนกัน สถานะ login ถูกเก็บข้าม task เพื่อไม่ต้องเข้าสู่ระบบใหม่ทุกครั้ง IP เขตเวลา และภาษาได้รับการจับคู่เป็นชุดเดียวกัน และ environment ถูกสร้างกับคืนทรัพยากรตามความต้องการเหมือน computing resource

PurpleMark ทำงานอยู่ที่ชั้นนี้ โดยเปลี่ยน browser environment ให้เป็นทรัพยากรที่จัดตารางได้ เพื่อให้ Agent มุ่งเน้นที่ตรรกะของ task

จึงประเมินทางเลือกได้ง่ายขึ้น ระบบทดสอบระดับองค์กรและ script ที่มีอยู่แล้วสามารถอยู่บนแนวทางเดิม แอปพลิเคชัน Web ที่ซับซ้อนและต้องควบคุมในระดับ request เหมาะกับยุคที่ขับเคลื่อนด้วยโปรโตคอล ส่วนงานที่ให้โมเดลวางแผนและต้องทำงานอย่างเสถียรในระยะยาวยังใช้เทคโนโลยีของสองยุคแรกได้ แต่ต้องแก้ชั้น environment แยกต่างหาก หากสถานการณ์ของคุณต้องการให้การทำงานดูเหมือนผู้ใช้จริงเป็นคนดำเนินการ สิ่งนั้นไม่ใช่สิ่งที่ framework ระบบอัตโนมัติสามารถให้ได้ด้วยตัวมันเอง ไม่ว่าจะเป็นยุคใด

นอกเหนือจากแนวทางทางเทคนิคยังมีขอบเขตอีกข้อ การทำงานอัตโนมัติต้องปฏิบัติตามกฎของ platform เป้าหมายและกฎหมายท้องถิ่น สิ่งที่ทำได้ในเชิงเทคนิคไม่ได้หมายความว่าเหมาะสมในเชิงธุรกิจเสมอไป