Prhub

#38848 [Bugfix] Fix Qwen3 tool parser for Responses API tools

vllm-project/vllm · 作者 sfeng33 · 合并时间 2026-04-08 10:08

分析状态 已生成
文件变更 4提交数 4 · 评论 4
代码增减 +99 / -113
bugfix tool-calling qwen responses-api v1

执行摘要

修复 Qwen3 工具解析器对 Responses API 工具的支持,确保参数类型正确解析。

Qwen3CoderToolParser 和 Qwen3XMLToolParser 假设所有工具都有 .function.name.function.parameters 结构(ChatCompletionToolsParam 类型),但 Responses API 的 FunctionTool 对象使用扁平结构(.name, .parameters 直接),导致参数类型查找失败,所有值都被返回为字符串。PR body 中描述了这个问题的具体表现和测试对比,如 dimensions 参数在修复前返回字符串化的 JSON,修复后正确返回对象。

该 PR 值得精读,因为它展示了如何通过共享工具函数解决 API 兼容性问题,并涉及规范遵循与灵活性的权衡。建议关注 find_tool_properties 的设计决策、测试覆盖的讨论以及工具解析模块的统一化趋势。

讨论亮点

Review 中核心讨论点:1) gemini-code-assist[bot] 指出 find_tool_properties 缺少回退逻辑,若工具定义无 'properties' 键可能破坏兼容性;sfeng33 回复认为 OpenAPI/JSON Schema 规范要求工具参数必须有 'properties',因此不是问题。2) gemini-code-assist[bot] 指出测试 fixture 只包含 'xml' 参数,导致 Qwen3CoderToolParser 未被测试;sfeng33 认为这超出本 PR 范围。最终 PR 被 aarnphm 批准,但测试覆盖疑虑未解决。

实现拆解

实现方案分为三个关键部分:1) 在 vllm/tool_parsers/utils.py 新增 find_tool_properties 函数,利用现有的 _extract_tool_info 统一处理 ChatCompletionToolsParam 和 FunctionTool 两种工具类型,返回属性配置;2) 在 vllm/tool_parsers/qwen3coder_tool_parser.pyqwen3xml_tool_parser.py 中移除冗余的 _get_arguments_config_get_param_type 逻辑,改为调用新函数;3) 更新测试文件 tests/tool_parsers/test_qwen3coder_tool_parser.py 以支持两种工具类型的参数化测试,验证修复效果。

文件 模块 状态 重要度
vllm/tool_parsers/utils.py tool-parsing modified 8.0
vllm/tool_parsers/qwen3coder_tool_parser.py tool-parsing modified 7.0
vllm/tool_parsers/qwen3xml_tool_parser.py tool-parsing modified 7.0
tests/tool_parsers/test_qwen3coder_tool_parser.py testing modified 6.0

分析完成后,这里会展示 LLM 生成的相对完整源码片段和详细注释。

关键符号

find_tool_properties _get_arguments_config (removed) _parse_xml_function_call (modified) _get_param_type (modified)

评论区精华

find_tool_properties 回退逻辑 正确性

gemini-code-assist[bot] 指出缺少回退可能破坏兼容性;sfeng33 反驳说规范要求有 properties 键。

结论:未解决,但 PR 被批准,基于规范假设。 · 已解决

测试覆盖率 测试

gemini-code-assist[bot] 指出 Qwen3CoderToolParser 未被测试;sfeng33 说超出范围。

结论:未解决,测试覆盖可能不足。 · 待处理

风险与影响

技术风险包括:1) find_tool_properties 函数假设工具定义遵循 OpenAPI/JSON Schema 规范,若缺少 'properties' 键,参数类型转换可能失败,导致回归;2) 测试覆盖率不足,Qwen3CoderToolParser 在参数化测试中未被充分覆盖,增加潜在 bug 风险;3) 修改核心解析逻辑可能影响流式和并行工具调用场景,需依赖现有测试验证。

影响范围:使用 Responses API 与 Qwen3 模型进行工具调用的用户。影响程度:修复了参数类型错误,提升了工具解析的正确性,避免数据格式问题,对依赖类型敏感的应用(如数学计算或结构化数据处理)至关重要。系统层面,统一工具查找逻辑减少代码冗余,增强了可维护性。团队层面,强化了 tool-calling 和 responses-api 模块的健壮性。

缺少回退逻辑 测试覆盖不足 规范依赖风险

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接,后续同步到相关引用后会出现在这里。

完整报告

执行摘要

本次 PR 修复了 Qwen3 工具解析器在 Responses API 中无法正确处理 FunctionTool 扁平结构的问题,通过统一工具属性查找逻辑,确保参数类型正确解析,提升了工具调用的正确性和数据格式一致性。

功能与动机

Qwen3 工具解析器(包括 Qwen3CoderToolParserQwen3XMLToolParser)原先假设所有工具都有 .function.name.function.parameters 结构(对应 ChatCompletionToolsParam 类型),但 Responses API 的 FunctionTool 对象使用扁平结构(.name.parameters 直接定义),导致参数类型查找失败,所有值被错误地返回为字符串。如 PR body 所述,修复前 dimensions 参数返回字符串化的 JSON,修复后正确返回对象。

实现拆解

实现方案围绕统一工具属性查找逻辑展开:

  1. 共享工具函数:在 vllm/tool_parsers/utils.py 新增 find_tool_properties 函数,委托给现有的 _extract_tool_info 处理两种工具类型,返回属性配置。
  2. 解析器重构:在 vllm/tool_parsers/qwen3coder_tool_parser.pyqwen3xml_tool_parser.py 中移除冗余的 _get_arguments_config_get_param_type 方法,改为调用新函数。
  3. 测试更新:在 tests/tool_parsers/test_qwen3coder_tool_parser.py 中更新测试 fixture,支持 ChatCompletionToolsParamFunctionTool 两种工具类型的参数化测试。

关键代码示例(来自 utils.py):

def find_tool_properties(
    tools: list[Tool] | None,
    tool_name: str,
) -> dict[str, Any]:
    """Find a tool by name and return its properties dict, or {}."""
    if not tools:
        return {}
    for tool in tools:
        name, params = _extract_tool_info(tool)
        if name == tool_name:
            return (params or {}).get("properties", {})
    return {}

评论区精华

Review 讨论聚焦于两个核心点:

  1. 正确性权衡:gemini-code-assist[bot] 指出 find_tool_properties 缺少回退逻辑,可能破坏非标准工具定义的兼容性;sfeng33 反驳称 > "This is not a concern because OpenAPI/JSON Schema spec requires tool parameters to be an object schema with a 'properties' key." 基于规范假设,此疑虑未完全解决但 PR 被批准。
  2. 测试覆盖:gemini-code-assist[bot] 指出测试 fixture 只包含 'xml' 参数,导致 Qwen3CoderToolParser 未被测试;sfeng33 回应 > "This is technically correct, but out of scope for this PR." 测试覆盖问题被视为未解决。

风险与影响

  • 技术风险find_tool_properties 依赖 OpenAPI/JSON Schema 规范,若工具定义缺少 'properties' 键,参数类型转换可能失败;测试覆盖率不足增加回归风险;核心解析逻辑修改可能影响流式和并行工具调用场景。
  • 影响分析:直接影响使用 Responses API 与 Qwen3 模型进行工具调用的用户,修复参数类型错误提升正确性;系统层面统一工具查找逻辑,减少代码冗余,增强可维护性。

关联脉络

  • 与 PR #38860(修复 tool-calling 和 responses-api 参数传递)紧密相关,同属 tool-calling 模块的 bugfix 系列。
  • 与 PR #38755(迁移 Responses API 流式解析到统一解析器)一脉相承,显示仓库正推进统一解析器架构,以减少重复代码和提升兼容性。
    结合历史 PR,可见仓库在 tool-calling 和 responses-api 领域持续优化,注重规范遵循和模块化设计。

参与讨论