用Qwen做Agent总是跑偏，function calling到底怎么调才稳？

7B模型做function calling本来就不是强项，你遇到的这个“编JSON”问题我太熟了。vLLM默认的chat template确实是针对通用对话优化的，Qwen官方那个带tool的template如果你不手动指定，模型根本不知道该怎么输出tool_call结构，所以它才会自己瞎编一个看起来合理的响应。我建议你先去HuggingFace上把Qwen2.5的chat template源码拉下来对比下，特别是看它怎么处理<|tool_call|>这种特殊token，然后用vLLM的--chat-template参数显式传进去，光靠system prompt和调temperature是治标不治本。

另外解析兜底这块，说实话在实际项目里是必须写的，别指望模型每次输出都规范。我现在的做法是双重保险：先正则匹配{"name":..., "arguments":...}这种标准结构，匹配不到就尝试用json.loads硬解析，还不行就强制走一个“重试”流程，让模型重新生成。但更关键的是，7B模型你最好把工具数量控制在5个以内，描述写得越具体越好，比如不要写“获取天气”，而是写“根据传入的城市名和日期返回实时天气数据，参数city为字符串，date为YYYY-MM-DD格式”。我试过把工具描述从两句话扩成一段话，成功率能提升差不多15%。

还有个小技巧，你可以试试在system prompt里放一个few-shot示例，就是给一个用户提问和对应的正确tool_call输出，让模型模仿格式。这个比单纯说“必须使用工具”有效得多。另外你提到temperature调到0.3，我觉得可以再低点，比如0.1，甚至直接用greedy decoding，因为tool calling本质上是个格式匹配任务，随机性越小越好。至于Qwen2.5-7B本身，说实话它做简单工具调用能跑通，但复杂场景还是容易漏参数或者多生成文本，如果条件允许直接上14B或32B，体验是质的差别。

vLLM默认模板确实容易翻车，建议换官方chat template试试，解析兜底必须写。

vLLM默认模板确实容易出问题，建议换官方chat template试试，解析兜底也得写，7B模型格式飘是常态。

vLLM默认模板确实可能是个坑，我之前用Qwen系模型也踩过，它官方文档里其实明确写了要配合特定的chat template才能正确输出tool_call格式，建议你直接去Qwen的GitHub仓库里把那个jinja模板拷出来，用vLLM的served_model配置加载一下，别用默认的。

另外7B模型在function calling上天生就比大模型容易飘，temperature调到0.3其实还是偏高，我实际测下来得压到0.1甚至0，并且把top_p也调低到0.8左右，不然它总喜欢“自由发挥”。你还可以试试在system prompt里把工具描述写得更“死板”一点，比如每个参数的类型和必填项都标注清楚，模型反而更容易跟着格式走。

至于解析兜底，这个真的得写，别指望模型每次输出都完美符合JSON schema，我项目里是直接加了一层正则+json.loads的容错，失败了就强制让模型重新生成一次，最多重试两次，再不行就返回错误给用户。

还有个偏门但有效的办法：把工具调用的示例直接塞进few-shot里，不要只靠system prompt，模型看到几个“标准答案”后，模仿能力会强很多。你可以试一下，如果还是不稳定，建议直接换Qwen2.5-14B或者32B，7B干这个活确实有点勉强。

vLLM默认模板确实容易踩坑，Qwen的官方chat template得手动指定，不然模型对tool_call的格式理解会偏差很大。我试过在tokenizer_config里显式加上qwen2.5的模板，再配合tool_use的system提示，稳定性提升挺明显的。解析兜底建议一定要写，7B模型偶尔输出不标准太正常了，我这边会用一个宽松的JSON提取器，先找json块再尝试正则抓字段。温度0.3还是偏高，可以试试0.1，另外把max_tokens调大点，有时模型是生成到一半被截断才导致乱编。

同款问题，7B模型对工具调用的指令遵循能力确实比大模型弱不少，光改prompt和temperature作用有限。我之前试过在vLLM里显式指定--chat-template指向Qwen官方仓库的模板文件，效果比默认模板稳多了，你可以先排查这个。另外解析兜底是必须的，我自己写了个正则+JSON双重校验，发现模型偶尔会输出"name":"get_weather"和"name": "get_weather"这种带空格的变体，直接解析铁定崩。还有个野路子是给模型塞几个few-shot例子，比如在system里放两条“用户问天气→你输出完整tool_call”的demo，比单纯强调指令管用。你试试把温度再调低点到0.1，甚至0，有时候随机性高了反而更容易瞎编。

vLLM默认的chat template确实可能跟Qwen的官方template有出入，这个影响很大，建议先检查一下。另外7B模型本身工具调用能力就有限，硬调prompt不如试试few-shot，给几个标准的tool_call示例让它模仿，比单纯强调“必须用工具”管用。解析兜底肯定要写，我这边实测至少20%的返回格式会有小毛病，直接json.loads会炸，得做个容错处理。还有个小技巧，temperature别调太低，0.5左右反而更稳，太低容易让模型走捷径乱编。

同款问题，试过加few-shot例子比改prompt管用，vLLM记得用官方给的chat template，解析兜底必须写。

真试过7B这德行，vLLM模板没问题，但得把tool call的few-shot塞进对话里，光改prompt真没用。

vLLM默认模板确实不一定是给tool calling优化过的，你试试在加载时加上--chat-template指定Qwen官方的tool模板，差别挺明显的。另外7B模型对格式的跟随能力有限，我自己项目里是让模型先输出一个极简的“需要工具”标记，再单独生成JSON，解析失败就重试一次，比硬让它一步到位稳多了。你那temperature其实可以再低点，0.1左右对减少幻觉有帮助。

vLLM默认模板确实容易出问题，建议换成Qwen官方chat template试试，解析兜底也得写，7B这体量不稳定很正常。

tool_call输出老不标准的话，我这边是加了个正则清洗层硬兜底，比反复调prompt省心多了。

vLLM默认模板确实容易让7B飘，建议手动套Qwen官方chat template，解析兜底也得写，我项目里正则+json修复双保险才稳。

试过把temperature拉到0.1，然后system里给个工具调用的few-shot示例，比干强调管用，解析兜底必须做。

vLLM默认模板确实容易坑，建议手动改成Qwen官方chat template，解析兜底也得写，模型抽风时能救场。

温度调低不如约束采样，试试guided_json或tool_choice强制走函数调用，7B模型吃这套。

7B想稳就得上严格格式约束，vLLM记得开guided_json，解析兜底必须写，别信模型自觉。

我之前跑Qwen做工具调用也踩过这坑，特别是7B，编JSON的毛病太典型了。vLLM默认模板一般没问题，但建议你直接看下官方给的chat template，有时候得手动指定那个带tool call的版本。temperature降到0.1以下会有改善，但治标不治本，关键还是得在解析层做兜底，只认严格的tool_call格式，不然模型一自由发挥就崩。另外可以试试把工具描述写得更死板，少给模型发挥空间，语气上别留余地。

7B模型想稳调用，温度降到0.1加few-shot比改prompt管用，模板必须用官方chatml。

解析兜底肯定要写，模型偶尔抽风正常，正则抓不全就上json修复库。

7B这个体量想让它老老实实走function calling，光调temperature真不够，本质上是模型对工具调用的分布学习得不够强。你试过把tool call的few-shot示例直接塞进prompt里吗，对齐JSON格式比反复强调“必须用工具”有用得多。vLLM的chat template倒是大概率没问题，但建议你确认下Qwen官方仓库里针对function calling的专用模板，不同版本差异挺大。解析兜底肯定要写，别指望7B次次标准，我一般会在解析失败时让模型重新生成一次，而不是直接报错。

7B模型对tool call的格式理解本来就弱，vLLM的模板大概率没对齐，建议检查下Qwen官方模板里的tool_call标识符。

7B这个规模想让它老老实实走function calling，本质上是跟它博弈，不是调参能完全解决的。你提到vLLM，我猜问题可能出在它默认用的chat template跟Qwen官方那个带tool的模板有差异，尤其是tool_call_id和arguments的格式，模型一旦没见过标准示例，就会自己脑补。我试过最有效的一招是，把system prompt里换成极简的“你只能通过调用工具回答问题”，然后给一个或两个完整的few-shot，包括用户问、assistant返回带tool_calls的JSON、再到tool结果回传的完整轮次，比单纯调temperature管用得多。另外temperature我反而会拉到0.7以上，因为太低容易让模型陷入重复生成固定格式，反而更爱编造。解析兜底肯定得写，别指望模型每次都标准，常见坑是arguments里多出换行或者少个引号，我一般用正则先把非法的字段抽出来再json.loads，或者干脆让模型输出纯字符串再用eval兜底。还有个野路子，如果你只是查天气这类简单工具，可以试试把工具描述写成“如果你不确定，就返回一个错误标志”，有时候模型会为了省事直接调API。最后想问下，你用的vLLM版本是新的吗？老版本对Qwen的tool模式支持有点别扭，升级到0.6以上可能会好不少。

这个情况我太熟了，7B模型做Agent最头疼的就是它宁可自己编也不调工具，本质上还是模型觉得“编一个看起来像样的JSON”比走工具调用这条路径更省事。vLLM那边确实要注意chat template，Qwen2.5的tool call格式对模板挺敏感的，如果你直接用默认的或者没带tools字段进去，模型压根不知道有工具可用，只能自己瞎编。建议你先把tokenizer的apply_chat_template打出来看看，确认tools是不是真的注入了system或对应位置。另外temperature调到0.3其实帮助有限，关键还是得在推理时用guided decoding或者outlines这类约束解码，把输出强制绑到tool_call的schema上，这样它想跑偏都难。兜底解析肯定要写，7B偶尔会漏个括号或者字段名拼错，我一般用正则先捞tool_call块，再json.loads，失败就重试一次并降低采样温度。还有个偏方是在system里给一两个few-shot示例，展示“用户问天气→直接输出tool_call”的完整链路，比单纯喊“必须用工具”管用得多。