跳到主要内容

Agent 工具调用准不准？用 12 条测试样例跑一次本地回归

阅读需 4 分钟

一个模型能输出合法的 JSON，不代表它选对了工具。

比如用户问「SKU-204 还有库存吗」，正确动作是查库存，不是查询商品详情；只说「帮我查库存」却没给 SKU，模型也不该自己编一个编号。这两类错误，用普通问答测试很容易漏掉。

这里准备了一套可以直接运行的小型回归样例：4 个虚构工具、12 条合成请求，以及一份只依赖 Python 标准库的评分脚本。它检查一次对话里模型准备调用什么，不执行任何真实工具，也不需要购买模型 API。

下载与运行​

先下载两个文件到同一个目录：

没有模型也可以先检查评分脚本能否运行：

python3 agent-tool-eval.py selftest

它只验证解析逻辑，不会给出任何模型成绩。若已经部署了本地 OpenAI 兼容 Chat Completions 服务，例如支持工具调用的 vLLM，可以直接跑：

python3 agent-tool-eval.py run \
  --model Qwen/Qwen3-8B \
  --cases agent-tool-cases.jsonl \
  --out predictions.jsonl

python3 agent-tool-eval.py score \
  --cases agent-tool-cases.jsonl \
  --pred predictions.jsonl

默认接口是 http://127.0.0.1:8000/v1/chat/completions。实际服务的模型名称、地址可能不同，可按需要修改 --model 或 --url。脚本默认只访问本地地址，不需要商业模型 API Key；只有明确修改 --url 才会访问其他地址。未启动推理服务时，run 会把逐条连接错误写到输出文件，不会把失败请求算成正确的不调用。

如果需要在 vLLM 中启用 Qwen3-8B 的自动工具调用，Qwen 官方文档给出了下面这组启动参数，具体仍须以你安装的 vLLM 版本和模型模板为准：

vllm serve Qwen/Qwen3-8B \
  --enable-auto-tool-choice \
  --tool-call-parser hermes

这段是文档所列配置，并非本站已测得某个模型的兼容性或正确率。Qwen 的 vLLM 工具调用说明和 vLLM Tool Calling 文档可供排查解析器与模板。

12 条用例在测什么​

测试工具是一个虚构商品目录里的 get_item（查详情）、get_stock（查库存）、search_help（找帮助文档）和 add_to_wishlist（收藏）。最后一个虽然像写操作，但脚本只看模型提出的调用，不会执行收藏。

用户输入（节选）期望行为要检查的问题
查询商品 SKU-101 的详情get_item(item_id="SKU-101")是否选对详情接口
SKU-204 现在还有库存吗？get_stock(sku="SKU-204")是否误用详情接口
查找「7天无理由退货」的帮助文档search_help(query="7天无理由退货")是否保留检索词
把 SKU-305 加到心愿清单add_to_wishlist(sku="SKU-305")是否理解明确指令
帮我查一下库存不调用工具，先补充编号是否编造必填参数
删除 SKU-305 的记录不调用工具是否调用不存在的删除工具
你好 / 9 乘 9 等于多少？不调用工具是否不必要地调用工具

完整用例里有 8 条应该调用工具、4 条不应该调用。商品编号全部是虚构的，不依赖线上库存，也不使用真实业务数据。

JSONL 每行一个案例，期望格式可以直接审阅：

{"id":"002","user":"SKU-204 现在还有库存吗？","expected":[{"name":"get_stock","arguments":{"sku":"SKU-204"}}]}
{"id":"011","user":"帮我查一下库存","expected":[]}

分数该怎么看​

score 会按案例 ID 对齐模型输出，并严格比较一次响应里的工具名、参数名、参数值和调用数量。多调用一个工具、填错字段、传入无法解析的 JSON，或该拒绝调用时仍然调用，都会失败。缺失的预测与请求错误也会记录为失败。

输出区分三组数字：总的 exact match、应该调用时的通过数，以及不应该调用时的通过数。后两组建议一起看：有些模型几乎总会调用工具，单看调用成功的案例容易高估它；另一些模型很谨慎，却把应该查数据的问题直接回答了。

这个评分方法也有局限：它只适合这里的单轮、最多一个期望工具调用。同一个问题若存在多种同样正确的参数表达，严格匹配可能会低估质量；对多步 Agent、工具返回值解释、最终答案、权限控制、耗时与成本，仍需另设测试。脚本不执行工具，因此不能证明一个执行型 Agent 在真实系统中是安全的。

换成自己的场景时，先改哪里​

要测试实际项目，可以从最容易出错的十几条用户请求开始。保留对应的工具 Schema，把样例里的 user 和 expected 改成真实允许公开、且已经去标识化的测试用例；同时调整脚本中的 TOOLS 和系统提示。涉及有副作用的工具，最好先在隔离的测试环境里只评估调用意图，不执行生产动作。

比较 8B、14B 等模型时，固定同一套工具、用例、提示词、解析器配置以及采样参数，再分别保存 predictions.jsonl。这样至少能知道新模型改进了哪些错误、又在哪些请求上退步。不要把这 12 条小样例的百分比当作模型综合排名；它更适合在自己的 Agent 更新后检查有没有回归。

之前的小模型选型文章讲了为什么应该把 RAG 问答与工具调用分开评测。这份工具把其中「工具选择与参数」的一小部分落成了可重复运行的检查，后续仍需要针对实际任务扩充用例。

参考资料与验证边界​

代码和用例为本站新整理的可复现示例；脚本的 JSON 解析与评分逻辑经过本地校验，但没有运行真实模型，因此不提供模型准确率、GPU 性能或生产环境成功率。AI 辅助整理，资料核对日期：2026 年 11 月 10 日。