用开源模型搭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系列，工具调用的原生支持好了不少。

试试few-shot，在system里塞几个标准工具调用示例，比调参数管用，Qwen对格式示例挺敏感的。

我最近也在折腾这个，Qwen2.5-7B的function calling确实不稳定，尤其跟OpenAI那套格式对标的时候，经常给你来个“自然语言+JSON”混合体。我建议你先别急着微调，试试在system prompt里给一个极简的few-shot示例，比如直接把OpenAI文档里的那个天气函数调用原样贴进去，再让模型模仿输出，比调temperature管用多了。另外，自己写parser几乎是必须的，但别硬解析纯文本，可以先用正则把JSON块抠出来，再用json库去load，遇到缺括号的情况就尝试补全，比如自动加上右大括号或者用ast.literal_eval兜底。还有个小技巧，把工具调用的schema从JSON Schema改成更简单的列表描述，比如“函数名: get_weather，参数: location=北京, date=明天”，模型对这种结构化文本的遵循度反而更高。微调的话除非你有几百条真实报错样本，不然性价比太低，我试过用LORA跑了几轮，效果提升有限，还容易过拟合。最后建议你关掉采样，温度设成0，top_p设成1，虽然看起来死板，但比随机性带来的格式漂移靠谱多了。

我最近也在折腾这个，Qwen2.5系列对function calling的支持确实有点飘，尤其是7B这种小参数模型，输出格式稳定性比GPT-4差不少。建议别硬靠调参，先试试在system prompt里给一个超详细的JSON Schema示例，最好把“参数必须严格按这个结构，别加任何解释文字”写进去，能缓解不少。另外，别自己写parser，除非你想体验无穷无尽的边界case，可以看看LangChain里现成的output parser，或者直接上Outlines这种结构化生成库，约束解码能根治格式问题。微调的话成本太高，除非你任务特别固定，不然先用提示词工程和约束解码顶一阵子吧。

我之前用Qwen系列也撞过这堵墙，函数名和JSON格式漂移特别常见，尤其是模型一旦开始生成自然语言解释，输出就整个放飞了。我自己试下来，光靠调temperature真不解决根本问题，反而把temperature降到0.1附近再配合一个强制性的系统提示词，比如要求“只输出JSON，不要任何解释”，会稍微稳一点。但说到底，现成模型对严格格式的跟随能力就是有限，你与其硬写parser去猜，不如在prompt里把工具定义的schema写得极度具体，甚至直接在例子里给出一个完整正确的调用样例，few-shot比说什么都管用。还有个偏门技巧是，让模型先输出一个“思考标记”再输出JSON，虽然丑但有时候能神奇地减少格式崩坏，你可以试试。如果你后面想彻底省心，微调确实是最稳定的路，但用LoRA低成本调几百条数据就够了，不用全量微调。另外，LangChain那个JsonOutputFunctionsParser也不是万能的，它自己也会被格式坑，建议你抓一下模型原始输出，看看是不是被后处理给改了。

我之前也卡在这块好久，Qwen2.5对工具调用的格式稳定性确实不如专门微调过的模型。你可以先试试在系统提示词里给一个严格的JSON Schema示例，然后强制让模型先输出思考过程再输出最终结果，这样能减少不少乱写参数的情况。

另外别急着上微调，成本太高。langchain里有个OutputFixingParser可以自动纠错，配合pydantic校验一下，至少能把语法错误拦下来。至于函数名写错的问题，我后来是把所有可用函数描述直接塞进few-shot示例里，效果比只给定义好很多。

你要是实在懒得折腾，也可以看看llama.cpp的grammar功能，直接限定输出格式，一步到位。不过qwen对这种约束支持一般，需要自己调下模板。

别硬调参了，先试试few-shot给几个标准例子，比啥都管用。实在不行再上正则兜底，微调真没必要。

别死磕微调，先试试few-shot给两个标准例子，Qwen对格式的跟随能力会好很多，parser兜底也得写。

7B模型原生function calling确实不稳，建议直接上支持tool call的微调版或者换14B，省得跟parser死磕。

Qwen2.5原生支持function calling，直接用它的tool template别自己拼prompt，稳很多。