大模型调用工具，为什么解析器比模型更容易出错

**摘要**：客户的 Agent 平台要接大模型，第一天联调就全挂：带 `tools` 字段的请求一律 400。等 400 修好，又出现一个更阴的问题——服务不报错，但 `tool_calls` 字段永远是空的，模型的工具调用原文混在正文里吐出来。最后定位到的原因跟模型质量毫无关系：vLLM 里工具调用的输出解析器按启动参数指定，选错了不报错、只静默失败。本文按当时三道关卡的顺序复盘这次上线，给出一套可以直接照抄的闭环验收清单。适合要给业务系统/Agent 平台接 Function Calling 的工程同学。一、背景：Agent 平台联调，一天撞了两堵墙这套服务之前一直跑得好好的：纯对话、RAG 问答、长文档摘要都没问题。直到客户的 Agent 平台接进来——该平台按 OpenAI 标准协议传 `tools` 字段，联调第一天出现两类症状：症状一：带 tools 的请求全部 400 'auto' tool choice requires --enable-auto-tool-choice and --tool-call-parser to be set症状二（修完 400 之后）：请求成功返回，但 tool_calls 字段恒为空， 模型的"工具调用"以 XML 原文形式混在 content 里有意思的是：模型从头到尾都是对的——它确实生成了一次工具调用。错的是服务端的"翻译官"。二、第一关：工具调用默认是关的`tools` 报 400 是三个症状里最友好的一种，因为它会报错。vLLM 默认不启用工具调用，必须在启动时显式配两个参数：docker run ... \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder这里有两个容易踩的点：1.这两个参数是启动参数，不是运行时配置——改它需要删旧容器、重建。很多人会先去翻运行时的配置接口，白找一圈；2.`--tool-call-parser` 的取值没有"自动检测"——它是一个需要你按模型家族指定的字符串，vLLM 不会替你判断。这就埋下了第二关的雷。三、第二关：不报错的错，才是最贵的错400 修完之后，客户端同学反馈"调用成功了但拿不到结构化结果"。看了一眼返回：{ "choices": [{