[Bug] enable_social_context_injection 启用时会导致 LLM 工具调用（Tool Call）失效

[beren929]

Plugin Version

Next-2.1.0

AstrBot Version

v4.22.2

Database Type

SQLite (default)

Operating System

Linux

Bug Description

当 Social_Context_Settings.enable_social_context_injection 设置为 true 时，插件会向 LLM 请求中注入回复风格指令（如"详细解释型"、"直接回答型"、"引导思考型"等），这些指令会强烈诱导模型直接生成文字回复，导致模型不再调用已注册的工具（Tool Call），搜索等功能完全失效。

Steps to Reproduce

启用 astrbot_plugin_self_learning，保持 enable_social_context_injection: true
同时启用 astrbot-web-searcher 插件
向 BOT 发送需要搜索的消息，例如"搜索今天新闻"
观察 LLM 返回结果中 finish_reason 为 stop，tool_calls 为空列表 []
将 enable_social_context_injection 改为 false 后重启，同样消息可正常触发 finish_reason='tool_calls'

Expected Behavior

期望的修复方式
建议在 Social_Context_Settings 中增加一个独立开关，例如：
json"disable_reply_mode_injection_when_tools_present": true
或在检测到当前请求已注册工具时，跳过回复模式相关的指令注入，仅保留情感、好感度等不影响工具调用判断的上下文注入。

Error Logs

日志关键信息
问题出现时：
finish_reason='stop', tool_calls=[]
prompt_tokens=16000~22000
关闭后正常：
finish_reason='tool_calls'
tool_calls=[ChatCompletionMessageFunctionToolCall(...name='web_search_tavily'...)]
根本原因分析
Hook 执行顺序为：
astrbot_plugin_self_learning - inject_diversity_to_llm_request  ← 注入回复风格指令
astrbot_plugin_livingmemory - handle_memory_recall
astrbot-web-searcher - edit_web_search_tools                    ← 最后才挂载工具
self_learning 注入的 [HIDDEN_INSTRUCTION_START] 指令块中包含"推荐回复模式：详细解释型"等内容，使模型倾向于直接生成回答，而非判断是否需要调用工具。

Relevant Configuration

Additional Context

环境信息
AstrBot 版本：v4.22.2
插件：astrbot_plugin_self_learning
模型：本地 qwen3.5-35b（gguf 量化，通过 LM Studio 部署）
工具调用插件：astrbot-web-searcher（Tavily）

[github-actions]

🤖 Issue 审查报告

优先级: 🟠 high

📋 用户处理意见

问题摘要: 开启 Social_Context_Settings.enable_social_context_injection 后会注入“回复模式/风格”类强引导指令，模型更倾向直接输出文本而不是触发 tool_calls，导致依赖工具调用的插件（如 web-searcher）失效。

问题分类: 配置错误

建议操作：

1. 在 self-learning 插件配置中将 Social_Context_Settings.enable_social_context_injection: false
2. 重启 AstrBot（确保插件重新加载配置）
3. 验证同一条“搜索xx”消息能再次出现 finish_reason='tool_calls' 且 tool_calls 非空

---

🔧 开发者修复建议（点击展开）

技术摘要: 当前的“回复模式/风格”注入属于强约束系统提示，且在工具挂载前执行，容易压制/干扰后续工具调用决策；应在检测到本轮请求存在 tools 时跳过（或弱化）该类注入，或提供独立开关。

相关模块: services/social, services/response, services/hooks, config

相关文件: config.py, services/social/social_context_injector.py, services/response/response_diversity_manager.py, services/hooks/llm_hook_handler.py

根因分析: 根据 issue 现象与代码结构，注入“引导思考型/详细解释型”等内容来自 services/response/response_diversity_manager.py（定义了多种回复模式文案），并通过社交上下文注入链路（services/social/social_context_injector.py）或 LLM hook（services/hooks/llm_hook_handler.py）写入到最终请求 messages/system prompt。由于 hook 顺序中 self_learning 的注入早于 astrbot-web-searcher 的 edit_web_search_tools 挂载 tools，导致注入逻辑无法基于“本轮存在工具”做条件判断；同时该注入本身会显著提高模型直接回答倾向，进而出现 finish_reason='stop' 且 tool_calls 为空。

修复建议: 1) 在 config.py 的 Social_Context_Settings 增加独立开关（如 disable_reply_mode_injection_when_tools_present: true，默认 true），并在 config.py 的加载逻辑（目前已在 230/340-341 一带加载 social_context_settings）补齐字段解析与默认值。
2) 在 services/social/social_context_injector.py（或实际实现 inject_diversity_to_llm_request 的位置，通常会调用 ResponseDiversityManager）注入前检查当前 LLM 请求是否存在 tools：

• 若框架把 tools 放在 request['tools'] / request.tools / context['tools']，则当其非空时：跳过“回复模式/风格”注入，仅保留情感/好感度/关系图谱等更中性的上下文。
• 或将“回复模式”文案降级为弱提示（例如放入非 system 的 developer/user note，或改写为‘在不影响工具调用的前提下…’）。

3. 若当前注入发生在 hook 阶段且拿不到 tools（因为 web-searcher 更晚挂载），则需要调整 hook 执行顺序：在 services/hooks/llm_hook_handler.py 中让“工具编辑/挂载类 hook”先运行，再运行 self_learning 的注入 hook；或者把 self_learning 的注入改为在所有 hook 之后的“finalize request”阶段执行，但仍需读取 tools 并做跳过逻辑。
4. 增加回归测试：构造一个包含 tools 的请求，启用 enable_social_context_injection 时，断言不会注入 response_diversity 的‘推荐回复模式’块（或断言注入内容不包含 services/response/response_diversity_manager.py 中的模式关键词），以保证 tool_calls 行为不被压制。

---

Note

信息不完整 — 请补充以下信息以便我们更快地处理：

• logs

---

_{🤖 此报告由 AI 自动生成，已分析仓库源码，仅供参考。开发者会尽快审阅您的 issue。}

[beren929]

经过进一步排查，发现问题与模型架构有关。
原模型 qwen3.5-35b-A3B 是 MoE 架构，实际每次只激活约 3B 参数，在 self_learning 注入回复风格指令后上下文变长，工具调用判断能力明显退化。
换用 Qwen3.5-27B（稠密模型，全量激活 27B 参数）后，保持 self_learning 开启，工具调用恢复正常稳定。
因此这个问题是插件注入内容 + MoE 模型工具调用能力不足共同导致的，在能力更强的稠密模型上表现不明显。
但插件本身在检测到工具调用场景时跳过回复风格注入的建议仍然有价值，可以作为对弱模型的兼容性优化，避免用户在使用本地小模型时遇到同样的问题。