การเข้าใจหน้าจอของ AI Agent บน Android: เลือก UI tree, ภาพหน้าจอ หรือใช้ร่วมกัน

เลือก UI tree, screenshot หรือทั้งสองสำหรับหน้าจอ Android

คำตอบตรงที่สุดคือให้เริ่มจากหลักฐานที่พอดีกับงาน ถ้างานต้องเลือกปุ่ม กรอกช่อง อ่านชื่อรายการ หรือดูสถานะที่แอปอธิบายไว้ชัดเจน ให้ใช้ UI tree หรือข้อมูลเชิงความหมายก่อน ถ้างานต้องเข้าใจสิ่งที่อยู่ในภาพ เช่น chart, map, canvas, รูปสินค้า, สีสถานะ หรือ layout ที่ไม่มีคำอธิบายชัด ให้ใช้ screenshot และคอมพิวเตอร์วิทัศน์ ถ้าหน้าจอมีทั้งปุ่มที่มีความหมายและบริบทภาพที่สำคัญ ให้ใช้ทั้งสองแบบแล้วตรวจความสอดคล้องก่อนลงมือ

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

เรามองเส้นทางเป็นสามแบบ แบบแรกคือ semantic-first ใช้โครงสร้างการช่วยการเข้าถึงเพื่ออ่าน text, role, state, action และ bounds แบบที่สองคือ visual-first ใช้ภาพหน้าจอเมื่อสิ่งสำคัญอยู่ในพิกเซล แบบที่สามคือ hybrid ใช้ UI tree เพื่อหาเป้าหมายและใช้ screenshot เพื่อยืนยันตำแหน่งหรือบริบทภาพ ก่อนเสนอ action ให้ผู้ใช้ตรวจ

สำหรับการควบคุมโทรศัพท์เต็มวงจรตั้งแต่เจตนา ข้อเสนอ การยืนยัน ไปจนถึงผลลัพธ์ อ่านต่อได้ที่ AI agent ควบคุมโทรศัพท์ Android: จากเจตนา สู่ข้อเสนอ การยืนยัน และผลลัพธ์ที่ตรวจได้ หน้านี้โฟกัสเฉพาะการเลือกหลักฐานหน้าจอที่เอเจนต์ควรใช้ก่อนลงมือ

Android accessibility tree บอกอะไรได้และบอกอะไรไม่ได้

Android accessibility tree คือโครงสร้างเชิงความหมายของหน้าต่างที่แอปเปิดเผยผ่านระบบ Accessibility แต่ละ node อาจมีข้อความ คำอธิบาย สถานะ focus, checked, enabled, clickable, selected, bounds, hierarchy และ action ที่ทำได้ เอกสาร AccessibilityNodeInfo ของ Android อธิบาย node เหล่านี้ในฐานะตัวแทนของเนื้อหาในหน้าต่าง accessibility

สำหรับเอเจนต์โทรศัพท์ Android ข้อมูลแบบนี้มีค่าเพราะ compact และ action-aware ถ้าปุ่มมี content description ว่า ส่ง ถ้าช่องข้อความมี label ชัด ถ้ารายการมี checked state หรือถ้าปุ่ม disabled อยู่ UI tree ช่วยให้เอเจนต์ไม่ต้องเดาจากภาพอย่างเดียว Bounds ยังช่วยเชื่อมจากสิ่งที่อ่านได้ไปยังตำแหน่งบนหน้าจอเมื่อ action ที่รองรับต้องแตะหรือเปิดรายการ

อย่างไรก็ตาม accessibility service เป็นเทคโนโลยีช่วยการเข้าถึงที่ผู้ใช้เปิดใช้และกำหนดค่าได้ ไม่ใช่ทางลัดทั่วไปสำหรับ automation ทุกแอป เอกสาร คู่มือ Android accessibility service ระบุความสามารถอย่างการตรวจเนื้อหาหน้าจอและการโต้ตอบแทนผู้ใช้ในบริบท assistive use cases โดยการอ่าน hierarchy ต้องมีการกำหนดค่า window-content retrieval ที่เหมาะสม

failure modes สำคัญมีอย่างน้อยสี่แบบ หนึ่ง แอปเรนเดอร์ด้วย canvas หรือ WebView จน node ไม่สะท้อนสิ่งที่เห็นจริง สอง node ซ้ำกันหรือ label คลุมเครือ เช่น ปุ่มหลายอันชื่อ OK สาม node stale เพราะหน้าจอเปลี่ยนหลัง inspection สี่ content description ผิดหรือขาด ทำให้ความหมายของปุ่มไม่ชัด นอกจากนี้บางหน้าจอมี overlay, dialog, keyboard หรือระบบแปลภาษาเข้ามาทับ ทำให้ hierarchy ที่อ่านได้ไม่ตรงกับสิ่งที่ผู้ใช้เห็นทั้งหมด

แนวทางที่เราใช้คือเชื่อ UI tree เมื่อ semantics ชัดและสอดคล้องกับงาน แต่หยุดหรือขอหลักฐานเพิ่มเมื่อ node ไม่พอ เช่น มีปุ่มหลายปุ่มชื่อเหมือนกัน หรือ app แสดงข้อมูลสำคัญเป็นภาพโดยไม่มี text ให้ตรวจ

เมื่อใดหลักฐานพิกเซลจำเป็นต่อเอเจนต์ Android

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

กรณีที่ต้องใช้ภาพหน้าจอบ่อยคือแผนที่ กราฟ ตารางภาพ canvas เกม เครื่องมือวาดรูป สินค้าใน shopping app ปุ่มไอคอนที่ไม่มีคำอธิบาย คิวอาร์โค้ด รูปถ่าย ใบเสร็จ หรือสถานะที่แยกด้วยสี เช่น แดง เขียว เทา Visual grounding ช่วยให้เอเจนต์เห็นความสัมพันธ์ที่ node tree อาจไม่บอก เช่น ปุ่มอยู่ใต้การ์ดสินค้าใด หรือข้อความ warning อยู่ใกล้ field ไหน

แต่ screenshot ไม่ได้บอก semantics โดยตรง OCR อ่านคำได้ แต่ไม่ได้พิสูจน์ว่าข้อความนั้นเป็นปุ่มหรือ action ใด ภาพเห็นปุ่มสีเขียว แต่ไม่รู้ว่ากดแล้วส่ง จ่ายเงิน ลบ หรือยืนยันอะไรกันแน่ นอกจากนี้การระบุตำแหน่งด้วยภาพของเอเจนต์มือถือยังเสี่ยงจาก orientation, display scale, animation, scrolling, keyboard, notification shade, overlay, capture timing และการเปลี่ยนแปลงหลังจับภาพ

failure modes ของ screenshot มีอย่างน้อยสี่แบบ หนึ่ง OCR อ่านผิดหรือข้ามข้อความเล็ก สองพิกเซลจับ state ที่กำลังเปลี่ยนระหว่าง animation สาม coordinate ที่ได้ใช้ไม่ได้หลังหน้าจอเลื่อนหรือหมุน สี่ข้อมูลส่วนตัวถูกจับมากเกินจำเป็น เช่น ข้อความ แชต อีเมล หรือรูปภาพในหน้าจอเดียวกัน อีกกรณีคือภาพเห็นผลลัพธ์แต่ไม่รู้ hidden state เช่น account, permission หรือ selected item ที่ระบบไม่ได้แสดงชัด

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

เปรียบเทียบ UI tree กับ screenshot ตามคุณภาพหลักฐาน

UI tree และ screenshot เป็นหลักฐานคนละชนิด UI tree เหมาะกับความหมายและ action ที่แอปประกาศไว้ ส่วน screenshot เหมาะกับสิ่งที่ผู้ใช้เห็นจริงในพิกเซล ทางเลือกที่ดีขึ้นกับคำถามของงาน ไม่ใช่ความเชื่อว่าแบบใดฉลาดกว่าเสมอ

เอกสาร UI Automator ของ Android แสดงคุณค่าของ selector ที่เสถียร visible text, content description, resource identifier และการรอ state อย่างชัดเจน แม้ FoneClaw ไม่ได้อ้างว่าใช้ UI Automator ภายใน หลักคิดนี้ช่วยอธิบายว่าทำไมโครงสร้างที่เสถียรจึงสำคัญกว่าการเดาจากภาพเมื่อมีข้อมูล semantics ดีพอ

สร้าง workflow ผสม semantic และ visual grounding

workflow ผสมที่ดีเริ่มจาก inspection ไม่ใช่ action ขั้นแรกอ่านข้อมูลหน้าจอเชิงโครงสร้างก่อน: หน้าต่างใดเปิดอยู่ มี node ใดสำคัญ ปุ่มไหน clickable ช่องไหน editable และสถานะใดเกี่ยวกับคำขอ ถ้า semantics ชัดและเป้าหมายไม่อ่อนไหว อาจเสนอ action ได้โดยไม่ต้องใช้ screenshot

ขั้นที่สองคือ detect gap ถ้าเป้าหมายอยู่ใน canvas, chart, map, รูปภาพ, icon-only control หรือมีหลาย node ชื่อซ้ำกัน ให้เอเจนต์อธิบายว่าขาดหลักฐานอะไร ไม่ควรกดจากความมั่นใจเทียม ตัวอย่างเช่น มีปุ่ม Add หลายจุดในหน้ารายการ หรือแอปแสดงสถานะเป็นสีโดยไม่มี label ให้ tree อ่าน

ขั้นที่สามคือ capture minimal image ใช้ screenshot เฉพาะเมื่อพิกเซลตอบคำถามจริง และถ้าเป็นไปได้ให้ผู้ใช้เลือกหน้าจอหรือบริบทที่ต้องการแนบ การใช้ภาพทั้งหน้าทุกครั้งอาจจับข้อมูลส่วนตัวเกินจำเป็น โดยเฉพาะแชต อีเมล รูปถ่าย หรือข้อมูลบัญชีที่อยู่ใกล้ ๆ เป้าหมาย

ขั้นที่สี่คือ reconcile เอเจนต์ควรเชื่อม node กับ pixel เช่น bounds ของปุ่มตรงกับตำแหน่งภาพหรือไม่ label ใน tree ตรงกับข้อความที่เห็นหรือไม่ overlay บังเป้าหมายหรือไม่ ถ้าหลักฐานขัดกัน เช่น tree บอกปุ่ม enabled แต่ภาพเห็นปุ่มเทา หรือภาพเห็นปุ่มแต่ tree ไม่มี action ควรหยุดและขอผู้ใช้ยืนยันหรือใช้ manual fallback

ขั้นที่ห้าคือ propose and approve โดยเฉพาะงานที่มีผลจริง เช่น ส่งข้อความ กดซื้อ ลบรายการ ยืนยันฟอร์ม หรือเปลี่ยนการตั้งค่า ข้อเสนอควรบอกเป้าหมาย หลักฐานที่ใช้ และผลที่จะเกิด ถ้าเป็นงานกรอกฟอร์มบน Android ที่มีข้อมูลส่วนตัว หน้า กรอกฟอร์มด้วย Gemini บน Android: ใช้ AI อย่างไรให้สะดวกและยังควบคุมข้อมูลได้ จะลงรายละเอียดการตรวจ field และข้อมูลก่อนกรอกได้ชัดกว่า

ขั้นสุดท้ายคือ act and verify หลังทำ action ต้องอ่าน fresh state อีกครั้ง ไม่ควรถือว่า tap สำเร็จเพียงเพราะ gesture ถูกส่งแล้ว หน้าจออาจเปลี่ยนช้า แอปอาจไม่ตอบสนอง หรือ action อาจเปิด dialog เพิ่ม Verification จึงควรใช้หลักฐานใหม่จาก tree, screenshot หรือทั้งสองตามความเหมาะสม

นำวิธีเลือกหลักฐานมาใช้กับงานหน้าจอปัจจุบันใน FoneClaw

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

เส้นทาง semantic-first ของเราพึ่งข้อมูลอย่าง get_screen_info และ cross_app_read_screen เมื่อคำถามอยู่ที่โครงสร้างปัจจุบัน เช่น หน้าจอไหนเปิดอยู่ มีปุ่มหรือช่องใดให้ใช้ได้ และสถานะของ control เป็นอย่างไร เส้นทางนี้เหมาะกับงานที่ต้องระบุ target จาก text, description, bounds หรือ hierarchy โดยไม่ต้องจับภาพหน้าจอเพิ่มเติม

เมื่อคำถามอยู่ในพิกเซล เราใช้ screenshot_take หรือ screenshot_open ตามบริบทที่ผู้ใช้เลือก Current product path ของ FoneClaw รองรับการแนบภาพ การวิเคราะห์ภาพที่จับมา การรักษา dimensions และ file reference สำหรับ follow-up รวมถึงการเตรียม multimodal request ให้เหมาะกับงาน ภาพจึงถูกใช้เพื่อแก้คำถามเชิงภาพ ไม่ใช่เป็นค่าเริ่มต้นสำหรับทุกงาน

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

รายละเอียดเครื่องมือและขอบเขตผู้ใช้ดูได้ที่ ฟีเจอร์ของ FoneClaw ซึ่งอธิบาย 100+ built-in tools ในระดับผลิตภัณฑ์ หากต้องการเรียนรู้วิธีเรียกผู้ช่วยแบบลอยและแนบบริบทหน้าจอปัจจุบันโดยตรง อ่าน ผู้ช่วย AI แบบลอย Android หน้าจอปัจจุบัน: แนบบริบท ตรวจขั้นตอน และควบคุมงานได้

ทดสอบการเข้าใจหน้าจอด้วยงาน Android ที่ย้อนกลับได้

การทดสอบที่ดีควรเริ่มจากหน้าจอที่ไม่เสี่ยง เช่น หน้า settings ที่ไม่มีข้อมูลส่วนตัวหรือรายการทดลองในแอปที่แก้กลับได้ เขียน expected target และ expected state ก่อน เช่น ต้องการหาปุ่มที่ปิดอยู่ เปิดเมนูหนึ่งรายการ หรือสร้าง note ทดสอบที่ลบได้ อย่าเริ่มจากการส่งข้อความ จ่ายเงิน ลบข้อมูล หรือเปลี่ยนบัญชี

ทดสอบ tree-only ก่อน ให้ FoneClaw อ่านข้อมูลหน้าจอและอธิบาย target ที่เห็น ถ้าตอบได้จาก semantics ให้ดูว่าชื่อ control, state และ bounds สอดคล้องกับหน้าจอหรือไม่ จากนั้นเพิ่ม screenshot เฉพาะเมื่อมีข้อเท็จจริงที่ tree ตอบไม่ได้ เช่น icon ไม่มี label หรือ layout กำกวม

ลองเปลี่ยน orientation, scroll, เปิด keyboard หรือทำให้หน้าจอเปลี่ยน state แล้วดูว่าเอเจนต์ตรวจหลักฐานใหม่หรือยัง ทดลอง interrupt หนึ่งครั้ง เช่น สั่งหยุดหรือเปลี่ยนเป้าหมายกลางทาง งานที่ดีควรรายงานว่าส่วนใดทำแล้ว ส่วนใดยังไม่ทำ และต้อง verify อย่างไร

สุดท้าย ตรวจผลหรือ undo ด้วย fresh state หนึ่งครั้ง การสำเร็จในหน้าจอเดียวไม่ได้พิสูจน์ว่าทุกแอป ทุก OEM หรือทุก Android version ใช้ได้เท่ากัน หากต้องออกแบบ benchmark จริง ให้ใช้แนวทางใน เบนช์มาร์ก Phone Agent บน Android: วิธีประเมินงานจริง ความปลอดภัย และการกู้คืนในปี 2026 และสำหรับมุม permission ลึกกว่า อ่าน Sandbox ของ AI Agent กับสิทธิ์บนมือถือ: ทำไม Agent ที่ปลอดภัยยังต้องมีขอบเขต