AI Agent Token Cost: ทำไมการทำงานบนมือถือแบบโลคัลจึงช่วยลดต้นทุน

ต้นทุนของ AI agent เริ่มตั้งแต่คำสั่งแรก

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

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

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

แหล่งข้อมูลราคาของผู้ให้บริการคลาวด์ เช่น ข้อมูลราคา API ของ OpenAI และ ข้อมูลราคา Vertex AI ของ Google Cloud สะท้อนหลักเดียวกันคือ ค่าใช้จ่ายขึ้นกับโมเดล ปริมาณข้อมูลเข้า ข้อมูลออก และรูปแบบการประมวลผล แต่ในโลก phone agent ยังมีอีกชั้นหนึ่งคือ “งานนั้นทำสำเร็จจริงบนเครื่องหรือไม่” ถ้าตอบได้แต่ทำไม่ได้ ต้นทุนก็ยังไม่จบ

โทเคนรั่วตรงไหนในงานมือถือหลายขั้นตอน

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

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

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

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

ผู้ช่วยบนคลาวด์อาจรู้มาก แต่ยังทำงานบนเครื่องไม่จบ

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

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

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

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

การทำงานใกล้เครื่องช่วยประหยัดได้เมื่อขอบเขตชัด

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

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

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

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

มุมมองของ FoneClaw: งานที่รองรับไม่ควรถูกคิดใหม่ทุกครั้ง

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

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

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

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

วิธีประเมินต้นทุนจริงของ phone agent

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

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

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

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

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