Sessions and memory

การจัดการเซสชัน

OpenClaw จัดระเบียบการสนทนาเป็น เซสชัน ข้อความแต่ละรายการจะถูกกำหนดเส้นทางไปยัง เซสชันตามแหล่งที่มา -- DM, แชตกลุ่ม, cron jobs และอื่นๆ

วิธีการกำหนดเส้นทางข้อความ

แหล่งที่มา พฤติกรรม
ข้อความโดยตรง ใช้เซสชันร่วมกันตามค่าเริ่มต้น
แชตกลุ่ม แยกตามกลุ่ม
ห้อง/ช่องทาง แยกตามห้อง
Cron jobs เซสชันใหม่ต่อการรันแต่ละครั้ง
Webhooks แยกตาม hook

การแยก DM

ตามค่าเริ่มต้น DM ทั้งหมดจะใช้เซสชันเดียวร่วมกันเพื่อความต่อเนื่อง วิธีนี้เหมาะสำหรับ การตั้งค่าสำหรับผู้ใช้คนเดียว

วิธีแก้:

json5
{  session: {    dmScope: "per-channel-peer", // isolate by channel + sender  },}

ตัวเลือกอื่นๆ:

  • main (ค่าเริ่มต้น) -- DM ทั้งหมดใช้เซสชันเดียวร่วมกัน
  • per-peer -- แยกตามผู้ส่ง (ข้ามช่องทาง)
  • per-channel-peer -- แยกตามช่องทาง + ผู้ส่ง (แนะนำ)
  • per-account-channel-peer -- แยกตามบัญชี + ช่องทาง + ผู้ส่ง

Dock ช่องทางที่เชื่อมโยง

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

ตรวจสอบการตั้งค่าของคุณด้วย openclaw security audit

วงจรชีวิตของเซสชัน

เซสชันจะถูกนำกลับมาใช้จนกว่าจะหมดอายุ:

  • รีเซ็ตรายวัน (ค่าเริ่มต้น) -- เซสชันใหม่เวลา 4:00 น. ตามเวลาท้องถิ่นบนโฮสต์ Gateway ความใหม่รายวันอิงตามเวลาที่ sessionId ปัจจุบันเริ่มต้น ไม่ใช่ การเขียนเมตาดาต้าในภายหลัง
  • รีเซ็ตเมื่อไม่ได้ใช้งาน (ไม่บังคับ) -- เซสชันใหม่หลังจากไม่มีการใช้งานเป็นระยะเวลาหนึ่ง ตั้งค่า session.reset.idleMinutes ความใหม่เมื่อไม่ได้ใช้งานอิงตามการโต้ตอบจริงล่าสุดของผู้ใช้/ช่องทาง ดังนั้น Heartbeat, Cron และเหตุการณ์ระบบ exec จะไม่ ทำให้เซสชันยังคงอยู่
  • รีเซ็ตด้วยตนเอง -- พิมพ์ /new หรือ /reset ในแชต /new <model> ยัง เปลี่ยนโมเดลด้วย

เมื่อกำหนดค่าทั้งการรีเซ็ตรายวันและการรีเซ็ตเมื่อไม่ได้ใช้งาน รายการใดหมดอายุก่อนจะมีผล Heartbeat, Cron, exec และ turn ของเหตุการณ์ระบบอื่นๆ อาจเขียนเมตาดาต้าเซสชัน แต่การเขียนเหล่านั้นจะไม่ขยายความใหม่ของการรีเซ็ตรายวันหรือเมื่อไม่ได้ใช้งาน เมื่อการรีเซ็ต หมุนเซสชัน ประกาศเหตุการณ์ระบบที่อยู่ในคิวสำหรับเซสชันเก่าจะถูก ทิ้ง เพื่อไม่ให้การอัปเดตเบื้องหลังที่ค้างอยู่ถูกเติมไว้หน้าพรอมป์แรกใน เซสชันใหม่

เซสชันที่มีเซสชัน CLI ที่ provider เป็นเจ้าของและยังใช้งานอยู่จะไม่ถูกตัดโดยค่าเริ่มต้นรายวัน แบบโดยนัย ใช้ /reset หรือกำหนดค่า session.reset อย่างชัดเจนเมื่อควรให้ เซสชันเหล่านั้นหมดอายุตามตัวจับเวลา

ตำแหน่งที่เก็บสถานะ

สถานะเซสชันทั้งหมดเป็นของ Gateway ไคลเอนต์ UI จะสอบถาม Gateway เพื่อรับ ข้อมูลเซสชัน

  • ที่เก็บ: ~/.openclaw/agents/<agentId>/sessions/sessions.json
  • ทรานสคริปต์: ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl

sessions.json เก็บ timestamp ของวงจรชีวิตแยกกัน:

  • sessionStartedAt: เวลาที่ sessionId ปัจจุบันเริ่มต้น; การรีเซ็ตรายวันใช้ค่านี้
  • lastInteractionAt: การโต้ตอบของผู้ใช้/ช่องทางล่าสุดที่ขยายอายุเมื่อไม่ได้ใช้งาน
  • updatedAt: การกลายพันธุ์ของแถวในที่เก็บล่าสุด; มีประโยชน์สำหรับการแสดงรายการและการ prune แต่ไม่ใช่ แหล่งอ้างอิงที่เชื่อถือได้สำหรับความใหม่ของการรีเซ็ตรายวัน/เมื่อไม่ได้ใช้งาน

แถวเก่าที่ไม่มี sessionStartedAt จะถูก resolve จาก header เซสชัน JSONL ของทรานสคริปต์ เมื่อมี หากแถวเก่ายังไม่มี lastInteractionAt ด้วย ความใหม่เมื่อไม่ได้ใช้งานจะ fallback ไปยังเวลาเริ่มเซสชันนั้น ไม่ใช่การเขียน bookkeeping ในภายหลัง

การบำรุงรักษาเซสชัน

OpenClaw จำกัดพื้นที่จัดเก็บเซสชันโดยอัตโนมัติเมื่อเวลาผ่านไป ตามค่าเริ่มต้น จะทำงาน ในโหมด enforce และใช้การ cleanup ระหว่างการบำรุงรักษา ตั้งค่า session.maintenance.mode เป็น "warn" เพื่อรายงานสิ่งที่จะถูก cleanup โดยไม่เปลี่ยนแปลงที่เก็บ/ไฟล์:

json5
{  session: {    maintenance: {      mode: "enforce",      pruneAfter: "30d",      maxEntries: 500,    },  },}

สำหรับขีดจำกัด maxEntries ระดับ production การเขียนของ runtime Gateway จะใช้ high-water buffer ขนาดเล็กและ cleanup กลับลงมาถึง cap ที่กำหนดค่าไว้เป็นชุด การอ่าน session store จะไม่ prune หรือ cap entries ระหว่างการเริ่มต้น Gateway วิธีนี้หลีกเลี่ยงการเรียกใช้การ cleanup store แบบเต็มทุกครั้งที่เริ่มต้นหรือทุกเซสชัน cron แบบแยก openclaw sessions cleanup --enforce จะใช้ cap ทันที

เซสชัน probe การรันโมเดลของ Gateway มีอายุสั้นตามค่าเริ่มต้น แถวที่ตรงกับ คีย์ชัดเจนแบบเข้มงวด เช่น agent:*:explicit:model-run-<uuid> ใช้ระยะเก็บคงที่ 24h แต่การ cleanup จะถูก gate ด้วยแรงกดดัน: จะลบแถว probe ที่ค้างเฉพาะเมื่อ ถึงแรงกดดันจาก maintenance/cap ของ session-entry เท่านั้น เมื่อ cleanup model-run ทำงาน จะทำงานก่อน cutoff อายุ stale-entry ที่กว้างกว่าและ cap ของ entry เซสชัน direct ปกติ group, thread, cron, hook, heartbeat, ACP และ sub-agent จะไม่สืบทอด ระยะเก็บ 24 ชั่วโมงนี้

การบำรุงรักษาจะรักษาตัวชี้การสนทนาภายนอกที่คงทนไว้ รวมถึงเซสชันกลุ่ม และเซสชันแชตที่ scoped ตาม thread ขณะเดียวกันยังอนุญาตให้รายการ cron, hook, heartbeat, ACP และ sub-agent แบบสังเคราะห์หมดอายุออกไปได้

หากก่อนหน้านี้คุณใช้การแยก direct-message และภายหลังเปลี่ยน session.dmScope กลับเป็น main ให้ preview แถว DM แบบ peer-keyed ที่ค้างอยู่ด้วย openclaw sessions cleanup --dry-run --fix-dm-scope การใช้ flag เดียวกัน จะ retire แถว direct-DM เก่าเหล่านั้นและเก็บทรานสคริปต์ของแถวเหล่านั้นไว้เป็น archive ที่ถูกลบ

Preview ด้วย openclaw sessions cleanup --dry-run

การตรวจสอบเซสชัน

  • openclaw status -- path ของ session store และกิจกรรมล่าสุด
  • openclaw sessions --json -- เซสชันทั้งหมด (กรองด้วย --active <minutes>)
  • /status ในแชต -- การใช้บริบท โมเดล และ toggle
  • /context list -- สิ่งที่อยู่ใน system prompt

อ่านเพิ่มเติม

  • Session Pruning -- การตัดแต่งผลลัพธ์ของเครื่องมือ
  • Compaction -- การสรุปการสนทนายาว
  • Session Tools -- เครื่องมือเอเจนต์สำหรับงานข้ามเซสชัน
  • Session Management Deep Dive -- schema ของ store, ทรานสคริปต์, นโยบายการส่ง, เมตาดาต้า origin และการกำหนดค่าขั้นสูง
  • Multi-Agent — การกำหนดเส้นทางและการแยกเซสชันข้ามเอเจนต์
  • Background Tasks — วิธีที่งานแบบ detached สร้าง task records พร้อมการอ้างอิงเซสชัน
  • Channel Routing — วิธีที่ข้อความขาเข้าถูกกำหนดเส้นทางไปยังเซสชัน

ที่เกี่ยวข้อง

Was this useful?
On this page

On this page