[Plugin] astrbot_plugin_judge

[HEI1491]

插件信息

{
  "name": "astrbot_plugin_judge",
  "display_name": "智能路由判断",
  "desc": "根据用户消息复杂度,智能选择高智商模型或快速模型进行回答",
  "author": "HEI",
  "repo": "https://github.com/HEI1491/astrbot_plugin_judge",
  "social_link": "https://github.com/HEI1491"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_judge

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

main.py

代码评审团

Guido van Rossum：
“老实说，看到这个 main.py 的类定义方式，我的血压有点升高。你在类定义之外定义函数（如 on_llm_request 和所有命令处理函数），然后像拼积木一样通过 JudgePlugin.method = method 赋值进去？这是 Python，不是 JavaScript 的原型链黑魔法！这种写法不仅让 IDE 的代码补全功能直接瘫痪，也严重破坏了代码的可读性和封装性。请把这些方法老老实实地缩进到 JudgePlugin 类里面去。 另外，那个 try...except 导入 judge_* 模块的方式……这是一种对包结构缺乏信心的表现。请理清你的包结构，统一使用相对导入。”

Linus Torvalds：
“这个文件就是一团混乱的胶带！为什么要把一个插件拆成十几个 Mixin？这看起来像是为了拆分而拆分，结果制造了‘Mixin 地狱’。如果你的类需要继承 15 个父类才能工作，说明你的架构设计本身就有问题——这违反了单一职责原则。把这些逻辑组合（Composition）起来，而不是继承（Inheritance）！还有，那个 __init__.py 是空的，那这些乱七八糟的导入逻辑又是为了掩盖什么路径问题？清理干净！”

Grace Hopper：
“在逻辑层面，我注意到你在 main.py 里虽然注册了钩子，但具体的实现逻辑分散在各个 Mixin 里，这种‘幽灵行为’让调试变得异常困难。虽然从功能上看，你正确使用了 Star 继承和 astrabot.api 的 logger，但这种‘散装’的代码结构是潜在 Bug 的温床。如果在运行时 JudgePlugin 没有正确初始化某些 Mixin 的属性（虽然你在 __init__ 里调用了 super，但 Mixin 的初始化顺序是个迷），整个程序就会崩溃。”

审查报告

• 代码质量与编码规范:

  • 严重结构问题: 将 on_llm_request、judge_status 等方法定义在类外部，最后通过赋值语句（如 JudgePlugin.on_llm_request = on_llm_request）挂载到类上，这是极不推荐的反模式（Anti-pattern）。这不仅破坏了封装性，还导致代码难以阅读、维护，且 IDE 无法提供有效的类型提示。建议: 将所有这些函数移动到 JudgePlugin 类定义内部作为实例方法。
  • 导入逻辑混乱: 使用 try...except 块来尝试相对导入和绝对导入（from .judge_utils import ... vs from judge_utils import ...）。这表明项目的包结构不明确。建议: 明确项目作为包的结构，统一使用相对导入（如果作为插件包发布）或绝对导入。

• 可维护性与可读性:

  • Mixin 滥用: 类 JudgePlugin 继承了十几个 Mixin 类。虽然这是一种拆分代码的方式，但过度的 Mixin 会导致“命名空间污染”和属性来源不明确，增加了维护难度。

---

judge_hooks.py

审查报告

• 潜在缺陷或问题:

  • 内存泄漏风险: on_llm_request 中向 self._llm_pending 字典添加了条目，原本期望在 on_llm_response 中移除。然而，如果 LLM 请求超时、抛出异常导致 on_llm_response 未被触发，或者 AstrBot 核心未正确回调，这些条目将永远滞留在内存中。建议: 引入定期清理机制（如 TTL 检查）或使用 WeakValueDictionary（虽然这里不太适用），确保过期的 pending 记录能被释放。

• 代码质量:

  • 导入优化: 在 on_llm_request 和 on_llm_response 内部使用 import time。虽然 Python 的 import 有缓存，但在高频调用的钩子函数内部进行 import 仍是不必要的开销且代码风格不佳。建议: 将 import time 移至文件顶部。

---

judge_utils.py

审查报告

• 潜在缺陷或问题:

  • 性能隐患: 在 _cache_set 方法中，为了清理过期键，代码执行了 for k, (exp, _) in list(cache.items()):。list(cache.items()) 会在每次写入缓存时创建一个包含所有缓存项的列表副本。如果缓存条目较多（尽管有 max_entries 限制），这是一个 O(N) 的操作，且增加了内存抖动。建议: 仅在达到容量限制或定期清理时进行全量扫描，或者使用 OrderedDict 等更高效的数据结构。

• 代码质量:

  • 重复导入: _now_ts 方法内部进行了 import time。建议: 将导入移至模块顶部。

---

judge_lock.py

审查报告

• 逻辑正确性:
  • 被动清理: _session_locks 的过期清理仅发生在 _get_lock 调用时。如果用户锁定后不再说话，或者该会话不再活跃，锁对象将一直占用内存直到重启。虽然对于文本对象内存占用不大，但属于设计上的疏漏。

---

judge_stats.py

审查报告

• 代码质量:
  • 异常捕获过宽: _stats_inc 和 _stats_add_record 中使用了宽泛的 try...except Exception 且直接吞掉了异常。虽然统计不应影响主流程，但这可能会隐藏 self._stats_counters 类型错误等逻辑 Bug。

---

judge_context.py

审查报告

• 代码质量:
  • JSON 解析依赖: _get_command_llm_context 方法中直接对 conversation.history 字符串进行 json.loads。这假设了 AstrBot 的底层存储格式永远是 JSON 字符串。如果框架未来变更存储方式（如直接存储对象），此插件将失效。建议检查是否有官方 API 获取历史消息对象列表，而非解析原始存储字符串。

---

其他文件 (judge_acl.py, judge_budget.py, judge_commands.py, judge_config.py, judge_decider.py, judge_llm.py, judge_router.py, judge_rules.py, init.py)

审查报告

• 综合评价:
  • 这些文件主要包含业务逻辑实现，未发现明显的安全漏洞或严重的 Python 规范违规。
  • judge_commands.py: 正确使用了 yield event.plain_result(...) 发送消息，符合规范。
  • judge_llm.py: 提供了对 provider 的封装，异常处理得当。
  • judge_router.py: 包含了断路器和路由逻辑，使用了随机库，逻辑自洽。

---

总结

该插件逻辑复杂且功能丰富，但代码结构（尤其是 main.py）存在严重的风格问题，可能导致维护困难。虽然使用了 Mixin 模式试图解耦，但最终在 main.py 中的组装方式（Monkey Patching）破坏了这一努力。此外，内存管理（缓存和 pending 队列）方面缺乏主动清理机制，长期运行可能存在微小的内存泄漏风险。

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
judge_acl.py
judge_budget.py
judge_commands.py
judge_config.py
judge_context.py
judge_decider.py
judge_hooks.py
judge_llm.py
judge_lock.py
judge_router.py
judge_rules.py
judge_stats.py
judge_utils.py

---

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