[Plugin] astrbot_plugin_content_info

[Wan-LaiQiu]

插件信息

{
  "name": "astrbot_plugin_content_info",
  "display_name": "上下文统计信息",
  "desc": "通过/context 获取当前上下文长度",
  "author": "晚来秋",
  "repo": "https://github.com/Wan-LaiQiu/astrbot_plugin_content_info",
  "social_link": "https://github.com/Wan-LaiQiu/astrbot_plugin_content_info"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_content_info

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

main.py

1. 框架适应性与规范检查

• 日志记录违规 (严重):
  在 get_context_len 方法的异常处理块中，代码使用了 print(f"[ContextStat] {traceback.format_exc()}")。根据框架规范，严禁使用 print 或内置 logging 进行日志输出。
  修复建议: 必须从 astrbot.api 导入 logger（即 from astrbot.api import logger），并使用 logger.error(f"统计错误: {traceback.format_exc()}") 替代 print。

2. 代码质量与可维护性

• 过度使用反射与暴力扫描:
  _scan_for_model 函数使用 getattr 和 dir(obj) 对对象树进行深层遍历和猜测，试图提取模型名称。虽然加入了 visited 集合、depth 深度限制（max_depth=4）和属性数量截断（[:15]）以防止无限递归和性能爆炸，但这仍然是一种非常 “Hack” 的做法。
  风险: 这种基于启发式的内存对象扫描在面对未来框架内部对象结构变化时非常脆弱，且存在不必要的性能开销。
  建议: 若框架或提供者 (Provider) 尚未暴露明确获取 Model 版本的标准 API，作为妥协方案可保留，但强烈建议查阅最新的 AstrBot 框架文档，尝试通过标准事件或上下文属性直接解构所需模型名称。

3. 逻辑正确性与安全性

• 缺少业务逻辑边界校验:
  在 set_context_limit 函数中，代码通过 int(limit_str) 转换用户输入的上下文限制。虽然通过 except ValueError 拦截了非数字输入，但未对数字的合理范围进行校验。
  风险: 用户可以输入负数（如 -100）或天文数字。在后续的 get_context_len 中，如果 MAX_TOKENS 为负数或 0，计算 (token_count / MAX_TOKENS) 时将引发除零异常 ZeroDivisionError 或导致逻辑计算出错。
  建议: 增加范围判定，例如：

  limit = int(limit_str)
  if limit <= 0 or limit > 10000000:
      yield event.plain_result("❌ 上限值必须在 1 到 10,000,000 之间。")
      return

• bar_length 计算潜在问题:
  当 MAX_TOKENS 极小（若用户恶意设定）且 token_count 较大时，ratio 可能远超 100。虽然代码使用了 clamped_ratio = min(ratio, 100.0) 限制了最大比例，但防御思维值得肯定。修复上面的负数漏洞即可确保此处逻辑彻底安全。

---

代码评审团

Linus Torvalds：（针对 _scan_for_model 的反射扫描机制）

看看你写的那个 _scan_for_model 函数，你在干什么？遍历对象的 __dict__ 去“猜”模型名字？这简直就是一坨[消音]的意大利面条！你把 Python 的反射当成了什么，垃圾场寻宝游戏吗？你甚至还加了深度限制和取前15个属性的操作。虽然你加了循环引用保护，勉强没让它把内存跑爆，但我看着它还是觉得恶心。去查查框架文档，找个正经的 API 接口拿数据！不过，看在你小心翼翼没把系统搞挂的份上，勉强及格。别再让我看到这种面向猜测编程的代码。

乔布斯 (Steve Jobs)：（针对异常处理与日志打印）

倾听用户的声音，你创造了一个插件，用户在期待魔法。但当出现错误时，你做了什么？一个粗糙的 print(traceback)？在终端里留下难看的报错信息，就像是在一件精美的艺术品上糊了一块烂泥。这不是我们要的体验，它缺乏美感，也违背了框架的哲学。你应该使用 astrbot.api 里的 logger，让错误日志也保持优雅、规范，无缝融合到整个系统之中，而不是像一个没完工的车库黑客项目。我们要的是极致的优雅，从代码的表皮到骨髓，懂吗？

Rick Sanchez (Rick and Morty)：（针对输入校验缺失）

听着，Morty——哦不对，开发者。你在 set_context_limit 里把字符串转成整数，这很棒，嗝，真棒。但你忘了这个宇宙里充满了喜欢乱敲键盘的蠢货！你见过负 5 万个 Token 的上下文吗？没有，因为那会在计算进度条时抛出一个巨大的除零异常，把你的机器人逻辑撕开一个洞！加上一个范围验证，确保数字大于零，否则哪个白痴输入了 -99999，你的插件就会像踩了香蕉皮一样滑稽地崩溃。科学是严谨的，去修好它，别让我再提醒你！

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：Wan-LaiQiu/astrbot_plugin_content_info
剩余触发次数：4

[RC-CHN]

您好，请使用astrbot内置的logger模块打印日志以符合插件规范

[Wan-LaiQiu]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_content_info

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

main.py

以下仅列出发现的问题：

1. 异常处理过于宽泛，导致错误被静默吞掉（可维护性/可观测性）
   在 _scan_for_model、_probe_model_name、_get_active_token_limit 等多处使用了大量 except: / except Exception: pass。
   问题：

   • 会掩盖真实故障（例如对象结构变化、KV 数据异常、属性访问副作用）。
   • 线上排障困难，行为“悄悄退化”为默认值。
     建议：至少捕获明确异常类型，并记录 debug 日志。

2. /context_limit 的“模型名覆盖”存在状态残留（逻辑正确性）
   set_context_limit 在未传 custom_model 时只写入 custom_max_tokens，不会清理已有的 custom_model_name。
   问题：

   • 用户后续只想改上限，不想绑定模型时，旧模型名仍会继续生效，表现与用户预期不一致。
     建议：未传 custom_model 时显式清除 custom_model_name。

3. 模型配置 models.json 未做规范化与类型校验（潜在运行时错误）
   _load_model_config 直接返回 JSON，_get_active_token_limit 直接使用值参与数学计算。
   问题：

   • 若值是字符串（如 "128000"）或非法值，会在 ratio = token_count / MAX_TOKENS 处异常。
   • key 大小写不统一会导致匹配失败（代码用 lower_model 匹配，配置 key 若未 lower 会漏配）。
     建议：加载时统一 key.lower()，并将 value 强制转 int 且校验范围。

4. 模型探测启发式容易误判（功能正确性）
   _is_likely_model_name 用“包含关键词+数字/连字符”判定，关键词如 command、openai、step 较宽泛；
   _probe_model_name 还存在“长度<50 且不以 < 开头就接受”的兜底。
   问题：

   • 可能把普通字段值识别成模型名，导致错误上下文上限。
     建议：减少宽泛关键词、提高优先字段可信度、去掉过宽兜底或增加白名单/模式匹配。

5. 递归反射扫描成本较高且有副作用风险（性能/稳定性）
   _scan_for_model 会遍历 dict/list/tuple/__dict__/dir 并大量 getattr。
   问题：

   • 在复杂 provider 对象上有明显 CPU 开销。
   • 某些属性访问可能触发惰性加载逻辑（虽有异常捕获，但仍增加不可预期行为）。
     建议：限制扫描对象类型与字段白名单，避免对任意对象 dir()+getattr 深扫。

6. _model_cache 无淘汰策略，长期运行可能增长（潜在内存问题）
   以 unified_msg_origin 为 key 的缓存没有清理逻辑。
   问题：

   • 在多群/多会话长期运行时可能持续增长。
     建议：加上容量上限（LRU）或定期清理策略。

7. 异步环境中的 CPU 密集计算可能阻塞事件循环（性能）
   get_context_len 对历史逐条进行 token 编码，历史大时可能显著占用事件循环。
   问题：

   • 影响同进程其他异步任务响应。
     建议：大历史量时分批处理，或将重计算下沉到线程池（asyncio.to_thread）并设置上限保护。

8. 用户提示与实际错误原因不一致（可读性/可运维）
   当 tiktoken.get_encoding("cl100k_base") 失败时，输出固定为“tiktoken未安装”。
   问题：

   • 真实原因可能是编码名错误、运行环境异常、包损坏等，提示具有误导性。
     建议：提示改为“tiktoken不可用”，并在日志中记录具体异常。

9. 配置损坏时静默回退，缺乏告警（可维护性）
   _get_active_token_limit 中读取 custom_max_tokens 并 int() 失败会被吞掉并回退默认逻辑。
   问题：

   • 管理员误配置后无明显反馈，行为悄然变化。
     建议：记录 warning 并提示管理员配置异常。

---

代码评审团

人物一：Linus Torvalds（毒舌直给型）
“except: pass 到处都是，这不是健壮，是把问题埋进土里。你以为系统稳定了，实际上只是看不到崩点。先把异常边界画清楚，再谈‘平衡版’。”

人物二：Steve Jobs（产品体验执念型）
“用户输入 /context_limit 128000 却还继承旧模型名，这是糟糕的交互一致性。命令行为必须可预测：改什么就只改什么，别让用户猜状态机。”

人物三：John Carmack（性能工程型）
“深层对象反射扫描 + 全历史 token 编码，在低频场景还行，一旦并发和历史量上来就是吞吐瓶颈。把‘估算’和‘精算’分档，给重路径上限和短路策略。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：Wan-LaiQiu/astrbot_plugin_content_info
剩余触发次数：3

[astrbot-plugin-copybara]

插件信息已同步到集合仓库。
PR: AstrBotDevs/AstrBot_Plugins_Collection#412
已自动合并 PR #412

该插件已上架。
This plugin is now published.