-
由于似乎是第三方插件的冲突，这里只记录一下。不求解决方案。但很好奇具体是什么原因引起的，有一些想法但不确定
-
可能的话，给装了类似插件导致出现同样问题的朋友一些参考
发现问题的过程，并非重点(点击展开)
先说一下之前遇到的问题
注：使用的适配器为onebot6.0.2（最新）和gocqdev1.1.1-dev-0.5.2（最新）及内置qsign0.7.2（最新），但问题应当与此无关
之前在用dialogue插件时，训练诸如“提问A回答B”时，在QQ群内直接发送“A”时并无响应而需要发送“dialogue A”才会响应“B”。
但在沙盒中的“群聊模式”则直接发送A就可以（沙盒模式的用户权限为1）
后来在群内管理的建议下尝试使用了blockly插件来实现相同功能。但由于初期尝试的不熟练导致了bot加的所有群理论上发送任何消息都会被响应
结果在测试中仍然只有沙盒会被响应。感到奇怪时，突然发现之前一直过滤掉
tsugu 插件的群会有响应，因此意识到是与 tsugu-bangdream-bot 插件有关。
问题描述：
在同时打开tsugu-bangdream-bot（以下简称tsugu）与dialogue插件时会导致dialogue插件训练的对话无法被正常响应，必须使用 dialogue xxx 才可被正常响应。同时blockly插件也有类似的问题
如下图，正常的情况下应当是在我输入 任意语句 时，bot会回复 world ；而当我发送利用dialogue插件训练的问答 非凡哥呢 时，bot会回复 您好（用户id），我是一名人类
而当我在先打开
tsugu插件再打开 dialogue与 blockly时，变成了如图这样：
可以看到并没有正常响应。
但很奇怪的是，同样情况下respondent插件可以被正常响应：
问题的可能原因？：
由于我并没有深入研究过各插件的实现原理，以下只是我的部分猜想，保假不保真，但或许能提供一些思路。
在描述我拙劣的猜想前我想先简要介绍一下tsugu插件的功能。
tsugu插件是一个游戏相关的辅助插件，提供了许多查询游戏讯息的指令
但在这些指令之外，有一些指令并未被写入koishi的指令管理中，比如
日服模式这个指令可以切换查询的游戏服务器（并不是上图中某个指令的别名，查看过了）。
猜想，或许是这种在koishi的指令列表之外的指令的识别，其使用的方式阻塞了dialogue和 blockly的响应。
在此猜想基础上再次试验后发现，当 先启用 dialogue和 blockly再启用tsugu 后，可以正常响应
但为什么会这样？
几个疑惑点：
-
blockly的响应逻辑是什么？为什么在别的插件响应后（如输入日服模式后仅会被tsugu响应）它会自动不响应（发送world）？ -
是否可以通过一些方式手动调整插件加载顺序来避免冲突？但查看日志发现我的
dialogue插件初始化时应该是在tsugu之前被加载的，为什么在此时仍会出现被阻塞的情况、而手动重新按顺序加载后就不会呢？消息读取后处理的先后逻辑究竟是怎么样的？
-
同样情况下，
respondent插件无论是先加载还是后加载、上述提到的三个插件开着还是关闭，都可以被正常响应，这又是为什么？说到底tsugu会与dialogue和blockly产生这种奇怪冲突的缘由究竟是什么？
应该无关，但系统信息如下：
System:
OS: Windows 10 10.0.19045
CPU: (8) x64 Intel(R) Core™ i7-7700HQ CPU @ 2.80GHz
Binaries:
Node: 16.19.1
Yarn: 3.5.0
Koishi:
Core: 4.15.0
Console: 5.16.1
Koishi Desktop: 0.10.7
所有插件截止发帖时均已是最新版本