AI Agent ที่เข้าใจบริบทส่วนตัวบนโทรศัพท์: จากสัญญาณงานสู่การลงมือบน Android

บริบทส่วนตัวคืออะไรเมื่อดูจากงานเดียวบนโทรศัพท์

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

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

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

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

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

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

ชั้นที่สองคือประวัติเซสชัน เช่น คำสั่งก่อนหน้า งานที่ยังค้างอยู่ ร่างที่เตรียมไว้ หรือผลจาก tool ล่าสุด ข้อมูลนี้ช่วยให้เอเจนต์ไม่ถามซ้ำและเดินงานต่อได้ แต่ควรหมดอายุเมื่อจบงานหรือเมื่อผู้ใช้เปลี่ยนหัวข้ออย่างชัดเจน ชั้นที่สามคือข้อมูลจากบริการที่เชื่อมไว้ เช่น ปฏิทิน อีเมล ไฟล์ หรือบริการ Google บางอย่างในบัญชีที่มีสิทธิ์ใช้งาน คำแนะนำ Gemini Connected Apps ของ Google แสดงว่าการเชื่อมบริการเพื่อคำตอบและงานที่เป็นส่วนตัวมีการควบคุมแยกและมีเงื่อนไขตามบัญชี ซึ่งเป็นเหตุผลที่เราควรแยก connected data ออกจากสิทธิ์ Android runtime

ชั้นที่สี่คือค่ากำหนด เช่น ภาษาที่ชอบ รูปแบบคำตอบ เส้นทางที่มักเลือก หรือระดับการอนุมัติที่ต้องการ ชั้นสุดท้ายคือความจำระยะยาวที่ใช้ข้ามงาน เช่น ข้อเท็จจริงถาวรบางอย่างเกี่ยวกับผู้ใช้หรือวิธีทำงานที่ผู้ใช้ยืนยันแล้ว คำแนะนำการปรับแต่งคำตอบของ Gemini แยกแหล่ง personalization อย่าง past chats, connected apps และ response instructions ไว้ชัดเจน จุดนี้ช่วยย้ำว่า memory, session context และ connected data ไม่ใช่สิ่งเดียวกัน

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

เลือกบริบทขั้นต่ำที่พอสำหรับงาน

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

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

แนวทางลดการขอ permission ของ Android Developers แนะนำให้ใช้ scoped alternatives และลดการขอสิทธิ์ที่ไม่จำเป็น ส่วน คำแนะนำ runtime permissions ของ Android อธิบายว่าแอปอยู่ใน sandbox และผู้ใช้สามารถปฏิเสธ dangerous permissions ได้ สำหรับ phone agent ความหมายเชิงปฏิบัติคือ workflow ต้อง degrade gracefully เมื่อไม่ได้สิทธิ์ เช่น ให้ผู้ใช้คัดลอกข้อความเอง เปิดหน้าตั้งค่าที่เกี่ยวข้อง หรือเตรียมร่างโดยยังไม่ส่ง

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

เปลี่ยนบริบทให้เป็นงาน Android ที่รองรับและตรวจได้

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

ใน FoneClaw โมเดลที่กำหนดค่าไว้รับหน้าที่ reasoning และ planning ส่วน FoneClaw เป็น Android phone-agent runtime ที่จัดการ governed execution บนเครื่อง งานเริ่มจากบริบทที่ผู้ใช้ให้มา เช่น หน้าจอปัจจุบัน คำสั่งในเซสชัน หรือผลจากงานก่อนหน้า จากนั้นระบบเลือกความสามารถที่รองรับใน 100+ built-in tools ตรวจว่า permission พร้อมหรือไม่ และใช้ approval policy ที่สัมพันธ์กับความเสี่ยงของ action

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

current-screen attachment, session continuity, approvals, stopping, permission recovery และ post-action state checks ทำให้สะพานจากบริบทไปสู่ action มองเห็นได้มากขึ้น นี่คือจุดที่บทเรียนจากการสร้าง FoneClaw ชัดที่สุด: ผู้ใช้ไม่ได้ต้องการให้ AI ควบคุมทุกแอปแบบเงียบ ๆ ผู้ใช้ต้องการงานที่ระบบรองรับ ทำในขอบเขตที่เห็นได้ หยุดได้ และอธิบายได้เมื่อ Android permission หรือสถานะแอปไม่พร้อม

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

รู้ทันบริบทเก่า เกินจำเป็น ขัดแย้ง และมีคำสั่งแฝง

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

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

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

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

ทดสอบผู้ช่วย AI แบบรู้บริบทด้วยงานที่ย้อนกลับได้

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

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

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

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

การออกแบบบริบทปัจจุบันของ FoneClaw และขั้นถัดไป

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

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

เรายังแยก temporary context, durable memory, Android permissions, connected-service settings, approval policy และ network path ออกจากกัน เพราะสิ่งเหล่านี้มีความหมายต่อความไว้วางใจไม่เหมือนกัน บริบทบางอย่างใช้เฉพาะงานนี้ บางอย่างอยู่ในเซสชัน บางอย่างเกี่ยวกับบัญชีหรือบริการออนไลน์ที่ผู้ใช้กำหนดค่าไว้ และบางอย่างเป็น permission บน Android ที่ต้องขอเมื่อถึงจุดใช้งาน การแยกให้ชัดทำให้ผู้ใช้เข้าใจได้ว่าควรเปิดอะไร ปิดอะไร และตรวจผลอย่างไร

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

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