Qwen 3.5 和 3.6 的修复版聊天模板

C++引擎上的工具调用

官方模板使用|items来迭代工具调用参数：

{%- for key, value in tool_call.arguments|items %}

Python 的 Jinja 支持 |items。C++ 运行时（LM Studio、llama.cpp、MLX）不支持——模板会产生渲染错误而非输出。本模板改用直接字典键查找：

{%- for args_name in tool_call.arguments %}
    {%- set args_value = tool_call.arguments[args_name] %}

它还将 is sequence 替换为 is iterable（更严格的 C++ 运行时要求如此），移除了 |safe 包装器（这也是仅限 Python 的），并处理以原始字符串而非对象形式返回的参数。

developer 角色

OpenAI 兼容的 API 规范会为系统级指令发送 message.role == "developer"。官方 Qwen 模板仅检查 "system"，遇到其他值时会抛出错误。此处的两个模板均接受 "developer" 并将其映射到系统角色。

空思考块

官方模板会将每个过往的助手轮次都包装在思考标签中：

<|im_start|>assistant
<think/>
</think >

Here is the answer...

当不存在推理内容时，这些标签就成了无用的累赘——它们会浪费上下文 tokens 并破坏前缀缓存。Qwen 3.5 模板在输出前会检查 reasoning_content。Qwen 3.6 模板则更进一步：它会尊重 preserve_thinking 参数，检查 reasoning_content|trim|length > 0，并将历史可见性与 <|think_off|> 覆盖标记关联起来。

</thinking> 幻觉问题（仅 Qwen 3.6）

Qwen 3.6 模型有时会生成 </thinking> 而非预期的闭合标签。官方解析器仅按 </think > 进行拆分，因此会解析失败。3.6 模板会检测实际使用的闭合标签，并据此进行拆分：

{%- if '</think >' in content %}
    {%- set think_end_token = '</think >' %}
{%- elif '</thinking>' in content %}
    {%- set think_end_token = '</thinking>' %}

它还能处理生成中断的情况（思考过程中达到最大 tokens 限制），通过挽救不完整的流，而非注入损坏的标签对。

参数序列化

官方模板无条件使用 |tojson 序列化参数值，这虽然能正确将 Python 的 True 转换为 JSON 的 true，但当值本身已是字符串时会出错。修复后的模板会先检查类型——字符串原样保留，其他所有内容则通过 |tojson 处理。

工具调用前自动关闭未闭合的思考块

模型有时会启动一个思考块，然后立即调用工具，而不输出闭合标签。官方模板不处理这种情况——未闭合的思考标签会渗入工具调用，导致输出格式错误。两个修复后的模板都能检测到此模式，并在工具调用边界前自动注入闭合标签。

无用户查询异常

官方模板会反向扫描消息列表，寻找最后一条“真实”的用户查询（跳过工具结果包装器）。如果所有用户消息都是工具结果——或者根本没有用户消息——它会触发 raise_exception('No user query found in messages.')，导致模板硬崩溃。

这会破坏实际使用场景：

• 智能体工具调用链，其中对话以工具结果结束，没有新的用户查询
• 在 OpenClaw 等运行时中执行 /reset 或 /new 之后，先前会话的工具结果仍然存在，但没有新的用户消息
• 无用户消息的纯系统上下文

修复方案用优雅的回退机制替代了异常：{%- set ns.last_query_index = messages|length - 1 %}。这样，思考显示逻辑会自然降级——当启用 preserve_thinking 时，包含推理内容的助手轮次仍然会显示思考标签。