关联 Issue

Ref #5222

改动文件

astrbot/
├── builtin_stars/builtin_commands/commands/
│   └── conversation.py                        # 在 reset/new/del 中调用 stop_all()
├── core/
│   ├── pipeline/
│   │   └── scheduler.py                       # execute() 中注册/注销活跃事件
│   └── utils/
│       └── active_event_registry.py           # 新增：UMO → 活跃事件映射注册表

背景

用户在 LLM 请求（特别是工具调用）正在处理时执行 /reset、/new 或 /del，旧请求的响应仍然会被发送给用户，导致混乱和不一致的体验。

根因

/reset、/new、/del 命令在执行会话操作前，没有终止该会话下正在处理的活跃事件。事件的 stop_event() / is_stopped() 机制已存在，但缺少从会话命令到活跃事件的查找和终止能力。

修复内容

1. 新增 ActiveEventRegistry（astrbot/core/utils/active_event_registry.py）

• 维护 unified_msg_origin → 活跃事件集合的映射
• 提供 register()、unregister()、stop_all(umo, exclude=) 方法
• 模块级单例，参照 session_lock.py 的模式

2. 修改 PipelineScheduler.execute()（astrbot/core/pipeline/scheduler.py）

• 在 execute() 入口处注册事件
• 在 finally 块中注销事件，确保无论正常完成还是异常退出都会清理

3. 修改会话命令（conversation.py）

• reset()：在清除对话历史前，调用 stop_all() 终止该 UMO 下所有其他活跃事件
• new_conv()：在创建新对话前，终止活跃事件
• del_conv()：在删除对话前，终止活跃事件
• 三个命令均通过 exclude=message 排除自身，确保命令自身的响应正常发出

行为变化

• 变更前：用户在工具调用执行中发送 /reset、/new 或 /del，旧的 LLM 响应仍会在命令执行后发出
• 变更后：命令执行时立即终止活跃事件，pipeline 各阶段及 agent 工具调用循环检测到 is_stopped() 后中断，旧响应不再发出

风险与兼容性

• ActiveEventRegistry 是纯新增模块，不影响现有代码路径
• PipelineScheduler.execute() 改动仅增加了 try/finally 包装，不改变原有执行逻辑
• stop_all() 只作用于同一 UMO 下的其他事件，不影响其他会话

验证

• 本地端到端测试：发送触发工具调用的消息，在工具执行期间发送 /reset，确认旧响应未被发出
• 服务器端到端测试：部署后在实际环境中验证 /reset、/del 命令均能正确终止活跃事件