[Plugin] astrbot_plugin_group_digest

[Ewingsal]

插件信息

{
  "name": "astrbot_plugin_group_digest",
  "display_name": "群聊兴趣日报与主动互动插件",
  "desc": "基于 AstrBot 实现群聊消息总结、群热门话题分析、成员兴趣摘要与日报生成、通过LLM 建议astrbot定时主动发言。",
  "author": "Ewingsal",
  "repo": "https://github.com/Ewingsal/astrbot_plugin_group_digest",
  "social_link": "https://github.com/Ewingsal"
}

插件检查清单

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

ai代码审查相关问题已做出相应修改

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_group_digest

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

main.py

1. 数据持久化目录未使用框架规范接口

   • 当前通过 _resolve_data_dir() + 配置拼接路径来推断数据目录，未使用 StarTools.get_data_dir()。
   • 按你给的框架约束，这会导致插件在不同部署形态下目录行为不一致，且增加维护成本。

2. 配置解析缺少容错，存在启动/运行期崩溃风险

   • 多处直接 int(self._conf_get(...))（如 max_active_members、max_topics）没有 try/except 或统一 clamp，配置值若为非法字符串会抛 ValueError。
   • 影响点：
     • __init__ 中 SchedulerRuntimeOptions(...) 构建阶段可能直接导致插件初始化失败。
     • 命令执行路径中也可能触发异常（虽有外层兜底，但会退化为“日报生成失败”）。

---

init.py

（未发现需要报告的问题）

---

services/init.py

（未发现需要报告的问题）

---

services/digest_service.py

1. 日志导入不符合框架硬性要求

   • 存在 except 后回退到内置 logging.getLogger(__name__) 的逻辑。
   • 你给出的规范要求 logger 必须且只能来自 from astrbot.api import logger。

2. 在“无消息”场景下仍会先触发 provider 解析，增加不必要异步开销

   • build_report_for_period_with_metrics() 里先 _resolve_expected_provider_id()，后才判断 message_count<=0。
   • 这会导致空窗口下仍发起 provider 选择逻辑（可能涉及异步调用和错误路径），属于可避免的性能/稳定性损耗。

3. 异常吞噬影响可维护性

   • _report_from_payload() 使用裸 except Exception: return None，无日志。
   • 缓存反序列化失败时缺少可观测性，排障难度高。

---

services/group_origin_store.py

1. 并发读写存在竞态，可能丢数据

   • upsert_group_origin() 采用“读全量 -> 改内存 -> 写全量”，未加锁。
   • 异步环境下多事件并发归档时，后写覆盖前写，导致记录丢失。

2. 脏数据容错不足

   • list_group_records() 中 int(data.get("last_active_at", 0)) 对异常字符串无保护，可能抛 ValueError 并中断调度流程。

---

services/interaction_service.py

（未发现需要报告的问题）

---

services/llm_analysis_service.py

1. 事件兼容性不足：仅取 event.unified_msg_origin 属性

   • _resolve_provider_id() 没有像主插件那样尝试 get_unified_msg_origin() 等兼容读取。
   • 在部分适配器事件对象只提供 getter 时，会误判“无法获取 unified_msg_origin”。

2. 模板格式化风险未隔离

   • _build_analysis_prompt() 直接 template.format(...)，若自定义模板占位符不匹配，会抛异常并导致语义分析失败。
   • 建议至少对模板格式异常做明确错误提示/降级，而不是让调用链兜底成通用失败。

---

services/message_filters.py

（未发现需要报告的问题）

---

services/models.py

（未发现需要报告的问题）

---

services/report_cache_store.py

1. 并发写入竞态风险

   • upsert_record() 同样是“读全量 -> 改内存 -> 写全量”，未加锁；并发场景会出现覆盖写，造成缓存条目丢失。

2. 缓存脏数据会导致读取路径异常中断

   • ReportCacheRecord.from_dict() 多处 int(...) 强转，无容错；
   • get_record() 未捕获 ValueError/TypeError，缓存文件一旦有非预期值会直接抛错影响主流程。

---

services/scheduler_service.py

1. 日志导入不符合框架硬性要求

   • 与 digest_service.py 同样存在回退到 logging.getLogger 的逻辑，违反“只能从 astrbot.api 导入 logger”。

2. 无并发上限控制，存在网络 I/O 突发风险

   • run_once_for_time() 对所有群组直接 asyncio.gather(*tasks)，会同时触发多路 LLM 调用与消息发送。
   • 群组数量大时容易触发上游限流、超时和雪崩重试，属于典型异步并发治理缺口。

---

services/storage.py

1. 并发追加存在丢消息风险

   • append_message() 是全量读写且无锁；并发事件下可能发生写覆盖，导致消息归档丢失。

2. 脏数据容错不足

   • _read_records() 仅捕获 FileNotFoundError, JSONDecodeError，但 MessageRecord.from_dict() 的 int(...) 可能抛 ValueError，会导致读取流程中断。

3. 性能瓶颈明显（全量读写）

   • 每次追加都读取并重写整个 JSON 文件，消息量增大后延迟会线性恶化；在高频群聊下会明显拖慢处理链路。

---

tests/init.py

（未发现需要报告的问题）

---

tests/test_digest_service.py

1. 导入路径可移植性问题
   • 使用 from services.xxx import ...，依赖特定工作目录/PYTHONPATH。
   • 在标准包安装或 CI 隔离环境下，测试可能出现 ModuleNotFoundError（更稳妥是使用包内绝对导入路径）。

---

tests/test_message_filters.py

1. 同样存在测试导入路径可移植性问题
   • from services... 的导入方式与上面一致，存在环境耦合。

---

代码评审团

人物一：Linus Torvalds（硬核工程视角）
“你这功能链路挺完整，但 JSON 存储层全是 read-modify-write 无锁操作，在并发下就是‘看起来能跑，实际上会悄悄丢数据’。先把数据一致性打牢，再谈功能花活。”

人物二：Steve Jobs（产品体验视角）
“用户不会关心你内部是 provider 解析还是缓存命中，他们只会看到‘有时好用、有时报错’。配置解析要优雅失败、错误提示要可理解，这决定了产品是否‘just works’。”

人物三：Deadpool（夸张吐槽但给方案）
“调度器 gather 全开冲刺像一群人同时挤一扇门：LLM、发送接口、日志全在尖叫。加个并发信号量，不然你的日报系统会在高峰时段把自己日报掉。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
services/__init__.py
services/digest_service.py
services/group_origin_store.py
services/interaction_service.py
services/llm_analysis_service.py
services/message_filters.py
services/models.py
services/report_cache_store.py
services/scheduler_service.py
services/storage.py
tests/__init__.py
tests/test_digest_service.py
tests/test_message_filters.py

注意：由于项目规模或Token限制，本次仅审核了部分优先文件。以上报告内容由 AI 直接生成。

---

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

当前仓库：Ewingsal/astrbot_plugin_group_digest
剩余触发次数：4

[Ewingsal]

已根据本次 AI 自动审核意见完成一轮针对性修复，主要修改如下：

1.数据目录与框架规范
已移除原先通过 _resolve_data_dir() 自行推断目录的方式，统一改为通过框架接口获取 AstrBot data 目录，并将消息归档、群会话标识与日报缓存路径统一收敛到这一层解析，减少不同部署形态下的路径不一致问题。

2.配置解析容错
针对 max_active_members、max_topics、max_messages_for_analysis、scheduled_send_hour、scheduled_send_minute 等整数配置，已增加统一的安全解析与默认值回退逻辑，避免非法配置导致插件初始化或运行时直接抛出 ValueError。

3.日志与异常可观测性
已移除回退到内置 logging.getLogger 的逻辑，统一使用框架提供的官方 logger。
补充了缓存反序列化失败、模板渲染失败等关键路径的 warning / fallback 日志，避免异常静默吞掉、影响排障。

4.无消息场景优化
已调整日报生成链路，在无有效消息时提前返回，不再先执行 provider 解析，减少不必要的异步开销。

5.事件兼容性
在 llm_analysis_service 中补充了 unified_msg_origin 的兼容读取逻辑，不再只依赖单一属性访问，兼容 getter 场景。

6.模板格式错误降级
对自定义 prompt 模板的 format() 过程增加了异常保护；当模板占位符配置错误时，会记录日志并优先回退到默认模板，避免直接导致整条语义分析链路失败。

7.JSON 存储一致性与脏数据容错
已为 storage.py、group_origin_store.py、report_cache_store.py 三个读写频繁的 JSON 存储类增加 asyncio.Lock，降低并发场景下 read-modify-write 覆盖写导致的数据丢失风险。
对消息、群 origin、缓存记录的反序列化路径补充了类型转换保护和脏数据容错，避免单条坏数据导致整个流程中断。

8.scheduler 并发治理
已为 scheduler 增加受控并发，不再无上限地 gather(*tasks) 全开；当前通过并发上限控制多群定时任务，降低 LLM 调用和消息发送的瞬时压力。

9.测试导入路径
已将测试中的导入方式调整为更稳定的包内路径，减少对工作目录 / PYTHONPATH 的依赖，并补充了相关测试用例。

10.插件自有消息过滤
另外补充修复了插件自身命令消息、日报输出消息及可识别 bot 自发消息对统计、语义分析与缓存判断的污染问题，避免命令/插件输出反向影响日报结果与缓存命中。

[Ewingsal]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_group_digest

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

main.py

1. 数据目录默认值与 StarTools.get_data_dir() 语义叠加不一致

   • _get_framework_data_dir() 已经拿到框架规范目录（通常是 data/plugin_data/<plugin_name>），但 _resolve_data_file_path() 的默认值仍是 "plugin_data/astrbot_plugin_group_digest/xxx.json"。
   • 结果会拼成类似：<data_dir>/plugin_data/astrbot_plugin_group_digest/messages.json，出现重复层级，偏离“在插件数据目录下直接落文件”的常见约定。
   • 风险：部署后路径混乱、迁移困难、与运维预期不一致。

2. 构造函数中启动调度器的时机存在初始化竞态风险

   • __init__ 内直接 self.scheduler_service.start(...)，若此时宿主环境尚未进入可创建任务的事件循环，会触发 RuntimeError（虽在 service 内部捕获，但会导致调度器未启动）。
   • 风险：插件“看起来初始化成功”，但定时任务实际未运行，行为隐蔽。

---

services/group_origin_store.py

1. 读写并发一致性不足（读路径未加锁）

   • upsert_group_origin() 写操作有锁，但 list_group_records() / _read_raw() 无锁。
   • 并发场景下可能读到写入中的半成品 JSON，触发 JSONDecodeError 后退化为空数据。
   • 风险：调度侧“偶发读不到群 origin”，出现误跳过。

2. 文件写入非原子

   • _write_raw() 直接覆盖写，进程异常/中断时可能留下截断文件。
   • 风险：持久化文件损坏，后续长期处于“空数据恢复”状态。

---

services/report_cache_store.py

1. 缓存键构造存在潜在冲突

   • _build_key() 使用 f"{group_id}::{date}::{mode}" 拼接。
   • 若 group_id/date/mode 含 ::，可产生键碰撞（覆盖其他记录）。
   • 风险：跨群或跨模式缓存串扰，命中错误报告。

2. 读写并发一致性不足（读路径未加锁）

   • upsert_record() 有锁，get_record() / _read_raw() 无锁。
   • 并发读写可导致读到中间态并误判缓存 miss。
   • 风险：缓存命中率异常下降、重复计算增加。

3. 文件写入非原子

   • 与 group_origin_store 同类问题：直接覆盖写，异常中断可能损坏缓存文件。

---

services/scheduler_service.py

1. 批量并发处理缺乏“单群故障隔离”

   • run_once_for_time() 中 asyncio.gather(*tasks) 未使用 return_exceptions=True。
   • 任何一个 _process_single_group... 未捕获异常，可能让整轮调度直接抛错，影响其他群处理结果。
   • 风险：单点异常放大为整批失败。

2. 调度配置对象为可变引用，运行期修改风险

   • start() 直接保存外部传入 scheduler_config / runtime_options 引用，若外部后续修改对象，调度行为会被隐式改变。
   • 风险：线上行为漂移、问题难复现。

---

services/storage.py

1. 消息追加是全量读-改-写，性能随数据量线性退化

   • append_message() 每次都 _read_records() + append + _write_records()。
   • 群消息量上来后，写入开销明显增大。
   • 风险：高频消息场景下吞吐下降，延迟抖动。

2. 读写并发一致性不足（读路径未加锁）

   • 写操作有锁；load_messages()/get_message_stats() 读取无锁。
   • 并发读写时可能读到不完整 JSON，触发异常后回退为空列表。
   • 风险：日报统计“偶发 0 消息”、缓存误刷新。

3. 异常回退策略过于激进，可能掩盖数据损坏

   • _read_records() 在 JSON 解析失败时直接返回 []。
   • 风险：上层将其当成“真实无消息”，产生错误业务决策（如误发“暂无消息”）。

---

tests/init.py

1. 违反项目日志约束（即便在测试桩中）

   • 使用了 logging.getLogger("astrbot.tests")，而规则要求 logger 必须来自 astrbot.api。
   • 风险：测试环境与生产日志接口不一致，掩盖日志相关兼容问题。

2. 在包初始化中修改 sys.path 与 sys.modules 副作用较大

   • 该文件 import 即执行全局注入，影响其他测试模块解析顺序与模块缓存。
   • 风险：测试间相互污染、定位困难。

---

tests/test_digest_service.py

1. 测试辅助 _run() 使用 asyncio.run()，在已有事件循环环境不兼容
   • 若在启用事件循环插件（如某些 pytest 配置）下运行，会报 “asyncio.run() cannot be called from a running event loop”。
   • 风险：测试在不同 CI/本地配置下表现不一致（脆弱测试）。

---

代码评审团

人物一：Linus Torvalds（直球派）
“你把并发锁只加在写上、读却裸奔，这就像给前门装了防盗门，窗户却大开。storage/group_origin/cache 三处同款问题，先把一致性做扎实，否则后面任何‘偶发空数据’都会把人逼疯。”

人物二：Ada Lovelace（结构派）
“调度器批处理如果不能做到‘单群失败不拖全局’，那它就不是稳健的自动机。asyncio.gather 的异常传播策略需要明确设计，不然系统会在最需要可靠性的时候崩在边角输入上。”

人物三：Tony Stark（工程效率派）
“全量 JSON 读改写在 demo 阶段能跑，但在真实群聊流量下就是性能定时炸弹。你已经写了 TODO，建议尽快落地分片/增量策略，不然日报还没生成完，群都聊到明天了。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
services/__init__.py
services/digest_service.py
services/group_origin_store.py
services/interaction_service.py
services/llm_analysis_service.py
services/message_filters.py
services/models.py
services/report_cache_store.py
services/scheduler_service.py
services/storage.py
tests/__init__.py
tests/test_digest_service.py
tests/test_message_filters.py

注意：由于项目规模或Token限制，本次仅审核了部分优先文件。以上报告内容由 AI 直接生成。

---

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

当前仓库：Ewingsal/astrbot_plugin_group_digest
剩余触发次数：3

[Ewingsal]

已根据最新一轮 AI 自动审核意见完成一轮高优先级修复，相关修改已同步到仓库最新代码中，主要包括：

本轮已完成的修复
1.数据目录语义修正
调整了数据目录解析逻辑，不再简单拼接固定前缀。
现在会根据框架返回目录的语义，区分当前是根 data 目录还是插件数据目录，并自动选择合适的相对路径，避免出现重复层级路径。
2.scheduler 启动时机优化
不再在插件构造阶段直接强行启动调度器。
改为在插件初始化和实际事件/命令入口中通过一次性检查确保 scheduler 启动，降低事件循环尚未就绪时的初始化竞态风险。
3.JSON 存储一致性增强
为以下存储组件补齐了读写锁控制：
services/storage.py
services/group_origin_store.py
services/report_cache_store.py
除写路径外，读路径也纳入一致性控制，避免并发读写时读到半成品 JSON。
4.文件写入改为原子写
以上三个 JSON 存储组件均已改为“临时文件写入 + os.replace 原子替换”的方式，降低进程异常中断导致文件损坏的风险。
5.scheduler 单群故障隔离
调整了多群批量处理逻辑，单个群处理失败时不会拖垮整轮调度。
当前会对单群异常进行隔离和记录，其他群仍可继续执行。
6.调度配置对象防漂移
scheduler 启动时不再直接持有外部可变配置对象引用，而是保存拷贝，减少运行期被隐式修改带来的行为漂移问题。
以上修改已同步提交到当前仓库最新代码中，欢迎继续审核。@astrpluginreviewer

[Ewingsal]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_group_digest

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

main.py

1. 过度宽泛的导入异常捕获会掩盖真实错误

   • except Exception 用于 AstrBotConfig、StarTools 导入兜底，容易把真正的环境错误（例如依赖损坏、版本接口变化、拼写问题）吞掉，导致后续以“降级模式”运行并在更远处报错，排障困难。
   • 建议至少收敛为 ImportError，避免误吞运行时异常。

2. 标题模板格式化缺乏容错

   • title_template.format(date=...) 在多个路径中直接调用（如 render_text、_render_no_messages、_render_analysis_error），当配置里出现非法花括号或未知占位符时会直接抛异常，导致命令失败。
   • 这是配置边界处理不足，建议增加格式化异常兜底（回退默认模板）。

---

services/digest_service.py

1. 反序列化布尔值存在逻辑错误风险

   • _report_from_payload 中 stats_only=bool(payload.get("stats_only", False))：若缓存里是字符串 "false"，结果会被转成 True。
   • 这会造成报告渲染分支错误（误判为仅统计模式）。

2. 缓存恢复时对结构类型校验不完整

   • semantic_raw.get("member_interests", {}).items() 假设其为 dict；若缓存被污染为 list/str，会触发异常并整体回退为 None。
   • 虽有总异常兜底，但粒度较粗，导致“局部坏数据”放大为“整条缓存失效”。

---

services/llm_analysis_service.py

1. 对上下文方法“必须是 awaitable”的假设过强
   • _resolve_provider_id 中直接 await getter(...)。若框架侧返回同步函数（返回 str），会触发 TypeError；当前 except TypeError 分支再次 await getter(umo)，依旧可能抛同类错误并泄漏出去。
   • 建议统一判断返回值是否可等待（或用 inspect.isawaitable）后再决定 await 与否。

---

services/scheduler_service.py

1. 发送接口同样假设为异步，兼容性不足

   • _default_send_message 无条件 await sender(...)。如果 context.send_message 是同步函数，会直接 TypeError。
   • 建议与 LLM provider 解析逻辑类似，兼容同步/异步可调用返回。

2. 调度触发时间与实际执行时间可能偏离

   • _run_loop 超时后调用 run_once_for_time(trigger_time=next_run)，若事件循环阻塞或延迟唤醒，统计窗口仍按“计划触发时刻”计算，可能漏掉延迟期间消息。
   • 属于时间边界一致性问题，建议评估是否应使用实际执行时刻参与窗口计算。

---

tests/init.py

1. 违反日志适配约束

   • 使用了 Python 内置 logging 并 logging.getLogger("astrbot.tests")。
   • 按你给出的框架约束，logger 必须且只能来自 astrbot.api，不应使用内置 logging 体系。

2. 全局模块注入副作用较强

   • 直接改写 sys.modules["astrbot*"]，会影响同进程其他测试模块的导入行为，易出现交叉污染。
   • 建议通过更局部的 fixture/monkeypatch 控制生命周期。

---

tests/test_digest_service.py

1. asyncio.run 在测试中反复嵌套调用存在事件循环冲突风险
   • _run() 每次都 asyncio.run(coro)；当测试环境已有运行中的 event loop（常见于异步测试插件）会直接报错。
   • 建议改为 pytest.mark.asyncio + await 方式，或统一事件循环 fixture。

---

代码评审团

人物一：Linus Torvalds（直球暴躁流）
你这套代码主干是靠谱的，但“except Exception 到处兜底”这件事太像拿胶带修内核：短期能跑，长期炸锅。导入失败就导入失败，别把真正错误藏起来。建议：把异常收窄到 ImportError，让错误尽早、明确地暴露。

人物二：乔布斯（产品体验偏执流）
配置是用户体验的一部分。title_template.format(...) 一旦写错，整个指令失败——这不是“灵活”，这是“脆弱”。建议：模板格式化失败时优雅降级到默认标题，并给出可读提示，而不是把用户丢进异常黑洞。

人物三：钢铁侠 Tony Stark（工程效率流）
你在异步世界里默认所有外部接口都 await，这很“理想国”。现实是：有的 SDK 给你 async，有的给你 sync。send_message/get_current_chat_provider_id 都该做可等待判定，不然就是“我以为能飞，结果推进器没装”。建议：统一封装一个 maybe_await() 工具函数，所有外部可调用走同一兼容层。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
services/__init__.py
services/digest_service.py
services/group_origin_store.py
services/interaction_service.py
services/llm_analysis_service.py
services/message_filters.py
services/models.py
services/report_cache_store.py
services/scheduler_service.py
services/storage.py
tests/__init__.py
tests/test_digest_service.py
tests/test_message_filters.py

注意：由于项目规模或Token限制，本次仅审核了部分优先文件。以上报告内容由 AI 直接生成。

---

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

当前仓库：Ewingsal/astrbot_plugin_group_digest
剩余触发次数：2