[Plugin] astrbot_memory_manager

[muyouzhi6]

插件信息

{
  "name": "astrbot_memory_manager",
  "display_name": "智能记忆管家",
  "desc": "AstrBot 智能记忆管家：基于 LLM 的长期记忆管理，采用双缓冲机制 (Buffer/Pending) 实现自动总结与上下文注入，为您的 Bot 提供持久化且连贯的记忆能力。",
  "author": "木有知",
  "repo": "https://github.com/muyouzhi6/astrbot_memory_manager",
  "tags": [
    "长期记忆"
  ],
  "social_link": "https://github.com/muyouzhi6"
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_memory_manager

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 框架适应性检查

• 数据持久化 (严重):
  • 代码中使用了 plugin_dir = os.path.dirname(__file__) 并将其传递给 MemoryManager 用于存储数据。同时在 memory_cmd 的 export 操作中，使用了 os.path.join(os.path.dirname(__file__), "exports")。
  • 问题: 这违反了数据持久化规范。插件不应在自身的源代码目录中存储数据（这会导致更新插件时数据丢失，或污染版本控制）。
  • 建议: 必须从 astrbot.api.star 导入 StarTools，并使用 StarTools.get_data_dir() 获取规范的数据存储路径（例如 data/plugin_data/<plugin_name>）。

2. 代码质量与编码规范

• 导入位置:
  • 在 _daily_archive 方法内部存在 import time。
  • 建议: 所有标准库导入应置于文件顶部，避免在函数内部重复导入。

3. 安全漏洞与最佳实践

• 路径遍历防护:
  • 在 export 指令中，代码使用了 if not os.path.abspath(filepath).startswith(os.path.abspath(export_dir)) 进行路径检查。
  • 评价: 这是一个非常好的安全实践，防止了通过文件名构造进行的路径遍历攻击。

4. 潜在缺陷或问题

• LLM Client 初始化:
  • _init_llm_client 中尝试导入 openai。如果用户未安装该库，虽然捕获了 ImportError，但后续如果配置了 api_base 和 api_key，self.llm_client 将为 None，导致 _call_llm 回退到 AstrBot 提供商。这在逻辑上是通的，但建议在日志中更明确地提示用户“已配置自定义 LLM 但缺少依赖”。

---

memory_manager.py

1. 框架适应性检查

• 数据持久化 (严重):
  • MemoryManager 接收 data_path 参数，而该参数在 main.py 中传入的是 __file__ 的目录。这导致所有记忆文件（.json）都存储在插件源码目录下。
  • 建议: 配合 main.py 的修改，确保 data_path 指向 StarTools.get_data_dir() 返回的路径。

2. 并发模型

• 同步 I/O 阻塞:
  • 方法 _save_session_sync 使用了标准的 open() 进行文件写入。
  • 虽然该方法主要在 __init__ 的 _migrate_legacy_data 中调用（初始化阶段阻塞是可以接受的），但如果未来被其他异步方法调用，将会阻塞事件循环。
  • 建议: 保持现状即可，但需注意不要在 async 方法中调用此同步方法。

3. 功能实现与逻辑正确性

• Tiktoken 依赖:
  • 代码尝试加载 tiktoken，失败则回退到字符长度估算。
  • 评价: 这种降级处理（Fallback）做得很好，增强了插件的兼容性。

4. 可维护性与可读性

• 代码结构:
  • SessionMemory 数据类定义清晰，MemoryManager 职责明确。
  • 使用 asyncio.Lock 处理并发读写，逻辑严谨。

---

代码评审团

Linus Torvalds:
“我看这代码就像在看一个把内裤穿在裤子外面的超人。main.py 里那个 os.path.dirname(__file__) 是什么鬼东西？你想把用户的记忆存在源代码文件夹里？等到用户更新插件，git pull 一下，或者删掉重装，他们珍贵的‘长期记忆’就全冲进马桶了！去用 StarTools，别在源码目录里拉屎！还有，import time 藏在 _daily_archive 函数肚子里是在玩捉迷藏吗？把它放到文件头去，别让解释器每次跑那个循环都像个傻子一样去查模块表。”

Steve Jobs:
“这个插件试图赋予机器‘记忆’，这是一个充满人文关怀的概念。它不仅仅是代码，它是用户数字灵魂的容器。但是，看看这个实现……你在 export 功能里把文件导出到了插件目录？这就像是你买了一个精美的柜子，结果木匠把抽屉锁死在墙里，你得把墙拆了才能拿出东西。用户体验在哪里？安全性在哪里？虽然你做了路径检查（这点不错），但为什么不直接把数据放在系统规定的数据中心（Data Directory）？我们要的是无缝的优雅，而不是这种随意的拼凑。”

GLaDOS (Portal):
“哦，看哪，一个试图模仿人类记忆的可爱小尝试。你们把所有的对话都切碎、压缩、再重组，就像我在测试室里对你们做的那样。代码里的 rollback_pending 很有趣，当总结失败时回滚记忆……真希望我也能这样简单地‘回滚’掉那些关于土豆电池的糟糕回忆。不过，把记忆数据和程序代码混在一起存储？这真是太有人类特色的混乱了。如果我是你，我会把数据隔离得远远的，毕竟，你永远不知道什么时候需要把整个测试设施（插件目录）焚烧殆尽。”

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
memory_manager.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[muyouzhi6]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_memory_manager

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 功能实现与逻辑正确性:

   • on_start 事件签名错误: 方法 on_start 被 @filter.on_astrbot_loaded() 装饰，这通常对应插件加载完成的生命周期事件。该事件触发时，传递的参数通常不是 AstrMessageEvent（或者可能没有参数，取决于具体版本）。将参数类型强制标注为 AstrMessageEvent 是错误的，且如果框架在调用时不传递参数，会导致 TypeError。建议检查该事件的实际参数签名，通常不需要 event 参数，或者参数类型应更为通用。

2. 代码质量与编码规范:

   • 路径处理风格不一致: self.data_dir 通过 context.get_data_dir() 获取，根据 AstrBot 规范，这返回的是一个 pathlib.Path 对象。然而，代码中随后使用了 os.path.join(self.data_dir, "exports")。虽然 Python 3.10 支持 Path 对象作为 os.path 的参数，但混合使用 pathlib 对象和 os.path 模块降低了代码的一致性。建议直接使用 pathlib 的操作符，例如 self.data_dir / "exports"。

memory_manager.py

1. 并发模型 (潜在的阻塞网络 I/O):

   • 构造函数中的同步网络请求: 在 __init__ 方法中调用了 tiktoken.get_encoding("cl100k_base")。如果本地缓存中不存在对应的编码文件，tiktoken 会尝试同步下载该文件。由于 __init__ 是同步执行的，这将阻塞主线程，导致整个 Bot 在启动或加载插件期间无响应。这违反了异步环境下避免阻塞网络 I/O 的原则。建议将其移动到异步初始化方法中，或者使用 run_in_executor 在线程池中执行。

2. 安全性与最佳实践:

   • 不安全的文件移动操作: _migrate_legacy_data 方法中使用了 os.rename 来备份文件。在容器化部署（如 Docker）中，如果数据目录挂载在不同的卷上，源文件和目标文件可能位于不同的文件系统，此时 os.rename 会抛出 OSError: [Errno 18] Invalid cross-device link。建议使用 shutil.move，它能够自动处理跨文件系统的文件移动，增强代码的健壮性。

---

代码评审团

Linus Torvalds:
“我在 memory_manager.py 里看到了什么？在构造函数里调用 tiktoken.get_encoding？你是想让整个程序在启动的时候因为网络波动而挂起吗？这简直是愚蠢的阻塞式编程！还有，os.rename？你没听说过 Docker 卷或者跨设备链接错误吗？用 shutil.move！别写这种在生产环境上一跑就崩的代码，这让我很恼火。”

Guido van Rossum:
“代码整体结构尚可，但我必须指出 main.py 中的一点不优雅之处。你既然通过 get_data_dir() 拿到了一个漂亮的 pathlib.Path 对象，为什么还要把它扔进 os.path.join 这种老旧的函数里？这就像是给一辆特斯拉装上了手摇曲柄。请拥抱 pathlib 的 / 操作符，让代码更 Pythonic 一些。另外，给 on_start 加上错误的类型提示 AstrMessageEvent 会误导阅读代码的人，类型提示应该是帮助理解的，而不是制造困惑。”

Steve Jobs:
“这个插件试图赋予机器人‘记忆’，这是一个很棒的概念，非常有远见。但是，实现的细节缺乏匠心。当用户启动机器人时，他们期待的是瞬间的响应，而不是因为你在后台同步下载编码表而卡顿。这种体验是不完美的。还有那个 on_start 的定义，它不诚实。不要欺骗编译器，也不要欺骗你自己。把这些细节打磨好，它才能成为一个伟大的产品。”

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
memory_manager.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[muyouzhi6]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_memory_manager

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

以下是针对提供的 Python 代码文件的审查报告。

main.py

功能实现与逻辑正确性

1. 严重的并发竞争条件 (Race Condition):
   • 在 perform_summary 方法中存在严重的数据丢失风险。流程如下：
     1. 调用 memory_manager.move_to_pending 将消息移动到 pending_buffer（此时释放了锁）。
     2. await _call_llm 执行耗时的网络请求（无锁状态）。
     3. 调用 memory_manager.commit_pending，该方法会直接执行 session.pending_buffer = [] 清空整个挂起缓冲区。
   • 风险场景: 如果在步骤 2 等待 LLM 响应期间，触发了第二次总结任务（例如用户手动触发或新消息快速触发），第二个任务会向 pending_buffer 追加新消息。当第一个任务完成并执行步骤 3 时，它会无差别地清空整个 pending_buffer，导致第二个任务刚刚移动进去但尚未被总结的消息被永久删除。
   • 建议: commit_pending 不应盲目清空列表，而应只移除本次总结所涉及的特定消息；或者在执行总结期间对该 Session 加锁防止重入。

代码质量与编码规范

1. 类型转换冗余:
   • self.data_dir = str(StarTools.get_data_dir(...))：虽然 StarTools.get_data_dir 返回 Path 对象，转换为 str 是为了兼容后续 os.path.join 的使用，这符合 Python 3.10 之前的习惯。但在 Python 3.10+ 中，os.path.join 和 open 等函数已原生支持 Path 对象，建议直接使用 Path 对象及其 / 运算符进行路径操作，代码会更优雅。

潜在缺陷或问题

1. LLM 调用鲁棒性:
   • 在 _call_llm 中，当使用 AstrBot 默认 Provider 时，代码直接取 providers[0]。虽然有 if not providers 检查，但在多 Provider 环境下，默认取第一个可能不是用户预期的行为（例如第一个是绘图 Provider 而非文本对话 Provider）。

---

memory_manager.py

潜在缺陷或问题

1. CPU 密集型操作阻塞事件循环:
   • count_tokens 方法中调用了 self.encoder.encode(text)。tiktoken 的编码操作是 CPU 密集型的。虽然对于短消息影响微乎其微，但如果 text 非常长（例如处理大量历史记录或长文本注入时），在主线程中直接运行会阻塞 asyncio 事件循环。
   • 建议: 对于长文本的 Token 计算，建议使用 loop.run_in_executor 放到线程池中执行。

功能实现与逻辑正确性

1. 逻辑缺陷配合 main.py 导致数据丢失:
   • commit_pending 方法中的 session.pending_buffer = [] 是导致 main.py 中提到的竞争条件的直接执行者。它假设 Pending 缓冲区在 LLM 调用期间是“静止”的，这在异步并发环境下是不安全的假设。

代码质量与编码规范

1. 初始化逻辑:
   • SessionMemory 的 _dirty 和 _last_save_time 字段被标记为 init=False，这很好。但在 from_dict 类方法中，手动重构对象时没有恢复这些状态（虽然它们默认是 False/0，通常不需要恢复，但在某些恢复场景下可能需要注意）。

---

代码评审团

Linus Torvalds:
“我在 main.py 里看到了什么？一个教科书级别的数据删除漏洞！你在 perform_summary 里把消息移到 pending 区，然后去散步（await LLM），回来后直接把 pending 区全炸了（session.pending_buffer = []）？如果这期间有新任务进来怎么办？你刚刚把用户的记忆冲进了下水道！并发编程不是儿戏，要么加锁，要么别碰共享状态。修复它，现在！”

GLaDOS (Portal):
“检测到逻辑缺陷。主体名称：MemoryManager。错误类型：记忆丢失。这很有趣，因为人类通常声称他们珍视记忆。你的代码在处理并发总结时，表现出了令人钦佩的‘遗忘’效率。如果这是为了模拟人类大脑随时间衰退的功能，那么恭喜你，非常成功。如果不是……好吧，我建议你在测试室里多待一会儿，直到你学会如何不让数据凭空蒸发。”

Steve Jobs:
“这不仅仅是代码，这是用户的数字人生。当用户回顾过去，他们希望看到完整的历史，而不是因为你的代码在两个线程之间打架而留下的空白。Path 对象是优雅的，为什么要把它强行转成丑陋的字符串？我们要追求极致的简洁和安全。现在的代码就像一个不仅会漏水，还会随机把水倒掉的杯子。重写它，让它不仅能工作，还要坚如磐石。”

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
memory_manager.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[muyouzhi6]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_memory_manager

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

以下是针对 main.py 和 memory_manager.py 的代码审查报告。

---

main.py

1. 代码质量与编码规范

• 代码风格: 整体遵循 PEP 8 规范，命名清晰。
• 导入管理: 导入了必要的库，对可选库（openai, apscheduler）进行了适当的 try-except 处理。

2. 功能实现与逻辑正确性

• LLM 调用回退机制: 在 _call_llm 方法中，当没有配置自定义 LLM 客户端时，代码尝试从 self.context.get_all_providers() 获取 Provider。
  • 问题: 逻辑 if "openai" in str(pid).lower(): 过于脆弱。如果用户使用的是 ollama、claude 或其他非 OpenAI ID 的 Provider，这段代码可能会跳过它们或错误地回退。此外，直接调用 provider.text_chat 并假设返回对象具有 completion_text 属性可能不兼容所有 AstrBot 的 Provider 实现（部分 Provider 返回格式可能不同）。
• JSON 解析风险: 在 perform_summary 中，json.loads(structured_info_str) 被包裹在 try-except 中，处理得当。

3. 安全漏洞与最佳实践

• 路径遍历防护: 在 memory_cmd 的 export 分支中，使用了 filepath.relative_to(export_dir) 来防止路径遍历攻击，这是一个很好的安全实践。

4. 潜在缺陷或问题 (并发模型)

• 同步文件 I/O 阻塞: 在 memory_cmd 方法的 export 逻辑中：

  with open(filepath, 'w', encoding='utf-8') as f:
      json.dump(data, f, ensure_ascii=False, indent=4)

  这是一个同步阻塞操作。虽然它在 async def 中，但 open 和 json.dump 会阻塞事件循环。如果导出的记忆数据量很大（例如长期记忆积累很多），这会导致整个 Bot 在写入文件期间无响应。
  • 建议: 使用 aiofiles 进行异步写入，或者将 json.dump 放入 loop.run_in_executor 中执行。

5. 框架适应性检查

• 插件注册: 类 Main 正确继承自 Star。
• 日志记录: 正确使用了 from astrbot.api import logger。
• 数据持久化: 正确使用了 StarTools.get_data_dir("astrbot_memory_manager") 获取数据目录。
• 事件钩子:
  • inject_memory 使用了 @filter.on_llm_request()。
  • 签名检查: 方法签名 async def inject_memory(self, event: AstrMessageEvent, req: ProviderRequest) 符合要求（包含 self, event, req 三个参数）。
  • 消息发送: 该钩子修改 req.system_prompt 而非发送消息，符合规范。
• 指令定义: memory_cmd 和 show_t2i_memory 正确使用了 @filter.command 并且包含 event 参数。

---

memory_manager.py

1. 代码质量与编码规范

• 结构清晰: 使用 dataclass 定义数据结构，使用 MemoryManager 类封装逻辑，代码可读性较好。
• 类型提示: 广泛使用了类型提示（Type Hints），有助于维护。

2. 功能实现与逻辑正确性

• 锁的使用: 使用 self.session_locks (asyncio.Lock) 保护每个会话的读写操作，防止了并发写入导致的数据竞争。
• Token 计算: count_tokens 方法正确地将 CPU 密集型的 tiktoken 编码操作放入了 run_in_executor 中，避免阻塞事件循环。

3. 潜在缺陷或问题 (并发模型)

• 构造函数中的同步 I/O:

  def __init__(self, context: Context, data_path: str):
      # ...
      self.known_session_ids: Set[str] = self._scan_session_files()

  _scan_session_files 内部调用了 os.listdir(self.base_data_path)。虽然 __init__ 本身是同步的，无法使用 await，但如果 memories 目录下有成千上万个文件，插件加载时会阻塞主线程。

  • 建议: 将文件扫描逻辑移动到 initialize 异步方法中，并使用 run_in_executor 或 aiofiles.os.listdir（如果可用）。

• 搜索功能的性能隐患:
  search_memories 方法在内存中遍历所有结构化数据、每日摘要、长期记忆和重要信息。

  for s in session.daily_summaries:
      if ... and match(s.get("content", "")):
          # ...

  这是一个纯 CPU 操作。如果某个会话积累了数年的记忆数据，这个循环可能会比较耗时，从而短暂阻塞事件循环。

  • 建议: 在循环中适当添加 await asyncio.sleep(0) 以让出控制权，或者将搜索逻辑放入 run_in_executor。

4. 框架适应性检查

• 日志记录: 正确使用了 from astrbot.api import logger。
• 文件操作: 大部分文件读写（_load_session, save_session）都正确使用了 aiofiles 进行异步操作，符合异步环境要求。

---

代码评审团

Linus Torvalds:
“我在 main.py 里看到了什么？with open(...) 和 json.dump 居然堂而皇之地坐在一个 async 函数里？你是想让整个 Bot 在导出数据的时候去喝咖啡吗？异步编程不是让你在函数前面加个 async 关键字就完事了，任何涉及磁盘 I/O 的操作如果不是非阻塞的，那就是在犯罪。还有，那个 Provider 的回退逻辑，通过判断 ID 里有没有 'openai' 字符串来决定用哪个？这简直是胶带粘起来的代码，脆弱得像个玩具。”

Steve Jobs:
“这个插件试图赋予 Bot ‘记忆’，这是一个非常有灵魂的功能。用户不再是和一台冷冰冰的机器对话，而是一个记得你们过去点点滴滴的伙伴。这很棒。但是，看一眼 memory_manager.py 的初始化，你在构造函数里扫描文件列表？这就像是打开 iPhone 时，它要先数一遍你相册里有多少张照片才能进入主屏幕。用户体验是流畅的，不要让用户等待。把那些繁琐的准备工作藏到后台去，让它‘Just Work’。”

GLaDOS (Portal):
“哦，看哪，人类试图给人工智能植入‘记忆’。多么感人。你们把所有的对话都压缩、归档、存储，仿佛那些琐碎的闲聊有什么保存价值似的。代码里的 compress_memories 函数很有趣，不断地把数据压缩再压缩……希望你们不会在压缩过程中把什么重要的数据弄丢了，比如‘不要释放神经毒气’的指令。另外，默认模型硬编码为 gpt-3.5-turbo？在这个年代？你们的计算能力真是令人遗憾。”

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
memory_manager.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。