การดีบักไม่ใช่แค่โค้ด: ทำไมเอเจนต์ AI ถึงต้องคลิกปุ่มเพื่อแก้ปัญหา

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

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

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

ปัญหานี้เคยเกิดขึ้นโดยบังเอิญเมื่อผู้พัฒนาเขียนสคริปต์ขนาดเล็กเพื่อจับภาพหน้าจอของฟอร์ม 4D ที่กำลังทำงานแล้วนำมาทำเป็นภาพเคลื่อนไหว GIF สำหรับหน้า README โดยใช้เครื่องมือ 4d-capture-gif จากนั้นสังเกตเห็นว่า Claude Code เรียกใช้มันเพื่อการดีบัก เนื่องจากสคริปต์ดังกล่าวรายงานโครงสร้างของฟอร์มและตำแหน่งของปุ่มด้วย ทำให้เอเจนต์รู้ว่าจะต้องคลิกที่ตรงไหน สำหรับกรณีง่ายๆ วิธีนี้ใช้งานได้จริง แต่การใช้ภาพหน้าจอร่วมกับพิกัดไม่ใช่แนวทางที่ยั่งยืนในการพัฒนาต่อ

ทางออกที่ดีกว่าคือการอ่านต้นไม้ UI โดยตรง บนระบบปฏิบัติการ macOS สามารถเขียนสคริปต์ Accessibility API จากภาษา Python ผ่าน pyobjc ร่วมกับไลบรารีอัตโนมัติอื่นๆ ทำให้เอเจนต์สามารถคลิกที่องค์ประกอบที่ #37 ซึ่งคือปุ่มบันทึก แทนที่จะคลิกที่พิกัด (412, 260) แบบสุ่มเสี่ยง

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

ความสำเร็จด้านระบบอัตโนมัติเกิดขึ้นได้ทันทีโดยอาศัยรากฐานจากการเข้าถึง ซึ่งถือเป็นการจับคู่ที่ลงตัวและถูกต้องตามหลักการพัฒนาซอฟต์แวร์มานานหลายทศวรรษ โดยทาง Apple ได้ระบุแนวทางดังกล่าวไว้ในเซสชัน WWDC26 หัวข้อ Refine accessibility for custom controls ที่อธิบายถึงป้ายกำกับ ค่า การกระทำที่ปรับได้ และการกระทำที่กำหนดเอง รวมถึงเอกสารประกอบของ AppKit และไลบรารีการเข้าถึงอื่นๆ

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

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

ที่มา: Dev.to