1. 端侧小模型工具调用的核心矛盾
1.1 为什么2B模型在端侧做Function Calling容易“串味”
把2B级别的模型部署到端侧硬件上跑工具调用，很多人第一次跑通之后都会遇到一个非常具体的现象：模型输出的内容里，XML标签和自然语言正文搅在一起，比如先来一句“好的，我来帮你查询天气”，紧接着跟一段<tool_call>{"name":"get_weather",...}</tool_call>，然后又开始解释“根据查询结果……”。解析器一跑就崩，要么JSON解析失败，要么把解释文字当成了参数值。
这个问题的根源不在模型“笨”，而在于端侧场景下几个约束同时叠加：模型参数量小、量化精度低、上下文窗口窄、推理框架对输出格式的约束能力弱。2B模型本身对指令的遵循能力就有限，当你用few-shot或者系统提示词告诉它“只输出XML”时，它在训练数据里见过大量“先解释再调用”的模式，这些模式会在生成时抢占概率质量。端侧量化（比如INT4、INT8）进一步削弱了模型对格式边界的敏感度，原本在FP16下能稳定输出的闭合标签，量化后可能就漏掉了。
我实测过几个2B级别的模型在端侧NPU上跑工具调用，同样的提示词，FP16下格式正确率大概在85%左右，换成INT4量化之后直接掉到50%以下，而且错误模式高度一致：标签和正文混排、标签不闭合、JSON里混入中文解释。这不是偶然，是端侧部署必须正面解决的问题。
1.2 端侧工具调用的典型链路长什么样
先把这个链路拆清楚，后面排查问题才有依据。一个典型的端侧工具调用链路包含这几个环节：
- 输入构造：把用户query、系统提示词、工具定义（schema）、历史对话拼成一个prompt，喂给模型。
- 模型推理：端侧推理框架（如llama.cpp、MLC、ONNX Runtime、厂商NPU SDK）加载量化后的2B模型，做自回归生成。
- 输出解析：从生成的token流里提取工具调用结构，通常是XML或JSON格式。
- 工具执行：把解析出的参数传给本地函数或API，拿到结果。
- 结果回填：把工具返回结果再拼回上下文，让模型生成最终回复。
问题几乎全部集中在第2和第3步之间。模型生成的文本是“自由文本”，而解析器期望的是“结构化文本”，两者之间的鸿沟就是标签和正文混排的温床。端侧硬件通常没有服务端那么充裕的显存和算力，没法跑一个大的“格式校验模型”来做后处理，所以必须在提示词、解码策略、解析器三个层面同时下手。
1.3 为什么服务端方案直接搬到端侧会翻车
服务端跑7B、13B甚至更大的模型时，工具调用的格式稳定性通常靠三件事保证：模型本身能力强、可以用constrained decoding（约束解码）、有充足算力做重试和校验。端侧这三条全部打折。
2B模型在指令遵循上的“注意力预算”很有限。你可以理解为：模型的总注意力就那么多，它要同时关注“用户问了什么”“我该调用哪个工具”“参数是什么”“输出格式是什么”，当参数量小的时候，这些任务之间会互相干扰。服务端大模型可以并行处理这些约束，2B模型则会“顾此失彼”——它可能正确识别了工具和参数，但在输出格式上偷懒，把标签和解释混在一起。
另一个容易被忽略的点是tokenizer。端侧部署为了减小模型体积，有时会换用更激进的tokenizer或者对词表做裁剪，导致<tool_call>这种特殊token被拆成多个子词，模型在生成时对标签边界的感知变弱。我遇到过某个端侧方案里</tool_call>被拆成了</、tool、_、call、>五个token，模型经常只生成前三个就停了，标签自然不闭合。
2. 标签与正文混排的六种典型表现
2.1 表现一：解释文字包裹在标签内部
最常见的一种。模型输出类似：
我来帮你查一下天气。 <tool_call> {"name": "get_weather", "arguments": {"city": "北京"}} 好的，已经为你查询了。 </tool_call>注意这里“好的，已经为你查询了”被包进了<tool_call>标签内部。解析器如果按标签提取内容，会把这句话当成JSON的一部分，直接解析失败。这种错误的成因是模型没有建立“标签内只能是结构化数据”的强约束，它在训练时见过的XML里，标签内包含自然语言的情况太常见了（比如HTML的<p>标签），所以它会自然地往里塞解释。
2.2 表现二：标签不闭合或闭合错位
模型生成了<tool_call>开头，但结尾忘了写</tool_call>，或者写成了</tool>、</function_call>。端侧量化模型在长序列生成时，对“配对标签”这种需要跨距离记忆的结构特别容易出错。2B模型的上下文记忆能力有限，当JSON内容比较长时，它生成到后面已经“忘了”开头用的是什么标签名。
我做过一个统计：在INT4量化的2B模型上，当工具参数超过5个字段时，标签闭合错误率从12%飙升到40%以上。参数越多，模型需要维持的“格式记忆”越长，出错概率越高。
2.3 表现三：XML和JSON混用
模型一会儿用XML风格，一会儿用JSON风格，输出成这种四不像：
<tool_call> {"name": "get_weather", "arguments": "<city>北京</city>"} </tool_call>或者：
{"tool_call": "<name>get_weather</name><args>...</args>"}这种混用的根源是提示词里同时出现了XML和JSON的示例，或者工具schema的定义方式和输出格式的约定不一致。2B模型没有能力区分“这是schema的定义语法”和“这是输出的格式要求”，它会把自己看到的所有格式特征都揉进输出里。
2.4 表现四：多个工具调用挤在一个标签里
当用户query可能触发多个工具时，模型会输出：
<tool_call> {"name": "get_weather", "arguments": {...}} {"name": "get_time", "arguments": {...}} </tool_call>两个JSON对象之间没有分隔符，或者用了逗号但整体不是合法JSON数组。解析器要么只能拿到第一个，要么直接报错。端侧模型对“数组”这种嵌套结构的生成能力很弱，它更倾向于平铺直叙地罗列。
2.5 表现五：标签名漂移
提示词里约定的是<tool_call>，模型输出成了<tool>、<function>、<call>、<tool_use>等等。这种漂移在few-shot示例不够多或者示例中标签名不统一时特别明显。2B模型对“精确字符串匹配”的敏感度远低于大模型，它更多是在做“语义近似生成”，觉得<tool>和<tool_call>意思差不多就用了。
2.6 表现六：正文和标签交替出现
模型输出一段解释，然后一个标签，再一段解释，再一个标签：
我需要先查询天气。 <tool_call>{"name":"get_weather","arguments":{"city":"北京"}}</tool_call> 然后根据结果告诉你。 <tool_call>{"name":"format_result","arguments":{...}}</tool_call>这种“边想边说边调用”的模式，在对话场景下看起来自然，但对解析器来说是灾难。它要求解析器能区分“哪些标签是真正的工具调用”“哪些是模型在自言自语”。
3. 从提示词层面压制格式漂移
3.1 系统提示词要“窄”不要“全”
很多人的系统提示词写得很全：你是一个智能助手，你可以调用工具，工具的定义如下，输出格式要求如下，注意事项如下……对2B模型来说，信息越多，注意力越分散。我的经验是：端侧2B模型的系统提示词要尽可能窄，只保留三样东西——角色一句话、工具schema、输出格式一句话。
比如：
你是一个工具调用助手。根据用户问题选择工具并输出调用。 工具定义： - get_weather: 查询天气，参数 city (string) 输出格式（只输出这个，不要任何其他文字）： <tool_call>{"name":"工具名","arguments":{...}}</tool_call>关键在最后那句“只输出这个，不要任何其他文字”。这句话必须放在提示词的最末尾，因为模型对末尾内容的注意力权重最高。我实测过，把格式约束放在开头和放在末尾，格式正确率能差20个百分点。
3.2 few-shot示例要“干净”且“一致”
给2B模型做few-shot，示例数量控制在2到3个就够了，多了反而会挤占上下文窗口。更重要的是示例必须“干净”——示例里绝对不能出现“好的我来帮你查”这种解释性文字，否则模型会模仿这种模式。示例的标签名、JSON结构、参数命名必须完全一致，不能一个示例用<tool_call>另一个用<function_call>。
我习惯用这种格式：
用户：北京天气怎么样 <tool_call>{"name":"get_weather","arguments":{"city":"北京"}}</tool_call> 用户：现在几点了 <tool_call>{"name":"get_time","arguments":{}}</tool_call>注意示例里没有“助手：”前缀，也没有任何解释。这样模型学到的模式就是“用户输入直接跟工具调用”，中间不插入任何自然语言。
3.3 用“停止序列”截断多余输出
端侧推理框架通常支持stop sequence配置。把</tool_call>设为停止序列，模型生成到这个字符串就停止，后面的解释文字根本不会产生。这是最直接有效的手段，比任何提示词技巧都管用。
但要注意：停止序列是“生成到该字符串时停止”，如果模型把</tool_call>写错了（比如写成</tool>），停止序列不会触发。所以停止序列要和提示词约束配合使用，不能只靠它。
3.4 工具schema的描述要“短平快”
2B模型对长描述的处理能力很弱。工具schema里的description字段如果写了一大段，模型会把这些描述文字也当成输出内容的一部分。我的做法是：description控制在10个字以内，参数名用英文短词，参数类型只写string/number/boolean，不写嵌套对象。
比如不要写：
{ "name": "search_product", "description": "根据用户提供的关键词在商品库中进行模糊搜索，返回匹配的商品列表，支持分页和排序", "parameters": { "type": "object", "properties": { "keyword": {"type": "string", "description": "搜索关键词"}, "page": {"type": "integer", "description": "页码，从1开始"}, "sort": {"type": "string", "enum": ["price_asc", "price_desc", "sales_desc"]} } } }而是写成：
{ "name": "search_product", "description": "搜索商品", "parameters": { "keyword": "string", "page": "number" } }牺牲一些表达能力，换取格式稳定性，在端侧2B模型上是划算的。
4. 解码策略与推理框架的配合
4.1 温度调到0，但别指望它解决一切
温度设为0（贪心解码）能减少随机性，让输出更稳定。但很多端侧框架在量化后，即使温度设为0，由于数值精度的损失，logits的排序也可能发生微小变化，导致输出不稳定。我遇到过同一个输入连续跑10次，有2次格式出错的情况，温度已经是0了。
所以温度0是必要条件，不是充分条件。还要配合top_k=1、top_p=1、repetition_penalty=1.0（不要加惩罚，惩罚会干扰格式token的生成）。
4.2 约束解码在端侧的可行性
约束解码（constrained decoding）是服务端解决格式问题的利器，它通过在解码时屏蔽不符合格式的token，强制模型输出合法结构。端侧能不能用？取决于推理框架。
llama.cpp从某个版本开始支持GBNF语法约束，可以定义XML/JSON的语法规则，解码时只允许符合语法的token被采样。这是端侧最靠谱的方案。MLC和ONNX Runtime目前对约束解码的支持还不完善，需要自己改推理循环。
如果你用的框架支持GBNF，强烈建议上约束。我实测下来，加了GBNF之后，2B模型INT4量化的格式正确率能从50%拉到95%以上。代价是解码速度会慢10%到20%，因为每步都要做语法状态检查，但端侧工具调用对延迟的容忍度通常比纯对话高，这个代价可以接受。
4.3 用“前缀强制”把模型逼上正道
如果框架不支持约束解码，可以用“前缀强制”这个土办法：在生成开始前，手动把<tool_call>这几个token作为已生成内容塞进上下文，让模型从<tool_call>之后开始生成。这样至少保证了开头标签的正确性。
具体操作是在推理框架的generate函数里，把初始input_ids设置为<tool_call>对应的token序列，然后让模型续写。结尾的</tool_call>则靠停止序列来保证。这个方法不能保证中间JSON的合法性，但能解决“标签名漂移”和“开头带解释”两个问题。
4.4 推理框架的tokenizer要对齐
前面提到过tokenizer裁剪的问题。端侧部署时，如果你用的是自己转换的模型权重，一定要确认tokenizer和训练时一致。特别是特殊token（如<tool_call>、</tool_call>）是否被注册为single token。如果不是，考虑在tokenizer里手动添加这些特殊token，并确保模型embedding层有对应的向量。
有些端侧方案为了省空间，把词表从15万裁到3万，<tool_call>被拆成多个子词。这种情况下，模型对标签边界的感知会严重退化。解决办法要么是不裁剪词表，要么是在微调时让模型适应裁剪后的tokenizer。
5. 输出解析器的容错设计
5.1 不要用严格的XML解析器
很多人第一反应是用标准XML解析库去解析模型输出，结果发现模型输出的“XML”根本不合法——标签不闭合、属性没引号、特殊字符没转义。标准解析器直接抛异常，整个链路就断了。
端侧工具调用的解析器必须是“宽容解析器”。我的做法是：不追求完整解析XML，而是用正则表达式提取<tool_call>和</tool_call>之间的内容，然后对提取出的字符串做JSON解析。如果JSON解析失败，再尝试修复（补全括号、去掉尾部逗号、提取第一个完整JSON对象）。
5.2 多级降级策略
解析器应该设计成多级降级：
- 第一级：严格匹配
<tool_call>...</tool_call>，提取内容做JSON解析。 - 第二级：如果标签不闭合，尝试从
<tool_call>开始提取到字符串末尾，然后找最后一个}作为JSON结束。 - 第三级：如果JSON解析失败，用正则提取
"name"和"arguments"字段的值，手动构造调用结构。 - 第四级：如果全部失败，把原始输出返回给模型，让它重新生成，并在提示词里强调“上次输出格式错误，请只输出XML”。
端侧算力有限，重试次数控制在1到2次，不要无限重试。
5.3 处理“正文混入”的清洗逻辑
对于标签内混入正文的情况，可以在JSON解析前做一次清洗：找到第一个{和最后一个}，只保留这两个字符之间的内容。这个简单的操作能解决大部分“解释文字包裹在标签内”的问题。
但要注意：如果JSON内部本身包含{或}（比如参数值里有花括号），这个清洗会出错。所以清洗前要先判断：第一个{之前的内容是否包含中文或自然语言特征，如果有，才做清洗；如果没有，直接解析。
5.4 解析日志要留痕
端侧设备通常没有远程日志，但调试阶段一定要把原始输出、解析结果、失败原因写到本地文件。我习惯在解析器里加一个环形缓冲区，保留最近100条原始输出和解析结果，出问题时可以导出分析。这个习惯帮我定位过很多“偶发格式错误”，最后发现都是特定参数组合触发的。
6. 常见问题速查与避坑清单
6.1 格式问题排查速查表
| 现象 | 最可能原因 | 优先排查项 | 解决手段 |
|---|---|---|---|
| 标签内混入解释文字 | 提示词含解释性示例 | few-shot示例是否干净 | 清理示例，加停止序列 |
| 标签不闭合 | 量化精度损失 | 模型是否为INT4 | 换INT8或加约束解码 |
| 标签名漂移 | 提示词标签不统一 | 系统提示和示例标签名 | 统一标签名，加前缀强制 |
| JSON解析失败 | 输出含非法字符 | 是否有中文标点 | 清洗+宽容解析 |
| 多个调用挤在一起 | 模型未学数组结构 | 是否有多工具场景 | 拆成多次单工具调用 |
| 正文标签交替 | 模型“边想边说” | 是否有思考链提示 | 去掉思考链，强制单轮输出 |
6.2 避坑清单
- 不要用“请”“麻烦”等礼貌用语：2B模型会把礼貌用语当成输出内容的一部分，提示词越直接越好。
- 不要在提示词里写“你可以……”：这种开放性表述会让模型觉得“可以输出解释”，改成“你必须只输出……”。
- 不要混用中英文标签：
<工具调用>和<tool_call>混用会让模型彻底混乱。 - 不要在工具描述里写示例：工具schema里的example字段会被模型当成输出模板，直接抄进结果里。
- 不要忽略tokenizer的特殊token注册：这是最隐蔽的坑，格式问题查了一圈最后发现是tokenizer没对齐。
- 不要用大模型的提示词直接套：7B能扛住的复杂提示词，2B扛不住，必须做减法。
6.3 一个实测有效的提示词模板
经过多轮迭代，我在端侧2B模型上稳定使用的提示词模板是这样的：
你是工具调用器。只输出一行XML，不要任何解释。 工具： get_weather(city:string) 查天气 get_time() 查时间 格式： <tool_call>{"name":"工具名","arguments":{参数}}</tool_call> 用户：{query}注意几个细节：角色描述只有“工具调用器”四个字；工具定义用最简的函数签名形式；格式说明只有一行；用户query前没有“助手：”之类的引导词。这个模板在INT4量化的2B模型上，配合停止序列，格式正确率能稳定在90%以上。
7. 端侧部署的额外考量
7.1 上下文窗口的取舍
2B模型的上下文窗口通常不大，端侧部署时为了省内存还会进一步压缩。工具调用的prompt里包含系统提示、工具定义、few-shot示例、历史对话，很容易把窗口占满。我的做法是：工具调用场景下，历史对话只保留最近2轮，few-shot示例最多2个，工具定义只保留当前query可能用到的工具（用关键词匹配做预筛选）。
上下文越短，模型对格式的注意力越集中。我对比过，把上下文从2048压到512，格式正确率反而提升了，因为模型不用在长上下文里“找”格式要求。
7.2 量化精度的选择
INT4量化对格式的影响前面说过了。如果端侧硬件支持INT8，优先用INT8。如果只能用INT4，建议对embedding层和输出层保持FP16，只对中间层做INT4。这个混合精度方案能在模型体积增加不多的情况下，显著改善格式稳定性。
另外，量化校准集里最好包含一些工具调用的样本，让量化过程“见过”XML格式的token分布。用纯对话数据做校准，量化后格式token的概率会被压得很低。
7.3 端侧硬件的算力分配
工具调用通常发生在对话过程中，端侧设备可能同时在跑其他任务（语音识别、界面渲染）。算力紧张时，推理框架可能会降低精度或跳过某些计算，导致输出不稳定。如果发现格式错误和系统负载相关，可以考虑给工具调用任务更高的优先级，或者在调用前做一次“预热推理”（跑一个短输入让模型进入稳定状态）。
7.4 多工具场景的拆分策略
端侧2B模型一次只处理一个工具调用，成功率最高。如果用户query可能触发多个工具，不要指望模型一次输出多个调用，而是拆成多轮：第一轮让模型选一个工具，执行后把结果回填，第二轮再让模型选下一个。虽然多了一次推理，但格式稳定性大幅提升。
这个策略在端侧特别划算，因为端侧推理的瓶颈通常在内存带宽而不是算力，多跑一轮的代价没有服务端那么大。
8. 我踩过的几个真实坑
第一个坑是停止序列的配置位置。我一开始把</tool_call>配在了推理框架的全局stop里，结果模型在few-shot示例里生成到</tool_call>就停了，示例都没生成完。后来改成只在最终生成阶段启用停止序列，few-shot阶段不启用，才解决。
第二个坑是JSON里的中文。模型有时候会在参数值里输出中文，比如{"city":"北京"}，这本身没问题，但如果输出的是{"city":"北京"}（带中文引号），JSON解析就失败。解决办法是在提示词里明确写“参数值用英文引号”，或者在解析前做一次引号替换。
第三个坑是模型“自作聪明”地补全参数。工具定义里只有city一个参数，模型有时候会输出{"city":"北京","unit":"celsius"}，多出来的unit参数导致工具执行报错。后来我在解析器里加了参数白名单，只提取schema里定义过的参数，多余的丢弃。
第四个坑是并发调用时的上下文污染。端侧设备可能同时处理多个请求，如果共用一个模型实例，前一个请求的生成状态可能影响后一个。解决办法是每个请求独立初始化推理状态，或者用请求队列串行处理。
这些坑在文档里都不会写，只有实际跑过端侧2B模型工具调用的人才会遇到。端侧部署和云端最大的区别就是：云端可以靠资源堆叠掩盖问题，端侧必须把每个环节都抠到极致。格式问题看似是模型能力问题，实际上是提示词、解码、解析、硬件四层配合的结果，任何一层偷懒，标签和正文就会混在一起给你看。
