一、现象

vLLM 起 Qwen3.8-27B（FP8）给 Agent 做工具调用（我这里是 Hermes）。模型明明在输出工具调用，API 侧却解析不出来，日志里反复刷：

WARNING [qwen3xml_tool_parser.py:305] Error when parsing XML elements:
not well-formed (invalid token): line 6, column 1

一周里积了 94 条。每次工具调用作废，模型重试一次，整体体感又慢又不稳。

二、先排除一个常见嫌疑

第一反应：是不是我下的模型是 Coder 变体，格式对不上？

直接翻模型目录的 config.json：

model_type = qwen3_5
base_model: Qwen/Qwen3.8-27B

标准官方版，没有 Coder 血统。再看它自带的 chat_template.jinja：模板里教模型用的就是 <function>/<parameter> 格式——和我们实际收到的输出完全一致。模型输出没问题。

三、真凶：parser 太"较真"

vLLM 里 Qwen3 的工具调用 parser 有两个，认的标签完全一样（都是 <function>/<parameter>），差别在实现：

• qwen3_xml：用真 XML 解析器（expat）做校验。标签要闭合，参数值要合法 XML——值里出现未转义的 <、&、引号，直接报错。
• qwen3_coder：纯正则，只认标签边界，内容"合不合法"根本不管，没收尾也照收。

Agent 场景对严格版是致命的：工具参数里全是 shell 命令、JSON、引号——恰恰是全世界最不像 XML 的内容，塞进 <parameter> 就不是合法 XML 了，expat 罢工，整条工具调用作废。

四、解决

vLLM 启动参数改一个：

--tool-call-parser qwen3_coder

重启。前后实测对比（同机同模型，只有 parser 这一处改动）：

	修复前（约 6 天）	修复后（18.5 小时）
请求量	—	2265 个 chat completions
not well-formed 解析错误	94 次（日均 16 次）	0 次
parser 相关日志行	2 万多行	0 行

顺带一提：改完体感变快，不是基础 token 速度变了——是省掉了每次作废后的重试。

五、注意边界

• 修的是服务层，不是模型。权重没问题，别想着去下载什么"修复版模型"。
• parser 的选择是"宽松 vs 严格"，不是"新 vs 旧"。如果你的场景参数值都很干净、且想要严格校验，qwen3_xml 依然成立。
• 双向坑：也有用户报告 qwen3_coder 在某些 checkpoint 上死循环输出 !!!!!!（HF Qwen3-Coder-Next 讨论 #17），换回 qwen3_xml 才好。选哪个看你的模型版本和参数值"脏"不脏，拿日志说话。
• 适用面：vLLM 跑 Qwen3 家族 + 参数值长、含特殊字符的 Agent 工具调用场景。日志里刷同样 WARNING 的，先试这个。

六、相关发现（不是我一个人的孤证）

• NVIDIA NemoClaw #6457 / #6551（2026-07）：DGX Spark 上 Qwen3.6-35B-A3B 用 qwen3_xml 起服务，工具调用 HTTP 400，日志同样的 not well-formed（303 行 vs 我这边 305 行，版本差几行）。NVIDIA 的修复 PR 把 recipe 改成 qwen3_coder，根因描述和本帖一致。
• vllm-project/recipes PR #826（2026-08，未合并）：Qwen3.8-27B 的官方 recipe 正把 parser 改回 qwen3_xml。按官方教程配的人，下一步大概率会踩这个坑——欢迎踩完来对答案。
• openclaw #124284（2026-08，open）：完全相同的报错行（line 6, column 1）和 3 次重试症状，归因到了流式包装 bug，parser 没动。

七、环境

vLLM（0.1.15 构建）、Qwen3.8-27B-FP8、Hermes Agent。