Qwen3.7-Plus 在思考模式下为什么不能强制调用指定工具？

Qwen3.7-Plus 在思考模式下不能通过 tool_choice 强制调用某个指定函数，是平台对“先推理再自主选择工具”流程的参数限制，并非函数定义失效。开启 enable_thinking 时，tool_choice 只支持 auto 或 none；要指定函数，必须对这一轮关闭思考模式，或者把任务拆成规划与执行两次调用。

冲突发生在两个控制目标之间

思考模式（Thinking Mode）让模型在生成工具调用前先产生推理内容，用于分析用户意图、选择工具和规划参数。指定工具的 tool_choice 则跳过工具选择，要求模型始终返回某个固定函数。前者保留模型的选择过程，后者由应用直接替模型作出选择，因此平台不允许在同一轮同时启用这两个互相冲突的控制。

Qwen3.7-Plus 属于混合思考模型，而且默认开启思考。如果应用只设置了指定函数对象，却没有显式关闭思考，即使代码在其他模型上可用，也可能收到参数错误或无法获得预期的强制调用。

tool_choice 在思考模式下有哪些合法值

配置	含义	思考模式下
auto	模型判断是否需要调用以及选择哪个工具	支持
none	禁止本轮调用工具，直接生成回复	支持
required	要求调用工具，具体行为取决于接口和工具数量	不能用于该思考模式的强制场景
指定函数对象	固定调用给定名称的函数	不支持，需先关闭思考

这里还要区分 Chat Completions 与 Responses 等接口。不同接口对 required 的细节可能不同，但 Qwen3.7-Plus 开启思考时的核心边界不变：只使用 auto 或 none。

方案一：关闭本轮思考并指定工具

如果业务流程已经确定必须调用某个函数，例如用户点击“查询订单”按钮后必定执行订单查询，那么不需要模型再次推理是否调用。把 enable_thinking 设为 false，同时把 tool_choice 设置为目标函数即可。

from openai import OpenAI

client = OpenAI(
    api_key="从环境变量读取的密钥",
    base_url="千问平台的 OpenAI 兼容地址",
)

tools = [{
    "type": "function",
    "function": {
        "name": "get_order_status",
        "description": "按订单号查询订单状态",
        "parameters": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"}
            },
            "required": ["order_id"],
            "additionalProperties": False,
        },
    },
}]

response = client.chat.completions.create(
    model="qwen3.7-plus",
    messages=[{"role": "user", "content": "查询订单 A1024"}],
    tools=tools,
    tool_choice={
        "type": "function",
        "function": {"name": "get_order_status"},
    },
    extra_body={"enable_thinking": False},
)

enable_thinking 是千问扩展参数，通过 OpenAI Python SDK 调用时放在 extra_body 中。关闭思考只影响这一轮请求，不会让模型失去函数参数生成能力。应用仍需验证返回的函数名和参数，再决定是否执行。

工具执行后要移除强制选择

第一次响应返回 tool_calls 后，应用执行函数，并把 assistant 工具调用消息与 tool 结果消息追加到上下文。第二次请求用于让模型汇总结果，此时必须移除 tool_choice；否则模型会再次收到“必须调用同一函数”的命令，可能重复返回工具调用而不是自然语言答案。

messages.append(response.choices[0].message)
messages.append({
    "role": "tool",
    "tool_call_id": tool_call.id,
    "content": tool_result_json,
})

final_response = client.chat.completions.create(
    model="qwen3.7-plus",
    messages=messages,
    tools=tools,
    extra_body={"enable_thinking": False},
)

第二次请求保留 tools 并非总是必要，但不能继续保留指定函数的 tool_choice。如果业务明确禁止再次调用工具，也可以将它设为 none，要求模型只总结已有结果。

方案二：保留思考并让模型自动选工具

如果用户意图不明确，或者多个工具的适用条件需要推理，就保持 enable_thinking=true，并把 tool_choice 留为默认的 auto。模型会先输出 reasoning_content，随后决定是否生成 tool_calls。

这时提示词和工具描述可以提高选择准确率，但不能提供“必定调用某个工具”的协议保证。应用必须允许模型直接回复，也要处理它选择其他合法工具的情况。若业务合同要求某个动作必定发生，就不应把最终决定留给 auto。

方案三：把推理与强制执行拆成两轮

既希望模型分析复杂输入，又要求最终执行固定工具时，可以使用两阶段流程。第一阶段开启思考并设置 tool_choice=none，让模型整理意图、缺失信息和参数候选；应用验证结果。第二阶段关闭思考，只提供已经确定的目标工具，并使用指定函数对象强制生成工具调用。

1. 规划请求：开启思考，禁止工具，产出可验证的参数草案。
2. 应用校验：检查用户授权、必填字段、数据格式和业务规则。
3. 执行请求：关闭思考，指定目标函数，生成符合 Schema 的参数。
4. 本地执行：再次校验函数名和参数，执行工具并保存结果。
5. 汇总请求：移除强制选择，只让模型解释工具返回值。

如果函数参数完全由应用掌握，例如按钮已经携带可信订单 ID，应用也可以直接调用函数，无需为了形式而让模型生成一次工具调用。Function Calling 是模型与应用之间的协调协议，不是执行普通业务函数的必要前置步骤。

流式调用还要正确拼接工具参数

思考模式常与流式输出一起使用。流中可能先出现多段 reasoning_content，工具名称和 arguments 也可能分散在多个增量块中。应用应按工具调用索引或 ID 累积参数，等流结束后再解析完整 JSON，不能把每个片段当成独立调用。

后续请求若回传 assistant 消息，思考模式要求保留对应的 reasoning_content。遗漏字段或错误拼接消息顺序，会产生与 tool_choice 限制不同的协议错误，因此日志应分别记录请求参数、流式组装结果和最终工具调用。

常见错误配置

• 只设置指定函数，却依赖 Qwen3.7-Plus 的默认思考状态，导致参数组合不支持。
• 把 enable_thinking 放在错误层级，实际没有关闭思考。
• 第二轮汇总仍保留指定函数，造成同一工具循环调用。
• 认为强制调用等于安全执行，没有校验模型生成的参数。
• 流式场景未累积 arguments，拿到半截 JSON 就执行工具。

如何验证配置生效

准备一个无副作用的测试函数，只接收一个必填字符串。先开启思考并传指定函数，确认接口能暴露不受支持的参数组合；再将 enable_thinking 改为 false，预期响应包含目标函数名和可解析参数。执行模拟结果后，移除 tool_choice 发起汇总请求，预期得到自然语言回复且不再产生相同调用。

结论很直接：Qwen3.7-Plus 不是不能调用指定工具，而是不能在同一轮既开启思考又强制指定。业务已确定工具时关闭该轮思考；选择仍需模型判断时使用 auto；两者都需要时拆成规划、校验、强制执行和汇总四个明确阶段。