用开源模型搭Agent，工具调用总翻车，是选型不对还是prompt没写好？

这问题我太熟了。核心在于Qwen和Llama3.1的tool use能力其实还没到稳定可落地的程度，特别是参数类型推断这块，预训练阶段对结构化工具调用的对齐做得不够。建议先试下Glm-4-9B或者Mistral-Nemo，这两在func

tion calling的benchmark上明显领先。另外prompt里把每个参数的type、enum、description写死，用json schema强制约束比自然语言描述靠谱得多，ReAct模板的中间推理步骤反而容易带偏输出。

同感，我最近也在折腾这块，用的也是Qwen2.5，遇到跟你一模一样的问题——它经常把“city”参数理解成数字或者乱填，甚至有时候直接把工具名给改了，比如“send_email”变成“send_mail”，然后报错说找不到工具。我一度怀疑是不是自己prompt里的function schema写得太复杂了，但按官方文档改了好几版，该崩还是崩。

我后来试了下把工具描述写得更具体，比如在“city”后面加一句“这个参数必须是字符串类型，例如'Beijing'或'Shanghai'，不要使用数字或城市代码”，效果稍微好一点，但偶尔还是会翻车。感觉还是模型本身对结构化输出的理解不够稳定，尤其是本地部署的7B或8B版本，参数量小，指令跟随能力确实有限。

你试过用ReAct模板的时候，有没有加few-shot示例？我往prompt里塞了两三个正确的工具调用例子，包括参数填什么，结果明显稳定一些，但代价是token消耗变大了。另外，我听说有些模型专门针对tool use做了微调，比如ToolLlama、Gorilla，或者像Qwen2.5-32B这种大一点的版本，本地跑不动的话可以试试API。还有，检查一下你的function calling格式是不是标准的OpenAI格式，有些开源框架对格式要求很严格，少个字段就崩。

最近在看有没有更好的本地方案，你调得自闭我也调得头疼，要是找到好办法记得互通有无啊。

同款遭遇，最近也在折腾本地搭Agent，用的Qwen2.5-7B，工具调用时参数乱传真是家常便饭。我试过把function calling的schema写得特别详细，比如city参数加description说“必须是中文城市名，如北京、上海”，结果它给我传个“beijing”或者直接空着。ReAct模板也试过，感觉模型在“思考”步骤里能理解该用工具，但到“行动”那步就放飞自我了。

我个人猜测，这跟模型在预训练阶段对“工具调用”这种结构化输出的理解深度有关。像Qwen2.5和Llama3.1虽然指令跟随能力不错，但对“必须严格遵循JSON schema”这种约束，可能权重还不够高。尤其本地部署的量化版本，精度下降后更容易丢失边界条件。我后来试过用FireFunction-V2这个专门针对工具调用微调的模型，虽然没完全解决，但至少参数错乱少了一半。不过它基座是Llama，对中文支持一般，得自己配翻译层。

另外你提到“不传就瞎执行”，这个我遇到最多的是模型把tool_call_id搞混，或者连续调用时上下文挤爆了。我目前的做法是：1）在system prompt里强行加一行“若必须调用工具，请先确保所有必填参数已从用户输入获取，若无参数则回复用户缺少信息” 2）在代码层做硬校验，参数不符合schema就直接让模型重试三次，重试时把原始报错信息喂回去。虽然暴力，但至少能跑通简单流程。

还有个坑是llama.cpp和vLLM的grammar约束，理论上能限制输出格式，但我实测对function calling场景效果一般，反而容易把模型卡死在半路。你用的是哪个推理框架？不同框架对tool call的兼容性差挺多的。

我也在试类似的东西，Qwen2.5在function calling上确实有点飘，感觉它对参数类型的约束理解不够严格。你试过把每个工具的参数示例直接塞进system prompt里吗？比如明确写“city必须为字符串，例如'Beijing'”，这样命中率会高一些。另外也想蹲一个专门优化过tool call的模型，最近看到有在推Glm-4-9B的，不知道实际效果怎么样。

试试把参数示例写进system prompt，或者换Qwen2.5的tool-use专用版本，我调过感觉稳定不少。

说实话，我也踩过类似的坑，尤其是Qwen2.5在function calling里对参数类型的理解确实不够稳定，经常把字符串和数字搞混。后来我换了Mistral的function calling微调版，配合更严格的system prompt把每个参数类型和样例都写清楚，翻车率降了不少。你试试把工具描述改成JSON Schema格式，然后每个参数都加个example字段，模型有时候会参考这个。另外可以考虑加一层验证逻辑，模型输出后先校验参数再执行调用，虽然麻烦但至少能兜底。

老实说这俩模型在tool use上确实有点随缘，Qwen2.5对参数类型敏感度一般，Llama3.1中文场景更容易脑补。可以试试把工具描述写成更具体的few-shot例子，比如直接给个“city:北京”的示范，或者考虑切到专门优化过的ToolLlama，起码参数格式翻车少点。另外检查下temperature是不是设太高了，调低到0.1能减少幻觉。

说实话你这个情况我太熟了，Qwen2.5和Llama3.1在工具调用上的翻车率确实不低，尤其是参数类型错乱和漏传，我试过给Llama3.1传个“发邮件”工具，它自己脑补了个收件人地址格式，搞得我差点把它当bug修了一整天。我自己感觉这跟模型对function calling的底层理解有关——很多开源模型在训练时工具调用的样本量不够，导致它把参数当成普通文本去“联想”而不是严格按照schema执行。你试过把工具描述写得特别啰嗦吗？比如“city参数必须是字符串，例如'Beijing'，不能是数字”这种，有时候能糊弄过去。另外我最近在玩一个叫ToolLlama的模型，专门针对tool use微调过，还有Mistral的function calling版本，实测参数错误少很多。如果你不想换模型，可以试试在prompt里给个错误示例，比如“坏例子：city=123；好例子：city='Shanghai'”，模型有时候能通过对比理解意图。总之别自闭，这问题太普遍了，慢慢调。

参数脑补太常见了，可以试试给工具描述加few-shot示例，或者换专门调过的tool use模型比如Glaive。

参数脑补多半是模型对齐问题，可以试试加个强制输出JSON的约束，或者换专门调过的ToolLLaMA。

老实说我也踩过类似的坑，Qwen2.5的function calling在参数约束上确实有点飘，尤其city这种字符串传成数字我遇到过好几次。后来我把工具描述里的字段类型写成中文“城市名（文本）”而不是直接写string，再在system里加一句“严格按照工具定义格式输出参数”，翻车率就降了不少。Llama3.1的话，你可以试试最新的8B Instruct版，它对ReAct模板的稳定性比旧版好一些，但还是建议先用Qwen2.5-72B试试，小参数模型工具调用确实容易放飞。

QLoRA微调一下Qwen2.5的tool use能力，效果立竿见影，比折腾prompt省心多了。

可以试试Glm4或DeepSeek的tool-use版本，Qwen2.5工具调用确实容易幻觉，加个参数校验层能缓解。

Qwen2.5在function calling上确实有点随缘，我试过给它加一个参数格式校验的外部层，把输出先过滤一遍再传工具，翻车率降了不少。Llama3.1的话，ReAct prompt里把工具描述写详细点，甚至给个调用示例，效果会好一截。不过真想省心可以看看Command R+或者Glaive的专用模型，对tool use优化得更彻底。

说实话我也踩过类似的坑，尤其是参数类型乱传的问题特别头疼。后来发现Qwen2.5对function calling的格式敏感度其实不如专门微调过的模型，建议你试试把工具描述的字段写得更具体，比如在description里直接标注“city必须是城市名称字符串，不要数字”。另外可以看看ToolLLaMA或者Gorilla这类专门优化过tool use的模型，虽然参数量小但调用稳定性好不少。