[Plugin] astrbot_plugin_dida365

[zhenyumi]

插件信息

{
  "name": "astrbot_plugin_dida365",
  "display_name": "滴答清单连接器",
  "desc": "在 AstrBot 中连接 Dida365（滴答清单），支持任务查询、定时汇报和基于 LLM 的任务操作。",
  "author": "zhenyumi",
  "repo": "https://github.com/zhenyumi/astrbot_plugin_dida365",
  "tags": [
    "Todo",
    "定时",
    "提醒"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_dida365

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

client.py

• 潜在缺陷与性能瓶颈:
  • 在 _request_json_once 方法中，每次发起请求时都使用了 async with aiohttp.ClientSession(...) as session:。这会为每一个 API 请求创建并销毁一个 HTTP 会话，无法利用内部的连接池（Connection Pooling）与 Keep-Alive 机制。对于一个频繁调用 API 的任务同步插件，这会导致严重的性能损耗（TCP/TLS 握手开销）并在高并发下可能导致本地端口耗尽。
  • 建议: 在 DidaClient 类或服务的生命周期（如 initialize/terminate 阶段）中初始化一个全局共享的 aiohttp.ClientSession 实例并在请求间复用，在插件卸载时统一关闭。

llm_ops.py

• 可维护性与潜在崩溃风险:
  • 从 astrbot.core.astr_main_agent 导入并使用了 _get_session_conv。这是一个以单下划线开头的框架内部私有方法，这意味着它的签名和存在性在未来 AstrBot 的版本更新中可能随时发生变动。由于本插件强依赖该内部方法，极易在后续版本中出现兼容性断裂导致插件崩溃。
• 代码质量与编码规范:
  • 在 _build_persona_context 方法中，处理上下文深拷贝时使用了 json.loads(json.dumps(begin_dialogs))。这种序列化反序列化的操作开销较大且不够 Pythonic。
  • 建议: 使用 Python 标准库 copy 模块中的 copy.deepcopy(begin_dialogs) 替代。

reporting.py

• 可维护性与 Hack 实践风险:
  • 在 _get_conversation_for_target 方法中，不仅调用了私有的 _get_session_conv 方法，甚至为了绕过类型检查和满足其参数需求，强行在函数内部定义并实例化了一个 _SyntheticEvent（伪造事件类）。这种 Hack 做法是对框架设计意图的严重偏离，一旦框架在事件处理环节增加任何额外的属性检查或方法调用，此伪造类将立即抛出 AttributeError。
  • 建议: 尝试查阅 AstrBot 最新文档，寻找是否有官方开放的、通过 session_id 或 umo 获取 Conversation 对象的正式 API；若没有，建议向 AstrBot 社区提交 Feature Request，而不是在生产环境长期遗留此炸弹。
• 代码质量与编码规范:
  • 同 llm_ops.py，存在 json.loads(json.dumps(begin_dialogs)) 的序列化拷贝写法，建议替换为 copy.deepcopy。

task_ops.py

• 潜在缺陷与全局状态管理:
  • DidaTaskOpsCoordinator 类在类级别定义了 _PENDING_PLAN_CACHE: dict[str, dict[str, Any]] = {}。在 Python 中，类属性是所有实例共享的。由于插件框架在重载、多租户分配或环境隔离时可能创建该类的多个实例，这种跨实例共享的全局字典极易导致脏数据遗留或并发状态污染（甚至在内存泄漏时无法被回收）。
  • 建议: 应该在 __init__ 构造函数中将其初始化为实例属性，即 self._pending_plan_cache: dict[str, dict[str, Any]] = {}，从而保证缓存生命周期与服务实例严格一致。

---

代码评审团

Linus Torvalds：
老天，你的 ClientSession 每次请求都要重新 new 一个？你是在写什么一次性的玩具脚本吗？每一次 API 调用你都在强迫操作系统去做毫无意义的 TCP 握手和 TLS 协商，网络层的资源就在你这一开一关中被白白浪费了！连接池这种东西几十年前就发明了。不过公平地说，你的类型注解写得很详尽，甚至连 slots=True 都加上了，内存意识是不错的。现在，把你的 HTTP 会话管理也提升到同样的水平！

乔布斯：
你的代码从整体来看非常有结构感，像是一个经过深思熟虑的系统。但是，当我在 reporting.py 里看到你为了获取会话，硬生生拼凑出一个 _SyntheticEvent 的时候，这种感觉被打破了。这就像是在一件精美的铝合金设备内部，用一截丑陋的电线胶布把两块主板缠在了一起。这是一个极不优雅的“黑客级”妥协。永远不要对系统内部私有 API 存在侥幸心理，请找到更纯粹、更系统化的方式去获取所需的数据。

理查德·斯托曼 (Richard Stallman)：
在这个互联的数字世界，我们必须精准地控制我们程序的每一寸状态！你在 DidaTaskOpsCoordinator 中放置了一个全局的 _PENDING_PLAN_CACHE 类变量。你放弃了将数据约束在单一实例生命周期内的自由，而让它游荡在类的全局命名空间里。一旦你的软件在多上下文中运行，状态的混乱就会像剥夺自由的专有软件一样束缚你的调试过程。把这个字典拉回 __init__ 里去，让每个实例拥有自主控制自己状态的权利。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
client.py
exceptions.py
llm_ops.py
reporting.py
service.py
task_ops.py
time_utils.py
types.py

---

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

当前仓库：zhenyumi/astrbot_plugin_dida365
剩余触发次数：4

[zhenyumi]

已修改。

1. ClientSession 已改为在插件生命周期内复用，在 initialize() 创建、terminate() 关闭，请求侧不再每次新建会话。
2. json.loads(json.dumps(...)) 替换为 copy.deepcopy(...)。
3. _PENDING_PLAN_CACHE 从类级状态改为实例级状态，避免跨实例共享缓存。

似乎没有找到通过 session_id 或 umo 获取 Conversation 对象的正式 API，因此llm_ops.py 和 reporting.py 仍然依赖 _get_session_conv，保留了reporting.py 中的 _SyntheticEvent。没有移除这部分，是为了优先保持当前LLM汇报和自然语言任务操作能力。

• 修改的部分：llm_ops.py 在会话恢复失败时会给出更加清晰的错误信息。
• reporting.py 在相关链路失败时会稳定切换到 direct 模式进行汇报。

[astrbot-plugin-copybara]

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

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