[Bug]: Strict tool calling attaches no structural tag when the reasoning and tool parsers share a parser engine

快速结论：当 vLLM 的推理解析器（reasoning parser）与工具调用解析器（tool parser）指向同一个解析器引擎时，Strict Tool Calling 模式下可能不会附加结构约束标签（structural tag），导致模型输出不受 JSON Schema 约束。优先排查 --reasoning-parser 与 --tool-call-parser 的取值组合，以及 ToolParserManager.get_parser() 中是否存在共享解析器引擎的短路逻辑。

适用环境：vLLM（GitHub 仓库 vllm-project/vllm，Issue #53745）；报告环境为 Ubuntu 24.04.4 LTS x86_64、Python 3.12.3、PyTorch 2.13.0+cu130、NVIDIA RTX A6000 ×4、NVIDIA 驱动 580.173.02、AMD EPYC 7773X CPU。注意：`python collect_env.py` 显示 CUDA available 为 False，但实际检测到 4 张 A6000 GPU。

最快修复方案：暂无经过 Issue 验证的独立“一步修复”命令。Issue 关闭时，修复已合入当前 main 分支（社区成员 @youkaichao 在评论中指出 commit 46638857fdbb 已合并 #52830，移除了 get_parser 中的短路逻辑）。若你使用的是旧版 vLLM，可优先尝试升级到包含该修复的最新 main 构建。

注意事项：该修复仅合入 main，Issue 关闭时尚未确认发布到正式 release 版本；#53752 仍未合并，其测试用例虽然检查了 structural_tag，但使用了 mock，不能直接作为验收证据。评论者强调的验收标准是：在真实（未 mock）CPU 环境下，构造 strict: true 的 ChatCompletionRequest 进行验证。

问题场景

用户在 vLLM 中同时使用推理解析器（reasoning parser）与工具调用解析器（tool parser），并开启 Strict Tool Calling（strict: true）与 tool_choice=required。当两者复用同一个 ParserEngine 实例时，返回的响应中 structural_tag 为 None，意味着模型输出实际不受 JSON Schema 结构约束，可能导致生产环境出现畸形参数键（malformed argument keys）。

报错原文

[Bug]: Strict tool calling attaches no structural tag when the reasoning and tool parsers share a parser engine

#52830 merged on current main (`46638857fdbb`, 2026-08-26T04:37:36Z) and removed the `get_parser` short-circuit this issue names.

- On `d9fbe526c0` (the issue's main), `parser_manager.py:142-143` still returned the shared `ParserEngine` when `reasoning_engine_cls is tool_engine_cls`.
- On current main, that branch is gone. `get_parser` composes a `DelegatingParser`. `DelegatingParser.adjust_request` still calls `_apply_structural_tag` when `_tool_parser.structural_tag_model` is set. `ParserEngine.adjust_request` still only sets `skip_special_tokens = False`.
- `Qwen3EngineToolParser.structural_tag_model` remains `"qwen_3_coder"`.

原因分析

问题根源在 ToolParserManager.get_parser() 的短路逻辑（short-circuit）。当 reasoning_engine_cls is tool_engine_cls（即推理解析器与工具解析器使用同一个 ParserEngine 类）时，旧版代码在 parser_manager.py:142-143 处直接返回共享的 ParserEngine，跳过了 DelegatingParser 的组装过程。而 DelegatingParser.adjust_request() 中才包含调用 _apply_structural_tag() 的逻辑——一旦跳过该层，即使 strict: true 被正确设置，也不会在请求中附加结构约束标签 structural_tag，导致语法约束静默失效。

修复方式是移除该短路分支，让 get_parser() 始终组装 DelegatingParser，由后者根据注册的工具解析器决定是否调用 _apply_structural_tag()。Issue 关闭时该修复已合并进 main。

环境排查

确认 vLLM 版本是否为 2026-08-26 之前的 main（如 d9fbe526c0，存在短路逻辑）；修复合入于 46638857fdbb。
检查启动参数中 --reasoning-parser 与 --tool-call-parser 的组合是否指向同一解析器引擎（如 qwen3 与 qwen3_coder）。
构造请求体时确认 strict: true 与 tool_choice=required 均已传递。
若使用 Qwen3 系列模型，确认 Qwen3EngineToolParser.structural_tag_model 是否为 "qwen_3_coder"。
Issue 报告环境：Ubuntu 24.04.4、Python 3.12.3、PyTorch 2.13.0+cu130、NVIDIA RTX A6000、驱动 580.173.02。注意此处 PyTorch 为 2.13.0 且 CUDA runtime 显示 “Could not collect”，与常规版本号差异较大，可能是较新的开发构建或环境采集异常。

解决步骤

将 vLLM 升级到包含 #52830 修复的主线版本（commit 46638857fdbb 或之后）。该提交移除了 get_parser 中共享引擎的短路分支，使 DelegatingParser 始终被组装。
升级后，以 Issue 原始场景验证——使用命令行参数 --reasoning-parser qwen3 --tool-call-parser qwen3_coder，构造包含 strict: true 和 tool_choice=required 的 ChatCompletionRequest，检查响应是否携带非 None 的 structural_tag。
如果无法立即升级，可先检查本地 parser_manager.py（对应行 142-143）是否存在该短路判断；若存在，可优先尝试将其注释或移除，但需要自行重新编译且不受 Issue 验证支持。
如果输出仍不符合预期，进一步检查 ToolParserManager 的注册表中是否实际存在 qwen3_coder 对应的 Qwen3EngineToolParser，而不是回退到 Qwen3ParserToolAdapter（适配器不应替代完整解析器）。

验证方法

在修复后的版本上复现同一请求对象，需要用 Issue 评论者给出的验收标准确认：--reasoning-parser qwen3 --tool-call-parser qwen3_coder 且 strict: true、tool_choice=required 时，响应应带非 None 的 structural_tag；同一对解析器在 tool_choice=auto 时，应附加触发标签形式；使用 DelegatingParser 组合（如 deepseek_r1 + qwen3_coder）时也能正常附加。此外确认共享引擎路径上的 parser_cls.tool_parser_cls 是注册的 Qwen3EngineToolParser 而非 Qwen3ParserToolAdapter。最简单的判定：若模型 200 返回中出现了 JSON Schema 禁止的键（如把 objective 拼成 objctive），说明结构标签仍未生效，问题未解决。