[Bug]当把不同的配置文件应用在不同的机器人账号上时，会出现混乱的情况

[WaterGodFurina]

What happened / 发生了什么

tip：这是我目前的QQ机器人账号

为了保护隐私，我进行了打码，姑且就称为小A（3875开头的QQ号，昵称为棉花）和小B（2199开头的QQ号，昵称为星露）吧
以下为Astrbot的接入情况

其中小A（棉花）使用的配置文件为default，小B（星露）使用的配置文件是FCL_op

以下为我想要提交该问题的正文：
我使用Astrbot时，发现这两个配置文件没应用在对应的账号上，而是被“颠倒了”——小A用的是FCL_op的配置文件，小B用的是default的配置文件
以下为Astrbot配置文件应用的人设

以下为部分聊天记录

这里可以看出小A用的是小B的人格，而小B用的是小A的人格
这里还有另一条证据可以证明

Duplicate of #Duplicate of #这里小A启用内置指令，小B禁用内置指令，结果小B的内置指令可以使用，小A的不行

以上这两点让我认为Astrbot的配置文件结构写的有问题，希望可以修复下

额外补充：我尝试重启过Astrbot容器，也重建过Astrbot容器，并无效果。我是从v3.5.4版本慢慢升级到最新版本（v4.21.0）的，v4.20.1也有这个问题

Reproduce / 如何复现？

1.配置两个QQ机器人
2.将不同的配置应用在不同的机器人上
3.回到QQ软件测试，即可复现

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

AstrBot版本：v4.21.0
部署方式：Docker compose
使用的提供商：Gemini 3 flash/kimi 2.5
使用的消息平台适配器：OneBotv11

OS

Linux

Logs / 报错日志

无

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[dosubot]

感谢你的详细报告！这确实是一个已知的架构限制问题。

根本原因： AstrBot的配置路由机制使用UMO（Unified Message Origin）三段式格式：platform_id:message_type:session_id，不包含机器人账号ID（self_id）。当两个机器人账号（小A和小B）通过同一个aiocqhttp适配器实例连接时，产生的UMO完全相同，配置路由器无法区分是哪个机器人的消息。

临时解决方案： 为每个机器人账号创建独立的aiocqhttp适配器实例（使用不同的id和不同的端口），这样platform_id会不同，配置路由就能正确区分。

相关Issue：

• #5787 - 配置文件路由规则问题 - Provider单例架构限制
• #5464 - 多OneBotv11实例event loop问题

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[WaterGodFurina]

感谢你的详细报告！这确实是一个已知的架构限制问题。

根本原因： AstrBot的配置路由机制使用UMO（Unified Message Origin）三段式格式：platform_id:message_type:session_id，不包含机器人账号ID（self_id）。当两个机器人账号（小A和小B）通过同一个aiocqhttp适配器实例连接时，产生的UMO完全相同，配置路由器无法区分是哪个机器人的消息。

临时解决方案： 为每个机器人账号创建独立的aiocqhttp适配器实例（使用不同的id和不同的端口），这样platform_id会不同，配置路由就能正确区分。

相关Issue：

• #5787 - 配置文件路由规则问题 - Provider单例架构限制
• #5464 - 多OneBotv11实例event loop问题

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

  

你说的解决方案虽然可能有效，但我的aiocqhttp适配器实例就是单独配置的，platform_id本身就不同

[dosubot]

抱歉之前的回复没有准确定位问题。既然你的platform_id已经不同，问题可能出在其他地方。

经过进一步分析，更可能的原因是：

1. 路由规则插入顺序问题：UmopConfigRouter使用"首次匹配即返回"策略，没有优先级机制。如果存在通配符规则（如::匹配所有消息），且它的插入顺序在特定platform_id规则之前，就会导致配置错误匹配。

2. 持久化路由表陈旧：路由表从SharedPreferences加载，没有自动清理机制。如果你曾修改过platform_id或配置，旧规则可能仍存在并产生冲突。

3. 已知的顺序重置bug：#4573 报告了重启后配置顺序被重置的问题，这会影响路由匹配。

建议排查：

• 检查Web管理面板中的消息事件源路由规则设置，确认两个适配器对应的规则和顺序
• 查看是否存在通配符规则（如-或::）覆盖了特定规则

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}