วิกิหน่วยความจำ

memory-wiki คือ Plugin ที่รวมมา ซึ่งเปลี่ยนหน่วยความจำถาวรให้เป็นคลังความรู้ที่คอมไพล์แล้ว

มัน ไม่ได้ แทนที่ Plugin หน่วยความจำที่ใช้งานอยู่ Plugin หน่วยความจำที่ใช้งานอยู่ยังคง เป็นเจ้าของการเรียกคืน การโปรโมต การทำดัชนี และ Dreaming memory-wiki อยู่เคียงข้างมัน และคอมไพล์ความรู้ถาวรให้เป็นวิกิที่นำทางได้ พร้อมหน้าที่กำหนดแน่นอน ข้อกล่าวอ้างที่มีโครงสร้าง แหล่งที่มา แดชบอร์ด และไดเจสต์ที่เครื่องอ่านได้

ใช้เมื่อคุณต้องการให้หน่วยความจำทำงานเหมือนเลเยอร์ความรู้ที่ได้รับการดูแลมากขึ้น และ เหมือนกองไฟล์ Markdown น้อยลง

สิ่งที่เพิ่มเข้ามา

• คลังวิกิโดยเฉพาะพร้อมเลย์เอาต์หน้าที่กำหนดแน่นอน
• เมตาดาต้าข้อกล่าวอ้างและหลักฐานที่มีโครงสร้าง ไม่ใช่แค่ร้อยแก้ว
• แหล่งที่มา ความเชื่อมั่น ข้อขัดแย้ง และคำถามที่เปิดอยู่ในระดับหน้า
• ไดเจสต์ที่คอมไพล์แล้วสำหรับผู้ใช้ระดับ agent/runtime
• เครื่องมือค้นหา/ดึง/ปรับใช้/lint แบบวิกิโดยตรง
• การนำเข้า Open Knowledge Format เข้าสู่แนวคิดวิกิที่คอมไพล์แล้ว
• โหมด bridge เสริมที่นำเข้าอาร์ติแฟกต์สาธารณะจาก Plugin หน่วยความจำที่ใช้งานอยู่
• โหมดเรนเดอร์ที่เป็นมิตรกับ Obsidian และการผสานรวม CLI แบบเสริม

วิธีที่เข้ากับหน่วยความจำ

ให้คิดถึงการแยกแบบนี้:

ถ้า Plugin หน่วยความจำที่ใช้งานอยู่เปิดเผยอาร์ติแฟกต์การเรียกคืนแบบแชร์ OpenClaw จะค้นหา ทั้งสองเลเยอร์ได้ในครั้งเดียวด้วย memory_search corpus=all

เมื่อคุณต้องการการจัดอันดับเฉพาะวิกิ แหล่งที่มา หรือการเข้าถึงหน้าโดยตรง ให้ใช้ เครื่องมือแบบวิกิโดยตรงแทน

รูปแบบไฮบริดที่แนะนำ

ค่าเริ่มต้นที่แข็งแรงสำหรับการตั้งค่าแบบ local-first คือ:

• QMD เป็น backend หน่วยความจำที่ใช้งานอยู่สำหรับการเรียกคืนและการค้นหาเชิงความหมายแบบกว้าง
• memory-wiki ในโหมด bridge สำหรับหน้าความรู้ถาวรที่สังเคราะห์แล้ว

การแยกแบบนั้นทำงานได้ดีเพราะแต่ละเลเยอร์ยังคงมีจุดโฟกัสของตัวเอง:

• QMD ทำให้โน้ตดิบ การส่งออกเซสชัน และคอลเลกชันเพิ่มเติมค้นหาได้
• memory-wiki คอมไพล์เอนทิตี ข้อกล่าวอ้าง แดชบอร์ด และหน้าต้นทางที่เสถียร

กฎเชิงปฏิบัติ:

• ใช้ memory_search เมื่อคุณต้องการเรียกคืนแบบกว้างครั้งเดียวทั่วหน่วยความจำ
• ใช้ wiki_search และ wiki_get เมื่อคุณต้องการผลลัพธ์วิกิที่รับรู้แหล่งที่มา
• ใช้ memory_search corpus=all เมื่อคุณต้องการให้การค้นหาแบบแชร์ครอบคลุมทั้งสองเลเยอร์

ถ้าโหมด bridge รายงานว่าไม่มีอาร์ติแฟกต์ที่ส่งออกเลย แปลว่า Plugin หน่วยความจำที่ใช้งานอยู่ ยังไม่ได้เปิดเผยอินพุต bridge สาธารณะในตอนนี้ ให้รัน openclaw wiki doctor ก่อน แล้วค่อยยืนยันว่า Plugin หน่วยความจำที่ใช้งานอยู่รองรับอาร์ติแฟกต์สาธารณะ

เมื่อโหมด bridge เปิดใช้งานอยู่และเปิด bridge.readMemoryArtifacts openclaw wiki status, openclaw wiki doctor และ openclaw wiki bridge import จะอ่านผ่าน Gateway ที่กำลังทำงานอยู่ วิธีนี้ทำให้การตรวจ bridge ผ่าน CLI สอดคล้อง กับบริบท Plugin หน่วยความจำของ runtime ถ้า bridge ถูกปิดหรือปิดการอ่านอาร์ติแฟกต์ คำสั่งเหล่านั้นจะยังคงพฤติกรรมแบบ local/offline ของตัวเองไว้

โหมดคลัง

memory-wiki รองรับโหมดคลังสามแบบ:

isolated

คลังของตัวเอง แหล่งข้อมูลของตัวเอง ไม่มีการพึ่งพา memory-core

ใช้เมื่อต้องการให้วิกิเป็นแหล่งเก็บความรู้ที่คัดสรรเอง

bridge

อ่านอาร์ติแฟกต์หน่วยความจำสาธารณะและอีเวนต์หน่วยความจำจาก Plugin หน่วยความจำที่ใช้งานอยู่ ผ่านขอบเขต public plugin SDK

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

โหมด bridge ทำดัชนีได้:

• อาร์ติแฟกต์หน่วยความจำที่ส่งออก
• รายงาน dream
• โน้ตรายวัน
• ไฟล์รากของหน่วยความจำ
• ล็อกอีเวนต์หน่วยความจำ

unsafe-local

ช่องทางออกแบบ same-machine ที่ชัดเจนสำหรับพาธส่วนตัวในเครื่อง

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

เลย์เอาต์คลัง

Plugin เริ่มต้นคลังแบบนี้:

<vault>/  AGENTS.md  WIKI.md  index.md  inbox.md  entities/  concepts/  syntheses/  sources/  reports/  _attachments/  _views/  .openclaw-wiki/

เนื้อหาที่จัดการจะอยู่ภายในบล็อกที่สร้างขึ้น บล็อกโน้ตของมนุษย์จะถูกเก็บรักษาไว้

กลุ่มหน้าหลักคือ:

• sources/ สำหรับวัตถุดิบนำเข้าและหน้าที่หนุนด้วย bridge
• entities/ สำหรับสิ่งต่าง ๆ บุคคล ระบบ โปรเจกต์ และวัตถุที่ถาวร
• concepts/ สำหรับไอเดีย นามธรรม รูปแบบ และนโยบาย
• syntheses/ สำหรับสรุปที่คอมไพล์แล้วและ rollup ที่ดูแลไว้
• reports/ สำหรับแดชบอร์ดที่สร้างขึ้น

การนำเข้า Open Knowledge Format

memory-wiki สามารถนำเข้าบันเดิล Open Knowledge Format ที่แตกไฟล์แล้วด้วย:

openclaw wiki okf import ./bundles/ga4

นี่เป็นรูปแบบที่เหมาะที่สุดเมื่อแค็ตตาล็อกข้อมูล crawler เอกสาร หรือ agent เสริมข้อมูลผลิต OKF อยู่แล้ว: เก็บ OKF เป็นอาร์ติแฟกต์แลกเปลี่ยนแบบพกพา จากนั้นให้ memory-wiki เปลี่ยนมันเป็นหน้าแนวคิดแบบ OpenClaw-native และ ไดเจสต์ที่คอมไพล์แล้ว

ตัวนำเข้าทำตามรูปทรง OKF v0.1:

• ไฟล์ .md ที่ไม่สงวนไว้เป็นเอกสารแนวคิด
• แนวคิดที่นำเข้าแต่ละรายการต้องมีฟิลด์ frontmatter type ที่ไม่ว่าง
• ค่า type ของ OKF ที่ไม่รู้จักจะถูกยอมรับ
• ไฟล์ index.md และ log.md ที่สงวนไว้จะไม่ถูกนำเข้าเป็นแนวคิด
• ลิงก์ markdown ที่เสียหรือเป็นภายนอกจะถูกเก็บรักษาไว้

หน้าแนวคิดที่นำเข้าจะถูก flatten ไว้ใต้ concepts/ เพื่อให้เส้นทาง compile, search, get, dashboard และ prompt-digest ที่มีอยู่เห็นได้โดยไม่ต้องเพิ่ม ต้นไม้วิกิที่สอง แต่ละหน้าจะเก็บ ID แนวคิด OKF เดิม พาธต้นทาง type, resource, tags, timestamp และ frontmatter จาก producer ทั้งหมด ลิงก์ OKF ภายใน จะถูกเขียนใหม่ไปยังหน้าแนวคิดวิกิที่สร้างขึ้น และยังถูกปล่อยออกมาเป็นรายการ relationships แบบมีโครงสร้างพร้อม kind: okf-link

ข้อกล่าวอ้างและหลักฐานแบบมีโครงสร้าง

หน้าสามารถมี frontmatter claims แบบมีโครงสร้าง ไม่ใช่แค่ข้อความอิสระ

แต่ละข้อกล่าวอ้างมีได้:

• id
• text
• status
• confidence
• evidence[]
• updatedAt

รายการหลักฐานมีได้:

• kind
• sourceId
• path
• lines
• weight
• confidence
• privacyTier
• note
• updatedAt

นี่คือสิ่งที่ทำให้วิกิทำตัวเหมือนเลเยอร์ความเชื่อมากกว่ากองโน้ตแบบนิ่ง ข้อกล่าวอ้างสามารถถูกติดตาม ให้คะแนน โต้แย้ง และโยงกลับไปยังแหล่งข้อมูลได้

เมตาดาต้าเอนทิตีสำหรับ agent

หน้าเอนทิตียังสามารถมีเมตาดาต้า routing สำหรับใช้งานโดย agent ได้ด้วย นี่เป็น frontmatter ทั่วไป จึงใช้ได้กับบุคคล ทีม ระบบ โปรเจกต์ หรือ เอนทิตีประเภทอื่นใด

ฟิลด์ทั่วไปประกอบด้วย:

• entityType: เช่น person, team, system หรือ project
• canonicalId: คีย์ตัวตนที่เสถียรซึ่งใช้ข้าม alias และการนำเข้า
• aliases: ชื่อ handle หรือ label ที่ควร resolve ไปยังหน้าเดียวกัน
• privacyTier: public, local-private, sensitive หรือ confirm-before-use
• bestUsedFor / notEnoughFor: คำใบ้ routing แบบกระชับ
• lastRefreshedAt: timestamp การรีเฟรชแหล่งข้อมูลที่แยกจากเวลาแก้ไขหน้า
• personCard: การ์ด routing เฉพาะบุคคลแบบเสริม พร้อม handles, socials, emails, timezone, lane, ask-for, avoid-asking-for, confidence และ privacy
• relationships: edge แบบมีชนิดไปยังหน้าที่เกี่ยวข้อง พร้อม target, kind, weight, confidence, evidence kind, privacy tier และ note

สำหรับวิกิบุคคล โดยปกติ agent ควรเริ่มที่ reports/person-agent-directory.md จากนั้นเปิดหน้าบุคคลด้วย wiki_get ก่อนใช้รายละเอียดการติดต่อหรือข้อเท็จจริงที่อนุมานมา

ตัวอย่าง:

pageType: entityentityType: personid: entity.brad-grouxcanonicalId: maintainer.brad-grouxaliases:  - Brad  - bgrouxprivacyTier: local-privatebestUsedFor:  - Microsoft Teams and Azure routingnotEnoughFor:  - legal approvallastRefreshedAt: "2026-04-29T00:00:00.000Z"personCard:  handles:    - "@bgroux"  socials:    - "https://x.example/bgroux"  emails:    - brad@example.com  timezone: America/Chicago  lane: Microsoft ecosystem  askFor:    - Teams rollout questions  avoidAskingFor:    - unrelated billing decisions  confidence: 0.8  privacyTier: confirm-before-userelationships:  - targetId: entity.alice    targetTitle: Alice    kind: collaborates-with    confidence: 0.7    evidenceKind: discrawl-statclaims:  - id: claim.brad.teams    text: Brad is useful for Microsoft Teams routing.    status: supported    confidence: 0.9    evidence:      - kind: maintainer-whois        sourceId: source.maintainers        privacyTier: local-private

pipeline การคอมไพล์

ขั้นตอนการคอมไพล์อ่านหน้าวิกิ normalize สรุป และปล่อยอาร์ติแฟกต์ สำหรับเครื่องที่เสถียรไว้ใต้:

• .openclaw-wiki/cache/agent-digest.json
• .openclaw-wiki/cache/claims.jsonl

ไดเจสต์เหล่านี้มีไว้เพื่อให้ agents และโค้ด runtime ไม่ต้อง scrape หน้า Markdown

เอาต์พุตที่คอมไพล์แล้วยังขับเคลื่อน:

• การทำดัชนีวิกิรอบแรกสำหรับ flow การค้นหา/ดึง
• การ lookup claim-id กลับไปยังหน้าที่เป็นเจ้าของ
• ส่วนเสริม prompt แบบกระชับ
• การสร้างรายงาน/แดชบอร์ด

แดชบอร์ดและรายงานสุขภาพ

เมื่อเปิดใช้งาน render.createDashboards การคอมไพล์จะดูแลแดชบอร์ดไว้ใต้ reports/

รายงานในตัวประกอบด้วย:

• reports/open-questions.md
• reports/contradictions.md
• reports/low-confidence.md
• reports/claim-health.md
• reports/stale-pages.md
• reports/person-agent-directory.md
• reports/relationship-graph.md
• reports/provenance-coverage.md
• reports/privacy-review.md

รายงานเหล่านี้ติดตามสิ่งต่าง ๆ เช่น:

• คลัสเตอร์โน้ตข้อขัดแย้ง
• คลัสเตอร์ข้อกล่าวอ้างที่แข่งขันกัน
• ข้อกล่าวอ้างที่ไม่มีหลักฐานแบบมีโครงสร้าง
• หน้าและข้อกล่าวอ้างที่มีความเชื่อมั่นต่ำ
• ความสดใหม่ที่ล้าสมัยหรือไม่ทราบ
• หน้าที่มีคำถามยังไม่ resolved
• การ์ด routing ของบุคคล/เอนทิตี
• edge ความสัมพันธ์แบบมีโครงสร้าง
• ความครอบคลุมของชั้นหลักฐาน
• privacy tier ที่ไม่เป็นสาธารณะซึ่งต้องตรวจทานก่อนใช้

การค้นหาและการดึงข้อมูล

memory-wiki รองรับ backend การค้นหาสองแบบ:

• shared: ใช้ flow การค้นหาหน่วยความจำแบบแชร์เมื่อมี
• local: ค้นหาวิกิในเครื่อง

ยังรองรับ corpora สามแบบด้วย:

• wiki
• memory
• all

พฤติกรรมสำคัญ:

• wiki_search และ wiki_get ใช้ไดเจสต์ที่คอมไพล์แล้วเป็นรอบแรกเมื่อทำได้
• claim ids สามารถ resolve กลับไปยังหน้าที่เป็นเจ้าของได้
• ข้อกล่าวอ้างที่ถูกโต้แย้ง/ล้าสมัย/สดใหม่มีผลต่อการจัดอันดับ
• label แหล่งที่มาสามารถอยู่รอดไปถึงผลลัพธ์ได้
• โหมดค้นหาสามารถ bias การจัดอันดับสำหรับการค้นหาบุคคล routing คำถาม หลักฐาน จากแหล่งข้อมูล หรือข้อกล่าวอ้างดิบ

กฎเชิงปฏิบัติ:

• ใช้ memory_search corpus=all สำหรับการเรียกคืนแบบกว้างครั้งเดียว
• ใช้ wiki_search + wiki_get เมื่อคุณให้ความสำคัญกับการจัดอันดับเฉพาะวิกิ แหล่งที่มา หรือโครงสร้างความเชื่อระดับหน้า

โหมดค้นหา:

• auto: ค่าเริ่มต้นแบบสมดุล
• find-person: boost เอนทิตีที่เหมือนบุคคล alias, handle, social และ canonical ID
• route-question: boost การ์ด agent, คำใบ้ ask-for, คำใบ้ best-used-for และ บริบทความสัมพันธ์
• source-evidence: boost หน้าต้นทางและเมตาดาต้าหลักฐานแบบมีโครงสร้าง
• raw-claim: boost ข้อกล่าวอ้างแบบมีโครงสร้างที่ตรงกัน และส่งคืนเมตาดาต้า claim/evidence ในผลลัพธ์

เมื่อผลลัพธ์ตรงกับข้อกล่าวอ้างแบบมีโครงสร้าง wiki_search สามารถส่งคืน matchedClaimId, matchedClaimStatus, matchedClaimConfidence, evidenceKinds และ evidenceSourceIds ใน payload รายละเอียดได้ เอาต์พุตข้อความ ยังรวมบรรทัด Claim: และ Evidence: แบบกระชับเมื่อมี

เครื่องมือสำหรับ agent

Plugin ลงทะเบียนเครื่องมือเหล่านี้:

• wiki_status
• wiki_search
• wiki_get
• wiki_apply
• wiki_lint

สิ่งที่เครื่องมือทำ:

• wiki_status: โหมดคลังปัจจุบัน สุขภาพ ความพร้อมใช้งานของ Obsidian CLI
• wiki_search: ค้นหาหน้าวิกิ และเมื่อกำหนดค่าไว้ ค้นหา corpora หน่วยความจำแบบแชร์; รับ mode สำหรับการค้นหาบุคคล routing คำถาม หลักฐานจากแหล่งข้อมูล หรือการ drilldown ข้อกล่าวอ้างดิบ
• wiki_get: อ่านหน้าวิกิตาม id/path หรือ fallback ไปยัง corpus หน่วยความจำแบบแชร์
• wiki_apply: การกลายพันธุ์ synthesis/metadata แบบแคบโดยไม่ผ่าตัดหน้าแบบ freeform
• wiki_lint: การตรวจโครงสร้าง ช่องว่างแหล่งที่มา ข้อขัดแย้ง คำถามที่เปิดอยู่

Plugin ยังลงทะเบียนส่วนเสริมคลังข้อมูลหน่วยความจำแบบไม่ผูกขาดด้วย ดังนั้น memory_search และ memory_get ที่ใช้ร่วมกันจึงเข้าถึง wiki ได้เมื่อ Plugin หน่วยความจำที่ใช้งานอยู่ รองรับการเลือกคลังข้อมูล

พฤติกรรมของพรอมป์และบริบท

เมื่อเปิดใช้ context.includeCompiledDigestPrompt ส่วนพรอมป์หน่วยความจำ จะเพิ่มสแนปช็อตที่คอมไพล์แล้วแบบกระชับจาก agent-digest.json

สแนปช็อตนั้นตั้งใจให้มีขนาดเล็กและมีสัญญาณสำคัญสูง:

• เฉพาะหน้าสำคัญที่สุด
• เฉพาะข้อกล่าวอ้างสำคัญที่สุด
• จำนวนข้อขัดแย้ง
• จำนวนคำถาม
• ตัวระบุคุณภาพด้านความมั่นใจ/ความสดใหม่

ตัวเลือกนี้เป็นแบบ opt-in เพราะมันเปลี่ยนรูปทรงพรอมป์ และมีประโยชน์เป็นหลักสำหรับเอนจินบริบท หรือการประกอบพรอมป์แบบเดิมที่ใช้ส่วนเสริมหน่วยความจำอย่างชัดเจน

การกำหนดค่า

ใส่การกำหนดค่าไว้ใต้ plugins.entries.memory-wiki.config:

{  plugins: {    entries: {      "memory-wiki": {        enabled: true,        config: {          vaultMode: "isolated",          vault: {            path: "~/.openclaw/wiki/main",            renderMode: "obsidian",          },          obsidian: {            enabled: true,            useOfficialCli: true,            vaultName: "OpenClaw Wiki",            openAfterWrites: false,          },          bridge: {            enabled: false,            readMemoryArtifacts: true,            indexDreamReports: true,            indexDailyNotes: true,            indexMemoryRoot: true,            followMemoryEvents: true,          },          ingest: {            autoCompile: true,            maxConcurrentJobs: 1,            allowUrlIngest: true,          },          search: {            backend: "shared",            corpus: "wiki",          },          context: {            includeCompiledDigestPrompt: false,          },          render: {            preserveHumanBlocks: true,            createBacklinks: true,            createDashboards: true,          },        },      },    },  },}

สวิตช์สำคัญ:

• vaultMode: isolated, bridge, unsafe-local
• vault.renderMode: native หรือ obsidian
• bridge.readMemoryArtifacts: นำเข้าอาร์ติแฟกต์สาธารณะของ Plugin หน่วยความจำที่ใช้งานอยู่
• bridge.followMemoryEvents: รวมบันทึกเหตุการณ์ในโหมด bridge
• search.backend: shared หรือ local
• search.corpus: wiki, memory, หรือ all
• context.includeCompiledDigestPrompt: เพิ่มสแนปช็อต digest แบบกระชับต่อท้ายส่วนพรอมป์หน่วยความจำ
• render.createBacklinks: สร้างบล็อกที่เกี่ยวข้องแบบกำหนดได้ซ้ำเสมอ
• render.createDashboards: สร้างหน้าแดชบอร์ด

ตัวอย่าง: โหมด QMD + bridge

ใช้ตัวเลือกนี้เมื่อคุณต้องการ QMD สำหรับการเรียกคืน และ memory-wiki สำหรับชั้นความรู้ ที่ดูแลรักษาไว้:

{  memory: {    backend: "qmd",  },  plugins: {    entries: {      "memory-wiki": {        enabled: true,        config: {          vaultMode: "bridge",          bridge: {            enabled: true,            readMemoryArtifacts: true,            indexDreamReports: true,            indexDailyNotes: true,            indexMemoryRoot: true,            followMemoryEvents: true,          },          search: {            backend: "shared",            corpus: "all",          },          context: {            includeCompiledDigestPrompt: false,          },        },      },    },  },}

สิ่งนี้จะคงไว้:

• QMD รับผิดชอบการเรียกคืน Active Memory
• memory-wiki มุ่งเน้นหน้าที่คอมไพล์แล้วและแดชบอร์ด
• รูปทรงพรอมป์ไม่เปลี่ยนแปลงจนกว่าคุณจะเปิดใช้พรอมป์ digest ที่คอมไพล์แล้วโดยตั้งใจ

CLI

memory-wiki ยังเปิดเผยพื้นผิว CLI ระดับบนสุดด้วย:

openclaw wiki statusopenclaw wiki doctoropenclaw wiki initopenclaw wiki ingest ./notes/alpha.mdopenclaw wiki compileopenclaw wiki lintopenclaw wiki search "alpha"openclaw wiki get entity.alphaopenclaw wiki apply synthesis "Alpha Summary" --body "..." --source-id source.alphaopenclaw wiki bridge importopenclaw wiki obsidian status

ดูข้อมูลอ้างอิงคำสั่งฉบับเต็มได้ที่ CLI: wiki

การรองรับ Obsidian

เมื่อ vault.renderMode เป็น obsidian Plugin จะเขียน Markdown ที่เป็นมิตรกับ Obsidian และสามารถเลือกใช้ CLI ทางการ obsidian ได้

เวิร์กโฟลว์ที่รองรับประกอบด้วย:

• การตรวจสอบสถานะ
• การค้นหา vault
• การเปิดหน้า
• การเรียกใช้คำสั่ง Obsidian
• การข้ามไปยังโน้ตประจำวัน

ส่วนนี้เป็นทางเลือก wiki ยังคงทำงานในโหมด native ได้โดยไม่มี Obsidian

เวิร์กโฟลว์ที่แนะนำ

1. เก็บ Plugin หน่วยความจำที่ใช้งานอยู่ของคุณไว้สำหรับการเรียกคืน/การเลื่อนระดับ/Dreaming
2. เปิดใช้ memory-wiki
3. เริ่มด้วยโหมด isolated เว้นแต่คุณต้องการโหมด bridge อย่างชัดเจน
4. ใช้ wiki_search / wiki_get เมื่อแหล่งที่มามีความสำคัญ
5. ใช้ wiki_apply สำหรับการสังเคราะห์แบบแคบหรือการอัปเดตเมทาดาทา
6. รัน wiki_lint หลังจากมีการเปลี่ยนแปลงสำคัญ
7. เปิดแดชบอร์ดหากคุณต้องการมองเห็นความล้าสมัย/ข้อขัดแย้ง

เอกสารที่เกี่ยวข้อง

• ภาพรวมหน่วยความจำ
• CLI: memory
• CLI: wiki
• ภาพรวม Plugin SDK