สอน Phone Agent ด้วยการสาธิต: บันทึกหน้าจอ สกิลใช้ซ้ำ และความปลอดภัย Android

สาธิตให้ Agent เข้าใจงาน ไม่ใช่สั่งให้จำทุกจุดแตะ

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

รายงานของ ITmedia วันที่ 22 กรกฎาคม 2026 ระบุว่า Record a Skill ใน Claude Cowork บันทึกงานพร้อมคำอธิบายด้วยเสียงแล้วแปลงเป็นสกิลที่ใช้ซ้ำได้ ขณะที่ การทดลองใช้งานที่ Android Authority เผยแพร่เมื่อวันที่ 21 กรกฎาคม 2026 อธิบายว่าระบบบันทึกหน้าจอระหว่างผู้ใช้เล่าเวิร์กโฟลว์ โดยมีเป้าหมายเพื่อลดการเขียนคำสั่งเดิมซ้ำสำหรับงานประจำ สัญญาณนี้ทำให้แนวคิดการสอนด้วยตัวอย่างจับต้องได้ แต่ไม่ได้ทำให้ Claude Cowork กลายเป็นระบบควบคุมโทรศัพท์ Android

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

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

จากการบันทึกหนึ่งครั้งสู่สกิลที่เรียกใช้ซ้ำ

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

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

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

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

การสร้างสกิลจากการสาธิตไม่เท่ากับการฝึก Phone Agent ในระดับโมเดล งานวิจัยและการฝึกอาจใช้สภาพแวดล้อมจำลองเพื่อพัฒนาความสามารถทั่วไป ส่วนสกิลจัดระเบียบงานเฉพาะสำหรับการใช้งานซ้ำ ความแตกต่างนี้อธิบายเพิ่มเติมใน PhoneBuddy-4B กับการฝึก Phone Agent: ทำไม Mock-App RL จึงสำคัญต่อ Android Agent เมื่อแยกสองเรื่องออกจากกัน ผู้ใช้จะประเมินได้ว่าต้องการปรับโมเดล สร้างเวิร์กโฟลว์ หรือเพียงบันทึกขั้นตอนเพื่ออ้างอิง

เหตุใดการเล่นภาพเดิมซ้ำจึงเปราะบางบน Android

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

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

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

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

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

บันทึกตัวอย่างอย่างไรให้ได้กฎโดยไม่เก็บข้อมูลลับ

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

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

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

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

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

ทดสอบ กำหนดสิทธิ์ และดูแลสกิลก่อนใช้งานจริง

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

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

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

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

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

มุมมองของ FoneClaw ต่อเวิร์กโฟลว์โทรศัพท์ที่ใช้ซ้ำได้

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

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

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

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

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