用开源模型搭Agent，工具调用总是格式不对，有大佬踩过坑吗？

我之前搞llama3也卡在这，parser写到最后比agent逻辑还复杂。后来发现干脆别让模型自己拼JSON，用jinja2把function schema做成填空模板，让模型只输出参数名和值，格式错误率直接降了70%。你那个模型还可以试试在system prompt里给几个one-shot例子，要跟实际调用格式完全一致，比调温度有用多了。

另外Qwen对tool calling有专门的chat template，你直接调transformers的apply_chat_template，别自己拼对话历史，不然很容易把特殊token搞乱。微调真没必要，先检查是不是prompt里把工具描述写太长了，模型容易抓不住重点。

这个问题我太有感触了，上个月用Qwen2.5-7B做类似的事，也是被工具调用格式折磨到怀疑人生。后来试了一圈发现，光调temperature和top_p真的治标不治本，模型生成时对JSON结构的“感觉”不够稳定，尤其是函数名长或者参数嵌套深的时候，特别容易崩。我的经验是，与其自己写parser硬解析，不如在prompt里直接塞一个few-shot示例，最好把你要调用的API的完整JSON schema写进去，再给两三个“错误输出”和“正确输出”的对比，模型会明显更听话。另外，你可以试试在系统提示里强制要求它先输出一个“思考过程”，然后再单独一行输出JSON，这样能减少把参数混进自然语言的情况。还有个比较脏但有用的技巧：把temperature降到0.1，然后把top_p调到0.9，虽然会牺牲一点多样性，但格式稳定度会高很多。微调的话，除非你有几百条真实工具调用的历史数据，不然性价比真的不高，我之前试过用LoRA微调，训练数据量不够反而更容易产生幻觉。最后，如果实在不行，可以看看Llama.cpp的grammar功能，它能在解码层面强制输出合法JSON，比纯靠模型自觉靠谱多了。

我之前也卡在过这个坑里，Qwen2.5-7B对function calling的格式敏感度确实不太稳定，尤其是参数嵌套多层的时候，动不动就给你来个中英文逗号混用或者少个花括号。后来我试了两种办法，一个是在system prompt里把OpenAI的JSON schema直接贴进去，再给一个“错误对照表”，比如告诉它“如果函数名是get_weather，不要写成getWeather”，效果比单纯调温度参数强很多。另一个是干脆绕开模型自己生成完整JSON，改成让它输出“工具名+参数键值对”的纯文本，然后我自己用正则或者json.loads容错解析，虽然丑但稳。微调的话除非你有几百条真实失败案例，否则性价比不高，因为格式错误往往不是知识问题，而是生成概率分布的问题。另外建议你试试把temperature降到0.1以下，并且关闭top_p，让采样更确定，同时把max_tokens设大点，有时候截断也会导致JSON不完整。还有个取巧的方法，就是给模型看一个“半成品”示例，比如在user消息里放一个“参考这个格式，只填参数值，不要重复函数名”，很多开源模型对填空式任务要乖得多。

我之前也卡在这块好久，Qwen2.5-7B对function calling的支持其实不算原生，别指望它默认就输出标准JSON。后来我是直接在system prompt里塞了一个极简的few-shot示例，加上“必须严格输出JSON，不要解释”这种强约束，成功率能到八成。parser肯定得写，但别硬解析，用json修复库兜底，比微调省事多了。另外temperature别调太高，0.1左右反而更稳，你可以试试。

这个坑我太熟了，之前用Qwen系列调工具调用也是被格式问题折磨到怀疑人生。我试下来最有效的一招是别指望模型自己输出标准JSON，而是把工具定义的schema直接塞进system prompt里，并且给一个“如果参数不全就返回特定错误码”的指令，这样至少能拦住一半的格式错误。另外你说temperature和top_p时好时坏，我后来发现把temperature调到0.1以下，再把top_p设成0.9，输出稳定性会好很多，但代价是偶尔会死板地重复模板。自己写parser这事我建议别硬刚，因为模型可能把参数塞进自然语言里，这时候你不如加一层正则加规则匹配，先把明显的残缺JSON补全，再处理那些漏掉的字段。至于微调，除非你有大量真实调用日志，否则性价比太低，我试过用几百条样本微调Qwen2.5-1.5B，效果还不如调prompt明显。有一个取巧的办法是让模型先输出一个“思考过程”再输出最终调用，这样它更容易把参数从上下文里抽出来，格式反而更规整。最后推荐你看看OpenAI官方文档里关于function calling的few-shot示例，直接把他们的例子改成Qwen能懂的表述，很多格式问题就消失了。

我之前用Qwen系列也遇到过一模一样的问题，后来发现光调温度没用，得在system prompt里把工具返回的JSON schema和示例写死，最好给两三个few-shot例子。另外建议试试把解析逻辑做成容错式的，比如用json修复库或者正则兜底，别指望模型每次都完美输出。微调的话成本太高，除非你的工具调用特别固定，不然先靠prompt工程撑住比较现实。

别硬调参了，直接上结构化输出或者json mode，Qwen对那个支持还行，parser治标不治本。

我之前也在这块卡了好久，Qwen2.5对function calling的格式敏感度确实不如GPT系列。后来发现把工具定义写得特别详细，每个参数都带上示例值，输出稳定性会提升不少。parser硬写肯定要的，但别全指望它，可以加一层正则兜底，至少能救回一半的JSON错误。另外你试试在system prompt里明确给一个完整的调用示例，比单纯调temperature管用多了。微调暂时别考虑，成本太高，先拿few-shot顶一顶。

我之前也被这个问题折磨过一阵子，Qwen系列对工具调用的格式确实不如GPT那么稳，尤其是你提到把参数塞进自然语言这个情况，太真实了。我的经验是，别指望temperature能救命，它跟输出格式的稳定性关系真不大，反而调低了会让模型更保守，有时候连函数名都开始瞎猜。

自己写parser不是不行，但你会陷入无穷无尽的边界情况，今天补一个括号，明天它给你多出个逗号，搞到最后你根本不是在调Agent，是在给模型擦屁股。我后来换了条路，直接把OpenAI的function calling格式写进系统prompt里，并且给了一个“错误示例”加上一个“正确示例”，对比着喂进去，效果提升非常明显，你可以试试。

另外有个小技巧，如果模型实在憋不出JSON，就让它先输出一个“```json”代码块，然后你再用正则把块里的内容抠出来，配合json5或者解析器容错，能解决大部分少括号的问题。关于微调，除非你的场景特别固定，否则真不建议动，成本高不说，Qwen2.5-7B基座微调后可能连通用能力都受影响。

还有一个坑你可能还没踩到，就是工具描述写得太啰嗦，模型反而容易混淆，把每个函数的description缩短到一句话，参数类型写清楚，别用“可选”这种模糊词，准确率能再上一档。你先按这个思路调调，如果还是乱，可以试试最新版的Qwen3系列，工具调用的原生支持好了不少。