工具调用解决什么
工具调用让模型不直接作答，而是按约定格式输出结构化请求（函数名加参数），由业务侧真正执行、再把结果回填给模型继续推理。自托管服务需要显式启用对应解析器，解析器与模型族配套；没开的时候，模型吐出的 JSON 只会留在普通文本里，链路看上去通、实际调用不到。
基本信息
| 协议形态 | OpenAI 风格的 tools 与 tool_calls |
|---|---|
| 服务端开关 | vLLM 的 --enable-auto-tool-choice 等 |
| 解析器 | --tool-call-parser，按模型族选择 |
| 解析位置 | 服务端把文本还原成结构化字段 |
| 下游 | 网关或业务执行并回填结果 |
典型使用场景
- 需要实时数据（天气、库存、订单）但不想重新训练模型
- 把内部系统封装成工具接入问答，让模型决定何时调用
- 多步任务里由模型决定调用顺序与参数
- 把精确计算交给外部程序，避免模型算术出错
- 结构化输出不好用时，用工具调用拿稳定的参数格式
服务端启用
服务端启用
vllm serve <模型路径> --enable-auto-tool-choice --tool-call-parser hermes
# 解析器名称按模型族与版本文档选择
# 用错解析器最典型的表现是 tool_calls 一直为空请求侧
请求侧
tools = [{"type": "function", "function": {
"name": "get_weather",
"description": "查询指定城市当前天气", # 描述质量直接影响模型是否调用
"parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
}}]
r = client.chat.completions.create(model="<模型名>", messages=[{"role": "user", "content": "上海天气？"}], tools=tools, tool_choice="auto")
print(r.choices[0].message.tool_calls) # 非空说明链路打通各环节的预期表现
| 环节 | 正常表现 | 异常表现 |
|---|---|---|
| 服务端解析 | tool_calls 有结构化内容 | 为空，通常是解析器不匹配 |
| 参数内容 | 符合声明的 schema | 缺字段或类型不对 |
| 业务执行 | 结果按 tool 角色回填 | 拼成字符串导致模型关联不上 |
| 模型行为 | 该调时才调 | 该调不调，多是描述不足 |
工具描述与参数说明本身就是提示的一部分：写得越具体，模型越容易选对工具、填对参数，效果比反复调温度明显。
流式返回下 tool_calls 通常分片到达，需要按 index 累积后再解析；直接读第一片往往只拿到半个参数，表现为参数偶发缺失。