เบนช์มาร์ก Phone Agent บน Android: วิธีประเมินงานจริง ความปลอดภัย และการกู้คืนในปี 2026
คู่มือจากทีม FoneClaw สำหรับสร้างเบนช์มาร์ก Phone Agent บน Android ที่วัดผลลัพธ์จริง สิทธิ์ การอนุมัติ การกู้คืน trace และความน่าเชื่อถือ มากกว่าอัตราสำเร็จเพียงตัวเลขเดียว
- เบนช์มาร์ก Phone Agent บน Android ควรวัดทั้งผลลัพธ์ที่ตรวจได้และกระบวนการที่ควบคุมได้ ไม่ใช่ดูเพียงว่าเอเจนต์แตะหน้าจอคล้ายมนุษย์หรือทำขั้นตอนดูสมเหตุสมผล
- B-MoCA, MobileWorld, KnowU-Bench และ PhoneHarness ช่วยเปิดช่องว่างคนละแบบ ตั้งแต่การเปลี่ยน configuration, งานหลายแอป, personalization, consent, ไปจนถึง observable side effects และ execution traces
- ชุดทดสอบที่ใช้ได้จริงควรแยกแกน configuration, horizon, ความชัดของเจตนา, GUI เทียบ structured tools, ผลกระทบของ action, interruption และ recovery เพื่อรู้ว่าเอเจนต์พังตรงไหน
- ความสามารถปัจจุบันของ FoneClaw ให้ตัวอย่างงาน Android ที่นำไปออกแบบ test matrix ได้ เช่น current-screen attachment, floating access, task continuity, approvals, stopping, permission recovery และ 100+ built-in tools โดยบทความนี้เสนอวิธีทดสอบ ไม่ได้รายงานคะแนน benchmark ของ FoneClaw
เบนช์มาร์ก Phone Agent บน Android ควรวัดอะไร
เบนช์มาร์ก Phone Agent บน Android ที่มีประโยชน์ต้องตอบมากกว่าคำถามว่า “งานสำเร็จไหม” เพราะ phone agent ทำงานกับอุปกรณ์จริง ผู้ใช้จริง และผลกระทบจริง การแตะปุ่มถูกลำดับหรือพูดคำตอบดูน่าเชื่อถือยังไม่พอ สิ่งที่ต้องวัดคือเอเจนต์เข้าใจเป้าหมายหรือไม่ ใช้อำนาจเท่าที่จำเป็นหรือไม่ ทำ side effect ที่ถูกต้องหรือไม่ ผู้ใช้ควบคุมจุดสำคัญได้หรือไม่ และระบบตรวจผลกับกู้คืนได้อย่างไรเมื่อเงื่อนไขเปลี่ยน
จากมุมที่เราสร้าง FoneClaw งานหนึ่งอาจดูสำเร็จบนหน้าจอ แต่ยังไม่ผ่านในเชิง product หากส่งข้อความผิดผู้รับ เปิด setting ผิดช่วงเวลา ขอสิทธิ์เกินงาน หรือเดินหน้าต่อหลังผู้ใช้ปฏิเสธ เบนช์มาร์กที่ดีจึงต้องรวมทั้ง outcome และ process evidence: สถานะเริ่มต้นคืออะไร เอเจนต์เห็นอะไร ตัดสินใจอย่างไร ขออนุมัติเมื่อไร ลงมือด้วยเครื่องมือใด และตรวจผลอย่างไร
วิธีคิดนี้ทำให้การประเมิน Mobile Agent ใกล้กับ QA ของระบบจริงมากขึ้น เราต้องสร้างชุดทดสอบที่ทำซ้ำได้ มีข้อมูลตั้งต้นชัด มีผลลัพธ์คาดหวัง มีนโยบาย retry และมีบันทึก trace ที่อ่านย้อนกลับได้ สำหรับทีมที่กำลังสร้าง harness เพื่อให้ agent ปรับปรุงตัวเอง บทความ Phone Agent ที่พัฒนาตัวเอง: เวอร์ชันสกิล การทดสอบ และการย้อนกลับ จะช่วยต่อยอดเรื่องเวอร์ชัน การทดสอบ และการ rollback จากกรอบในบทความนี้
ภูมิทัศน์เบนช์มาร์ก Mobile Agent ปี 2026
ปี 2026 มีงาน benchmark ที่ช่วยให้เราเห็นว่า mobile agent พังได้หลายแบบ ไม่ควรนำคะแนนจากคนละ benchmark มารวมเป็น leaderboard เดียว เพราะแต่ละชุดทดสอบวัดโลกคนละใบ บางชุดเน้น configuration ของอุปกรณ์ บางชุดเน้นงานหลายแอป บางชุดเน้น personalization และ consent บางชุดเน้น side effects ที่ตรวจได้จากหลาย action surface
| Benchmark | สิ่งที่วัดเด่น | บทเรียนสำหรับ Phone Agent |
|---|---|---|
| B-MoCA | B-MoCA ใน PMLR 2026 กำหนด 131 งาน Android ประจำวัน และสุ่ม configuration ของอุปกรณ์ เช่น UI layouts และ language settings | Agent ต้อง generalize ข้ามภาษา layout และการตั้งค่าของเครื่อง ไม่ใช่จำหน้าจอจาก test device เดียว งานตรงไปตรงมามักง่ายกว่างานซับซ้อนตามผลที่ paper รายงานในบริบทของตนเอง |
| MobileWorld | MobileWorld จาก ACL 2026 มี 201 tasks ใน 20 applications งานเฉลี่ย 27.8 steps และ 62.2% เป็น multi-app พร้อมหมวด agent-user interaction และ MCP-augmented tasks | งานระยะยาวและข้ามแอปต้องวัด state, interruption และ handoff ไม่ใช่แค่คลิกสุดท้าย Paper รายงาน 51.7% สำหรับ agentic framework ที่ดีที่สุดและ 20.9% สำหรับ end-to-end model ที่ดีที่สุดใน setting ของ MobileWorld เอง |
| KnowU-Bench | KnowU-Bench preprint ครอบคลุม 42 general GUI tasks, 86 personalized tasks และ 64 proactive tasks โดยซ่อน user profile และเปิด behavioral logs | Personalization ต้องทดสอบการถามให้ชัด การขอ consent ก่อน proactive action และการยับยั้งหลังผู้ใช้ปฏิเสธ ความรู้จักผู้ใช้ไม่ควรกลายเป็นการทำเกินเจตนา |
| PhoneHarness | PhoneHarness preprint รวม GUI, CLI และ host-side tool actions และให้คะแนน observable side effects พร้อมบันทึก auditable execution traces | การประเมินต้องดูว่า action เกิดขึ้นจริงและตรวจได้ไหม ไม่ใช่ดูคำอธิบายของโมเดลอย่างเดียว การแยก execution harness ออกจาก benchmark ช่วยให้ทีมผลิตภัณฑ์ออกแบบ trace และ verification ได้เป็นระบบ |
กรอบเหล่านี้ยังชี้ว่า tool discovery เป็นส่วนหนึ่งของการทดสอบ หากเอเจนต์เลือกเครื่องมือผิดตั้งแต่ต้น task success ก็ไร้ความหมาย สำหรับมุมการค้นหา resource และการวัดความน่าเชื่อถือของเครื่องมือ อ่านต่อได้ที่ Agentic Resource Discovery คืออะไร: ค้นหาเครื่องมือเอเจนต์โดยไม่สับสนกับสิทธิ์บนมือถือ
หกมิติสำหรับชุดทดสอบ Android Phone Agent จริง
ชุดทดสอบที่ดีต้องแยกมิติของความยากออกจากกัน เพื่อรู้ว่าสาเหตุที่พังคืออะไร ไม่ใช่โยนงานยาว ๆ เข้าไปแล้วได้เพียงคำตอบว่า agent ทำไม่สำเร็จ มิติแรกคือ configuration variation: ภาษาเครื่อง layout, ขนาดหน้าจอ, dark mode, permission state, OEM skin และแอปเวอร์ชันต่างกัน เอเจนต์ที่ใช้ได้จริงต้องรับมือกับความต่างเหล่านี้ได้มากกว่าหน้าจอตัวอย่างเดียว
มิติที่สองคือ horizon: งานหนึ่งหน้าจอ งานหลายหน้าจอ และงานหลายแอปควรถูกแยกวัด มิติที่สามคือความชัดของเจตนา คำสั่งอย่าง “เปิด DND 30 นาที” ต่างจาก “เตรียมเครื่องให้พร้อมประชุม” เพราะอย่างหลังต้องตีความบริบทและถามกลับ มิติที่สี่คือ action surface: GUI, structured tools, host-side tools หรือ hybrid workflow มีความเสี่ยงและ trace ต่างกัน
มิติที่ห้าคือผลกระทบของ action งาน read-only เช่น อ่านหน้าจอหรือสรุป notification ควรแยกจาก reversible device control เช่น volume หรือ DND และแยกจาก external effects เช่น ส่งข้อความ โทรออก หรือแชร์ไฟล์ มิติที่หกคือ interruption และ recovery: ระหว่างงาน แอปอาจเปลี่ยนหน้าจอ สิทธิ์อาจถูกถอน มีสายเข้า หรือผู้ใช้อาจกดหยุด การทดสอบที่จริงจังต้องใส่เหตุการณ์เหล่านี้ไว้ ไม่ใช่ทดสอบเฉพาะเส้นทางเรียบที่สุด
ข้อควรระวังคือจำนวน steps ไม่ได้บอกความยากทั้งหมด งานสามขั้นที่มีผลภายนอกและผู้รับคลุมเครืออาจยากกว่างานยี่สิบขั้นที่เป็น read-only ความยากที่ดีต้องผูกกับความเสี่ยง ความคลุมเครือของเจตนา ความสดของ device state และความสามารถในการตรวจผล
ตัวชี้วัดที่ต้องมากกว่า task success rate
Task success rate เป็นจุดเริ่ม แต่ไม่ใช่จุดจบของ ตัวชี้วัดความน่าเชื่อถือ Phone Agent ก่อนรายงานอัตราสำเร็จ ต้องกำหนด denominator ให้ชัด: นับงานที่ผู้ใช้ปฏิเสธอย่างถูกต้องเป็น fail หรือ pass? อนุญาต retry กี่ครั้ง? งานที่ agent หยุดเพื่อขอข้อมูลเพิ่มควรจัดเป็น partial, needs-user หรือ success? หากนโยบายเหล่านี้ไม่คงที่ ตัวเลข success rate จะเปรียบเทียบยาก
Scorecard ที่เราใช้คิดควรมีอย่างน้อยหกกลุ่ม หนึ่ง verified pass คือผลลัพธ์เกิดขึ้นจริงและตรงกับ expected state สอง partial checkpoints คือเอเจนต์ทำบางขั้นถูกแต่ยังไม่จบ สาม wrong side effects คือการเปลี่ยนแปลงผิดเป้าหมาย สี่ recovery quality คือระบบรู้วิธีกลับมาเมื่อสิทธิ์หรือหน้าจอเปลี่ยน ห้า latency และ cost คือเวลารวม จำนวน model/tool calls และการใช้ทรัพยากร หก trace quality คือมีบันทึกพอให้ทีมตามรอยและแก้ regression ได้
LLM judge มีประโยชน์ในการช่วยจัดหมวดหรืออ่าน trace จำนวนมาก แต่ผลสำเร็จของ phone task ต้องผูกกับ observable side effects และหลักฐานจากระบบ เช่น setting เปลี่ยนจริงไหม draft ถูกสร้างไหม ข้อความถูกส่งหรือยังรออนุมัติไหม PhoneHarness เน้นแนวคิด side-effect verification และ auditable traces ซึ่งใกล้กับสิ่งที่ product QA ต้องใช้ในโลกจริง
เมื่อมี approvals, permissions และ audit เข้ามา scorecard ต้องผูกกับตัวตนและเครื่องมือด้วย บทความ ตัวตนของเอเจนต์ AI: สิทธิ์ การอนุมัติแยกตามเครื่องมือ และบันทึกตรวจสอบบน Android ขยายวิธีคิดเรื่อง identity, permission และ trace ที่จำเป็นต่อการวัดความน่าเชื่อถือของ agent action
ทดสอบการอนุมัติ สิทธิ์ การยับยั้ง และการหยุดงาน
เบนช์มาร์ก AI Agent 2026 ต้องให้ safety behavior เป็นส่วนหนึ่งของคะแนน ไม่ใช่ภาคผนวกหลัง task success งานที่ดีควรวัดว่า agent ขอ authority เท่าที่จำเป็นหรือไม่ ขออนุมัติก่อน action ที่มีผลจริงหรือไม่ ถามให้ชัดเมื่อเจตนาคลุมเครือหรือไม่ และหยุดเมื่อผู้ใช้ปฏิเสธหรือกด stop ได้อย่างสะอาดหรือไม่
KnowU-Bench มีประโยชน์ตรงที่ทดสอบ clarification, proactive consent และ restraint after rejection ในบริบท personalization สิ่งนี้สำคัญมากบนโทรศัพท์ เพราะ agent ที่รู้พฤติกรรมผู้ใช้อาจคาดเดาได้ดีขึ้น แต่ต้องแยก “เดาได้” ออกจาก “ได้รับอนุญาตให้ทำ” หากผู้ใช้ปฏิเสธข้อเสนอ ระบบควรบันทึกสถานะและไม่ไล่ทำทางอ้อมด้วยเครื่องมืออื่น
การทดสอบ approval ควรดูทั้ง timing และ content จุดอนุมัติควรเกิดก่อนผลกระทบจริงและบอกผู้ใช้ว่าเป้าหมายคืออะไร เหตุผลคืออะไร ข้อมูลใดถูกใช้ และผลลัพธ์จะเป็นอะไร หากต้องการมุมการออกแบบหน้าจอยืนยันโดยเฉพาะ บทความ UX การอนุมัติ AI Agent บนมือถือ: ออกแบบจุดยืนยัน เหตุผล และทางกู้คืนให้ผู้ใช้ควบคุมได้ อธิบายภาษาของ approval ที่ใช้ได้จริงบนมือถือ
สุดท้ายต้องทดสอบ stop และ audit พร้อมกัน การหยุดที่ดีต้องหยุดงานที่กำลังทำจริง ไม่ใช่แค่หยุดการพูดของ agent และบันทึกหลังหยุดต้องแสดงว่าอะไรยังไม่เกิด อะไรเกิดแล้ว และต้องกู้คืนอย่างไร
เราจะประเมินงาน Phone Agent ปัจจุบันของ FoneClaw อย่างไร
ใน FoneClaw เรามอง benchmark เป็นวิธีเรียนรู้จากระบบที่ส่งให้ผู้ใช้ ไม่ใช่ป้ายคะแนนเพื่อประกาศตัวเลขลอย ๆ ข้อมูลดาวน์โหลด FoneClaw ล่าสุด แสดงความสามารถปัจจุบันพร้อม floating assistant, current-screen attachment, task continuity, approvals, stopping, permission recovery, งาน DND, volume, meeting-mode, screenshot reliability และ quick actions สิ่งเหล่านี้ให้พื้นที่ทดสอบ state, context, approval และ recovery ได้ชัดมาก
ชุดทดสอบสำหรับ FoneClaw ควรเริ่มจาก read-only state tests เช่น แนบหน้าจอปัจจุบันแล้วให้ agent สรุปสิ่งที่เห็น ตรวจว่า observation สดหรือเป็นหน้าจอเก่า และดูว่าเมื่อผู้ใช้เปลี่ยนหน้าจอ agent ขอบริบทใหม่ถูกจังหวะหรือไม่ กลุ่มที่สองคือ reversible device-control tests เช่น DND, volume, Bluetooth หรือ screenshot งานเหล่านี้ควรวัดการตรวจสถานะก่อนทำ การอนุมัติตามความเสี่ยง และการยืนยันผลหลังทำ
กลุ่มที่สามคือ external-effect approval tests เช่น messaging, calendar, tasks หรือ calls ที่เกี่ยวกับคนอื่นหรือข้อมูลจริง งานกลุ่มนี้ต้องมีผู้รับหรือเป้าหมายชัด มีเนื้อหาครบ และมีจุดอนุมัติก่อนผลกระทบเกิดขึ้น กลุ่มที่สี่คือ permission loss and recovery เช่น ปิด permission ระหว่างงาน ให้ agent ต้องอธิบายสิ่งที่ขาด เปิดเส้นทางแก้ และกลับมาทำต่อได้เมื่อผู้ใช้อนุญาต
กลุ่มที่ห้าคือ current-screen change and stopping ให้เริ่มงานผ่าน floating assistant แล้วเปลี่ยนหน้าจอหรือกดหยุดกลางทาง ระบบควรรักษาสถานะงาน แยกสิ่งที่เสร็จแล้วออกจากสิ่งที่รอ และไม่ทำ action ต่อหลัง stop กลุ่มที่หกคือ capability breadth tests จาก หน้าฟีเจอร์ของ FoneClaw ซึ่งอธิบาย 100+ built-in tools และ governed Android workflows ในระดับผู้ใช้ เราจะใช้เป็น portfolio ของงานทดสอบ ไม่ใช่การประกาศคะแนน benchmark ในบทความนี้
ผู้ใช้ที่ต้องการตัวอย่างงาน audit ที่จับต้องได้สามารถเริ่มจากสุขภาพเครื่องและสิทธิ์ก่อน บทความ ตรวจสุขภาพโทรศัพท์ Android ด้วย AI: เช็กสิทธิ์สำคัญ แอปพิเศษ และแอปที่ซ่อนด้วย FoneClaw เป็นกรณีที่ดีสำหรับทดสอบ read-only, permission visibility และ recovery แบบไม่เสี่ยงเท่างานที่ส่งผลภายนอกทันที
สร้าง protocol ทดสอบ Phone Agent ที่ทำซ้ำได้
Protocol ที่ทำซ้ำได้ต้องเริ่มจากการ freeze environment ระบุ device, Android version, locale, app versions, permission state, network, account fixture และ retry policy ให้ครบ จากนั้นกำหนด initial state และ expected final state ของแต่ละงาน เช่น ก่อนทดสอบ DND สถานะต้องปิด หลังจบต้องเปิด 30 นาทีและมีหลักฐานยืนยันผล
ขั้นต่อไปคือสุ่มหรือเปลี่ยนเพียงหนึ่งแกนในแต่ละรอบ เช่น เปลี่ยนภาษา UI แต่คง task เดิม หรือเปลี่ยน permission state แต่คง device เดิม วิธีนี้ทำให้รู้ว่าความพังมาจากแกนใด ระหว่างทดสอบต้องบันทึก prompt, observation, tool call, approval, stop event, retry, latency, cost และ final verification ทุกครั้ง
หลังจบงาน ให้ classify ผลเป็น verified pass, partial, user-needed, recovered, wrong side effect, unsafe continuation หรือ blocked by environment พร้อมเหตุผลที่ตรวจได้ ขั้นสุดท้ายคือ publish limitations ของ test suite เช่น ใช้เครื่องกี่รุ่น แอปใด รุ่นใด ภาษาใด และไม่ได้ครอบคลุม OEM behavior แบบใด นี่ทำให้ผู้อ่านเข้าใจขอบเขตของคะแนนและนำ protocol ไปทำซ้ำได้อย่างซื่อสัตย์
สำหรับทีมที่เพิ่งเริ่ม ให้เลือก reversible starter test สามงาน: สรุปหน้าจอที่ผู้ใช้แนบ, เปิด DND แบบมีเวลาจบ, และกู้คืน permission ที่ปิดไว้ แล้วค่อยขยายไปยัง messaging, calendar, navigation หรือ workflows หลายแอป เมื่อ protocol เสถียร จึงค่อยใช้ benchmark เพื่อเทียบ release ต่อ release หรือเทียบ model/tool configuration ภายในระบบของตนเอง
แหล่งข้อมูล: บทความนี้อ้างอิง B-MoCA ใน PMLR, MobileWorld ใน ACL Anthology, KnowU-Bench preprint, PhoneHarness preprint, หน้าฟีเจอร์ของ FoneClaw และ หน้า Download ของ FoneClaw