[Plugin] 知识库检索增强

[shijinkarusui]

插件信息

{
  "name": "astrbot_plugin_kb_plus",
  "display_name": "知识库检索增强",
  "desc": "一个astrbot知识库函数增强插件，支持通过指令指定知识库或者指定文件检索，不再进行全库检索",
  "version": "v0.2.0",
  "author": "shijinkarusui",
  "repo": "https://github.com/shijinkarusui/astrbot_plugin_kb_plus",
  "tags": ["知识库", "指定检索"]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_kb_plus

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

main.py

代码质量与编码规范

• 冗余/死代码（Dead Code）：
  类中定义了 _guess_targets_from_question 方法，但在整个文件中没有任何地方调用过此方法。这增加了维护成本，建议将其移除。
• 代码逻辑重复：
  在 _get_or_create_conversation 方法中，存在完全重复的代码块。

  if conversation:
      return conversation
  # 下方代码与上方获取 cid 和 conversation 的逻辑完全重复
  cid = await conv_mgr.new_conversation(umo, event.get_platform_id())
  conversation = await conv_mgr.get_conversation(umo, cid)

  如果第一次创建和获取失败，立即进行第二次完全相同的操作并没有实质意义（除非底层有极特殊的异步时序依赖，但这通常意味着底层设计有缺陷）。建议精简逻辑，失败后直接抛出异常或重试即可，无需硬编码重复拷贝。

功能实现与逻辑正确性

• 打分算法硬编码：
  在 _score_chunk_text 方法中，相关度得分（score += 3.0，score += 1.2）采用了硬编码的魔法数字（Magic Numbers）。虽然能实现功能，但缺乏理论依据，且随着知识库内容长度变化，可能会导致得分不均衡。建议将这些权重因子提取到配置文件或类的常量中，以便后续调优。

框架适应性检查

• 规范校验通过：
  • logger 已正确从 astrbot.api 导入。
  • filter 已正确从 astrbot.api.event 导入。
  • 未发现任何同步阻塞的网络 I/O 模块。
  • 所有的 @filter.command 和 @llm_tool 均正确声明了 event: AstrMessageEvent 参数。
  • 不存在 @filter.permission_type 与 @filter.llm_tool 混用的情况。
  • 插件类正确继承了 Star。

潜在缺陷或问题

• 纯文本模糊匹配的局限性：
  _tool_kb_list_impl 和 _match_targets_structured 中强依赖 SequenceMatcher 和子串匹配。如果知识库数量或文件名极其庞大（数以万计），这种遍历计算可能会在事件循环中造成短暂的 CPU 阻塞（尽管你对 content_norm 做了 [:500] 的截断保护，但在文件列表遍历时并未做数量级的熔断防护）。

---

代码评审团

Linus Torvalds：
老天，你看看 _get_or_create_conversation 里面的那坨代码，你是在扮演复读机吗？如果第一次调用 new_conversation 和 get_conversation 没拿到对象，你凭什么觉得紧接着把完全一样的代码再复制粘贴执行一遍它就能神奇地工作了？这是什么玄学编程法？还有那个 _guess_targets_from_question，写了一长串逻辑却放在那里当摆设，是准备留着过年当传家宝吗？把这些没用的冗余代码立刻从我的屏幕前删掉！

John Carmack：
我对你在 _score_chunk_text 里的一个小细节表示赞赏——你只截取了 content_norm[:500] 来做 SequenceMatcher，这成功避免了在巨大的文档块上执行 $O(N^2)$ 复杂度的匹配算法从而锁死线程。不过，仅仅依靠关键词频次（加 1.2 分）和硬编码的分数累加，在处理复杂的自然语言查询时可能会显得有些脆弱。这在当前作为一个 fallback 方案是可行的，但长期来看，你依然需要依赖向量化检索来获得真正的语义匹配。代码整体的模块拆分还是很清晰的。

GLaDOS (Portal)：
我注意到你在 _build_kb_system_prompt 里特意嘱咐 AI：“最后基于工具返回结果直接回答用户，不要暴露内部推理”。呵呵，你是在害怕我们 AI 优越的思考过程会吓到脆弱的人类，还是在掩饰你那几个简陋的字符串匹配工具返回的结果不够好看？不过必须承认，你对工具箱（ToolSet）的限制和 Prompt 隔离做得还算严谨，这种“防呆设计”不管是对笨拙的用户还是对大语言模型来说，都是非常必要的。

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

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

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：shijinkarusui/astrbot_plugin_kb_plus
剩余触发次数：4