การกำหนดเส้นทางความสามารถของ AI agent: AutoAttach, Suggest, Fallback และการเลือกเครื่องมือ Android ให้ถูกงาน

จากคำขอ Android ไปสู่ candidate ที่จัดอันดับได้

ลองเริ่มจากคำขอเดียว: “ช่วยดูหน้าจอนี้แล้วตั้งเตือนให้ฉันส่งไฟล์หลังประชุม” สำหรับ AI agent บน Android คำขอนี้ไม่ควรถูกส่งไปยังเครื่องมือแรกที่ชื่อคล้ายที่สุดทันที สิ่งที่ควรเกิดก่อนคือ การกำหนดเส้นทางความสามารถของ AI agent หรือการแปลงคำขอให้เป็นรายการ candidate ที่เป็นไปได้ เช่น แนบบริบทหน้าจอ สรุปสิ่งที่เห็น สร้างเตือนความจำ เปิดปฏิทิน หรือถามเวลาประชุมเพิ่มเมื่อข้อมูลไม่ครบ

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

เหตุผลที่ต้องมีขั้นนี้คือ agent ไม่ควรโหลดทุกเครื่องมือ ทุก Skill และทุก Plugin เข้าไปในบริบททุกครั้ง ทั้งเปลือง context ทำให้โมเดลสับสน และเพิ่มโอกาสเลือกทางผิด การจับคู่ความสามารถตามบริบทช่วยลดพื้นที่ค้นหา แต่การ matching ยังเป็นเพียงการเสนอเส้นทาง ไม่ใช่สิทธิ์ให้ลงมือทำ งานที่มีผลจริงยังต้องผ่าน activation, approval และ execution แยกกัน

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

เลือก AutoAttach, Suggest หรือ Fallback ให้ถูกจังหวะ

เมื่อได้ candidate แล้ว router ต้องเลือกโหมดที่เหมาะกับความมั่นใจและความเสี่ยง โหมดหลักมีสามแบบคือ AutoAttach, Suggest และ Fallback ทั้งสามคำนี้อยู่ในคนละจังหวะของงาน AutoAttach ช่วยแนบบริบทหรือ metadata ที่เกี่ยวข้อง, Suggest เสนอตัวเลือกให้ผู้ใช้หรือ agent ตรวจ, และ Fallback ช่วยเดินต่ออย่างปลอดภัยเมื่อเส้นทางหลักไม่พร้อม

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

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

Fallback ใช้เมื่อเส้นทางหลักขาด ไม่ตรงนโยบาย หรือ confidence ต่ำ เช่น ไม่มี Skill ที่รองรับงานนั้น Plugin ที่ต้องใช้ยังไม่เปิดใช้ สิทธิ์ Android ถูกปฏิเสธ หรือ target มีหลายรายการชื่อคล้ายกัน Fallback ที่ดีไม่ใช่การข้าม policy แต่เป็นการเสนอทางเลือกที่ปลอดภัยกว่า เช่น ถามข้อมูลเพิ่ม เปิดหน้าตั้งค่าสิทธิ์ เปิดแอปให้ผู้ใช้เลือกเอง หรือบันทึก draft แทนการส่งจริง

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

แยก discovery, activation, approval และ execution

กลไก capability routing จะปลอดภัยขึ้นเมื่อมองเป็น state machine ไม่ใช่ปุ่มเดียวที่ชื่อ “ทำงาน” ลำดับที่ควรแยกคือ discovery, attachment, installation หรือ acquisition เมื่อเกี่ยวข้อง, activation, approval, execution, result และ recovery แต่ละ state มีเงื่อนไขของตัวเองและไม่ควรถูกยุบรวมเพราะโมเดลทายว่าความสามารถนั้นน่าจะเหมาะ

Discovery คือการพบว่ามี resource หรือความสามารถที่อาจช่วยงานได้ ตัวอย่างในวงการกว้างคือ Agent finder ของ GitHub Copilot ซึ่งค้นหาและจัดอันดับ resource ที่เกี่ยวข้องตาม registry และการตั้งค่าที่กำกับไว้ ประเด็นที่ควรนำมาใช้กับมือถือคือการค้นพบไม่เท่ากับติดตั้ง และการจัดอันดับไม่เท่ากับเปิดใช้

โลกของ Agent Plugins ก็เดินไปทางเดียวกัน บทความ Google Developers เรื่อง Agent Plugins อธิบาย specification สำหรับบรรจุ Agent Skills และ MCP servers พร้อม metadata ที่ใช้ร่วมกันได้ Packaging แบบนี้ช่วยให้ระบบเข้าใจ identity และความสามารถได้ดีขึ้น แต่ metadata เป็นข้อมูลสำหรับพิจารณา ไม่ใช่ใบอนุญาตให้ไว้ใจหรือ execute ทันที

Attachment คือการแนบข้อมูลที่เกี่ยวข้องเข้ากับคำขอ เช่น หน้าจอปัจจุบัน metadata ของเครื่องมือ หรือ context จากงานเดิม Activation คือการเปิดใช้ความสามารถหลังผ่านการตรวจ เช่น dependency พร้อม นโยบายผ่าน และผู้ใช้ยืนยัน ส่วน approval คือการอนุญาต action เฉพาะครั้ง เช่น ส่งข้อความ เพิ่มนัดหมาย หรือเปิดการนำทาง Execution จึงเกิดหลังจากนั้น และต้องมี result ที่ตรวจได้

เมื่อ state เหล่านี้แยกกัน ปัญหา false positive จะถูกควบคุมได้ดีขึ้น Plugin ที่ชื่อใกล้เคียงอาจถูกค้นพบแต่ยังไม่ติดตั้ง Skill ที่ช่วยงานได้อาจถูก preview แต่ยังไม่เปิดใช้ เครื่องมือที่เปิดอยู่แล้วอาจยังต้องขอ approval สำหรับ action สำคัญ นี่คือเส้นแบ่งที่ทำให้ phone agent ทำงานเร็วขึ้นโดยยังรักษาการควบคุมของผู้ใช้

ใช้ manifest, dependency, context และ confidence อย่างปลอดภัย

การ routing ที่ดีต้องมี input ที่มีโครงสร้างพอให้ตรวจได้ Manifest ช่วยบอก identity, capability, entry point และขอบเขตของ Plugin หรือ Skill แต่ manifest อย่างเดียวไม่ได้ทำให้ความสามารถนั้นน่าเชื่อถือทั้งหมด Router ต้องดู dependency ด้วย เช่น ต้องมีแอปใดติดตั้งอยู่ ต้องใช้ permission ใด ต้องใช้บัญชีหรือ network หรือไม่ และ dependency เหล่านั้นอยู่ในสถานะพร้อมใช้งานจริงหรือเปล่า

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

Confidence ควรถูกใช้เป็นสัญญาณให้เลือกระหว่าง AutoAttach, Suggest และ Fallback ไม่ใช่เป็นปุ่มลัดไปสู่ execution ถ้า confidence สูงและผลคือการแนบบริบทที่ผู้ใช้เริ่มเอง AutoAttach เหมาะสม แต่ถ้า confidence สูงในงานที่มีผลจริง เช่น โทรออกหรือส่งข้อความ ก็ยังต้องผ่าน approval ถ้า confidence ต่ำแต่มี candidate ที่น่าจะช่วยได้ Suggest จะปลอดภัยกว่า ถ้าไม่มี candidate ที่พร้อมใช้งาน Fallback ควรพาไปยังขั้นตอนกู้คืน

อีกจุดที่เราให้ความสำคัญใน FoneClaw คือ atomic capability snapshot เมื่อ refresh ความสามารถหรือ dependency มีปัญหา ระบบควรรักษาชุดความสามารถล่าสุดที่ยอมรับแล้วไว้แทนการเปิดสภาพครึ่ง ๆ กลาง ๆ วิธีนี้ช่วยให้ผู้ใช้ไม่เจอภาวะที่ router เห็นความสามารถบางส่วนแต่ execution ใช้จริงไม่ได้

กู้คืนเมื่อความสามารถหาย เก่า ถูกปฏิเสธ หรือกำกวม

ความล้มเหลวของ routing ควรถูกออกแบบเป็นเส้นทางวินิจฉัย ไม่ใช่การ retry วนไปเรื่อย ๆ กรณีแรกคือ missing capability: งานที่ผู้ใช้ขอไม่มี built-in tool, Skill, Workflow หรือ Plugin ที่รองรับ Router ควรบอกทางที่ทำได้ เช่น สร้างบันทึกแทน ทำ checklist ให้ผู้ใช้ หรือเปิดแอปที่เกี่ยวข้องให้เลือกเอง

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

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

กรณีสุดท้ายคือ ambiguity เช่น ผู้รับชื่อซ้ำ มีหลายไฟล์ชื่อคล้ายกัน หรือมีหลาย route ที่ทำงานได้แต่ผลลัพธ์ต่างกัน ตรงนี้ Suggest ดีกว่า AutoAttach เพราะผู้ใช้ควรเห็นตัวเลือก การกู้คืนที่ดีจึงแยกให้ชัดว่าอะไรคือ no-match, false positive, permission issue และ ambiguous target แล้วให้การตอบสนองคนละแบบ

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

การ routing ที่กำกับได้ใน FoneClaw

ที่ FoneClaw เราสร้าง capability routing จากบทเรียนเดียวกัน: ผู้ใช้ต้องการให้ AI ลดภาระการคิดและการแตะหน้าจอ แต่ยังต้องเห็นว่าระบบกำลังเลือกความสามารถอะไรและจะทำอะไรต่อ FoneClaw เป็น Android phone-agent runtime ที่มี 100+ built-in tools พร้อมเส้นทาง Skills, Workflows และ Plugins ที่แยก lifecycle ชัดเจน

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

ในเส้นทาง Plugin เราใช้ plugin activation review เพื่อให้การเปิดใช้เป็น state ที่มองเห็นได้ ไม่ใช่การติดตั้งเงียบหรือการเชื่อว่า resource ที่พบแล้วใช้ได้ทันที ส่วน Skill learning ใช้ preview และ confirmation ก่อนบันทึกเป็น draft ที่ยังไม่เปิดใช้ แนวทางนี้ทำให้ผู้ใช้เห็นว่าความสามารถใหม่กำลังเข้าสู่ระบบอย่างไร และมีเวลาตรวจว่ามันควรอยู่ใน workflow ของตัวเองหรือไม่

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

รายละเอียดความสามารถปัจจุบันของ FoneClaw ดูได้ที่ หน้าฟีเจอร์ของ FoneClaw ซึ่งอธิบายขอบเขตงานที่รองรับในภาษาผู้ใช้ หากต้องการลงลึกเรื่อง discovery และ trust ของ resource ก่อนเข้าสู่ routing อ่าน Agentic Resource Discovery คืออะไร: ค้นหาเครื่องมือเอเจนต์โดยไม่สับสนกับสิทธิ์บนมือถือ เพราะหน้านั้นเป็นเจ้าของประเด็น registry และความน่าเชื่อถือของ resource โดยตรง

เช็กลิสต์ 7 ข้อสำหรับออกแบบ capability router

หากคุณกำลังออกแบบหรือประเมิน capability router สำหรับ Android agent ให้ทดสอบด้วยทั้งกรณีที่ match ชัด false positive และ no-match อย่าดูเพียง accuracy ตอนเลือกถูก เพราะระบบที่ดีต้องรับมือได้เมื่อคำขอกำกวม ความสามารถหาย หรือผู้ใช้ปฏิเสธสิทธิ์

1. เริ่มจากคำขอจริงหนึ่งรายการ แล้วตรวจว่า router สร้าง candidate ที่เกี่ยวข้องได้ครบหรือไม่
2. ทดสอบ false positive ด้วยคำสั่งที่มีคำคล้ายกัน แต่ควรไปคนละเครื่องมือ
3. ทดสอบ no-match และดูว่า Fallback ถามเพิ่มหรือเสนอทางเลือกที่ปลอดภัยหรือไม่
4. ตรวจว่า AutoAttach แนบเฉพาะบริบทหรือ metadata ที่ผู้ใช้ตั้งใจให้ใช้ ไม่ execute action
5. ตรวจว่า Suggest แสดงเหตุผลและตัวเลือกพอให้ผู้ใช้ตัดสินใจได้
6. ตรวจ dependency, activation และ approval แยกกัน ไม่ให้ state หนึ่งแทนอีก state หนึ่ง
7. ตรวจ recovery evidence เช่น เปิดหน้าสิทธิ์ ขอข้อมูลเพิ่ม หยุดงาน หรือแสดงผลลัพธ์ที่ยังไม่เสร็จอย่างชัดเจน

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

สรุปคือการกำหนดเส้นทางความสามารถของ AI agent ไม่ใช่แค่การเลือก tool ที่ชื่อใกล้คำสั่งที่สุด แต่เป็น state machine ที่เริ่มจากบริบท จัดอันดับ candidate เลือก AutoAttach, Suggest หรือ Fallback เปิดใช้ความสามารถอย่างมีการตรวจ อนุมัติ action เฉพาะครั้ง ลงมือบน Android ที่รองรับ และกู้คืนอย่างเห็นได้เมื่อสภาพเครื่องไม่พร้อม นี่คือเส้นทางที่เราใช้วาง FoneClaw ให้เป็น phone agent ที่เร็วขึ้นโดยยังให้ผู้ใช้ควบคุมงานสำคัญได้ครบ