Phone Agent ที่พัฒนาตัวเอง: เวอร์ชันสกิล การทดสอบ และการย้อนกลับ

Phone Agent ที่พัฒนาตัวเองปรับอะไร และไม่ต้องเปลี่ยนน้ำหนักโมเดลอย่างไร

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

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

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

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

งาน Self-Harness เปลี่ยนร่องรอยการทำงานเป็นข้อเสนอที่ทดสอบได้อย่างไร

งานวิจัยบอกอะไรเกี่ยวกับการปรับ Agent โดยไม่ฝึกโมเดลใหม่ งานวิจัย Self-Harness เสนอวงจรสามช่วง ได้แก่ ค้นหาจุดอ่อนจากร่องรอยการทำงาน สร้างข้อเสนอปรับชุดควบคุมภายในขอบเขต และตรวจสอบข้อเสนอก่อนยอมรับ จุดสำคัญคือการเปลี่ยนแปลงไม่ได้เริ่มจากความรู้สึกว่าควรแก้อะไร แต่เริ่มจากหลักฐานของขั้นตอนซึ่งนำไปสู่ผลล้มเหลว

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

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

ผู้เขียน Self-Harness รายงานว่าบน Terminal-Bench-2.0 อัตราผ่านของงานที่กันไว้สำหรับทดสอบดีขึ้นในโมเดลพื้นฐานคงที่สามรุ่น โดยปรับชุดควบคุมแทนน้ำหนักโมเดล ผลดังกล่าวเป็นหลักฐานตามการทดลองของงานวิจัยและช่วยชี้ว่าการออกแบบ harness มีผลต่อคุณภาพ Agent มาก อย่างไรก็ตาม งาน Phone Agent ยังต้องทดสอบความแปรผันเฉพาะ Android เช่น รุ่นแอป ภาษา สิทธิ์ และสถานะบัญชีเพิ่มเติม

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

FoneClaw พัฒนาการวางแผน ชุดควบคุม และสกิลที่ใช้ซ้ำ

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

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

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

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

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

วงจรเปลี่ยนแปลงตั้งแต่หลักฐานจนถึงการทยอยเปิดใช้และย้อนกลับ

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

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

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

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

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

การแก้ปัญหาลวงและการปรับเข้ากับตัวอย่างมากเกินไปเกิดขึ้นได้อย่างไร

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

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

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

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

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

รายการตรวจสอบก่อนปล่อยสกิลรุ่นใหม่สู่ Android จริง

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

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

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

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