Spring AI 2.1 RC1 เพิ่มด่านกดยืนยัน ก่อน AI ลงมือทำงานจริง

Spring AI เปิดตัว 2.1.0-RC1 และ 2.0.2 แล้ว โดยรุ่น RC1 เพิ่มระบบให้คนยืนยันก่อน AI เรียกเครื่องมือ และเปลี่ยนทิศทางความจำบทสนทนาไปสู่ session memory ตามรายการรุ่นที่เผยแพร่และประกาศของทีม Spring ในชุดข้อมูลวันที่ 23 ตุลาคม 2026 (GitHub, Spring Blog)

สำหรับคนทำงาน ความสำคัญอยู่ตรงช่วงระหว่าง “ช่วยร่างอีเมลให้หน่อย” กับ “ส่งอีเมลออกไปแล้ว” เอกสารอธิบายว่าการส่งอีเมล การจองเที่ยวบิน หรือการลบไฟล์ เป็นงานที่อาจต้องให้คนอนุมัติก่อน ระบบใหม่นี้เปิดทางให้แอปหยุดรอการตัดสินใจได้ ก่อนเครื่องมือลงมือทำจริง (Spring Docs)

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

สรุป 30 วินาที: เกิดอะไรขึ้น

Spring AI คือชุดเครื่องมือสำหรับนักพัฒนาที่สร้างแอปเกี่ยวกับ AI ในฝั่ง Java รอบนี้มีสองรุ่นที่ต้องแยกให้ออก: 2.1.0-RC1 เป็น release candidate หรือรุ่นเตรียมพร้อมก่อนออกตัวจริง ส่วน 2.0.2 เป็นรุ่นที่เอกสารชี้ให้ใช้เมื่อต้องการรุ่นเสถียรล่าสุด จึงไม่ควรอ่านเลข 2.1 แล้วสรุปว่าเหมาะกับระบบใช้งานจริงมากกว่าโดยอัตโนมัติ (GitHub, Spring Docs)

ของเด่นใน RC1 คือ tool-call confirmation หรือการให้คนอนุมัติก่อน AI เรียกความสามารถที่แอปจัดไว้ให้ อีกส่วนคือ session memory หรือระบบเก็บประวัติการสนทนาเป็นเหตุการณ์ต่อเนื่อง พร้อมย่อส่วนประวัติที่ส่งให้ AI โดยรักษารอบการสนทนาให้ครบ และประกาศเลิกแนะนำให้ใช้ ChatMemory ซึ่งเป็นระบบความจำเดิม รายการเดียวกันปรากฏทั้งบน GitHub และหน้าติดตามรุ่นของ NewReleases (GitHub, NewReleases)

ฝั่ง 2.0.2 มีงานแก้ความผิดพลาดหลายจุด เช่น การเคารพเวลารอ OpenAI ที่ตั้งไว้ การส่งคำขอเรียกเครื่องมือซ้ำในตัวตรวจผลลัพธ์ และการจัดการคำตอบจาก Ollama ที่ไม่มีข้อความ ทีมที่ใช้สาย 2.0.x อยู่จึงมีเหตุผลให้ตรวจรุ่นบำรุงรักษานี้ โดยไม่ต้องย้ายไปทดลอง RC เพื่อรับงานแก้เหล่านั้น (GitHub)

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

สำหรับทีม Java ที่กำลังเติม AI ในแอปธนาคาร ระบบวางแผนทรัพยากรองค์กรหรือ ERP และระบบบุคคลหรือ HR ผมเสนอให้แยกงานอ่านข้อมูลออกจากงานที่เปลี่ยนข้อมูลหรือสร้างภาระผูกพัน เอกสารรองรับนโยบายเลือกเครื่องมือที่ต้องยืนยัน และรองรับกฎที่ดูรายละเอียดของคำสั่ง เช่น เงื่อนไขเกี่ยวกับยอดโอน แต่ไม่ได้ประกาศว่ามีบริการโอนเงินจริงสำเร็จรูปให้เปิดใช้ทันที (Spring Docs)

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

ทำงานยังไง

เครื่องมือหรือ tool ในบริบทนี้คือความสามารถที่แอปเปิดให้ AI เรียกใช้ เมื่อ AI ขอเรียกเครื่องมือ ตัวจัดการจะตรวจนโยบายก่อนเริ่มทำงาน หากคำตอบรอบนั้นมีแม้แต่คำสั่งเดียวที่ต้องยืนยัน ระบบจะหยุดทั้งชุด ยังไม่มีคำสั่งใดในคำตอบนั้นทำงาน แล้วส่งรายการที่รอการตัดสินใจกลับมาให้แอป (Spring Docs)

นึกถึงพนักงานใหม่ที่ต้องให้หัวหน้าเซ็นก่อนโอนเงินครับ พนักงานเตรียมรายการมาได้ แต่ยังโอนไม่ได้จนกว่าหัวหน้าจะอนุมัติ ใน Spring AI นักพัฒนาต้องกำหนดก่อนว่างานไหนต้องรอเซ็น แอปจึงค่อยแสดงรายการให้คนตัดสินใจ แล้วนำผลอนุมัติหรือปฏิเสธกลับไปเดินงานต่อ ความเปรียบเทียบนี้อธิบายหน้าที่ของกลไก ส่วนสิทธิว่าใครเป็นหัวหน้าตัวจริง แอปต้องตรวจเองตามข้อจำกัดที่เอกสารระบุ (Spring Docs)

เมื่อตัดสินใจแล้ว แอปต้องส่งผลการตัดสินใจให้ครบทุกคำสั่งในคำตอบที่หยุดรอ รวมถึงคำสั่งที่เดิมไม่ถูกระบุว่าต้องยืนยัน รายการที่อนุญาตจึงทำงาน ส่วนรายการที่ปฏิเสธจะส่งข้อความผลการปฏิเสธกลับให้ AI แทนการเรียกเครื่องมือ แล้วแอปส่งผลเหล่านั้นไปให้โมเดลหรือระบบ AI สร้างคำตอบต่อ (Spring Docs)

ระหว่างรอ ตัวเฟรมเวิร์กไม่ได้ถือสถานะการหยุดค้างไว้ การหยุดเป็นคำตอบปกติ และการทำต่อเป็นคำขอครั้งใหม่ ลักษณะนี้ช่วยให้เดินงานต่อหลังระบบเริ่มใหม่ได้ แต่มีเงื่อนไขว่าแอปต้องเก็บประวัติการสนทนาไว้เอง การมีระบบยืนยันจึงไม่ได้แปลว่าแอปจะบันทึกทุกอย่างให้อัตโนมัติ (Spring Docs)

ความจำแบบใหม่เก็บบทสนทนาเป็น event log หรือบันทึกเหตุการณ์ที่เพิ่มต่อท้าย แต่ละเหตุการณ์มีข้อมูลระบุตัว เวลา และบทสนทนาที่สังกัด ส่วนข้อความที่ส่งให้ AI อ่านจะสร้างจากมุมมองของบันทึกนั้น จึงแยก “สิ่งที่เคยเกิดขึ้น” ออกจาก “สิ่งที่ต้องส่งให้ AI อ่านในรอบนี้” ได้ (Spring Docs)

คำว่า turn-aware compaction หมายถึงการลดประวัติที่ให้ AI เห็นโดยรักษาขอบเขตของรอบสนทนา ไม่ตัดจนเหลือคำสั่งเรียกเครื่องมือโดยไม่มีผลลัพธ์ หรือเหลือคำตอบโดยไม่มีคำถาม การลดประวัตินี้ไม่แก้บันทึกเดิม แต่เพิ่มขอบเขตเพื่อบอกว่าจากนี้ควรอ่านส่วนไหน เป็นความต่างที่ควรรู้ก่อนคิดว่าประวัติเก่าถูกลบทิ้งแล้ว (Spring Docs)

จุดสังเกต: มีปุ่มยืนยันแล้ว ยังต้องกันการทำงานซ้ำ

จุดที่ผมอยากขีดเส้นใต้คือ ระบบไม่ได้ป้องกันการนำผลอนุมัติเดิมกลับมารันซ้ำให้ หากส่งการตัดสินใจชุดเดิมสองครั้ง เครื่องมือก็ทำงานสองครั้งได้ เอกสารจึงให้แอปออกแบบการทำต่อให้ส่งซ้ำแล้วไม่เกิดงานซ้ำ หรือบันทึกว่ารายการที่หยุดรอนั้นจัดการเสร็จแล้ว สำหรับงานเกี่ยวกับเงิน นี่ควรเป็นหัวข้อทดสอบตั้งแต่ต้น (Spring Docs)

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

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

เรื่องเงิน / ผลกระทบ

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

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

ด้านความจำ เอกสารมีที่เก็บในหน่วยความจำสำหรับทดสอบและสาธิต ซึ่งข้อมูลหายเมื่อเริ่มระบบใหม่และไม่แชร์ข้ามตัวระบบที่ทำงานหลายชุด ส่วนงานใช้งานจริงมีตัวเก็บผ่าน JDBC หรือช่องทางเชื่อมฐานข้อมูลสำหรับ Java รองรับ PostgreSQL, MySQL, MariaDB และ H2 ตามรายการในเอกสาร ข้อนี้ช่วยให้ทีมประเมินงานจัดเก็บได้ แต่ยังไม่มีตัวเลขต้นทุนหรือผลทดสอบประสิทธิภาพในข้อมูลที่ให้มา (Spring Docs)

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ข้อมูลหน้า GitHub ที่ให้มามีวันที่กำกับ 23 ตุลาคม 2026 และแสดงทั้ง 2.1.0-RC1 กับ 2.0.2 แต่ข้อความไม่ได้แสดงวันและเวลาประจำแต่ละรุ่นแยกกัน จึงยังฟันธงไม่ได้ว่าแต่ละรุ่นออกวันที่ 22 หรือ 23 ตุลาคม และไม่มีเวลาเขตอื่นให้แปลงเป็นเวลาไทย หน้าประกาศของ Spring ยืนยันว่าทั้งสองรุ่นออกแล้วเช่นกัน (GitHub, Spring Blog)

ไม่พบความขัดแย้งเรื่องรายการฟีเจอร์ RC1 ระหว่าง GitHub กับ NewReleases แต่หน้าหลังเป็นการติดตามประกาศรุ่นเดียวกัน จึงไม่ควรนับเป็นผลทดสอบอิสระว่าทุกฟีเจอร์ทำงานครบในทุกสภาพแวดล้อม ทั้งสองหน้าระบุการย้าย OpenAI และ DeepSeek ไปใช้ message parts หรือโครงสร้างข้อความที่แบ่งเป็นส่วนย่อย และเพิ่มการค้น OpenSearch ด้วย embedding ซึ่งเป็นข้อมูลตัวเลขแทนเนื้อหาเพื่อใช้ค้นหา ส่วนรายละเอียดพฤติกรรมและผลต่อประสิทธิภาพยังไม่มีในข้อความที่ให้มา (GitHub, NewReleases)

เอกสารการยืนยันใช้เส้นทางรุ่นพัฒนา และทั้งเอกสารการยืนยันกับ session memory เตือนว่ายังไม่ถือว่าเสถียร โดยชี้ไปที่ 2.0.2 สำหรับรุ่นเสถียรล่าสุด จึงควรอ่านรายละเอียดเหล่านี้เป็นแนวทางของรุ่นที่กำลังพัฒนา ไม่ใช่คำประกาศว่า 2.1 ออก GA หรือรุ่นพร้อมใช้งานทั่วไปแล้ว แหล่งข้อมูลชุดนี้ยังไม่มีวันออก GA (Spring Docs, Spring Docs)

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

แล้วเราควรทำอะไร

คนทั่วไปและเจ้าของงาน

1. หากกำลังสั่งทำผู้ช่วย AI ผมแนะนำให้ทำรายการงานที่ต้องให้คนอนุมัติก่อน เช่น งานส่งข้อมูลออกไปหรือเปลี่ยนรายการสำคัญ แล้วให้ทีมพัฒนาระบุว่าเครื่องมือใดถูกตั้งให้หยุดรอ เพราะระบบจะตรวจตามนโยบายที่กำหนดไว้ (Spring Docs)
2. ตกลงให้ชัดว่าใครมีสิทธิอนุมัติงานประเภทใด และให้ทีมสาธิตกรณีคนไม่มีสิทธิเข้ามาตัดสินใจ เหตุผลคือเฟรมเวิร์กไม่ได้ตรวจตัวตนและสิทธิผู้อนุมัติแทนแอป (Spring Docs)
3. ขอชมทั้งกรณีอนุมัติ ปฏิเสธ และปล่อยค้างไว้ เอกสารระบุว่าหากทิ้งคำสั่งรอโดยไม่มีผลลัพธ์ ผู้ให้บริการโมเดลส่วนใหญ่จะปฏิเสธประวัติแบบนั้นในการเรียกครั้งถัดไป แอปจึงต้องจัดการรายการค้างก่อนรับข้อความใหม่ (Spring Docs)

ทีมดูแลระบบใช้งานจริงบน 2.0.x

1. ตรวจแผนอัปเดตไป 2.0.2 ซึ่งเป็นรุ่นเสถียรล่าสุดตามเอกสาร โดยอ่านรายการแก้ไขเทียบกับส่วนที่ระบบใช้อยู่ เช่น เวลารอ OpenAI และคำขอเรียกเครื่องมือซ้ำ ไม่จำเป็นต้องผูกการรับงานแก้เหล่านี้กับการทดลอง 2.1 RC (GitHub, Spring Docs)
2. ก่อนนำขึ้นใช้งาน ผมแนะนำให้ทดสอบเส้นทางงานที่พึ่งผู้ให้บริการ AI และตัวเก็บข้อมูลของทีมเป็นหลัก เพราะ 2.0.2 มีรายการแก้กระจายทั้งส่วนคำตอบ เครื่องมือ และตัวเก็บข้อมูลหลายชนิด รายการรุ่นไม่ได้ให้ผลทดสอบสำหรับแอปของคุณ (GitHub)

ทีมทดลอง 2.1.0-RC1 และวางแผนย้ายความจำ

1. ทดลองใน branch หรือชุดโค้ดแยกสำหรับทดสอบก่อน พร้อมออกแบบรายการเครื่องมือที่ต้องยืนยัน รุ่น RC ยังอยู่ก่อน GA และเอกสารเตือนว่ายังไม่เสถียร จึงควรใช้ช่วงนี้พิสูจน์ขั้นตอนงานของทีม (Spring Docs)
2. ทดสอบการกดซ้ำ การเริ่มระบบใหม่ระหว่างรอ และการปฏิเสธ โดยเก็บรายการต้นฉบับในพื้นที่ที่ผู้ใช้แก้ไม่ได้ พร้อมบันทึกว่ารายการใดจบแล้ว เหล่านี้ตอบข้อจำกัดเรื่องสถานะ สิทธิ และการทำงานซ้ำที่เอกสารระบุไว้โดยตรง (Spring Docs)
3. ทำบัญชีส่วนที่ใช้ ChatMemory และตัวช่วยนำความจำเข้าบทสนทนา เอกสารระบุว่า ChatMemory และ MessageChatMemoryAdvisor ถูกประกาศเลิกแนะนำให้ใช้ตั้งแต่ 2.1.0 และวางแผนถอดใน 3.0.0 จึงควรวางแผนย้าย ไม่ใช่อ่านคำว่า deprecated แล้วเข้าใจว่าหายไปทันที คำนี้หมายถึงยังมีอยู่แต่ควรเตรียมเปลี่ยนไปใช้สิ่งทดแทน (Spring Docs)
4. เมื่อทดลอง session memory ต้องส่งรหัส session หรือรหัสประจำบทสนทนาทุกครั้ง ระบบไม่มีบทสนทนากลางสำรองให้ เพราะอาจทำให้ประวัติคนละผู้ใช้รวมกันโดยไม่รู้ตัว และอย่าใช้ตัวเก็บในหน่วยความจำเป็นหลักฐานว่าข้อมูลจะอยู่หลังเริ่มระบบใหม่ (Spring Docs)

ผมมองว่า…

ผมมองว่า ข่าวนี้เป็นก้าวที่น่าสนใจในเชิงออกแบบผลิตภัณฑ์ ความเห็นของผมคือคุณค่าหลักไม่ใช่ AI ทำงานได้เร็วขึ้น แต่คือคนมีจังหวะตรวจและรับผิดชอบก่อนเกิดผลจริง การหยุดทั้งชุดคำสั่งทำให้ทีมต้องคิดถึงสิ่งที่ผู้ใช้กำลังอนุมัติให้ครบ ขณะเดียวกันข้อจำกัดเรื่องสิทธิและการทำซ้ำก็บอกตรง ๆ ว่าทีมยังต้องสร้างส่วนสำคัญเอง (Spring Docs)

ผมยังชอบแนวคิดแยกบันทึกเหตุการณ์ออกจากประวัติที่ให้ AI อ่าน เพราะช่วยให้คุยกันรู้เรื่องขึ้นว่า “เก็บไว้” กับ “ส่งให้โมเดลเห็น” เป็นคนละการตัดสินใจ อย่างไรก็ตาม นี่เป็นความเห็นต่อแนวทางออกแบบ ไม่ใช่ผลทดสอบว่าประหยัดค่าใช้จ่ายหรือปลอดภัยขึ้นเท่าไร ข้อเท็จจริงที่เอกสารยืนยันคือการลดประวัติไม่เปลี่ยนบันทึกเดิม และรักษาขอบเขตรอบสนทนาไว้ (Spring Docs)

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ควรติดตามต่อคือรายละเอียดรุ่นพร้อมใช้งานทั่วไปของ 2.1 และความชัดเจนของการต่อยอดสถานะ session เพราะเอกสารยังเตือนว่าอยู่ระหว่างพัฒนา ส่วนวันนี้ทีมที่ใช้สาย 2.0.x มี 2.0.2 ให้ตรวจแผนอัปเดตแล้ว ขณะที่คนทดลอง RC1 ควรให้ความสำคัญกับเส้นทางอนุมัติและการย้ายความจำไปพร้อมกัน (GitHub, Spring Docs)

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

Recap

• แยกแผนอัปเดต 2.0.2 ออกจากการทดลอง 2.1.0-RC1
• จำไว้ว่า RC ยังไม่ใช่รุ่น GA
• ระบุเครื่องมือที่ต้องรอคนอนุมัติก่อนลงมือ
• ตรวจสิทธิผู้อนุมัติและเก็บรายการต้นฉบับให้ผู้ใช้แก้ไม่ได้
• ทดสอบการปฏิเสธ รายการค้าง และการส่งผลอนุมัติซ้ำ
• วางแผนย้ายจาก ChatMemory ไป session memory
• ส่งรหัส session ทุกครั้งและเลือกที่เก็บให้เหมาะกับงานจริง
• แยกประวัติที่เก็บออกจากประวัติที่ส่งให้ AI อ่าน