ดีบักและกู้คืน AI Agent บนโทรศัพท์ Android: Runbook แยกสาเหตุ ลองซ้ำ และกู้คืนงาน

หยุดงานเอเจนต์ที่ล้มเหลวอย่างปลอดภัย

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

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

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

เก็บชุดหลักฐานขั้นต่ำ

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

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

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

แยกชั้นของความล้มเหลว

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

แนวทาง Android เรื่อง runtime permissions ย้ำว่าแอปต้องตรวจสิทธิ์ตอนใช้งาน และผู้ใช้สามารถปฏิเสธ ถอน หรือปฏิเสธถาวรได้ สำหรับปัญหาการเลือกความสามารถ เช่น AutoAttach, Suggest หรือ Fallback ที่พางานผิดทาง อ่านต่อได้ที่ การกำหนดเส้นทางความสามารถของ AI agent: AutoAttach, Suggest, Fallback และการเลือกเครื่องมือ Android ให้ถูกงาน

หาเหตุรากที่เกิดก่อนข้อความผิดพลาด

วงจร Detect–Attribute–Recover–Rerun ใช้ได้ดีกับโทรศัพท์เมื่อแปลเป็นภาษาปฏิบัติ: Detect คือระบุว่าอะไรผิดจากผลลัพธ์ที่คาดหวัง Attribute คือย้อนหาขั้นตอนแรกที่ทำให้เส้นทางผิด Recover คือซ่อมเงื่อนไขก่อนเริ่มใหม่ และ Rerun คือรันเฉพาะส่วนที่ปลอดภัยต่อการทำซ้ำ งานวิจัย AgentDebugX ชี้ว่าการเข้าใจทั้ง trajectory ช่วยหาสาเหตุได้ดีกว่าดู error สุดท้ายเพียงจุดเดียว แต่ผลวิจัยยังควรถูกใช้เป็นกรอบคิด ไม่ใช่หลักฐานประสิทธิภาพของผลิตภัณฑ์ใด

เริ่มจากปลายทางแล้วย้อนกลับ: ผลสุดท้ายผิดเพราะเครื่องมือรายงาน failure หรือเพราะผลลัพธ์จริงไม่ตรง? ถ้าเครื่องมือ failure ให้ดู precondition ก่อนเรียก เช่น สิทธิ์ หน้าจอ บัญชี เครือข่าย และค่า argument ถ้าผลลัพธ์จริงไม่ตรง ให้ดูแผนก่อนหน้า เช่น เลือกผู้รับผิด เลือกปฏิทินผิด หรือสรุปหน้าจอผิด

ตั้งชื่อสาเหตุพร้อมระดับความมั่นใจ เช่น “น่าจะเป็นสิทธิ์ Calendar ถูกถอน” หรือ “อาจเป็นโมเดลเลือกเครื่องมือผิดหลังตีความคำว่า ‘ส่งให้ทีม’ กว้างเกินไป” การตั้งชื่อแบบนี้ช่วยให้ recovery แคบลงและป้องกันการรันงานทั้งหมดใหม่ หากต้องการนำผลลัพธ์ไปทำเป็นชุดประเมิน อ่าน เบนช์มาร์ก Phone Agent บน Android: วิธีประเมินงานจริง ความปลอดภัย และการกู้คืนในปี 2026

กู้คืนโดยไม่ทำซ้ำผลลัพธ์ที่เกิดไปแล้ว

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

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

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

ใช้การควบคุมของ FoneClaw เพื่อวินิจฉัยและกู้คืน

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

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

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

ทำรายงานปัญหาที่ฝ่ายช่วยเหลือใช้ได้จริง

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

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

ป้องกันการเกิดซ้ำด้วยชุดทดสอบยอมรับ

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

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