MCP แบบ Stateless กับเวิร์กโฟลว์ Agent แบบ Stateful: คู่มือสถาปัตยกรรม Phone Agent Android

MCP 2026-07-28 เปลี่ยนอะไร

MCP แบบ Stateless กับเวิร์กโฟลว์ Agent แบบ Stateful เป็นคู่คำที่คนสร้าง agent ต้องเข้าใจพร้อมกัน หลัง ประกาศ Model Context Protocol 2026-07-28 แกนของ protocol ถูกวางเป็น stateless-first: request ควรอธิบายตัวเองได้มากขึ้น route ไปยัง instance ที่เข้ากันได้ได้ง่ายขึ้น และลดการพึ่ง session transport ที่ซ่อนสถานะไว้ใน server หนึ่งตัว

สิ่งที่เปลี่ยนในระดับมาตรฐานมีหลายส่วน รุ่นนี้พูดถึง stateless protocol core, MRTR, header routing, cacheable lists, authorization hardening และ extensions framework โดย Tasks ถูกจัดเป็น formal extension สำหรับงานที่ยาวกว่าการเรียกเครื่องมือครั้งเดียว แนวคิดจาก SEP-2575 Make MCP Stateless อธิบายการย้ายจาก mandatory initialization handshake ไปสู่ per-request metadata ที่ทำให้ server ตัดสินใจจากข้อมูลใน request ได้ชัดขึ้น

จากมุมที่เราสร้าง FoneClaw สิ่งนี้ไม่ได้ทำให้ agent กลายเป็นระบบไร้ความจำ ตรงกันข้าม มันบังคับให้เราวางเจ้าของสถานะให้ถูกที่ protocol transport ควร scale และ restart ได้ง่าย ส่วนสถานะของงานบน Android ควรอยู่ใน phone-agent host หรือ application layer ที่เข้าใจผู้ใช้ อุปกรณ์ สิทธิ์ การอนุมัติ และผลลัพธ์ ถ้าต้องการมุมเรื่องการค้นหาเครื่องมือและความน่าเชื่อถือของ resource discovery บทความ Agentic Resource Discovery คืออะไร: ค้นหาเครื่องมือเอเจนต์โดยไม่สับสนกับสิทธิ์บนมือถือ จะช่วยต่อภาพจาก protocol ไปสู่การเลือกเครื่องมืออย่างปลอดภัย

request lifecycle ของ MCP แบบ stateless ทำงานอย่างไร

ใน lifecycle แบบ stateless request ต้องพกข้อมูลที่จำเป็นต่อการประมวลผลมากขึ้น เช่น identity ที่เกี่ยวข้อง capabilities ที่คาดหวัง protocol version metadata สำหรับ routing และ reference ไปยัง state ที่ประกาศชัด หาก instance หนึ่ง restart หรือ load balancer ส่ง request ไปยัง instance อื่น ระบบยังควรตีความ request ได้จากข้อมูลที่มาพร้อมกัน แทนที่จะอาศัยความจำใน process เดิม

การค้นหาเครื่องมือและรายการ capability จึงควร cache ได้มากขึ้นเมื่อเหมาะสม ขณะที่ header routing ช่วยแยกปลายทางตาม protocol version หรือ feature set เอกสาร SEP-2575 วางหลัก per-request metadata เพื่อแทนสมมติฐานที่เคยเกิดจาก session negotiation ส่วน SEP-2567 Sessionless MCP via Explicit State Handles อธิบายวิธีใช้ state handles ที่ server สร้างขึ้นเพื่อให้ client ส่ง reference ต่อในคำขอถัดไป

สำหรับ phone agent จุดสำคัญคือ explicit handle เป็นเพียงตัวชี้ไปยังสถานะบางอย่าง ไม่ใช่ใบอนุญาตทำ action บนโทรศัพท์ การส่ง handle กลับไปยัง server อาจช่วย resume งานหรืออ้างถึงผลลัพธ์เดิมได้ แต่การส่ง SMS เปลี่ยน Do Not Disturb โทรออก หรือเปิด navigation ยังต้องมีสถานะผู้ใช้ สิทธิ์ Android การอนุมัติ และการตรวจผลใน application layer

ดังนั้น request lifecycle ที่ดีควรแยกข้อมูลสามชนิด: ข้อมูลที่ protocol ต้องใช้เพื่อ route และเข้าใจ request, reference ที่ช่วยอ้างถึง state เฉพาะงาน, และ application state ที่ phone agent ถือไว้เพื่อควบคุม action จริง เมื่อแยกสามส่วนนี้ชัด เซิร์ฟเวอร์ MCP ไร้สถานะจะ scale ง่ายขึ้นโดยไม่ลดความรับผิดชอบของงานบนอุปกรณ์

สถานะหกชนิดที่ Phone Agent ต้องถือเอง

เมื่อเราสร้างงาน Android ใน FoneClaw เราเรียนรู้เร็วมากว่าสถานะไม่ได้มีชนิดเดียว การพูดว่า agent เก็บ state หรือ server stateless ยังไม่พอ ต้องตอบให้ได้ว่า state ใดอยู่ที่ไหน อายุเท่าไร ใครอ่านได้ และใช้ทำ action อะไรได้ ตารางนี้คือแผนที่หกบัญชีสถานะที่ phone agent ควรถือหรือควบคุมเอง

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

Device state เป็นบัญชีที่หลอกง่ายที่สุด เพราะโทรศัพท์เปลี่ยนตลอดเวลา หน้าจออาจเปลี่ยน แอปอาจถูกปิด สิทธิ์อาจถูกถอน หรือผู้ใช้แก้ข้อมูลเองก่อน agent ลงมือ ดังนั้น phone agent ต้องอ่านสถานะอุปกรณ์ใหม่ก่อน action ที่มีผลจริง หากต้องการลงลึกเรื่องตัวตน สิทธิ์ และ audit trail บน Android บทความ ตัวตนของเอเจนต์ AI: สิทธิ์ การอนุมัติแยกตามเครื่องมือ และบันทึกตรวจสอบบน Android ขยายกรอบ governance ที่อยู่ใต้บัญชีสถานะเหล่านี้

MCP Tasks, MRTR, elicitation และการอนุมัติ

งาน agent จำนวนมากยาวกว่าการเรียกเครื่องมือครั้งเดียว MCP 2026-07-28 จึงทำให้ Tasks เป็น extension ที่เป็นทางการ และเปิดพื้นที่ให้ระบบติดตามงานระยะยาวผ่าน handle หรือ task reference ที่ชัดเจน ในขณะเดียวกัน MRTR และ elicitation ช่วยให้ client กับ server โต้ตอบกันเพื่อขอข้อมูลเพิ่มหรือจัดการคำตอบที่ต้องรอผู้ใช้ได้ โดยไม่ต้องดึง transport session ลับกลับมาเป็นที่เก็บทุกอย่าง

Tasks มีประโยชน์มากเมื่อเครื่องมือทำงานนาน เช่น ประมวลผลไฟล์ รอ service ภายนอก หรือเตรียมผลลัพธ์หลายขั้น แต่ task handle เป็นตัวชี้งาน ไม่ใช่การอนุญาตให้ทำทุกขั้นตอนต่อ ใน phone agent การอนุมัติควรเป็น record แยกที่บอกว่าใครอนุมัติอะไร ให้เครื่องมือใด ทำกับเป้าหมายใด และมีผลกระทบอย่างไร

ตัวอย่างบน Android คือการเตรียมข้อความ ผู้ใช้พูดเจตนา agent สร้างงานและอาจมี handle สำหรับขั้นตอนเตรียม draft แต่ก่อนส่งจริง approval record ต้องผูกกับผู้รับ เนื้อหา แอป SMS และผลที่จะเกิดขึ้น หาก task หมดอายุ หน้าจอเปลี่ยน หรือผู้ใช้แก้ข้อความเอง ระบบควรขอให้ตรวจใหม่ ไม่ใช้ approval เก่ากับ state ใหม่

แนวทางนี้ทำให้ Tasks, MRTR และ elicitation เป็นเครื่องมือของ workflow ที่โปร่งใส ไม่ใช่ทางลัดรอบการอนุมัติ งานยาวยังคง resume ได้ ส่วน action สำคัญยังต้องถูกผูกกับสถานะล่าสุดของผู้ใช้และอุปกรณ์

เวิร์กโฟลว์ Android แบบ stateful บน MCP ที่ stateless

ลองดูงาน SMS ที่ต้องเริ่มจากเสียงหรือผู้ช่วยแบบลอย ผู้ใช้พูดว่า “เตรียม SMS ถึงคุณนิดว่าฉันจะถึงช้าสิบนาที” ในสถาปัตยกรรมที่ดี agent host สร้าง task state ภายในก่อน: intent คือส่งข้อความ ผู้รับคือคุณนิด body คือแจ้งช้าสิบนาที action ที่มีผลจริงคือการส่ง SMS และต้องตรวจ default app, recipient, complete body และ stable send control ก่อนลงมือ

เมื่อเรียก connector หรือเครื่องมือผ่าน MCP แบบ stateless request จะพก metadata ที่จำเป็น เช่น tool capability, idempotency key, correlation ID, reference ไปยัง task state และข้อมูลที่ต้องใช้ในขอบเขตงาน ถ้า server instance เปลี่ยน request ยังคงตีความได้ แต่ host-side task ledger ยังคงเป็นเจ้าของบริบทงาน ผู้ใช้ และ approval ที่เกี่ยวข้อง

ก่อน action จริง FoneClaw-style host ต้องอ่าน device state ใหม่: แอป SMS เริ่มต้นพร้อมไหม ผู้รับที่เลือกตรงไหม มีสองซิมหรือ prompt เพิ่มไหม เนื้อหาถูกต้องไหม ปุ่มส่งเดียวเสถียรไหม หากครบ ระบบแสดง visible approval ให้ผู้ใช้เห็นสิ่งที่จะส่งและผลที่จะเกิดขึ้น หากอนุมัติแล้ว execution layer จึงทำงานโดยใช้ idempotency key เพื่อกันการส่งซ้ำเมื่อ retry เกิดขึ้น

หลัง action ต้อง verify ผลลัพธ์ เช่น ข้อความถูกส่งหรือ draft ยังรอผู้ใช้ ถ้า permission ขาดหรือ UI ไม่เสถียร ระบบพาไป recovery เช่น เปิดหน้าสิทธิ์ พาผู้ใช้รับช่วงบนหน้าจอ หรือเก็บงานไว้กลับมาทำต่อ ความสามารถปัจจุบันของ FoneClaw มีผู้ช่วยแบบลอย ความต่อเนื่องของงานบนเครื่องเดียว การกู้คืนสิทธิ์ และ quick actions เพื่อแสดงแนวคิด host-side state นี้ในผลิตภัณฑ์ Android ปัจจุบัน

บทความ ผู้ช่วย AI แบบลอย Android หน้าจอปัจจุบัน: แนบบริบท ตรวจขั้นตอน และควบคุมงานได้ อธิบายวิธีที่ FoneClaw ใช้บริบทหน้าจอแบบผู้ใช้เริ่มเองและความต่อเนื่องบนเครื่องเดียว ส่วนกรณีการโทรที่ต้องเลือกว่าจะใช้ protocol หรือ native dialer อย่างไรอยู่ใน AI Agent โทรออกได้ไหม: โทรศัพท์ผ่าน MCP เทียบกับการเปิดแอปโทรศัพท์ Android ด้วย FoneClaw

ขยายเซิร์ฟเวอร์ MCP โดยไม่เสียความน่าเชื่อถือของงานโทรศัพท์

ข้อดีของเซิร์ฟเวอร์ MCP ไร้สถานะคือการ deploy ง่ายขึ้น load balance ง่ายขึ้น restart ง่ายขึ้น และเหมาะกับ serverless หรือ pool หลาย instance มากขึ้น MCP Go SDK v1.7.0 เป็นตัวอย่าง SDK ที่รองรับ protocol 2026-07-28 และเอกสารของรุ่นนี้พูดถึง per-request metadata กับ server discovery สำหรับ lifecycle ใหม่ พร้อมเส้นทาง compatibility สำหรับ protocol รุ่นเก่า

แต่ reliability ของ phone task ไม่ได้เกิดจาก stateless transport อย่างเดียว งานที่มี external effect ต้องมี retry classification ที่ชัด แยกว่า request ใด retry ได้ทันที request ใดต้องตรวจผลก่อน และ request ใดต้องถามผู้ใช้ใหม่ SMS, การโทร, การเปลี่ยน setting และการแชร์ข้อมูลเป็นกลุ่มที่ต้องระวัง เพราะ retry ที่ซ้ำอาจสร้างผลซ้ำจริงบนโทรศัพท์หรือบริการปลายทาง

Idempotency key จึงเป็นแกนสำคัญ หาก request เดิมถูกส่งซ้ำเพราะ network timeout หรือ instance restart ระบบต้องแยกได้ว่านี่คือความพยายามเดียวกันหรือคำสั่งใหม่ Correlation ID ช่วยตามรอยข้าม agent host, MCP connector, Android tool และ audit log ส่วน result verification ช่วยบอกว่าควร retry, compensate, หรือพาผู้ใช้ไป recovery

กรณีเครื่องบันทึก AI เป็นตัวอย่างที่เห็นภาพ: บันทึกประชุมอาจกลายเป็นรายการ action บนโทรศัพท์ แต่แต่ละ action ต้องมี task state, approval และผลลัพธ์ของตัวเอง บทความ MCP สำหรับเครื่องบันทึก AI: เปลี่ยนโน้ตประชุมเป็นคำสั่งมือถือที่ยืนยันได้ ขยายกรณี recorder-to-action ที่ต้องแยก discovery, approval และ execution ออกจากกัน

ขอบเขตความปลอดภัยและเช็กลิสต์ย้ายระบบ

MCP 2026-07-28 รวม authorization hardening ไว้ใน release ภาพใหญ่ของการย้ายไป stateless จึงควรมาพร้อมการแยกขอบเขตความปลอดภัยให้ชัด Auth บอกว่า client หรือ connector มีสิทธิ์เข้าถึง service ใดในนามใคร Approval บอกว่าผู้ใช้ยอมให้ action เฉพาะงานใดเกิดขึ้น Device state บอกว่าตอนลงมือสภาพโทรศัพท์พร้อมหรือไม่ Audit บอกว่าหลังงานจบเกิดอะไรขึ้นจริง

สำหรับระบบเดิม การย้ายควรทำเป็นช่วง ๆ เริ่มจากตรวจ protocol version และ SDK compatibility จากนั้นย้าย metadata ที่เคยอยู่ใน session ไปอยู่ใน request อย่างตั้งใจ ออกแบบ explicit state handles สำหรับ state ที่ server ต้องอ้างถึงภายหลัง เพิ่ม idempotency key ให้ action ที่มีผลภายนอก และสร้าง audit trail ที่เชื่อม request, task, approval, execution และ result ได้ครบ

เช็กลิสต์ migration ที่เราใช้คิดสำหรับ connector ของ phone agent มีเจ็ดข้อ: 1. request อธิบายตัวเองพอให้ route ได้ 2. state handle มีอายุและเจ้าของชัด 3. approval แยกจาก auth 4. device state ถูกอ่านใหม่ก่อน action สำคัญ 5. retry policy แยก safe retry กับ action ที่ต้อง verify ก่อน 6. correlation ID ตามงานได้ข้ามระบบ 7. legacy client มีเส้นทาง negotiation หรือ fallback ที่ตรวจได้

สำหรับ FoneClaw วันนี้ เราใช้ความสามารถปัจจุบันเป็นหลักฐานของ host-side state ownership บน Android: ผู้ใช้เริ่มงานจากเสียงหรือหน้าจอที่แนบเอง เห็นงานที่รออนุมัติ กู้คืนสิทธิ์ และทำต่อผ่านเครื่องมือที่ถูกกำกับได้ ส่วนการออกแบบ connector ที่ใช้ MCP 2026-07-28 เป็นเส้นทางสถาปัตยกรรมที่ต้องผ่านเกณฑ์ด้าน auth, approval, idempotency, recovery และ audit เช่นเดียวกัน ความสามารถปัจจุบันของ FoneClaw ดูได้ที่ หน้าฟีเจอร์ของ FoneClaw และข้อมูลดาวน์โหลดล่าสุดอยู่ที่ หน้า Download ของ FoneClaw

แหล่งข้อมูล: บทความนี้อ้างอิง ประกาศ Model Context Protocol 2026-07-28, SEP-2575 Make MCP Stateless, SEP-2567 Sessionless MCP via Explicit State Handles, MCP Go SDK v1.7.0, หน้าฟีเจอร์ของ FoneClaw และ หน้า Download ของ FoneClaw