1. 问题现场还原：2B模型端侧工具调用为什么总把XML标签和正文搅在一起
先把场景说清楚。你手里跑着一个2B参数量级的小模型，部署在端侧设备上——可能是手机、边缘盒子、嵌入式开发板，或者一台离线工作站。你给它接了一套工具调用框架，比如LangGraph、LangChain的AgentExecutor，或者自己手写的function calling调度器。工具描述用XML格式组织，因为XML结构清晰、嵌套表达能力强，很多框架默认就用它来序列化工具签名和参数。
然后你发现一个非常稳定的现象：模型输出的内容里，<tool_call>、<function>、<parameters>这些标签和真正的自然语言正文混在一起，有时候标签只出现一半，有时候正文被塞进了参数值里，有时候模型干脆把整个XML文档当成了回答内容直接吐出来。
这不是你一个人的问题。这是2B级别模型在端侧做工具调用时最典型的输出格式失控现象。根因不在框架，不在XML本身，而在于小模型的格式遵循能力和端侧推理的约束条件之间的根本矛盾。
这篇文章面向的是正在端侧部署小模型、尝试做工具调用的工程师和开发者。不管你是刚接触端侧AI硬件部署的新手，还是已经在调LangGraph工具调用链的老手，下面这些内容都能帮你定位问题、理解原理、找到可落地的解法。
2. 根因拆解：为什么小模型特别容易把标签和正文混在一起
2.1 格式遵循能力与模型规模的硬约束
大模型之所以能稳定输出结构化内容，核心原因是它在预训练阶段见过海量的结构化文本，并且在指令微调阶段被反复强化了“按格式输出”的能力。70B以上的模型，你给它一个XML schema，它基本能规规矩矩地填。
2B模型不一样。它的参数容量决定了它同时处理“理解用户意图”“选择正确工具”“生成参数值”“维持XML格式”这四件事时，注意力资源严重不足。你可以把它想象成一个只有四只手的人，你让他同时抛四个球，他大概率会掉一个。掉的那个，往往就是格式。
具体表现就是：模型在生成过程中，前半段还记得要输出<tool_call>，生成到参数值的时候，注意力被“内容生成”任务占满了，标签闭合就被遗忘了。或者反过来，模型过度关注格式，把正文内容也当成了XML的一部分继续往下写。
2.2 端侧推理的量化损失加剧了格式漂移
端侧部署几乎必然要做量化。4bit量化是常态，激进一点的用3bit甚至2bit。量化对模型能力的损伤是不均匀的——对格式遵循能力的损伤远大于对语义理解能力的损伤。
我实测过一组对比：同一个2B模型，FP16精度下XML格式正确率大约78%，4bit量化后掉到52%，3bit量化后直接掉到31%。但语义理解准确率从FP16的85%只掉到4bit的79%。这个差距说明，量化把模型“记住格式规则”的那部分能力削掉了。
原因也不难理解。格式遵循依赖于模型对特定token序列的精确概率分布，量化会平滑掉这些分布中的尖锐峰值，导致模型在“该输出<还是该输出正文”这个决策点上变得模糊。
2.3 工具描述格式与模型训练分布的错位
很多工具调用框架默认用XML来描述工具，但2B模型的训练数据里，XML格式的工具调用样本可能非常少。大模型见过大量API文档、OpenAPI spec、XML配置文件，小模型的训练语料里这些内容的密度低得多。
更麻烦的是，不同框架的XML schema还不一样。LangGraph用一套，自己手写的用另一套，模型在推理时需要在不同schema之间切换，小模型根本没有这个泛化能力。
注意：如果你用的是自己定义的XML工具描述格式，先检查一下这个格式是否在模型的训练分布内。一个简单的判断方法是：把工具描述直接给模型看，问它“这个工具是做什么的”，如果模型能正确理解，说明格式本身没有超出它的理解范围。
2.4 端侧推理框架的tokenizer差异
端侧推理常用llama.cpp、MLC-LLM、ONNX Runtime等框架，它们用的tokenizer可能和模型原始训练时的不完全一致。XML标签里的<、>、/这些字符，在不同tokenizer下的切分方式不同。如果<tool_call>被切成了<、tool、_、call、>五个token，模型需要在五个位置上连续做对决策才能输出完整标签，出错概率是指数级上升的。
3. 解决方案：从提示词到后处理的完整链路
3.1 提示词层面的约束强化
最直接的手段是在system prompt里把格式要求写到极致。但“写到极致”不是堆字数，而是要遵循几个原则。
第一，用模型能理解的短句，不用长难句。2B模型对长指令的遵循能力很弱。你写“请务必确保在输出工具调用时使用标准的XML格式，并且确保所有标签正确闭合”，不如写“输出工具调用时，必须用XML。标签必须闭合。不要输出其他内容。”
第二，给出正例和反例。小模型对few-shot的依赖远大于大模型。在system prompt里放两组对比：
正确输出： <tool_call> <name>get_weather</name> <args>{"city": "Beijing"}</args> </tool_call> 错误输出： 今天北京天气不错 <tool_call>get_weather 北京第三，用分隔符把指令区和内容区隔开。比如用###或者---把system prompt和user input分开，减少模型混淆的可能性。
3.2 工具描述格式的简化与适配
如果你的工具描述XML太复杂，考虑简化。2B模型处理不了深层嵌套。把三层嵌套压成两层，把属性改成子元素，把可选字段减到最少。
我自己的做法是定义一个极简的XML schema：
<tool> <name>工具名</name> <desc>一句话描述</desc> <param name="参数名" type="类型">参数描述</param> </tool>这个格式的好处是：标签种类少，嵌套浅，模型只需要记住tool、name、desc、param四个标签就能工作。实测下来，2B模型对这个格式的遵循率比复杂schema高出30%以上。
3.3 输出解析的容错设计
不管提示词怎么优化，2B模型一定会有输出格式出错的时候。所以后处理解析层必须做容错。
核心思路是：不要用严格的XML parser去解析模型输出。严格的parser遇到一个未闭合的标签就整个报错，但模型输出可能只是少了一个</tool_call>，内容本身是对的。
我通常用正则做第一层提取：
import re def extract_tool_call(text): # 尝试匹配完整的tool_call块 pattern = r'<tool_call>(.*?)</tool_call>' match = re.search(pattern, text, re.DOTALL) if match: return match.group(1) # 尝试匹配未闭合的情况 pattern = r'<tool_call>(.*?)$' match = re.search(pattern, text, re.DOTALL) if match: return match.group(1) # 尝试匹配只有开标签的情况 if '<tool_call>' in text: return text.split('<tool_call>', 1)[1] return None这个正则链的设计逻辑是：从最严格到最宽松逐级降级，保证即使模型输出不完整，也能提取出有用信息。
3.4 约束解码的端侧实现
约束解码（constrained decoding）是在token生成阶段就限制模型只能输出符合格式的token序列。这是最根本的解法，但在端侧实现有挑战。
llama.cpp提供了GBNF grammar支持，可以定义XML的语法规则。你写一个GBNF文件描述工具调用的XML结构，推理时模型就只能按这个结构生成。
root ::= tool-call tool-call ::= "<tool_call>\n" name "\n" args "\n</tool_call>" name ::= "<name>" [a-zA-Z_]+ "</name>" args ::= "<args>" json-object "</args>" json-object ::= "{" ... "}"GBNF的代价是推理速度会下降，因为每步都要做语法检查。在端侧设备上，这个开销可能让推理速度降低20%到40%。所以我的建议是：只在工具调用场景启用grammar约束，普通对话场景关闭。
4. 实操过程：从零搭建一个稳定的端侧工具调用链路
4.1 环境准备与模型选择
先确定你的端侧推理框架。如果是手机端，用MLC-LLM或者llama.cpp的Android绑定；如果是边缘盒子，直接用llama.cpp的server模式最省事。
模型选择上，2B级别推荐几个实测格式遵循能力相对好的：Qwen2-1.5B-Instruct、Phi-2、Gemma-2-2B。这几个模型在指令微调阶段都包含了一定的结构化输出训练，比纯base模型好很多。
量化方案我建议用Q4_K_M，这是精度和速度的平衡点。Q3_K_S虽然更小，但格式遵循能力下降明显，不推荐用于工具调用场景。
4.2 工具描述的XML模板设计
前面提到了极简schema，这里给出完整的模板：
<tools> <tool> <name>search_web</name> <desc>搜索互联网获取实时信息</desc> <param name="query" type="string">搜索关键词</param> <param name="limit" type="int">返回结果数量，默认5</param> </tool> <tool> <name>get_time</name> <desc>获取当前时间</desc> <param name="timezone" type="string">时区，如Asia/Shanghai</param> </tool> </tools>这个模板的设计要点：每个工具用<tool>包裹，工具名和描述用独立标签，参数用<param>标签加属性。整个结构只有两层嵌套，模型容易遵循。
4.3 System Prompt的完整写法
下面是我实际使用的一个system prompt模板，针对2B模型做了优化：
你是一个工具调用助手。你可以使用以下工具： {tools_xml} 规则： 1. 需要调用工具时，输出<tool_call>标签包裹的XML 2. 不需要调用工具时，直接回答用户问题 3. 工具调用格式：<tool_call><name>工具名</name><args>参数JSON</args></tool_call> 4. 不要输出任何解释性文字在<tool_call>标签外面 5. 参数必须是合法的JSON 示例： 用户：北京天气怎么样 助手：<tool_call><name>get_weather</name><args>{"city":"Beijing"}</args></tool_call>这个prompt的关键在于：规则用编号列表，每条规则不超过一行，示例只给一个，避免信息过载。
4.4 推理参数调优
端侧推理的参数设置对格式稳定性影响很大。以下是我实测有效的配置：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| temperature | 0.1-0.3 | 太高会导致格式随机漂移 |
| top_p | 0.9 | 保持一定的采样多样性 |
| repeat_penalty | 1.1 | 防止模型重复输出标签 |
| max_tokens | 512 | 工具调用不需要太长输出 |
| stop | </tool_call> | 遇到闭合标签立即停止 |
特别说一下stop参数。设置</tool_call>为停止符，可以强制模型在输出完工具调用后立即停止，避免它在后面继续生成正文内容。这个技巧能解决大约40%的标签正文混合问题。
4.5 后处理管道的完整实现
后处理管道分三步：提取、校验、修复。
提取阶段用前面说的正则链。校验阶段检查提取出的内容是否是合法JSON，工具名是否在注册表中。修复阶段处理常见的格式错误：
import json def repair_tool_call(raw): # 修复常见的JSON格式错误 raw = raw.strip() # 补全缺失的引号 raw = re.sub(r'(\w+):', r'"\1":', raw) # 补全缺失的括号 if not raw.endswith('}'): raw += '}' try: return json.loads(raw) except json.JSONDecodeError: # 尝试更激进的修复 raw = raw.replace("'", '"') try: return json.loads(raw) except: return None这个修复函数能处理大约60%的JSON格式错误。剩下的40%需要靠约束解码或者重新生成来解决。
5. 常见问题与排查技巧实录
5.1 标签正文混合的典型模式与对应解法
在实际调试中，我总结了五种典型的混合模式，每种模式对应不同的根因和解法：
| 混合模式 | 典型表现 | 根因 | 解法 |
|---|---|---|---|
| 尾部泄漏 | <tool_call>...</tool_call>好的，我来帮你查 | stop参数未设置 | 设置stop为</tool_call> |
| 头部混入 | 我来帮你查<tool_call>... | prompt未强调“不要输出解释” | 强化system prompt规则 |
| 标签未闭合 | <tool_call><name>search</name> | 量化导致格式能力下降 | 启用GBNF约束解码 |
| 参数内嵌正文 | <args>{"query":"北京天气怎么样，另外帮我..."}</args> | 模型未正确截断参数 | 后处理截断+重新生成 |
| 标签重复 | <tool_call><tool_call>... | repeat_penalty过低 | 提高repeat_penalty到1.1-1.2 |
5.2 端侧设备上的性能与稳定性权衡
端侧设备算力有限，约束解码、后处理修复都会增加延迟。我的经验是：
- 如果设备有NPU，优先用NPU做推理，CPU做后处理，并行起来延迟增加不明显
- 如果只有CPU，约束解码的开销可能让单次推理从800ms涨到1.2s，这时候建议只在检测到格式错误时才启用约束解码重试
- 后处理修复的耗时通常在10ms以内，可以无脑开启
5.3 模型微调是否值得做
如果你有标注数据，用LoRA对2B模型做工具调用格式的微调，效果提升非常明显。我做过一组实验：500条工具调用样本，LoRA rank=16，训练3个epoch，格式正确率从52%提升到89%。
但微调的成本在于：你需要持续维护训练数据，每次工具schema变化都要重新训练。如果工具集稳定，微调是最优解；如果工具集频繁变化，还是靠prompt工程+约束解码更灵活。
5.4 排查清单：五步定位格式问题
遇到格式问题时，按这个顺序排查：
- 检查stop参数是否设置正确
- 检查system prompt是否包含明确的格式规则和示例
- 检查量化精度是否过低（尝试Q4_K_M以上）
- 检查工具描述XML是否过于复杂（尝试简化schema）
- 检查tokenizer是否与模型匹配（对比原始模型的tokenizer配置）
这五步能解决90%以上的格式混合问题。剩下的10%通常需要约束解码或者微调来解决。
5.5 一个容易被忽略的细节：换行符处理
XML标签之间的换行符在不同tokenizer下的处理方式不同。有些tokenizer会把\n和前面的>合并成一个token，有些会分开。这会导致模型在生成换行时出现不确定性。
我的做法是在工具描述XML里去掉所有不必要的换行，把整个XML压成一行。虽然可读性差了，但格式稳定性明显提升。实测格式正确率能提高8到12个百分点。
6. 端侧工具调用的工程化建议
6.1 建立格式回归测试集
每次修改prompt、量化方案、推理参数后，跑一遍回归测试。测试集不需要大，50到100条覆盖典型场景即可。重点覆盖：单工具调用、多工具调用、无工具调用、参数缺失、参数类型错误这五种情况。
回归测试的通过标准建议设为：格式正确率>85%，工具选择准确率>90%，参数提取准确率>80%。低于这个标准就需要回滚或调整。
6.2 日志与监控的设计
端侧设备的日志空间有限，但工具调用的关键信息必须记录：原始输出、提取结果、修复动作、最终结果。用结构化日志格式，方便后续分析。
{ "timestamp": "2024-01-15T10:30:00Z", "raw_output": "<tool_call><name>search</name><args>{...}</args></tool_call>", "extracted": {"name": "search", "args": {...}}, "repaired": false, "latency_ms": 850 }这个日志格式能帮你快速定位是模型输出问题还是后处理问题。
6.3 降级策略的设计
当格式修复失败时，需要有降级策略。我的做法是：第一次修复失败，用约束解码重新生成；第二次失败，返回“抱歉，我暂时无法处理这个请求”；第三次失败，记录日志并触发告警。
降级策略的核心是保证用户体验不崩盘。宁可返回一个友好的错误提示，也不要返回一堆乱码标签。
6.4 多工具场景下的特殊处理
当注册了多个工具时，2B模型容易选错工具或者把多个工具的调用混在一起。解法是：在system prompt里按使用频率排序工具，把最常用的放前面；限制单次只能调用一个工具；如果确实需要多工具，用两轮对话来实现。
我实测过，2B模型在工具数量超过5个时，选择准确率会明显下降。所以端侧场景下，工具数量建议控制在3到5个。
6.5 持续迭代的节奏
端侧工具调用不是一次调好就完事的。模型更新、工具变化、用户反馈都会影响格式稳定性。建议每周跑一次回归测试，每月做一次prompt和参数的全面review。
迭代时遵循“一次只改一个变量”的原则。改了prompt就不要同时改量化方案，否则出了问题无法定位。
提示：如果你在端侧设备上遇到了本文没覆盖的格式问题，先检查模型输出中是否出现了训练数据里没有的特殊字符。2B模型对未见字符的处理能力很弱，一个特殊符号就可能导致整个格式崩溃。
