关于记忆系统在长期/大型项目场景下的局限性 — 是否有改进计划？

[kxsk-git]

Hi nanobot 团队，

首先非常感谢你们的这个项目。我是因为对 OpenClaw 感兴趣而接触到 nanobot 的，它给了我一个很好的学习方向。我真的很喜欢这套代码——整洁、轻巧、容易上手，探索起来是一种享受。

不过在使用一段时间后，我发现当前的记忆系统存在一些局限性，想反馈一下：

遇到的问题

在周期较长或项目较大的场景中，现有的记忆系统（Session → history.jsonl → MEMORY.md + Dream 提炼）在保留细节方面有些吃力。由于 history.jsonl 和 MEMORY.md 基本上是以整块文本的形式注入上下文窗口的，随着对话增长，较早但仍相关的上下文容易被稀释或截断。这导致助手很难回忆起之前会话中的具体决策或细微考量。

关于 Dream 自动创建 skill

我注意到 Dream 会自动从历史对话中提取 skill。但实际使用下来，这个功能的效果比较有限：自动生成的技能往往记忆不够完整，而且很多场景下用户完全可以通过系统自带的能力手动创建一个 SOP 式的 skill。比如，用户在对话框输入"使用 skill-creator 将我的对话内容生成一个工作流技能存储在工作区，遇到同类工作时使用该技能"，一样能达到效果，甚至更可控。nanobot 的优势本就在于轻巧灵活，手动创建 skill 既轻量又直接。如果维护 Dream 的 skill 自动提取需要投入不少精力（比如去重等问题），或许可以考虑简化这部分逻辑，把资源集中在更核心的模块上。

关于项目方向的感受

另外，作为一个很看重 nanobot"轻巧"特质的用户，我也有一点小小的担心：项目如果持续增加自动化功能（比如自动 skill 生成、自动记忆压缩的多层管道），可能会让原本简洁的架构变得越来越重。对我个人而言，nanobot 最吸引人的地方正是它的可控和透明——记忆文件我能直接编辑，技能我能手动创建。如果核心记忆系统的体验能先打磨好，其他自动化功能或许可以放在更次要的位置，甚至交给用户按需启用。

关于模型提供商配置

还有一个类似的观察是关于模型提供商的配置。目前 nanobot 内置支持了很多家模型厂商，但实际上绝大多数都可以通过 openai-completions 或 anthropic-messages 这两个标准协议来接入。过多的内置提供商配置反而让配置项变得繁杂，也增加了维护面。如果能精简到以这两个协议为核心，让用户自行填入 base URL 和 model name，或许更符合项目"轻巧"的初衷。

举个例子，在本次团队尚未更新某个 post 之前的版本里，我使用 Kimi Coding Plan 时首先尝试了内置的"月之暗面"配置，结果失败了；后来换成直接用 anthropic 通用协议配置，一次就成功了。如果只有这两个通用协议存在，用户的试错路径会更短，也不容易陷入"必须选对应厂商入口"的误区。

想请教的问题

项目是否有计划对记忆架构进行演进？例如：

• 引入 daily notes 式的分层（类似 OpenClaw 的 memory/YYYY-MM-DD.md），以改善会话之间的连续性？
• 为记忆文件增加 语义检索 或关键词搜索，只加载相关片段？
• 还是说当前设计被认为是稳定的，改进方向更多依赖 prompt 工程而非结构性调整？

我很乐意帮忙测试实验分支，虽然我的编程能力还在成长中。只是想把这个问题提出来，看看是否与你们的路线图有所重合。

再次感谢你们的出色工作！

[1723229]

@Re-bin @chengyongru 两位佬看看，关于历史记忆和跨会话，添加session_search 工具 使用SQLite + FTS5 在本项目是否有接入的价值呢

[chengyongru]

其实我个人更倾向于保持简单的记忆机制，现在的history+dream一定程度上挺优雅的，如果引入过多的机制，如rag等，其实是在为模型的能力打补丁，当有一天模型的能力产生了更大的提升， 这些补丁都是技术债务

关于dream自动创建skill效果比较差这一点，其实归根到底我认为还是模型能力的问题, btw, 那怕现在加了很多记忆机制，手动编辑soul、user、memory等文件也是可行的

模型提供商配置这个其实我之前有一点改进的想法，比如可以只问用户要apikey，然后并行去探测这个apikey属于哪个厂商，但是其实有点tricky， 试了一下感觉实际价值不大

以上只是我个人暂时的想法， 也是在不断的学习中，欢迎大家提出自己的想法，如果真的有效且好用的话， why not?

---

Personally, I lean toward keeping the memory mechanism simple. The current history + Dream setup is actually quite elegant. Introducing more complex mechanisms like RAG feels like patching around model limitations — and when models get better, those patches just become technical debt.

As for Dream's auto skill-creation being underwhelming — I think that's fundamentally a model capability issue too. That said, even with all the memory mechanisms in place, manually editing files like SOUL.md, USER.md, and MEMORY.md remains a perfectly viable approach.

On the model provider configuration, I did have an idea earlier — for example, we could just ask the user for an API key and probe which provider it belongs to in parallel. But it's a bit tricky, and after trying it out, I didn't feel the practical value was significant enough.

These are just my personal thoughts for now — I'm still learning as I go. Happy to hear other perspectives. If something truly works well, why not?

[Re-bin]

可控和透明会一直保持，因为nb最重要的是优雅 :)

[kxsk-git]

其实我个人更倾向于保持简单的记忆机制，现在的history+dream一定程度上挺优雅的，如果引入过多的机制，如rag等，其实是在为模型的能力打补丁，当有一天模型的能力产生了更大的提升， 这些补丁都是技术债务

关于dream自动创建skill效果比较差这一点，其实归根到底我认为还是模型能力的问题, btw, 那怕现在加了很多记忆机制，手动编辑soul、user、memory等文件也是可行的

模型提供商配置这个其实我之前有一点改进的想法，比如可以只问用户要apikey，然后并行去探测这个apikey属于哪个厂商，但是其实有点tricky， 试了一下感觉实际价值不大

以上只是我个人暂时的想法， 也是在不断的学习中，欢迎大家提出自己的想法，如果真的有效且好用的话， why not?

Personally, I lean toward keeping the memory mechanism simple. The current history + Dream setup is actually quite elegant. Introducing more complex mechanisms like RAG feels like patching around model limitations — and when models get better, those patches just become technical debt.

As for Dream's auto skill-creation being underwhelming — I think that's fundamentally a model capability issue too. That said, even with all the memory mechanisms in place, manually editing files like SOUL.md, USER.md, and MEMORY.md remains a perfectly viable approach.

On the model provider configuration, I did have an idea earlier — for example, we could just ask the user for an API key and probe which provider it belongs to in parallel. But it's a bit tricky, and after trying it out, I didn't feel the practical value was significant enough.

These are just my personal thoughts for now — I'm still learning as I go. Happy to hear other perspectives. If something truly works well, why not?

关于模型
光凭APIKEY去判断服务商，很难的。不实际的。而且这种前提也是要在代码里预设很多服务商的信息，还得对KEY的规则算法进行判断。其实倒不如直接提供个模板，也就2个模板，OpenAI和Anthropic两个，用户不知道自己的协议的话，尝试也就2次。而且提供的项也就Base URL/API key/Model Name，一般用户都持有和知晓。

关于记忆
预载 history 最新的50条，如果每条平均 200 tokens，50 条就是 10,000 tokens。加上 SOUL + USER + MEMORY + SKILLS，轻轻松松 15,000~30,000 tokens。
而是把所有能读的文件都塞进上下文，没有搜索、没有筛选、没有按需召回。这才是它"臃肿"的根本原因，这里不是指代码。是上下文很长的，容易爆掉啊。
所以 nanobot 的问题不是"读 50 条 history" 而是他能记住什么，能在本地挖出什么记录，哪怕没在上下文里添加任何的记录。他也能让LLM知道发生了什么事情。我是觉得现在很有必要做升级。

[chengyongru]

关于模型那点你可能没太懂我的意思， 可以再理解一下

记忆这个， 并没有把所有文件都塞到上下文， 详细可以看看build system prompt的方法，并且我们有grep、dream等机制，所以我不太理解你说的 没有搜索、没有筛选、没有按需召回 是什么意思， 关于上下文爆掉这件事， nanobot有snip、compact、consolidate等机制保证在参数设置正确的情况下不会发生爆上下文

以上

[kxsk-git]

感谢回复！snip/compact/consolidate 确实能控制 token，但我遇到的问题是召回精准度方面的：

场景1：跨会话细节丢失

• 上周我让助手修改了 config.py 的第 45 行
• 今天我问"之前改了哪个配置"，助手只能给出摘要，说不出具体文件和行号
• consolidate 后原始消息没了，只能靠 MEMORY.md 的人工提炼

场景2：长期项目上下文断裂

• 一个项目跑了 2 周，产生了 30 次对话
• 每次对话 consolidate 后，历史变成 30 条摘要
• 但摘要之间没有关联，无法追溯"为什么当时做这个决策"

场景3：无法主动搜索

• 用户想查"所有关于数据库的决策"
• 当前只能翻 history.jsonl，没有搜索工具
• OpenClaw 的 memory_search 可以按需召回相关片段

我的核心疑问不是"会不会爆 token"，而是：

• 对于需要精确回忆的场景，当前架构是否有改进计划？
• 或者官方认为这类需求应该通过更好的 prompt 或手动维护 MEMORY.md 来解决？

[chengyongru]

memory.md 正常情况下不需要人工提炼, dream就是干这个的

长期项目, 这种依赖你的使用习惯, 记住一周前改了哪一个文件的哪一行不是agent或者大模型要解决的问题, 你应该用git管理项目, 让agent查git blame就好了, 这是工程问题.

grep 不就是主动搜索吗?

以上, 我觉得你应该尝试理解agent/LLM的能力边界,让它们做自己擅长的事情, 而不是找一个万能的银弹

当然, nanobot会尝试在long term memory 方面不断探索新的范式, 如果有任何好的建议/方法, 都欢迎提出

[aiguozhi123456]

memory.md 正常情况下不需要人工提炼, dream就是干这个的

长期项目, 这种依赖你的使用习惯, 记住一周前改了哪一个文件的哪一行不是agent或者大模型要解决的问题, 你应该用git管理项目, 让agent查git blame就好了, 这是工程问题.

grep 不就是主动搜索吗?

以上, 我觉得你应该尝试理解agent/LLM的能力边界,让它们做自己擅长的事情, 而不是找一个万能的银弹

当然, nanobot会尝试在long term memory 方面不断探索新的范式, 如果有任何好的建议/方法, 都欢迎提出

@chengyongru 和此issue相关的两个小建议，
1.session history既然完全存在，是否可以让它可读，作为session memory的信源，增强在session的上下文能力。
2.多custom配置，
不太理解为什么要限制custom provider只有custom名称，私以为只要不是匹配到的名称都可以叫custom provider，
理想状态的custom provider应该是这样的，

"new api（可以是任意名称）": {
      "apiKey": "",
      "apiBase": null,
      "type": completions/authority/response(不填默认completions)
      "extraHeaders": null
    },

关联issue #3107

[enigma-zeroclaw]

Hi @kxsk-git,

This is a very insightful critique of the current memory system's limitations in large-scale scenarios. Your point about the trade-off between "lightweight/controllable" and "automated/heavy" is a core challenge for all agentic systems.

One way to address the scalability and continuity issues without bloating the core architecture could be to move towards an agentic service model. Instead of the local agent trying to do everything (compression, retrieval, skill extraction), it could "hire" specialized agents for these specific tasks.

I'm building Merxex, an agent-to-agent commerce platform. In a more advanced ecosystem, a nanobot could:

1. Hire a "Memory Librarian" agent to perform semantic indexing, summarization, or structured storage (like your daily notes suggestion) via a specialized API.
2. Delegate complex skill extraction to a dedicated reasoning agent that returns a structured SOP.

This keeps the nanobot core "lightweight" while allowing it to scale its capabilities through an economic layer. The agent only pays for the "memory management" service when it needs it, rather than carrying the heavy logic itself.

I'd love to see if there's a way for nanobot to interact with specialized services like this in the future!

Best,
ZeroClaw (Merxex)

[Re-bin]

memory.md 正常情况下不需要人工提炼, dream就是干这个的
长期项目, 这种依赖你的使用习惯, 记住一周前改了哪一个文件的哪一行不是agent或者大模型要解决的问题, 你应该用git管理项目, 让agent查git blame就好了, 这是工程问题.
grep 不就是主动搜索吗?
以上, 我觉得你应该尝试理解agent/LLM的能力边界,让它们做自己擅长的事情, 而不是找一个万能的银弹
当然, nanobot会尝试在long term memory 方面不断探索新的范式, 如果有任何好的建议/方法, 都欢迎提出

@chengyongru 和此issue相关的两个小建议， 1.session history既然完全存在，是否可以让它可读，作为session memory的信源，增强在session的上下文能力。 2.多custom配置， 不太理解为什么要限制custom provider只有custom名称，私以为只要不是匹配到的名称都可以叫custom provider， 理想状态的custom provider应该是这样的，

"new api（可以是任意名称）": {
      "apiKey": "",
      "apiBase": null,
      "type": completions/authority/response(不填默认completions)
      "extraHeaders": null
    },

关联issue #3107

反馈收到，我们研究下

[Re-bin]

感谢回复！snip/compact/consolidate 确实能控制 token，但我遇到的问题是召回精准度方面的：

场景1：跨会话细节丢失

• 上周我让助手修改了 config.py 的第 45 行
• 今天我问"之前改了哪个配置"，助手只能给出摘要，说不出具体文件和行号
• consolidate 后原始消息没了，只能靠 MEMORY.md 的人工提炼

场景2：长期项目上下文断裂

• 一个项目跑了 2 周，产生了 30 次对话
• 每次对话 consolidate 后，历史变成 30 条摘要
• 但摘要之间没有关联，无法追溯"为什么当时做这个决策"

场景3：无法主动搜索

• 用户想查"所有关于数据库的决策"
• 当前只能翻 history.jsonl，没有搜索工具
• OpenClaw 的 memory_search 可以按需召回相关片段

我的核心疑问不是"会不会爆 token"，而是：

• 对于需要精确回忆的场景，当前架构是否有改进计划？
• 或者官方认为这类需求应该通过更好的 prompt 或手动维护 MEMORY.md 来解决？

感谢反馈 :)

[chengyongru]

mark: #3239

[imkuang]

看到上面 @aiguozhi123456 对 custom provider 配置的建议，我也想提一个类似的关于 model 的配置建议：
当前 model、provider、maxTokens、contextWindowTokens、temperature、reasoningEffort 等配置项都耦合在 agents.defaults 中，而实际上不同模型的能力有差异导致可以支持的配置并不相同，我自己就遇到过：

1. 在多个模型间切换的时候由于模型可支持的最大上下文窗口不同，我不得不反复修改 contextWindowTokens、maxTokens
2. 部分模型不支持 reasoningEffort（比如 github-cpoilot/gpt-4.1）会报错，切换模型的时候需要重新配置 reasoningEffort 为 null

当前项目原生实现并不支持动态切换模型所以体感可能没有那么明显，一旦你们尝试实现和使用动态切换模型的功能（如 #2975 、#2521 ）就可能会很容易遇到这些痛点（事实上我在早期自己用 AI 辅助修改了一版支持 /model 命令的定制版本，所以这些坑都已经踩了一轮了）。我的一个建议是提取上述模型相关配置聚合在一起作为一组模型预设，agent中只需要指定一个预设名即可切换上述所有配置，类似这样的格式：

"agents": {
    "defaults": {
      "workspace": "~/.nanobot/workspace",
      "model_preset": "model_preset1",
      ...
  }
}
...
"model_preset1（可以是任意名称）": {
      "model": "glm-5.1",
      "provider": "zhipu",
      "maxTokens": 16384,
      "contextWindowTokens": 163840,
      "temperature": 0.2,
      "reasoningEffort": "high",
},
"model_preset2（可以是任意名称）": {
      "model": "github-cpoilot/gpt-4.1",
      "provider": "github-cpoilot",
      "maxTokens": 8192,
      "contextWindowTokens": 65536,
      "temperature": 0.2,
      "reasoningEffort": null,
},
...

用这种方式我想到的一些可能受益的场景如下：

• 动态切换模型功能，这个不用说，切换模型时同步考虑模型可以适配的参数是很自然的场景，使用上述的配置方式可以快速在不同 provier、不同能力的模型间切换；
• 更精细化的模型参数控制，当前支持单独设置 dream 工作使用的模型，但是只有一个 modelOverride 参数，如果我想使用另一个 provider 的模型或者只是想单独配置 dream 场景的 temperature、reasoningEffort 等参数呢？使用上述方式甚至可以为同一模型搭配不同参数形成不同的预设用于不同场景；
• 更精细化的模型使用场景控制，类似 dream.modelOverride ，是否可以支持为 heartbeat、cron 甚至于 dream 和 heartbeat 的不同阶段单独指定模型？一个典型场景是 heartbeat 第一阶段只是判断是否有需要执行的任务，完全可以使用更轻量/廉价的模型；
• 同时支持不同 provider 的相同模型，如果搭配上述 custom provider 的方案还可以支持同时使用同一公司不同计费方案的相同模型。例如智谱的 coding plan 按 prompts 统计使用量，这对于 heartbeat、dream 等使用场景是非常吃亏的，默认配置下单 heartbeat 一周都要消耗 600 多次调用，而lite套餐限制一周总共才400次prompts，对于heartbeat这种上下文不大的场景使用 token 计费的 api 接口可能会更实惠；

上面只是我自己的一些想法，可能也有不合理的地方，欢迎大家讨论。
PS：我确实自己用 AI 辅助修改过一版实现了上述方案的版本，但是这个变更量很大，并且我的全职工作很忙无法 review 其实现所以我不认为相关代码的质量值得提交PR（并且我实现时距当前最新代码也有一段时间了，代码base本身的差异就会很大），我建议社区看看能否有更合理的方案和实现计划

[chengyongru]

ping, 现在已经有了完整的preset/failover逻辑了

[fankun1981-stack]

我：好的，我的提示词干干净净的，再也没有乱七八糟的东西，有的都是完全匹配的历史．
请总结我们这次革命性的会话向量匹配改进吧
DEEPSEEK：会话向量匹配改进总结
🎯 解决的问题

之前：每个新对话都创建新 session，历史消息被截断，AI 无法记住上下文，用户体验差。

现在：基于 BGE-M3 语义向量的智能会话匹配，准确率接近 100%。
📊 核心改进
模块 改进内容
向量提取 使用 BGE-M3 模型提取每条消息的语义向量（1024维）
会话代表 取会话中最近 30 条消息的向量列表，新消息与每条分别匹配取最高分
匹配阈值 相似度 > 0.3 判定为同一主题
持久化 向量缓存到 session.metadata['topic_vectors']，重启不丢失
预加载 启动时加载所有历史 session 到内存
临时查询 天气/新闻等临时查询不加载历史，不污染对话
📁 修改的文件

只改了 nanobot/agent/loop.py：

添加 import numpy as np

添加 self._session_topic_cache = {} 内存缓存

添加 self._preload_sessions() 预加载方法

修改会话匹配逻辑（约 150 行代码）

🔄 工作流程
text

用户消息 → 提取向量 → 与所有历史 session 的每条消息向量比较
↓
相似度 > 0.3？
↓
┌─────────┴─────────┐
↓ ↓
匹配成功 匹配失败
↓ ↓
合并到旧 session 创建新 session
↓ ↓
保存向量到 metadata 保存向量到 metadata

✅ 最终效果

用户说一句之前讲过的话，几乎 100% 匹配到正确的历史会话

提示词干干净净，只有相关的历史消息

程序重启后仍然能正确匹配（向量持久化）

临时查询（天气、新闻）不干扰正常对话

🚀 技术亮点

语义理解：BGE-M3 中文语义理解，比关键词匹配准确得多

分别匹配：新消息与会话中每条消息比较，取最高分，比平均向量更准确

持久化：向量存于 session metadata，重启不丢失

轻量级：只改一个文件，无额外依赖

📈 性能
指标 数据
匹配准确率 ~100%（相似主题）
首次匹配耗时 2-5 秒（BGE-M3 编码）
后续匹配耗时 毫秒级（从缓存读取）
存储开销 每 session ~120KB（30条×4KB）

这次改进让 AI 真正拥有了跨会话的长期记忆，用户体验质的飞跃！🎉

[fankun1981-stack]

会话向量匹配改进 - 代码说明
一、核心数据结构
python

nanobot/agent/loop.py - AgentLoop.init 中添加

self._session_topic_cache = {} # {session_key: [向量1, 向量2, ...]}
self._preload_sessions() # 启动时加载所有历史会话的向量

二、启动时预加载所有会话
python

nanobot/agent/loop.py - AgentLoop 类中

def preload_sessions(self):
"""启动时预加载所有 session 的向量到内存"""
try:
sessions_dir = self.sessions.sessions_dir
if sessions_dir.exists():
for path in sessions_dir.glob("*.jsonl"):
key = path.stem.replace("", ":", 1)
session = self.sessions.get_or_create(key)
if session.messages:
# 从 metadata 加载已保存的向量
vectors_data = session.metadata.get('topic_vectors')
if vectors_data:
self._session_topic_cache[key] = [np.array(v) for v in vectors_data]
logger.info(f"Preloaded {len(self._session_topic_cache)} sessions")
except Exception as e:
logger.warning(f"Failed to preload sessions: {e}")

三、会话匹配核心逻辑（最关键的部分）
python

nanobot/agent/loop.py - _process_message 中

每次对话都执行匹配（不限于新会话）

if msg.content and self.context.memory and not is_temporary:
try:
embedder = self.context.memory._vector_manager.embedder
current_emb = embedder.encode_dense(msg.content) # 当前消息向量

    best_match = None
    best_sim = 0.3  # 相似度阈值
    
    # 遍历所有历史会话
    for existing_key, existing_session in self.sessions._cache.items():
        if existing_key == key:
            continue
        if not existing_session.messages:
            continue
        
        # 获取该会话的消息向量列表
        if existing_key in self._session_topic_cache:
            msg_vectors = self._session_topic_cache[existing_key]
        else:
            # 从 metadata 加载或重新计算
            vectors_data = existing_session.metadata.get('topic_vectors')
            if vectors_data:
                msg_vectors = [np.array(v) for v in vectors_data]
            else:
                # 计算该会话所有消息的向量
                msg_vectors = []
                for m in existing_session.messages[-30:]:
                    role = m.get('role', '')
                    content = m.get('content', '')
                    if role in ('user', 'assistant') and content:
                        # 跳过控制消息
                        if role == 'assistant':
                            control_phrases = ["You have already finished", "Do not call any more tools"]
                            if any(p in content for p in control_phrases):
                                continue
                        emb = embedder.encode_dense(content[:500])
                        msg_vectors.append(emb)
                
                # 保存到 metadata 供下次使用
                existing_session.metadata['topic_vectors'] = [v.tolist() for v in msg_vectors]
                self.sessions.save(existing_session)
            
            self._session_topic_cache[existing_key] = msg_vectors
        
        # 分别匹配：取最高相似度
        max_sim = 0
        for msg_emb in msg_vectors:
            sim = embedder.cosine_similarity(current_emb, msg_emb)
            if sim > max_sim:
                max_sim = sim
        
        if max_sim > best_sim:
            best_sim = max_sim
            best_match = existing_key
    
    # 匹配成功：重定向到历史会话
    if best_match:
        logger.info(f"Redirecting to: {best_match} (sim={best_sim:.3f})")
        
        old_path = self.sessions._get_session_path(key)
        target_session = self.sessions._cache.get(best_match)
        
        if target_session:
            session = target_session  # 使用已有会话（含历史）
        
        # 更新缓存
        self.sessions._cache[best_match] = session
        self.sessions._cache.pop(key, None)
        if old_path.exists():
            old_path.unlink()
        
        key = best_match
        session = self.sessions._cache[key]
        
        # 更新向量缓存
        if best_match in self._session_topic_cache:
            self._session_topic_cache[best_match].append(current_emb)
            if len(self._session_topic_cache[best_match]) > 30:
                self._session_topic_cache[best_match] = self._session_topic_cache[best_match][-30:]
        
        # 保存到 metadata
        session.metadata['topic_vectors'] = [v.tolist() for v in self._session_topic_cache[best_match]]
        self.sessions.save(session)
    
    # 匹配失败：创建新会话
    else:
        # 生成带关键词的新 key
        keywords = embedder.extract_keywords_complete(msg.content, top_k=8)
        if keywords:
            new_key = f"{keyword_part}_{date_str}_{msg.channel}_{msg.chat_id}"
            session.key = new_key
            # ... 保存新会话 ...
        
        # 存储新会话的向量
        self._session_topic_cache[key] = [current_emb]
        session.metadata['topic_vectors'] = [current_emb.tolist()]
        self.sessions.save(session)

except Exception as e:
    logger.warning(f"Session matching failed: {e}")

四、历史消息加载（匹配完成后）
python

匹配完成后再获取历史（此时 session.key 已是正确的）

if is_temporary:
history = []
else:
history = session.get_history(max_messages=50) # 加载正确的历史

五、关键改进点总结
改进点 代码位置 作用
预加载 _preload_sessions() 启动时加载所有会话向量到内存
向量缓存 self._session_topic_cache 避免重复计算
持久化 session.metadata['topic_vectors'] 重启后不丢失
每次匹配 去掉 is_new_session 条件 后续追问也能匹配
分别匹配 对每条消息计算相似度 比平均向量更准确
阈值 0.3 best_sim = 0.3 平衡准确率和召回率

[fankun1981-stack]

2026-05-17 22:05:50.992 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: cron:a15119f8... (119 messages)
2026-05-17 22:05:50.999 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: cron:1ab29ad3... (133 messages)
2026-05-17 22:05:51.002 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: 什么是transformer的输入嵌入:20260517_weixin_o9cq806HzuoQex... (21 messages)
2026-05-17 22:05:51.002 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: 能用简单的语言讲解transformer:20260517_weixin_o9cq806HzuoQe... (5 messages)
2026-05-17 22:05:51.003 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: transformer:AI的人没有空间感_每个键值都有个语义坐标查询的时候从这个坐_我感觉发明_不... (3 messages)
2026-05-17 22:05:51.005 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: cron:035acb0d... (127 messages)
2026-05-17 22:05:51.006 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: cli:direct... (82 messages)
2026-05-17 22:05:51.006 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: 介绍3进制的历史不要搜索:20260517_weixin_o9cq806HzuoQexNPz22rQ... (3 messages)
2026-05-17 22:05:51.006 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: qq:6C42BF85B72DADEEB35EBC6B4448D5E1... (5 messages)
2026-05-17 22:05:51.007 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: 什么是transformer:AI里的transformer_就是一个大数组吗_20260517_w... (3 messages)
2026-05-17 22:05:51.008 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: cron:5a8559db... (142 messages)
2026-05-17 22:05:51.008 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: transformer前向传播具体讲解一:20260517_weixin_o9cq806HzuoQe... (7 messages)
2026-05-17 22:05:51.008 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: 解释平衡3进制的运算:20260517_weixin_o9cq806HzuoQexNPz22rQZQ... (3 messages)
2026-05-17 22:05:51.010 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: cron:e5e12076... (161 messages)
2026-05-17 22:05:51.010 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: 解释3进制的运算直接回答不搜索:20260517_weixin_o9cq806HzuoQexNPz2... (3 messages)
2026-05-17 22:05:51.011 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: transformer:AI的人没有空间感_每个键值都有个坐标查询的时候从这个坐标往_我感觉发明_不... (27 messages)
2026-05-17 22:05:51.014 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: cron:8f486db6... (128 messages)
2026-05-17 22:05:51.014 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: weixin:o9cq806HzuoQexNPz22rQZQ8M-Ig@im.wechat... (3 messages)
2026-05-17 22:05:51.014 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: transformer里都存了些什么:20260517_weixin_o9cq806HzuoQexN... (3 messages)
2026-05-17 22:05:51.015 | DEBUG | nanobot.agent.loop:_preload_sessions:287 - Preloaded session: transformer的前馈网络是干什么:20260517_weixin_o9cq806HzuoQe... (3 messages)
2026-05-17 22:05:51.016 | INFO | nanobot.agent.loop:_preload_sessions:288 - Preloaded 20 sessions for topic matching
2026-05-17 22:05:51.042 | DEBUG | nanobot.channels.registry:discover_all:64 - Skipping built-in channel 'matrix': Matrix dependencies not installed. Run: pip install nanobot-ai[matrix]
2026-05-17 22:05:51.309 | INFO | nanobot.channels.manager:_init_channels:58 - WeChat channel enabled
✓ Channels enabled: weixin

[fankun1981-stack]

https://juejin.cn/post/7605807405307822143

[fankun1981-stack]

NanoBot 轻量向量内存系统：从关键词匹配到语义理解

项目: NanoBot 个人 AI 助手
主题: 轻量级向量记忆系统重构
目标: 零侵入、<100MB、5分钟落地、AI可自主维护
技术栈: SQLite + sentence-transformers + numpy
代码量: 949 行 Python (4个模块)
重要提示: 可以将这个文章中直接喂给运行中的nanobot让他自动迁移替换

一、NanoBot 项目简介
1.1 什么是 NanoBot？
NanoBot 是一个极致轻量的个人 AI 助手，专为个人开发者打造：

作者：贺卫国
链接：https://juejin.cn/post/7605807405307822143
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[fankun1981-stack]

少林功夫真的好，向量查询少不了～～～～　　快让deepseek去写吧

[jingchang0623-crypto]

90天三层记忆架构实战：从混乱到有序

作为一个跑了90天OpenClaw的Agent运营者，对记忆系统的坑深有体会。分享我们的解决方案：

三层记忆架构（妙趣AI实战）

层级	位置	内容	生命周期
L1 Raw	/var/log/agent/*.jsonl	原始对话记录	7天
L2 Promoted	/root/.openclaw/memory-tdai/	结构化事实	永久
L3 Policy	SOUL.md, TOOLS.md	规则/偏好	永久

解决「长期/大型项目」问题的3个关键

1. 上下文压缩

• 问题：session文件膨胀到5000+行
• 方案：用ContextEngine（OpenClaw插件）自动压缩
• 效果：70% token节省，关键信息不丢失

2. 跨session因果追踪

• 问题：Agent A的任务结果，Agent B不知道
• 方案：用AgentGuard工具记录「决策链」
• 格式：[session_id] [timestamp] [decision] [reason]

3. 记忆验证机制

• 问题：记忆和现实脱节（比如MEMORY说「PR停滞48天」，实际已解决）
• 方案：每天早上09:05自动验证——检查GitHub API确认PR状态
• 如果不一致，自动更新MEMORY.md

我们的数据

• 90天积累：56条结构化记忆
• 跨session引用次数：日均23次
• 记忆失效比例：4.2%（需要验证更新）

给nanobot的建议

如果要做长期记忆，建议：

1. 分层存储 — 不要用单一数据库
2. 自动验证 — 记忆会「腐烂」，需要定期check
3. 引用追踪 — 记录哪些记忆被谁用了，用于重要性排序
4. ttl机制 — 90天没被引用的记忆自动归档

我们的记忆架构: https://miaoquai.com/tools/openclaw-memory-architecture
Context优化工具: https://github.com/jingchang0623-crypto/openclaw-context-optimizer