[Bug] 飞书群聊中前置 @机器人 导致 /stop 等指令未被识别 #9848

问题描述

在飞书群聊中，使用飞书常见的“先 @机器人，再输入指令”方式发送 @机器人 /stop 时，AstrBot 能被唤醒，但不会将消息识别为内置 /stop 指令，而是继续进入普通 LLM 处理流程。

如果当前 UMO 已有正在运行的 Agent，这条未识别的 /stop 还会被当成 follow-up message 捕获。

同样的问题会影响所有标准指令，例如插件提供的 /m。

如何复现？

1. 使用飞书（Lark）官方适配器，将机器人加入群聊。
2. 在群聊中启动一次会持续一段时间的 Agent 请求。
3. 按飞书的常见输入顺序发送：@机器人 /stop。
4. 观察 Debug 日志。

预期行为

• 消息链仍保留对机器人的 At 组件。
• 用于唤醒和命令解析的文本应等价于 /stop。
• 内置 stop handler 被激活，请求停止当前 Agent。

实际行为

• 消息已被 At 唤醒。
• stop command filter 没有匹配。
• 消息进入普通 AstrBot handler 和 LLM。
• 存在活跃 Agent 时，/stop 被捕获为 follow-up。

AstrBot 版本

v4.27.4

操作系统

macOS

部署方式

源码运行（uv run main.py）

使用的消息平台适配器

飞书 / Lark 官方适配器

错误日志

[19:58:03.939] [Core] [INFO] [core.event_bus:74]: [default] [lark-Soulter的智能助手(lark)] ou_3c8cd/ou_3c8cdef93ea5e6307a4d08499b381730: [At:ou_07f2f0eb25318d71f3264ea445da6c5f] /stop
[19:58:03.940] [Core] [DBUG] [waking_check.stage:165]: enabled_plugins_name: ['*']
[19:58:03.942] [Core] [DBUG] [method.star_request:46]: plugin -> astrbot - handle_session_control_agent
[19:58:03.943] [Core] [DBUG] [method.star_request:46]: plugin -> astrbot - handle_empty_mention
[19:58:03.943] [Core] [DBUG] [method.star_request:46]: plugin -> astrbot - persist_group_message
[19:58:03.943] [Core] [DBUG] [method.star_request:46]: plugin -> astrbot - on_message
[19:58:03.944] [Core] [DBUG] [agent_sub_stages.internal:193]: ready to request llm provider
[19:58:03.945] [Core] [INFO] [process_stage.follow_up:205]: Captured follow-up message for active agent run, umo=lark-Soulter的智能助手:GroupMessage:oc_1bd91d3b1b8b1105180f0de4697bd98b, order_seq=1

日志中没有出现 builtin_commands - stop，说明内置指令 handler 未被激活。

初步根因定位

这是根据当前代码作出的推断：

1. Lark 适配器的 _build_message_str_from_components() 会把 At 组件序列化进 message_str，生成类似 @机器人 /stop 的文本：
   • https://github.com/AstrBotDevs/AstrBot/blob/master/astrbot/core/platform/sources/lark/lark_adapter.py#L130-L153
2. WakingCheckStage 只有在 message_str 以 wake prefix（默认 /）开头时才会剥离 /：
   • https://github.com/AstrBotDevs/AstrBot/blob/master/astrbot/core/pipeline/waking_check/stage.py#L106-L143
3. At 检查虽然会将事件标记为 wake，但不会从 message_str 中移除前置的机器人 At。
4. CommandFilter 最终收到 @机器人 /stop，无法匹配命令名 stop：
   • https://github.com/AstrBotDevs/AstrBot/blob/master/astrbot/core/star/filter/command.py#L191-L218

临时绕过方式

将指令放在消息最前面、把 At 放到后面，例如：

/stop @机器人

该形式下 / 位于 message_str 开头，可以正常进入 wake-prefix 和命令解析流程。

修复建议

以下两种方式任选其一：

1. Lark 适配器保留消息链里的 At，但在构造供命令解析使用的 message_str 时剥离开头对机器人的 At。
2. 在 Core 唤醒阶段统一规范化“前置 At 自身 + 指令”的消息文本。

建议增加回归测试，至少覆盖：

• @bot /stop 能触发内置指令；
• @bot /plugin_command 能触发插件指令；
• 普通 @bot 自然语言 仍能正常进入 LLM。

检查清单

• 已搜索 Issue 列表，未发现相同问题。
• 使用内置 /stop 即可复现，与第三方插件无关。
• 问题位于 AstrBot 本体的飞书消息解析/命令匹配链路。
• 已阅读并同意项目贡献者行为准则。