Tool: remember — 4 โหมดจัดการความจำถาวร พร้อม conflict-scan และ compaction ด้วย LLM
remember บันทึกข้อเท็จจริงหรือข้อตกลงที่ต้องใช้ข้าม session เพื่อให้ agent กลับมาทำงานต่อโดยไม่ต้องสรุปบริบทเดิมใหม่ทุกครั้ง
Tool นี้คืออะไร
บันทึกข้อเท็จจริง (fact) เกี่ยวกับผู้ใช้ลงไฟล์ logs/memory.md แบบถาวร — เขียนลงไฟล์จริงบนดิสก์ ข้อมูลจึงคงอยู่ข้าม session และถูกโหลดกลับเข้า system prompt ในการสนทนาครั้งถัดไป แต่ละบรรทัดมีรูปแบบคงที่ - [YYYY-MM-DD] [category] fact เช่น - [2026-08-14] [ส่วนตัว] ชื่อ ปูม
4 โหมด ไม่ใช่แค่ “เขียนเพิ่ม”
Docstring ล็อกโหมดไว้ชัดเจนตาม parameter ที่ส่งมา — agent ห้ามเดาโหมดเอง:
| โหมด | Trigger คำพูด | ทำอะไร |
|---|---|---|
APPEND (fact อย่างเดียว) |
“จำไว้ว่า…”, “บันทึกว่า…” | เขียนบรรทัดใหม่ — เช็ค conflict กับของเดิมอัตโนมัติ (ดูหัวข้อถัดไป) |
REPLACE (fact + replace) |
“แก้จาก X เป็น Y” | หาบรรทัดที่มีข้อความ replace แล้วเขียนทับด้วย fact — ถ้าหาไม่เจอคืน error ไม่ใช่เขียนเพิ่มเงียบๆ |
FORGET (forget อย่างเดียว) |
“ลืม X ไปเลย”, “ไม่ต้องจำ X แล้ว” | ลบทุกบรรทัดที่มีข้อความ forget — ถ้าหาไม่เจอคืน error |
INSERT (fact + anchor) |
ขอแทรกความจำที่ตำแหน่งเฉพาะ | แทรกบรรทัดใหม่ก่อน/หลังข้อความ anchor หรือที่เลขบรรทัดที่กำหนด — ไม่รัน conflict-scan (เป็นการแก้แบบเจาะจง) |
Conflict-scan: ให้ LLM ตัดสินว่าอะไรซ้ำ/ขัดแย้งกัน ก่อนเขียนทุกครั้ง
จุดที่ทำให้ต่างจาก append เข้าไฟล์ดื้อๆ — โหมด APPEND ทุกครั้งจะเรียก LLM ตัวเบา (temperature=0, ปิด thinking) ถามว่า fact ใหม่นี้ ซ้ำหรือขัดแย้งกับบรรทัดไหนในไฟล์เดิมบ้าง (เช่น “ชอบกาแฟดำ” ตามด้วย “ชอบกาแฟนม” ภายหลัง) แล้วลบบรรทัดเก่าที่ขัดแย้งออกอัตโนมัติ — ข้อมูลใหม่ชนะเสมอ
มี guardrail กันความผิดพลาดของ LLM เอง: ถ้า LLM ตอบไม่ใช่ JSON, index ที่ชี้นอกขอบเขต, หรืออยากลบเกิน 3 บรรทัดในครั้งเดียว (_MAX_CONFLICT_REMOVALS) — ระบบตัดสินว่าคำตอบนั้น “garbage” แล้ว fallback ไปเป็น append เฉยๆ โดยไม่ลบอะไรเลย เพื่อไม่ให้ LLM ที่ตอบมั่วมาลบความจำของผู้ใช้ทิ้งโดยไม่ตั้งใจ
เมื่อไฟล์เกินเพดาน: compact ด้วย LLM ก่อน ตัดทิ้งดื้อๆ เป็นแผนสำรอง
ไฟล์มีเพดาน 5,000 ตัวอักษร (_MEMORY_MAX_CHARS) — เกินเมื่อไร ระบบจะให้ LLM เขียนไฟล์ใหม่ให้สั้นลงเหลือ 3,500 ตัวอักษร (_MEMORY_COMPACT_TO, เผื่อ headroom ไม่ให้ compact ซ้ำทุกครั้งที่เขียนเพิ่ม) โดยสั่งให้ รวม entry เรื่องเดียวกันเข้าด้วยกัน และเก็บวันที่ใหม่สุดเมื่อขัดแย้งกัน — ไม่ใช่แค่ตัดบรรทัดเก่าทิ้งทื่อๆ เหมือนเวอร์ชันก่อนหน้า
ถ้า LLM compact ล้มเหลว (timeout, ตอบไม่ครบ, ฯลฯ) มี deterministic fallback: ตัดบรรทัดที่เก่าที่สุดทิ้งทีละบรรทัดจนไฟล์กลับมาอยู่ในขนาดที่กำหนด — รับประกันว่าการเขียนความจำจะไม่มีวันพังเพราะ LLM ตอบช้า/ผิดพลาด และไฟล์ก่อน compact จะถูกสำรองไว้เป็น .bak เสมอ
Agent เรียก tool นี้เมื่อไร
ทำงานตามคำสั่งชัดเจนของผู้ใช้เท่านั้น ไม่ใช่ agent ตัดสินใจเองว่าอะไรควรจำ (ต่างจากระบบ compaction ของ conversation context ที่จัดการอัตโนมัติในเบื้องหลังโดยไม่ต้องสั่ง)
ทำไมเรื่องนี้ถึงสำคัญ
remember เริ่มจากงานง่ายๆ (เขียนบรรทัดเพิ่มลงไฟล์) แต่สะสมการตัดสินใจเชิงสถาปัตยกรรมไว้หลายชั้น: ความจำระยะยาวต้องมีเพดาน ไม่งั้นมันจะกลายเป็นภาระต่อ context แทนที่จะเป็นประโยชน์ — แต่แทนที่จะแก้ด้วยการตัดของเก่าทิ้งดื้อๆ อย่างเดียว ระบบเลือกให้ LLM ช่วยกลั่นกรอง ทั้งตอนเขียนเพิ่ม (conflict-scan กันข้อมูลซ้ำ/ขัดแย้งสะสม) และตอนไฟล์เต็ม (compact แทนตัดทิ้ง) โดยที่ยังมี deterministic fallback รองรับทุกจุดที่ LLM อาจพลาด — หลักการเดียวกับที่เห็นซ้ำทั่วทั้งโปรเจกต์นี้: ให้โมเดลช่วยตัดสินใจเนื้อหา แต่โค้ดยังคุมกรอบความถูกต้องอยู่เสมอ
ความคิดเห็น
กำลังโหลดความคิดเห็น...