[Plugin] astrbot_plugin_grok_suite

[muqing-kg]

插件信息

{
  "name": "astrbot_plugin_grok_suite",
  "display_name": "Grok AI 助手",
  "desc": "Grok 全能插件：文生图、图生图、图生视频、智能对话（自动联网）、LLM Tool 调用，一站式 AI 多媒体体验",
  "author": "沐沐沐倾",
  "repo": "https://github.com/muqing-kg/astrbot_plugin_grok_suite",
  "tags": [
    "AI",
    "生图",
    "视频",
    "联网搜索"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_grok_suite

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

main.py

代码质量与编码规范

• 文件/类体量过大、职责过载：GrokPlugin 集成了配置解析、权限控制、图片/视频生成、联网搜索、流式解析、落盘发送等多种职责，导致可读性与可测试性下降；后续任何小改动都更容易引入回归。
• PEP 8 合规性问题明显：
  • 多处超长行（大量字面量 prompt、正则、payload 构造、日志输出等），不利于审查与维护。
  • 部分命名含义不够一致：如 _save_and_send_media(event, url, media_bytes, ...) 里 url 参数基本未使用，易造成误解。
• 配置类型不统一：group_blacklist/group_whitelist/user_blacklist/user_whitelist 假设为 list，但配置系统可能返回字符串/其他类型时未做强健兜底（只对 JSON 配置做了 _parse_json_config_dict，但这些名单类配置未做类似处理）。

功能实现与逻辑正确性

• _parse_media_response 对流式响应的解析模型不可靠：
  • 使用 async for line in resp.content 假设每次迭代得到的是“行/SSE事件”，但 aiohttp 的 resp.content 默认是按 chunk产生数据，不保证按行或按 \n\n 事件边界切分，可能出现 JSON 被拆分导致解析失败、漏提取 URL/Base64。
  • 对 SSE 的处理只识别 data: 前缀，但未处理多行 data: 合并、事件分隔等常见情况，遇到真实 SSE 格式可能丢内容。
• _parse_image_params 与注释规则不完全一致：
  • 注释写“只识别开头连续的独立参数词”“顺序任意”，但实现固定只扫描 min(2, len(parts))，当用户给出三个参数词（例如未来扩展质量/风格，或出现额外占位词）会出现行为与注释不一致、且扩展困难。
• 视频宽高比默认值可能不一致：
  • DEFAULT_ASPECT_RATIO = "9:16"，但 _generate_video 的默认参数是 "16:9"，最终又在调用处传入 self.DEFAULT_ASPECT_RATIO。这类“多处默认值”容易造成维护时出现不一致。
• 合并转发节点 uin 可能无效：
  • self_id 转 int 失败则硬编码 10000，在部分平台/适配器下可能导致合并转发失败或显示异常；更稳妥的做法是使用平台保证可用的标识来源或让适配器决定。

安全漏洞与最佳实践

• 存在 SSRF / 任意 URL 拉取风险：
  • _download_media(url) 会对任意 http(s) URL 发起请求；
  • _get_image_from_event 读取消息里的 Comp.Image.url 并直接下载（消息中的 URL 未必可信/可能被构造，取决于平台适配层是否保证其为受信 CDN）。
  • 建议至少增加：允许域名白名单/仅允许平台 CDN、禁止内网地址段、限制重定向、限制协议为 https、限制端口等。
• 下载/读取缺少大小上限，容易 DoS：
  • _download_media、以及多处 await resp.read() / await resp.text() 都是无上限读入内存。攻击者只需提供超大资源或服务端返回超大响应即可造成内存压力。
  • 虽然 _parse_media_response 有 MAX_RESPONSE_BYTES，但它只覆盖特定路径，且实现方式仍有性能问题（见下）。
• 将外部错误原文写日志可能包含敏感信息：
  • 对失败响应 text[:200]、raw_text[:500] 等直接记录，若上游返回包含 request id、内部诊断、甚至回显 token（取决于上游实现），可能造成日志泄漏风险。至少应在日志中对疑似密钥/Token 做脱敏（如 Bearer ...、长串 base64 等）。

可维护性与可读性

• 大量“自定义兼容解析”逻辑堆叠：_parse_json_response/_parse_media_response/_extract_media_from_chunk/_extract_url_from_text/_extract_base64_from_text/_coerce_search_json 等组合极易互相影响，出现边界问题时定位困难；建议把“协议层解析”和“业务逻辑”解耦，并为典型响应样例加单元测试（尤其是流式与非流式两类）。
• 错误处理策略不一致：
  • 有的地方只向用户返回状态码翻译（丢失上游 message），有的地方又尝试在 _format_search_result 二次解析 raw；导致同类错误在不同入口表现不一致，排障体验不稳定。

潜在缺陷 / 性能与异步最佳实践（仅指出网络 I/O 相关）

• _parse_media_response 存在明显的 O(n²) 内存拷贝性能问题：
  • 在循环内做 raw_content += line，bytes 每次拼接都会复制已有内容，响应稍大就会产生严重性能与内存抖动；应改用 bytearray().extend(...) 或收集到 list[bytes] 最后 b"".join(...)。
• HTTP 客户端缺少基础的“限流/并发控制”：
  • 插件可能被群聊并发触发，当前实现没有为 _download_media、图片生成、搜索请求增加并发上限（例如 asyncio.Semaphore），容易在高并发时把连接数/文件描述符/上游 QPS 打满。
• resp.text() 默认解码可能被大响应拖垮：
  • _perform_web_search 直接 raw_text = await resp.text()，若服务端异常返回大文本/HTML，会造成较大内存占用；建议按字节上限读取或设置 ClientSession 的读取限制策略。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）
你这个类像是把一整套“图片/视频/搜索/存储/解析/权限”的微服务全塞进了一个文件里，然后指望它永远不坏。最要命的是 _parse_media_response 里 raw_content += line 这种 O(n²) 拼接，一旦流稍大就会让性能像雪崩。把协议解析拆出去、把 bytes 拼接改成 bytearray，这是最低限度的自救。

人物二（Guido van Rossum，偏语言与可读性）
代码里“注释承诺的行为”和“实现细节”开始分叉了：比如参数解析只看前两个 token，却声称规则更通用；默认宽高比有多个来源也不统一。建议把这些“规则”提炼成可测试的纯函数，并用清晰的数据结构表达（例如 dataclass 参数对象），否则以后每加一个参数都会越来越乱。

人物三（GLaDOS，冷幽默的安全视角）
我注意到你会从消息里的图片 URL 直接下载，也会下载 API 返回的任意 URL。真棒：这让 SSRF 和内存打爆都变得非常“用户友好”。加域名白名单、阻断内网地址、限制响应体大小、限制重定向次数——不然下次你排查的可能不是 bug，而是“为什么机器人在访问 127.0.0.1:2375”。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[astrbot-plugin-copybara]

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

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