ผู้ช่วย AI แบบลอย Android หน้าจอปัจจุบัน: แนบบริบท ตรวจขั้นตอน และควบคุมงานได้

เหตุผลที่ผู้ช่วยลอยช่วยลดการสลับแอปได้จริง

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

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

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

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

บริบทหน้าจอปัจจุบันคืออะไรและแนบเมื่อใด

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

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

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

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

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

ขอบเขตของหน้าต่างซ้อนและการอ่านหน้าจอบน Android

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

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

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

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

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

ขั้นตอนถาม ตรวจข้อเสนอ อนุมัติ และหยุดจากแอปปัจจุบัน

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

หลังรับคำขอ โมเดลควรสรุปข้อมูลที่นำมาใช้และเสนอขั้นตอนถัดไป ตัวอย่างอาจเป็น “สร้างนัดพบทีม วันพฤหัสบดี 14:00–15:00 น. ในปฏิทินงาน” หากข้อความบนหน้าจอไม่ได้ระบุเขตเวลาหรือมีหลายปฏิทิน ระบบต้องถามเพิ่ม ภาพตัวอย่างควรเปิดให้แก้ชื่อ เวลา ปฏิทิน และหมายเหตุก่อนที่ผู้ใช้จะกดปุ่มซึ่งระบุผลตรง ๆ ว่า “บันทึกนัดหมาย”

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

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

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

ค้นหาจากหน้าจอต่างจากเอเจนต์ที่ลงมืออย่างไร

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

Google อธิบายว่า Circle to Search ใช้ค้นหาข้อความ รูปภาพ หรือวิดีโอจากหน้าจอที่ผู้ใช้เลือก และแสดงผลเหนือหน้าจอปัจจุบัน ความสามารถนี้มีเฉพาะอุปกรณ์ Android บางรุ่นและเริ่มจากการกระทำของผู้ใช้ การใช้ภาพหน้าจอยังควบคุมได้จากการตั้งค่าผู้ช่วยดิจิทัล จึงเป็นตัวอย่างของการเลือกบริบทบนหน้าจอเพื่อค้นหา ไม่ใช่การเปิดให้บริการเฝ้าดูทุกแอปตลอดเวลา

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

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

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

ผู้ช่วยลอยและความต่อเนื่องบนเครื่องเดียวใน FoneClaw

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

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

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

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

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

รายการตรวจความสะดวก บริบท สิทธิ์ และการกู้คืน

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

1. พื้นที่หน้าจอ: ปุ่มลอยมีขนาดพอดี ย้ายหลบเนื้อหาได้ และแผงย่อไม่ปิดส่วนควบคุมหลักของแอปหรือไม่
2. การเริ่มรับบริบท: ผู้ใช้เป็นผู้แตะแนบหน้าจอหรือไม่ และมีสัญญาณชัดเจนว่าบริบทใดกำลังถูกใช้
3. ข้อมูลเท่าที่จำเป็น: ระบบใช้เฉพาะส่วนที่เกี่ยวข้องกับคำขอหรือดึงข้อมูลจากแอปและหน้าจออื่นเข้ามาโดยไม่จำเป็น
4. การตัดหน้าต่างซ้อน: ภาพหรือข้อมูลที่ส่งให้โมเดลตัดปุ่มและแผงของผู้ช่วยออกหรือไม่ เพื่อป้องกันการอ่านคำตอบของตัวเองปะปนกับแอป
5. ความสดใหม่: เมื่อเลื่อนหรือเปลี่ยนหน้า ระบบตรวจสถานะใหม่ก่อนกดปุ่ม สร้างรายการ หรือส่งข้อมูลหรือไม่
6. สิทธิ์: หน้าต่างอธิบายได้หรือไม่ว่าสิทธิ์ใดใช้แสดงผู้ช่วย สิทธิ์ใดใช้รับบริบท และสิทธิ์ใดจำเป็นต่อการลงมือ
7. ข้อเสนอและการอนุมัติ: ผู้ใช้เห็นเป้าหมาย ค่า และผลที่จะเกิดขึ้น พร้อมแก้ไขก่อนกดปุ่มที่ระบุการกระทำอย่างตรงไปตรงมาหรือไม่
8. การหยุด: ปุ่มหยุดยุติงานที่เลือกได้ทันทีและรายงานว่าส่วนใดทำเสร็จแล้วหรือยังไม่เริ่มหรือไม่
9. การกู้คืน: เมื่อสิทธิ์ขาด แอปเปลี่ยนหน้า หรือข้อมูลอ่านไม่ได้ ระบบให้แนบใหม่ เปิดสิทธิ์ ลองจากสถานะล่าสุด หรือเปลี่ยนไปแตะหน้าจอได้หรือไม่
10. การปิดงาน: หลังเสร็จ ผู้ใช้ล้างบริบท ย่อหรือปิดผู้ช่วย และตรวจผลที่สร้างไว้ได้ง่ายหรือไม่

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

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