Python: [Bug]:

[hongxichina]

Description

从仓库里搜下来的结论很明确：

不是代码里“禁止 Qwen 调 run_skill_script”，而是 Qwen 在这条多层技能链里更容易把工具调用“说出来”，而不是真正发出来。

我找到的证据有三类。

第一，代码里没有任何按模型名分支处理 run_skill_script 的逻辑。
我搜了模型名和 run_skill_script，没看到类似“如果是 qwen 就禁用工具”这种判断。真正的工具调用约束是统一的，都在：
src/agents/team_prompts.py
src/agents/team_runtime.py

第二，runtime 和测试里已经把一种失败模式写死成“已知问题”了：
模型输出了 agent_response/function_call/messages/in_progress 包装，但没有真正执行工具。
这不是我猜的，代码里就有专门诊断文案：
src/agents/team_runtime.py#L829
测试也直接断言了这种错误模式：
tests/test_team_runtime_media_request_sources.py#L119

第三，仓库文档已经记录过“为了验证工具调用稳定性，专门切到 Claude/GPT 做对比”的历史。
这说明你现在观察到的现象，之前就已经被当成模型稳定性问题处理过，不是偶发：
docs/视频确认执行轮工具调用与主智能体路由修正_2026_04_09-12-07-18.md
docs/确认执行轮次禁止分析文本_2026_04_09-02-27-46.md
docs/开发版主模型切换到ClaudeOpus4_6_2026_04_09-12-48-24.md

所以综合起来，原因更像是：

1. run_skill_script 这条链要求很苛刻。
   要求模型在确认执行轮里：

   • 先 load_skill
   • 再立刻真调 run_skill_script
   • args 必须是 JSON 对象
   • 不能输出 prose
   • 不能输出 function_call/messages 包装
     这对模型的工具调用服从性要求很高。

2. qwen3.5-plus / qwen3.6-plus 在你这套 DashScope OpenAI-compatible + agent-framework + nested sub-agent 组合里，更容易失败在协议层。
   失败形式就是：

   • 把函数调用写成文本
   • 把 args 串成字符串
   • 先讲解释再想调工具
   • 输出 status=in_progress 之类包装 JSON
     而不是发出真实 MCP 工具调用事件。

3. glm5.1 / glm5 / claude-opus-4-6 / claude-sonnet-4-6 在这条链上的实际服从性更高，所以你看到它们“能调”，Qwen“偏偏不行”。

一句话总结：

Qwen 不是“功能上不支持 run_skill_script”，而是“在你这条多层、强格式、确认执行轮的工具协议里，实际稳定性明显差于 GLM/Claude”。

如果你要继续往下做，最对路的不是再猜模型，而是两条工程路任选一条：

• 继续保守：把确认执行轮更多收口到代码里，少依赖模型真的去发 run_skill_script
• 继续实验：保留 Qwen，但只让它做推荐/问答，把真正执行脚本那一步完全代码化

你现在的仓库其实已经在往这个方向演化了。

Code Sample

Error Messages / Stack Traces

Package Versions

1.0.0rc5

Python Version

python3.12.3

Additional Context

No response