ผมใช้เวลา 5 วันในการแก้บั๊กหน่วยความจำของ OpenClaw Agent นี่คือทั้งหมดที่ผมได้เรียนรู้

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

และเป็นเวลาหลายสัปดาห์ มันก็ลืมสิ่งต่างๆ อยู่เรื่อยๆ

ไม่ใช่แบบ s subtle เลย ฉันใช้เวลาหนึ่งชั่วโมงในการตั้งค่างาน cron รายวัน เปลี่ยนโมเดล แล้วในเซสชั่นถัดไป Chiti จะทำตัวเหมือนเราไม่เคยคุยกัน ฉันอ้างถึงการตัดสินใจจากสองวันก่อนแล้วได้คำตอบแบบงงๆ ฉันขอให้มันทำงานต่อแต่มันก็เริ่มต้นจากศูนย์

ฉันเลยหยุดสร้างฟีเจอร์และใช้เวลา 5 วันเมื่อมีโอกาส แค่แก้ไขเรื่องความจำ นี่คือทุกสิ่งที่ฉันพบ ทุกสิ่งที่ฉันพัง และทุกสิ่งที่ใช้ได้ผลจริง

วันที่ 1: เอเจนต์ลืมทุกอย่างหลังการสนทนาที่ยาวนาน

ปัญหาแรกนั้นอธิบายได้ง่าย แต่เจ็บปวดในการวินิจฉัย

หลังจากการสนทนาที่ยาวนาน Chiti จะเริ่มสูญเสียบริบทก่อนหน้านี้ ไม่ใช่แบบค่อยเป็นค่อยไป มันแค่หายไป สิ่งที่ฉันบอกมันไป 20 ข้อความก่อนหน้านี้หายไป การตัดสินใจที่เราทำตอนเริ่มเซสชั่น? ไม่เคยเกิดขึ้น

ตัวการคือ compaction เมื่อการสนทนาเต็มหน้าต่างบริบท OpenClaw จะบีบอัดข้อความเก่าๆ เป็น summary เพื่อให้มีที่สำหรับข้อความใหม่ summary จับใจความสำคัญแต่ทิ้งรายละเอียด ชื่อ ตัวเลข การตัดสินใจที่แน่นอน - หายไป

นี่คือการออกแบบ หน้าต่างบริบทมีจำกัด แต่พฤติกรรมเริ่มต้นปฏิบัติต่อทุกอย่างเท่าเทียมกัน ซึ่งหมายความว่าคำสั่งที่คุณตั้งใจสร้างจากข้อความที่ 3 ได้รับการปฏิบัติแบบเดียวกับบทสนทนาทั่วไปจากข้อความที่ 7

สิ่งที่ฉันทำ:

ฉันเปิดใช้งาน memory flush ก่อน compaction สิ่งนี้บอกให้เอเจนต์เขียนบริบทสำคัญลงดิสก์ก่อนที่ตัวบีบอัดจะทำงาน

1{
2  "compaction": {
3    "memoryFlush": {
4      "enabled": true,
5      "softThresholdTokens": 4000
6    }
7  }
8}

เมื่อเซสชั่นใกล้ถึงขีดจำกัดบริบท OpenClaw จะเรียกใช้เทิร์นเงียบที่เตือนให้เอเจนต์บันทึกข้อเท็จจริงที่คงทนลงใน memory/YYYY-MM-DD.md ก่อนที่ compaction จะลบทิ้ง เอเจนต์เขียนสิ่งที่สำคัญ compaction ทำงาน และสิ่งสำคัญยังคงอยู่บนดิสก์แม้ว่า context summary จะสูญเสียมันไป

สิ่งที่ฉันเรียนรู้:

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

วันที่ 2: การค้นหาคืนค่าไร้สาระ

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

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

สิ่งที่ฉันทำ:

ฉันเปลี่ยนมาใช้ QMD เป็นระบบค้นหาหน่วยความจำหลัก QMD รวม BM25 (การจับคู่คำสำคัญ) กับ vector embeddings และ reranker ดังนั้นเมื่อฉันค้นหา "Charles payment failure" มันจะค้นหาผลลัพธ์ที่มีคำเหล่านั้นพอดี และผลลัพธ์ที่เกี่ยวข้องในเชิงความหมาย จากนั้นจัดอันดับใหม่ตามความเกี่ยวข้อง

ฉันยังกำหนดค่าเส้นทาง QMD เพื่อรวมโฟลเดอร์ learnings ของฉันด้วย:

1{
2  "memory": {
3    "qmd": {
4      "paths": "paths": [
5        {
6          "path": "/Users/ramya/clawd",
7          "name": "memory-root",
8          "pattern": "MEMORY.md"
9        },
10        {
11          "path": "/Users/ramya/clawd",
12          "name": "memory-alt",
13          "pattern": "memory_alt.md"
14        },
15        {
16          "path": "/Users/ramya/clawd/memory",
17          "name": "memory-dir",
18          "pattern": "**/*.md"
19        },
20        {
21          "path": "/Users/ramya/clawd/learnings",
22          "name": "learnings",
23          "pattern": "**/*.md"
24        }
25      ]
26    }
27  }
28}

สิ่งที่ฉันเรียนรู้:

การค้นหาเชิงความหมายล้วนๆ ฟังดูดีในทางทฤษฎี แต่ล้มเหลวกับคำนามเฉพาะ ตัวเลขเฉพาะ และวลีที่แน่นอน การค้นหาแบบไฮบริด (คำสำคัญ + เวกเตอร์ + การจัดอันดับใหม่) ดีกว่าอย่างเห็นได้ชัดสำหรับหน่วยความจำเอเจนต์ในโลกแห่งความจริง ถ้าเอเจนต์ของคุณไม่สามารถหาสิ่งที่คุณรู้ว่าอยู่ในไฟล์ของมันได้ ระบบค้นหาหลังบ้านน่าจะเป็นคอขวด ไม่ใช่ตัวไฟล์เอง

วันที่ 3: เอเจนต์ค้นหาเจอแต่ไม่ใช้มัน

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

ปัญหาคือการดึงข้อมูลไม่ได้เกิดขึ้นโดยอัตโนมัติ เอเจนต์ต้องตัดสินใจที่จะค้นหา และถ้าการสนทนาไม่กระตุ้นสัญญาณที่ถูกต้อง มันก็จะไม่ค้นหาสิ่งต่างๆ

สิ่งที่ฉันทำ:

ฉันเพิ่มคำสั่งการดึงข้อมูลที่ชัดเจนเข้าไปใน boot sequence แทนที่จะหวังว่าเอเจนต์จะค้นหาเมื่อจำเป็น ฉันบอกมันว่าเมื่อใดควรค้นหา:

markdown

ก่อนเริ่มงานใดๆ:

• ค้นหาบันทึกรายวันสำหรับบริบทที่เกี่ยวข้อง
• ตรวจสอบ LEARNINGS.md สำหรับกฎเกี่ยวกับงานประเภทนี้
• หากมีการกล่าวถึงลูกค้า ให้ค้นหาประวัติของลูกค้านั้น

ฉันยังสร้างการทดสอบการดึงข้อมูลด้วย ฉันจะปลูกเครื่องหมายเฉพาะในบันทึกรายวัน — เช่น "MARKER: 2026-02-20 — อย่าลืมตรวจสอบ git status ก่อนที่จะอ้างว่าโค้ดถูก push แล้ว" จากนั้นฉันจะรอ เริ่มเซสชั่นใหม่ และถาม: "เครื่องหมายจากเมื่อวานคืออะไร?" ถ้าเอเจนต์หาเจอ แสดงว่าการดึงข้อมูลทำงาน ถ้าไม่แสดงว่ามีอะไรพัง

สิ่งที่ฉันเรียนรู้:

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

วันที่ 4: ทำให้มันปลอดภัยต่อ Compaction

ถึงตอนนี้ฉันมี memory flush, การค้นหาแบบไฮบริด และคำสั่งการดึงข้อมูลแล้ว แต่ฉันยังคงสูญเสียบริบทในสถานการณ์เฉพาะ: เซสชั่นที่ยาวนานมากซึ่ง compaction ทำงานหลายครั้ง

ปัญหาคือ memory flush จะทำงานเพียงครั้งเดียวต่อรอบ compaction ถ้าเซสชั่นยาวพอที่จะมีการ compaction สองหรือสามครั้ง มีเพียงครั้งแรกเท่านั้นที่ได้รับการ flush ทุกอย่างหลังจากนั้นมีความเสี่ยง

สิ่งที่ฉันทำ:

ฉันกำหนดค่า context pruning ให้ทำงานร่วมกับ compaction:

1{
2  "contextPruning": {
3    "mode": "cache-ttl",
4    "ttl": "6h",
5    "keepLastAssistants": 3
6  }
7}

สิ่งนี้จะตัดบริบทเก่าอย่างรุนแรงหลังจาก 6 ชั่วโมง ในขณะที่เก็บการตอบสนองของผู้ช่วย 3 รายการล่าสุด เมื่อรวมกับ memory flush หมายความว่าเอเจนต์จะเขียนสิ่งสำคัญลงดิสก์ตั้งแต่เนิ่นๆ และบริบทเก่าจะถูกทำความสะอาดก่อนที่จะทำให้เกิดล้น

ฉันยังเพิ่มโปรโตคอลการทดสอบ MARKER: หลังจากการเปลี่ยนแปลงการกำหนดค่าที่สำคัญใดๆ ฉันจะปลูกเครื่องหมายในบันทึกรายวันและทดสอบการดึงข้อมูลข้ามขอบเขตของ compaction ถ้าเครื่องหมายรอด แสดงว่าการเปลี่ยนแปลงนั้นใช้ได้ ถ้าไม่ แสดงว่ามีอะไรพัง

สิ่งที่ฉันเรียนรู้:

เซสชั่นที่ยาวนานคือที่ที่ระบบหน่วยความจำถูกทดสอบจริงๆ การสนทนาสั้นๆ ไม่ค่อยถึง compaction การทำงานลึก 2 ชั่วโมงต่างหากที่คุณสูญเสียบริบทและไม่สามารถหาสาเหตุได้ ทดสอบระบบหน่วยความจำของคุณภายใต้ภาระ ไม่ใช่แค่ในการแชทด่วน

วันที่ 5: System Prompt บวมขึ้น 28%

นี่คือวันที่ทุกอย่างลงตัว ฉันรัน /context detail และจ้องไปที่ตัวเลข

เอเจนต์ของฉันกำลังโหลด system prompt 11,887 โทเค็นก่อนที่จะอ่านข้อความของฉันด้วยซ้ำ 51 ทักษะ ซึ่ง 20 ทักษะฉันไม่เคยใช้ MEMORY.md ยาว 200 บรรทัดของวิกิบริษัทที่โหลดทุกเซสชั่น และฉันมี boot sequence ที่แข่งขันกันสองอัน — อันหนึ่งใน BOOT.md (ซึ่ง OpenClaw ไม่รู้จักด้วยซ้ำ) และอีกอันถูกฝังลึก 200 บรรทัดใน AGENTS.md

ที่แย่ที่สุดคือทุกครั้งที่ฉันเปลี่ยนโมเดล Chiti ลืมทุกอย่าง ไม่มี handover protocol ไม่มีการเขียนบริบทปัจจุบันกลับ แค่หายไป

สาเหตุที่แท้จริง:

OpenClaw อ่านไฟล์เหล่านี้โดยอัตโนมัติในทุกเซสชั่นใหม่: AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, HEARTBEAT.md, MEMORY.md

ทุกอย่างอื่น — LEARNINGS.md, บันทึกรายวัน, เอกสาร, ไฟล์อ้างอิง — เอเจนต์ต้องอ่านมันเองโดยใช้เครื่องมือ ถ้าคำสั่งให้อ่านไฟล์เหล่านั้นไม่ได้อยู่ในไฟล์ที่โหลดอัตโนมัติไฟล์ใดไฟล์หนึ่ง (โดยเฉพาะ AGENTS.md) เอเจนต์จะไม่มีวันเห็นมัน

BOOT.md ของฉันมี boot sequence ทั้งหมด แต่ OpenClaw ไม่โหลด BOOT.md อัตโนมัติ ดังนั้นคำสั่งจึงนั่งอยู่ตรงนั้น ไม่ถูกอ่าน ไม่ได้ทำอะไร

สิ่งที่ฉันทำ:

ฉันทำการตรวจสอบและทำความสะอาดอย่างเต็มรูปแบบ:

1. ย้าย boot sequence ไปที่ด้านบนสุดของ AGENTS.md (ที่เดียวที่เชื่อถือได้สำหรับคำสั่งเริ่มต้น)
2. ลบ BOOT.md (OpenClaw ไม่รู้จัก)
3. ลบ BOOTSTRAP.md (ไฟล์แนะนำตัวครั้งเดียว ใช้เสร็จแล้ว สิ้นเปลือง 361 โทเค็นทุกเซสชั่น)
4. ลด MEMORY.md จาก 200 บรรทัดเหลือ 90 โดยย้ายเอกสารอ้างอิงไปยังโฟลเดอร์ docs/
5. ลบทักษะการตลาดที่ไม่ได้ใช้ 20 รายการที่กิน 3,000 โทเค็นต่อเซสชั่น
6. เพิ่มวินัยในการเขียน: ทุกงานบันทึกผลลัพธ์ ทุกความผิดพลาดกลายเป็นกฎ
7. เพิ่ม handover protocol: ก่อนเปลี่ยนโมเดลหรือสิ้นสุดเซสชั่น เอเจนต์เขียนบริบทปัจจุบันลงในบันทึกรายวัน

ตอนนี้ boot sequence มีลักษณะดังนี้:

markdown

ก่อนทำอะไร ANYTHING:

1. อ่าน USER.md
2. อ่าน learnings/LEARNINGS.md
3. อ่าน memory/YYYY-MM-DD.md (วันนี้ + เมื่อวาน)
4. อ่าน MEMORY.md (เฉพาะเซสชั่นหลัก ไม่ใช่ในกลุ่ม)
5. อ่าน PROTOCOL_COST_EFFICIENCY.md
6. พิมพ์: LOADED: USER | LEARNINGS | DAILY | MEMORY | PROTOCOL

วินัยในการเขียน:

markdown

หลังจากทุกงาน:

1. บันทึกการตัดสินใจ + ผลลัพธ์ → memory/YYYY-MM-DD.md
2. หากผิดพลาด → ผนวกไปยัง learnings/LEARNINGS.md
3. หากมีบริบทสำคัญ → อัปเดต MEMORY.md (เฉพาะระหว่างการตรวจสอบ heartbeat เท่านั้น ห้ามโดยตรงระหว่างทำงาน)

handover protocol:

markdown

ก่อนสิ้นสุดเซสชั่นหรือเปลี่ยนโมเดล:

เขียนส่วน HANDOVER ไปยัง memory/YYYY-MM-DD.md:

• สิ่งที่ถูกพูดคุย
• สิ่งที่ถูกตัดสินใจ
• งานที่ค้างอยู่พร้อมรายละเอียดที่แน่นอน
• ขั้นตอนต่อไปที่เหลืออยู่

ผลลัพธ์:

• System prompt: 11,887 → 8,529 โทเค็น
• ทักษะ: 51 → 32
• Session tokens: 18,280 → 14,627
• เบาลง 28% เอเจนต์ตัวเดียวกัน โมเดลเดียวกัน แค่มี noise น้อยลง

สิ่งที่ฉันเรียนรู้:

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

กฎที่ฉันหวังว่ารู้ตั้งแต่วันที่ 1

หลังจาก 5 วันของการพังและแก้ไข สิ่งเหล่านี้คือกฎที่ฉันจะให้กับใครก็ตามที่กำลังตั้งค่า OpenClaw memory:

1. มีเพียงไฟล์เหล่านี้เท่านั้นที่โหลดอัตโนมัติ: AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, MEMORY.md

ทุกอย่างอื่นจำเป็นต้องมีคำสั่งอ่านที่ชัดเจนใน AGENTS.md ถ้ามันไม่ได้อยู่ใน boot sequence เอเจนต์จะไม่เห็นมัน BOOT.md ไม่ใช่ของจริงใน OpenClaw ฉันมีมันเป็นสัปดาห์ มันไม่ได้ทำอะไรเลย

2. Boot sequence ต้องอยู่ที่ด้านบนสุดของ AGENTS.md

ไม่ใช่ตรงกลาง ไม่ใช่ด้านล่าง สุดด้านบน ไฟล์ที่โหลดอัตโนมัติจะถูกแทรกเข้าไปใน system prompt ดังนั้นคำสั่ง boot ต้องเป็นสิ่งแรกที่เอเจนต์ประมวลผล

3. วินัยในการเขียนสำคัญกว่าวินัยในการอ่าน

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

4. ห้ามเขียนไปยัง MEMORY.md โดยตรงระหว่างทำงาน

บันทึกรายวันเป็นแบบดิบและต่อท้ายอย่างเดียว MEMORY.md คือหน่วยความจำระยะยาวที่ได้รับการดูแล ถ้าคุณปล่อยให้เอเจนต์ทิ้งอะไรก็ได้ลงใน MEMORY.md มันจะบวมเป็นระเบียบ 200 บรรทัดภายในไม่กี่สัปดาห์ ดูแล MEMORY.md ในระหว่างการตรวจสอบเป็นระยะ (heartbeat หรือ cron) โดยกลั่นกรองข้อมูลเชิงลึกจากบันทึกรายวันล่าสุด ฉันเรียนรู้สิ่งนี้จากผู้ใช้ OpenClaw คนอื่นที่จับได้ว่าเอเจนต์ของเขากำลังทำแบบนี้เป๊ะ — ทำให้ MEMORY.md บวมด้วย noise ที่ไม่ได้ดูแลจนกระทั่งมันไร้ประโยชน์

5. LEARNINGS.md เป็นไฟล์ที่ถูกประเมินค่าต่ำที่สุด

ทุกความผิดพลาดที่เอเจนต์ทำควรกลายเป็นกฎหนึ่งบรรทัด "อย่าอ้างว่าโค้ดถูก push โดยไม่ตรวจสอบ git status" "อย่าอ่าน MEMORY.md ทั้งหมดในแชทกลุ่ม" "ยืนยันโซนเวลาของผู้ใช้เสมอก่อนกำหนดเวลา" กฎเหล่านี้ทบทวีคูณ หลังจากสองสามสัปดาห์ เอเจนต์ของคุณจะมีคู่มือปฏิบัติการส่วนตัวที่สร้างจากความล้มเหลวของมันเอง

6. ทดสอบการดึงข้อมูล ไม่ใช่แค่การจัดเก็บ

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

7. Handover protocol คือทางแก้ปัญหาการเปลี่ยนโมเดล

เอเจนต์ OpenClaw สูญเสียบริบททั้งหมดเมื่อคุณเปลี่ยนโมเดล โมเดลใหม่เริ่มต้นด้วยหน้าต่างบริบทที่ว่างเปล่า — มันเห็นเฉพาะไฟล์ที่โหลดอัตโนมัติเท่านั้น หากไม่มี handover protocol ที่ทิ้งสถานะปัจจุบันลงในบันทึกรายวันก่อนการเปลี่ยน โมเดลใหม่ก็จะไม่รู้ว่าเกิดอะไรขึ้น นี่คือจุดเจ็บปวดที่ใหญ่ที่สุดของฉันเป็นเวลาหลายสัปดาห์

8. รัน /context detail เป็นประจำ

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

9. การค้นหาแบบไฮบริดดีกว่าการค้นหาเชิงความหมายล้วนๆ

BM25 (คำสำคัญ) + เวกเตอร์ (ความหมาย) + การจัดอันดับใหม่ ให้ผลลัพธ์ที่ดีกว่าการใช้เวกเตอร์เพียงอย่างเดียวอย่างเห็นได้ชัด ชื่อลูกค้า ตัวเลขเฉพาะ วลีที่แน่นอน — การค้นหาเชิงความหมายพลาดสิ่งเหล่านี้ การค้นหาคำสำคัญจับมันได้ ใช้ทั้งสองอย่าง

10. Compaction ไม่ใช่ศัตรู บริบทที่ไม่ได้เขียนต่างหาก

ฉันใช้เวลาหลายวันต่อสู้กับ compaction ก่อนจะตระหนักว่าวิธีแก้ไขนั้นง่ายกว่า: ทำให้แน่ใจว่าสิ่งสำคัญใดๆ ถูกเขียนลงไฟล์ก่อนที่ compaction จะทำงาน Memory flush จัดการสิ่งนี้โดยอัตโนมัติ ถ้ามันอยู่บนดิสก์ มันรอดจาก compaction ถ้ามันอยู่แค่ในการสนทนา มันมีความเสี่ยง

การตั้งค่าปัจจุบันของฉัน

สำหรับการอ้างอิง นี่คือลักษณะพื้นที่ทำงานของฉันในตอนนี้:

workspace/

├── AGENTS.md (boot sequence + วินัยในการเขียน + handover protocol)

├── SOUL.md (บุคลิกภาพและพฤติกรรม)

├── IDENTITY.md (ชื่อ, บทบาท)

├── USER.md (ข้อมูลเจ้าของ)

├── TOOLS.md (แนวทางการใช้เครื่องมือ)

├── HEARTBEAT.md (พฤติกรรมการเช็คอินอัตโนมัติ)

├── MEMORY.md (หน่วยความจำระยะยาวที่ดูแลแล้ว, ~90 บรรทัด)

├── PROTOCOL_COST_EFFICIENCY.md

├── learnings/

│ └── LEARNINGS.md (กฎจากความผิดพลาด)

├── memory/ (บันทึกรายวัน: YYYY-MM-DD.md)

├── docs/ (เอกสารอ้างอิงที่ย้ายออกจาก MEMORY.md)

│ ├── tweetsmash-arch.md

│ ├── knowledge-transfer.md

│ ├── infrastructure.md

│ └── group-chat-rules.md

└── skills/ (32 ทักษะ, ลดลงจาก 51)

System prompt: 8,529 โทเค็น Session tokens: 14,627 จากหน้าต่างบริบท 200,000 โทเค็น (7.3%) เอเจนต์บูท อ่านสิ่งที่ต้องการ เขียนสิ่งที่เรียนรู้ และส่งต่อบริบทยู่ก่อนเปลี่ยนโมเดล

ใช้เวลา 5 วันเพื่อมาถึงจุดนี้ ส่วนใหญ่คือการเลิกเชื่อว่าการมีไฟล์มากขึ้นเท่ากับหน่วยความจำที่ดีขึ้น มันไม่ใช่ วินัยต่างหากที่ใช่ การทดลองของฉันยังคงดำเนินต่อไป

ฉันกำลังสร้าง TweetSmash และ LinkedMash — เครื่องมือบุ๊กมาร์กโซเชียลมีเดียกับผู้ร่วมก่อตั้งของฉัน ฉันแชร์สิ่งที่เรียนรู้เกี่ยวกับการรันเอเจนต์ OpenClaw ในระบบการผลิตบน X: @code_rams