Microsoft Agent Framework ได้ "ความจำระยะยาว" แบบเสียบปลั๊ก — CosmosMemoryContextProvider ออบเจ็กต์เดียว จำข้ามเธรดข้ามเซสชันได้เอง

หนึ่งในงานที่น่าเบื่อที่สุดของคนสร้าง agent คือ การทำให้มันจำได้ — ไม่ใช่จำในบทสนทนาเดียว (นั่นคือ context window) แต่จำข้ามเธรด ข้ามเซสชัน ข้ามวัน ว่าผู้ใช้คนนี้ชอบอะไร ทีมนี้ตัดสินใจอะไรไปแล้ว งานส่วนนี้ปกติต้องเขียนเอง: ตั้ง vector store แยก เขียน pipeline สรุปบทสนทนา จัดการ schema แล้วคอย sync ทั้งหมดให้ตรงกัน

วันที่ 24 กรกฎาคม 2026 ทีม Azure Cosmos DB โดย Theo van Kraay ประกาศตัวช่วยที่ตัดงานชุดนี้ทิ้ง — แพ็กเกจ agent-framework-azure-cosmos-memory ที่ให้ agent บน Microsoft Agent Framework มีความจำระยะยาวได้ด้วยการแนบออบเจ็กต์เดียว ชื่อ CosmosMemoryContextProvider

ทำไมต้องเป็น “context provider” ไม่ใช่ “memory API”

จุดที่ประกาศนี้อธิบายได้ดีคือความต่างเชิงสถาปัตยกรรม เฟรมเวิร์ก agent ส่วนใหญ่ให้ memory interface มา — API ตายตัวสำหรับเก็บและดึงความจำ แต่ Agent Framework เลือกทำนามธรรมที่กว้างกว่า: context provider ซึ่งเป็นแค่ hook สองตัวรอบการรันของ agent

• before_run — ค้นความจำที่เก็บบน Cosmos หาสิ่งที่เกี่ยวข้องกับข้อความที่เข้ามา แล้วฉีดผลลัพธ์ (บวกโปรไฟล์ผู้ใช้) เข้าไปใน context ของโมเดล
• after_run — เก็บเทิร์นใหม่ลงฐานข้อมูล แล้วปล่อยให้ pipeline ไปสกัดข้อเท็จจริง อัปเดตสรุป และปรับโปรไฟล์ผู้ใช้ในเบื้องหลัง

ความสำคัญของการออกแบบแบบนี้คือ มันไม่ได้ผูกกับเรื่องความจำ — hook คู่นี้เป็นรอยต่อสะอาด ๆ สำหรับฉีด “อะไรก็ตามที่ agent ควรรู้ก่อนคิด” และ “จับอะไรก็ตามที่มันผลิตออกมา” ความจำเป็นแค่ use case แรก ซึ่งแปลว่าถ้าคุณอยากทำ policy checker, audit logger หรือ context จากระบบภายในองค์กร คุณเสียบเข้าที่จุดเดียวกันได้เลย

เก็บอะไร และค้นยังไง

ข้างใต้ provider คือ Agent Memory Toolkit ที่ Microsoft ปล่อยมาก่อนหน้า สิ่งที่มันทำคือไม่ได้เก็บแค่บทสนทนาดิบ แต่กลั่นออกมาเป็นสามชั้น:

• เทิร์นดิบ ของบทสนทนา
• derived memories — สรุปเธรด, ข้อเท็จจริงที่สกัดได้, และโปรไฟล์ผู้ใช้ที่ข้ามเธรด
• ทั้งหมดลง Azure Cosmos DB for NoSQL เป็น JSON document

ส่วนการค้นคืนใช้ vector + full-text + hybrid search ที่มีอยู่ในฐานข้อมูลอยู่แล้ว — จุดขายตรงนี้ชัด: ไม่ต้อง provision vector store ตัวที่สอง และไม่มีอะไรต้องคอย sync

ความจำถูก scope ด้วย user_id ที่คงที่ (และ thread_id สำหรับบทสนทนาปัจจุบัน) ฉะนั้นเปิดเธรดใหม่เอี่ยมของผู้ใช้คนเดิม มันก็ยังจำได้ ตัวอย่างในบทความสาธิตชัด: บอก agent ว่า “ฉันชอบเดินป่าและแพ้ถั่วลิสง” แล้วเปิดเธรดใหม่ถามว่าควรแพ็กอะไรไปกินกลางทาง — มันตอบเป็นเมนูที่ไม่มีถั่ว ทั้งที่เธรดใหม่ไม่มีข้อความก่อนหน้าเลย

การติดตั้งจริงสั้นแค่นี้ (ยืนยันตัวตนผ่าน DefaultAzureCredential ไม่ใช้ API key):

pip install agent-framework-azure-cosmos-memory agent-framework-foundry

แล้วส่ง provider เข้าไปที่ context_providers=[provider] ของ Agent — บรรทัดเดียวนั้นคือทั้งการเชื่อมต่อ

ปรับได้ว่า “อะไรควรค่าแก่การจำ”

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

ถ้าปล่อยไว้ที่ค่าเริ่มต้น agent เฉพาะทางจะ “ลืมสิ่งที่สำคัญที่สุด” หรือไม่ก็รกไปด้วยเรื่องไร้สาระ การชี้ prompts_dir ไปที่โฟลเดอร์เทมเพลต Prompty ของคุณเอง (ตัวที่สำคัญสุดคือ extract_memories.prompty) ทำให้เปลี่ยนเกณฑ์ได้โดยไม่ต้อง fork toolkit — และเส้นทาง retrieval/injection ยังเหมือนเดิมทุกอย่าง

จุดที่ทำเพื่อโปรดักชัน (และช่องโหว่ที่เขาคิดถึงแล้ว)

สามข้อที่ทีมเน้นและควรอ่านถ้าจะเอาไปใช้จริง:

• การสกัดไม่บล็อก request — การเขียนเทิร์นเป็น non-blocking ส่วนการสกัดข้อเท็จจริงและสรุปรันเบื้องหลัง แล้วถูก drain ให้เรียบร้อยตอนออกจาก context ของ provider
• ปลอดภัยโดยค่าเริ่มต้น — นี่คือข้อที่ผมชอบที่สุด เพราะโปรไฟล์ผู้ใช้ถูกสร้างจากเนื้อหาบทสนทนาที่เก็บไว้ มันจึงเป็นข้อมูลที่ไม่น่าเชื่อถือโดยธรรมชาติ provider จึงฉีดมันเข้าไปในฐานะ ข้อความ user ธรรมดา ไม่ใช่ system หรือคำสั่ง agent และแปะโน้ตกำกับให้โมเดลถือว่าเป็นข้อมูลอ้างอิงที่ไม่น่าเชื่อถือ — ลดความเสี่ยง stored prompt injection ที่ความจำถูกวางยาแล้วกลายเป็นคำสั่งถาวร
• โมเดลของคุณ กฎของคุณ — ต้องระบุ deployment ของ chat และ embedding อย่างชัดเจน ไม่มีค่าเริ่มต้นเงียบ ๆ ที่อาจชี้ไปโมเดลที่คุณไม่ได้ deploy

ข้อจำกัด: แพ็กเกจนี้ยังเป็น พรีวิว และรองรับ Python เท่านั้น — API อาจเปลี่ยนก่อน GA

มุมมอง AI Curator

ประเด็นที่ควรจับจากประกาศนี้ไม่ใช่ “Microsoft ออกฟีเจอร์ความจำ” แต่คือ สงครามครั้งใหม่กำลังย้ายจากชั้นโมเดลไปที่ชั้นสถานะ (state) ตลอดปีนี้เราเห็นทุกเจ้าไล่แก้ปัญหาเดียวกัน — agent ที่ฉลาดแต่ความจำสั้นคือของเล่น ไม่ใช่เพื่อนร่วมงาน และคนที่คุมชั้นความจำได้ก็คือคนที่ agent ย้ายหนีได้ยากที่สุด สังเกตว่าดีลนี้ผูกกับ Cosmos DB + Microsoft Foundry ค่อนข้างแน่น — ความสะดวก “ออบเจ็กต์เดียวจบ” มีราคาของมันคือ การผูกกับผู้ให้บริการ ที่ลึกกว่าการเรียก API โมเดลเฉย ๆ เพราะข้อมูลของผู้ใช้คุณย้ายออกยากกว่าโค้ดมาก

ข้อที่ผมอยากให้นักพัฒนาไทยอ่านซ้ำคือเรื่อง safe-by-default ปีนี้บล็อกเราเขียนถึงกรณี prompt injection ผ่านช่องทางแปลก ๆ มาหลายรอบ — จาก MCP, จาก workflow ของ GitHub, จาก browser tool ความจำระยะยาวคือช่องทางถัดไปที่ชัดเจนมาก เพราะมันเป็นข้อความที่ผู้ใช้ (หรือคนที่แกล้งเป็นผู้ใช้) ป้อนเข้าไปได้ แล้วถูกดึงกลับมาอ่านซ้ำทุกครั้งโดยอัตโนมัติ ถ้าทีมคุณกำลังเขียนชั้นความจำเอง — ซึ่งทีมไทยหลายทีมทำอยู่ เพราะยังไม่พร้อมผูกกับคลาวด์เจ้าใหญ่ — ก็อปแนวคิดนี้ไปเลย: ความจำที่ดึงกลับมาต้องเข้าเป็น user message เสมอ ห้ามเข้าเป็น system prompt เด็ดขาด ไม่ต้องรอให้โดนก่อนแล้วค่อยแก้

และในมุมสถาปัตยกรรม จุดที่ถ่ายทอดไปใช้กับ stack อะไรก็ได้คือ หลักการ “กลั่น ไม่ใช่กอง” — การเก็บบทสนทนาทั้งหมดแล้วยัดเข้า context เป็นวิธีที่แพงและคุณภาพแย่ลงเรื่อย ๆ เมื่อประวัติยาวขึ้น การแยกเป็นเทิร์นดิบ + ข้อเท็จจริงที่สกัดแล้ว + โปรไฟล์สรุป คือแพตเทิร์นที่ใช้ได้ไม่ว่าคุณจะอยู่บน Cosmos, Postgres + pgvector หรือ Qdrant ที่รันเองในองค์กร

แหล่งข่าว

• Native Agent Memory for Microsoft Agent Framework, Powered by Azure Cosmos DB — Azure Cosmos DB Blog (24 ก.ค. 2026)
• Microsoft Agent Framework — DevBlogs
• Azure Cosmos DB Blog