SeedRealtime Phone Agent แบบ Full Duplex: เสียงสองทางกับชั้นลงมือทำบน Android ที่ FoneClaw กำลังสร้าง

SeedRealtime และ Seeduplex เปลี่ยนอะไรให้ Phone Agent

SeedRealtime Phone Agent แบบ Full Duplex เป็นหัวข้อที่น่าสนใจสำหรับคนสร้าง phone agent เพราะมันแตะปัญหาหลักของการสั่งงานด้วยเสียง: ผู้ใช้ไม่ได้พูดเป็นรอบสวยงามเสมอไป คนจริงหยุดคิด พูดแทรก เปลี่ยนใจ แก้คำสั่งกลางประโยค และอยู่ในสภาพแวดล้อมที่มีเสียงอื่นปนอยู่ Full-duplex voice AI จึงสำคัญเพราะทำให้ระบบสามารถฟังระหว่างพูด แทนการรอให้ฝ่ายหนึ่งพูดจบทั้งหมดก่อนอีกฝ่ายตอบ

ByteDance Seed เผยแพร่ บทความแนะนำ Seed Full-Duplex Speech LLM เมื่อวันที่ 9 เมษายน 2026 โดยอธิบาย Seeduplex เป็นกรอบการทำงาน native listen-while-speaking และระบุการปรับปรุงด้านการกดเสียงรบกวน การจับจุดจบประโยค และการรับมือการขัดจังหวะ พร้อม rollout ใน Doubao ส่วน หน้าโมเดล SeedRealtime ของ ByteDance Seed ทำให้เห็นว่า SeedRealtime อยู่ในกลุ่มโมเดลปัจจุบันของ Seed ในบริบทเสียงเรียลไทม์

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

Full-duplex voice AI จัดการการหยุด เสียงรบกวน และการขัดจังหวะอย่างไร

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

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

อีกประเด็นคือ barge-in หรือการที่ผู้ใช้พูดขัดระหว่างระบบกำลังตอบ ถ้าเอเจนต์กำลังอ่านข้อเสนอแล้วผู้ใช้พูดว่า “หยุดก่อน เปลี่ยนผู้รับเป็นทีมขาย” ระบบต้องแยกว่าคำพูดนี้เป็นคำสั่งใหม่ เสียงพื้นหลัง หรือคำยืนยันที่เกี่ยวกับงานเดิม งานวิจัย How Should LLMs Listen While Speaking? ชี้ว่าระบบ full-duplex ต้องเลือกวิธี route เสียงผู้ใช้ที่เข้ามาระหว่าง generation และมี tradeoff ระหว่างการผูกกับเสียงสดกับความทนทานต่อบริบทเดิม

ความเร็วของโมเดลก็เป็นส่วนหนึ่งของสมการ เสียงสองทางที่ดีต้องมี latency ต่ำพอให้ผู้ใช้รู้สึกว่าคุยได้จริง แต่ความเร็วอย่างเดียวไม่พอ สำหรับบริบท phone agent เราต้องเชื่อมความเร็วกับการควบคุมงานด้วย ถ้าสนใจประเด็น inference speed โดยเฉพาะ บทความ LLM 1000 TPS สำหรับเอเจนต์บนโทรศัพท์: เร็วขึ้นแล้วเปลี่ยนอะไร อธิบายว่าความเร็วของโมเดลเปลี่ยนประสบการณ์บนมือถืออย่างไรเมื่อจับคู่กับชั้น execution ที่ดี

ทำไมการสนทนาและการลงมือทำบน Android ต้องแยกชั้นกัน

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

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

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

สัญญาเจ็ดช่วงจากเสียงพูดถึงผลลัพธ์ที่ตรวจได้

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

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

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

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

เรากำลังสร้างชั้นลงมือทำของ FoneClaw อย่างไร

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

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

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

ในด้านงานจริง เครื่องมือปัจจุบันของ FoneClaw รองรับ selected governed Android actions เช่น Do Not Disturb, messaging ที่ต้องเห็นร่างและเงื่อนไขส่ง, dialer, navigation และ settings workflows บางส่วน ผู้ใช้ดูภาพรวมความสามารถได้จาก หน้าฟีเจอร์ของ FoneClaw และถ้าต้องการเข้าใจเส้นทางแนบบริบทหน้าจอปัจจุบันอย่างละเอียด บทความ ผู้ช่วย AI แบบลอย Android หน้าจอปัจจุบัน: แนบบริบท ตรวจขั้นตอน และควบคุมงานได้ จะช่วยแยกการแนบบริบทโดยผู้ใช้ออกจากการเฝ้าดูต่อเนื่อง

สถานการณ์ Voice Agent เรียลไทม์ที่ยังต้องมีจุดป้องกันก่อนลงมือ

สถานการณ์แรกคือ Do Not Disturb ระหว่างประชุม ผู้ใช้พูดว่า “เปิดห้ามรบกวนจนจบประชุมนี้” Voice Agent เรียลไทม์ที่ดีควรถามต่อถ้าเวลาจบไม่ชัด และเมื่อแปลงเป็น action บน Android แล้วควรแสดงว่าจะเปิดโหมดใด นานเท่าไร และจะกลับค่าเมื่อใด Full-duplex ช่วยให้ผู้ใช้พูดแทรกว่า “ไม่ใช่ชั่วโมงหนึ่ง แค่สามสิบนาที” ได้ลื่นขึ้น ส่วนชั้น execution ทำให้การตั้งค่าถูกอนุมัติและตรวจสถานะได้

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

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

สถานการณ์สุดท้ายคืองานหลายขั้นที่ถูกขัดจังหวะ เช่น ผู้ใช้เริ่มตั้งค่าโหมดประชุม แล้วมีสายเข้า หลังกลับมา ระบบต้องจำได้ว่างานรออะไร สิทธิ์ใดยังขาด และข้อเสนอเดิมยังสดพอหรือไม่ นี่คือเหตุผลที่เราให้ความสำคัญกับ task state และ recovery ใน FoneClaw เพราะ hands-free หรือ real-time ไม่ได้แปลว่างานบนโทรศัพท์จะปลอดความเสี่ยงโดยอัตโนมัติ

ความเป็นส่วนตัว แบตเตอรี่ ข้อจำกัดเสียงภาพ และสิ่งที่ต้องสร้างต่อ

Full-duplex voice AI เพิ่มความเป็นธรรมชาติ แต่ก็เพิ่มคำถามด้านความเป็นส่วนตัวและทรัพยากรด้วย ระบบที่ฟังระหว่างพูดต้องระวังไมโครโฟน เสียงพื้นหลัง และคำพูดที่ไม่ได้ตั้งใจให้เป็นคำสั่ง บนโทรศัพท์จริง การเปิดเสียงอย่างต่อเนื่องยังกระทบแบตเตอรี่ ความร้อน latency และความชัดเจนของ consent สำหรับ FoneClaw วันนี้ เราใช้ voice input และ current-screen context แบบผู้ใช้เริ่มเอง เพื่อให้บริบทของงานมีที่มาและจุดควบคุมชัดเจน

ด้านภาพก็ยังเป็นงานใหญ่ในอุตสาหกรรม บทความของ ByteDance Seed ระบุ visual input และ proactive interaction เป็น outlook สำหรับ Seeduplex ขณะที่งานวิจัย VideoFDB full-duplex audio-visual benchmark ชี้ว่า streaming audio-visual grounding ยังเป็นความท้าทายเฉพาะ และระบบที่ประเมินจำนวนมากใช้ visual streams ได้จำกัดเมื่อคำถามไม่ได้ถามภาพโดยตรง สำหรับ phone agent นี่แปลว่าการได้ยินอย่างเดียวหรือเห็นอย่างเดียวไม่พอ ต้องมีการผูกบริบทกับงานอย่างตั้งใจ

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

แหล่งข้อมูล: บทความนี้อ้างอิง บทความ Seed Full-Duplex Speech LLM ของ ByteDance Seed, หน้าโมเดล SeedRealtime, งานวิจัยเรื่องการฟังระหว่างพูดของ LLM, งานวิจัย VideoFDB, หน้าฟีเจอร์ของ FoneClaw และ หน้า Download ของ FoneClaw