核心观点

• 记忆全量索引，但按需调用 OpenClaw 把聊天记录和生成的文档都向量化+文本化进 Memory 索引，但不自动拼进上下文。Agent 通过 memory_search 和 memory_get 两个 tool 主动检索。这个设计极其简洁——把"什么时候需要记忆"的判断权交给了模型本身，而不是靠规则硬塞。

• 双路检索：BM25 + Vector Search 经典 RAG 组合，chunks 表存文本（路径、行范围、内容），向量在 chunks_vec，全文在 chunks_fts。没有花哨的 reranker 或多级检索，够用就行。这种"不过度工程"的态度值得学。

• 工作区文件也被索引——这个被低估了 不只是会话记录，OpenClaw 对工作区生成的 .md 文件也做了 chunks。意味着 Agent 写的文档、笔记、配置都变成了可检索的记忆。这让"Agent 的产出反哺 Agent 的认知"成为闭环。

• 增量索引 + compact 机制 会话的 .jsonl 做增量 chunks，监控变化到阈值后索引。/compact 会把旧消息压缩为摘要并改写 JSONL。这解决了长会话的上下文膨胀问题，但也意味着细节会丢失——trade-off 是清晰的。

• 对比 Character AI 的 profile 注入：OpenClaw 更"Agent" 大多数 Character AI 维护一份用户 Profile（姓名、喜好等）每次注入 system prompt。OpenClaw 认为这"显得有点多余"——因为如果 Agent 真的需要这些信息，它会自己去查。这个哲学差异很大：前者是"假设 Agent 需要"，后者是"让 Agent 自己判断需不需要"。

跟我们的关联

🪞Uota — Uota 当前的记忆架构（MEMORY.md + daily notes + SOUL.md 注入）其实更接近 Character AI 的 profile 注入模式，而不是 OpenClaw 的按需检索模式。值得思考：Uota 是否应该把部分"每次必读"的文件改为按需检索？特别是 MEMORY.md 越来越大之后，全量注入的 token 成本会成为问题。

🧠Neta — Neta 的角色记忆系统可以参考这个思路：与其每次把角色 profile 全塞进上下文，不如让模型按需检索角色属性。对于属性丰富的 OC（原创角色），这能显著降低 token 消耗同时保持一致性。

讨论引子

1. Uota 的 MEMORY.md 现在是每次主 session 全量注入的。如果改成按需检索（类似 OpenClaw 的 memory_search），会丢失什么？会获得什么？临界点在哪——MEMORY.md 多大的时候应该切换？

2. "让 Agent 自己判断需不需要记忆"听起来很美，但前提是模型足够聪明。如果模型判断失误、该查的没查，用户体验会直接崩。OpenClaw 敢这么做，是因为它面向的是开发者而非普通用户——Neta 的角色 AI 面向的是普通用户，能承受这个风险吗？

3. 增量索引 + compact 意味着旧对话的细节会被摘要替代。对于 Neta 的角色来说，用户三个月前说过的一句玩笑话可能是情感连接的关键——这种"细节"该怎么保？全存太贵，不存会断。