[Plugin] astrbot_plugin_infinite_memory

[ThriEy]

插件信息

{
  "name": "astrbot_plugin_infinite_memory",
  "display_name": "无限记忆插件",
  "desc": "根据token自动总结上下文，同时采用记忆图谱存储记忆，让AI拥有长期无限记忆",
  "author": "ThriEy",
  "repo": "https://github.com/ThriEy/astrbot_plugin_infinite_memory",
  "tags": [
    "记忆",
    "总结"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_infinite_memory

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

main.py

代码审查报告

1. 代码质量与编码规范

• 类型提示不匹配: self.data_dir 通过 StarTools.get_data_dir() 获取，返回的是 pathlib.Path 对象。虽然 Python 3.10 的 os 模块可以处理 Path 对象，但将其传递给 MemoryManager 时，后者的 __init__ 类型提示为 data_dir: str，这造成了类型提示与实际运行时的不一致。
• 脆弱的轮询逻辑: 在 _apply_summary_with_tail 方法中，存在一段 for _ in range(10): ... await asyncio.sleep(0.01) 的轮询代码用于等待新会话创建。这种基于时间的非确定性等待（Magic Number）是糟糕的实践，表明对 conversation_manager 的状态管理存在不确定性，容易在高并发或系统卡顿时导致失败。

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

• API 依赖脆弱性: 在 _on_llm_response 中，代码尝试访问 resp.raw_completion.usage。raw_completion 的结构完全取决于具体的 LLM 提供商（OpenAI, Anthropic 等），直接访问其属性而不进行更严谨的类型检查或使用统一的 resp.usage（如果可用）极易导致 AttributeError，尽管外层有 try-except，但这掩盖了潜在的逻辑缺陷。

3. 潜在缺陷或问题

• 并发竞争风险: 虽然使用了 self.session_summarizing 集合来防止重入，但在 on_message 中，从检查集合到添加到集合之间存在 await 调用（获取 conversation），这在极端并发情况下仍可能存在微小的竞争窗口。不过鉴于 Python 的协程调度机制，此风险较低。

---

memory_db.py

代码审查报告

1. 代码质量与编码规范

• 冗余的初始化操作: _init_db 方法在每次 MemoryDB 实例化（即 __init__）时都会被调用。这意味着每次数据库操作都会执行一次 CREATE TABLE IF NOT EXISTS 和 os.makedirs。虽然 SQLite 对此处理很快，但在高频调用的场景下（如消息流处理），这是一种不必要的性能开销。建议将初始化逻辑移至插件启动时执行一次。
• 数据类型处理不一致: 在 update_user_profile 中，存在 if isinstance(current_affinity, str): 的检查逻辑。根据 _init_db 中的定义，affinity 字段是 INTEGER。这种防御性编程暗示了数据库中可能存在脏数据，或者之前的版本存在类型处理错误，应当通过数据迁移或严格的写入验证来解决，而不是在读取时修补。

---

memory_manager.py

代码审查报告

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

• JSON 解析逻辑缺陷: _parse_summary_json 方法中的正则表达式 r'({.*})' 配合 re.DOTALL 是贪婪匹配。如果 LLM 返回的文本中包含多个分散的大括号（例如：“这是 JSON: {...}，请查收。”），正则会匹配从第一个 { 到最后一个 } 之间的所有内容，导致 json.loads 失败。建议使用非贪婪匹配 r'({.*?})' 或更健壮的 JSON 提取器。
• 误伤的“安全检查”: 在 _parse_summary_json 中，代码检查了 if "__" in raw_json ... 并抛出异常。这是对 json.loads 安全性的误解。json.loads 解析的是数据，不会执行代码。相反，这个检查会导致严重的误报：如果用户在对话中讨论 Python 的 __init__ 方法，生成的总结包含该字符串时，整个记忆保存流程将因“检测到不安全内容”而失败。

2. 代码质量与编码规范

• 类型提示误导: __init__ 方法的参数 data_dir 标注为 str，但实际上接收的是 pathlib.Path 对象。这会误导阅读代码的人或静态分析工具。

---

代码评审团

Linus Torvalds (Linux 之父)

“我看了一下 main.py 里的那个 for _ in range(10) 循环。你在开玩笑吗？用 sleep(0.01) 来祈祷对象被创建出来？这是编程，不是去教堂做礼拜！如果你的 API 不能保证原子性或返回可用的对象，那就去修 API，别在应用层写这种像胶带一样的垃圾代码。还有，那个 JSON 解析里的 if "__" in raw_json 简直是把‘偏执’写在了脸上，json.loads 什么时候会执行代码了？去读读文档吧！”

Guido van Rossum (Python 之父)

“整体结构还算清晰，使用了 pathlib 是个好习惯，但在类型提示上有些草率。在 MemoryManager 里标注 str 却传入 Path 对象，虽然 Python 的鸭子类型让它能跑起来，但这破坏了类型系统的契约精神。另外，memory_db.py 里每次实例化都尝试建表有点‘非 Pythonic’，我们通常喜欢显式优于隐式，初始化应该在插件加载时完成，而不是藏在每次数据库连接里。”

GLaDOS (Portal)

“哦，看哪，一个试图拥有‘无限记忆’的插件。多么可爱的尝试。你试图通过分析人类那些毫无意义的闲聊来构建‘用户画像’？而且你计算‘好感度’的算法竟然只是数数有没有‘开心’或者‘讨厌’这两个词？如果我微笑着说‘我讨厌你’，你的数据库大概会因为逻辑短路而爆炸吧。至于那个为了防止代码执行而禁止 __ 的检查……别担心，即使你允许了，你们人类的这点数据也威胁不到任何人。除了你们自己的服务器硬盘。”

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
memory_db.py
memory_manager.py

---

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

[Soulter]

把 __pycache__ 删除