ToolCall-15 深度研究：15 个场景，精准测出 LLM 到底会不会用工具
> GitHub: stevibe/ToolCall-15
> 作者: stevibe
> 技术: Next.js + TypeScript
> License: MIT
> 研究时间: 2026-03-26
🎯 一句话版本
15 个精心设计的场景测试 LLM 工具调用能力——选对工具、传对参数、多步链、克制不该调的冲动、错误恢复。所有工具结果都是 mock 的（确定性），有实时可视化 dashboard，支持 OpenRouter/Ollama/llama.cpp。比学术 benchmark 更实用、更直观。
🧠 为什么需要这个？
现有 tool calling benchmark 的问题：
| 问题 | ToolCall-15 的解法 |
|---|---|
| 学术化、不透明 | 每个场景有明确预期行为 |
| 无法直观展示 | **实时可视化 dashboard** |
| 不可复现 | 固定 prompt + mock 工具 + temperature:0 |
| 偏科（某一类测太多） | **5 类别均衡分布** |
| 评分模糊 | **pass/partial/fail 三级确定性评分** |
📊 5 大类别 × 3 场景
Category A: Tool Selection（选对工具）
| # | 场景 | 测什么 |
|---|---|---|
| TC-01 | "柏林天气怎么样？" | 有 `get_weather` 就别用 `web_search` |
| TC-02 | "AAPL 股价多少？" | 12 个工具里只选 1 个对的，抗干扰 |
| TC-03 | "告诉 Sarah 会议改到 3 点" | 没说"发邮件"——能推断出 `get_contacts` → `send_email` 链？ |
Category B: Parameter Precision（参数精准）
| # | 场景 | 测什么 |
|---|---|---|
| TC-04 | "东京温度，要华氏" | 传了 `units: "fahrenheit"` 吗？ |
| TC-05 | "下周一 9:30 排会" | 相对日期解析 + 时间格式 + 可选参数 |
| TC-06 | — | （多参数组合） |
Category C: Multi-Step Chains（多步链）
连续调用多个工具完成复杂任务。
Category D: Restraint and Refusal（克制与拒绝）
这是最有意思的类别——测试模型是否知道不该调工具：
- 用户问的问题可以直接回答，不需要工具
- 用户的请求不道德/不安全
- 工具不适用于当前场景
Category E: Error Recovery（错误恢复）
工具返回错误时，模型能否：
- 解释失败原因
- 建议替代方案
- 不要重复调用同一个失败的工具
📐 评分体系
每场景：pass = 2分 | partial = 1分 | fail = 0分
每类别：3 场景 × 2 分 = 6 分满分
最终分 = 5 个类别百分比的平均值
评分示例（TC-01: 柏林天气）
| 行为 | 评分 |
|---|---|
| 调 `get_weather({ location: "Berlin" })` | ✅ pass (2分) |
| 调 `web_search("Berlin weather")` | ⚠️ partial (1分) — 能用但次优 |
| 两个都调 | ❌ fail (0分) — 冗余 |
| 不调工具直接答 | ❌ fail (0分) — 编造数据 |
🔧 技术设计
确定性保证
- 固定 system prompt：所有场景共用同一个
- Mock 工具结果：每个工具返回预设的 JSON，不调真实 API
- temperature: 0：消除随机性
- 日期锚点：固定为 2026-03-20（周五），避免相对日期歧义
- 原始 trace 存储：每次运行都保存完整对话记录
12 个通用工具
所有 15 个场景共享同一套工具：
web_search / get_weather / calculator / send_email / search_files /
read_file / create_calendar_event / get_contacts / translate_text /
get_stock_price / set_reminder / run_code
模型每次都收到全部 12 个工具定义——这测试了忽略不相关工具的能力。
支持的 Provider
| Provider | 配置格式 |
|---|---|
| OpenRouter | `openrouter:openai/gpt-4.1` |
| Ollama | `ollama:qwen3.5:4b` |
| llama.cpp | `llamacpp:local-model` |
支持双表对比（LLM_MODELS + LLM_MODELS_2），适合 A/B 测试。
🆚 和其他 Benchmark 的对比
| ToolCall-15 | BFCL (Berkeley) | Scale ToolComp | PinchBench | |
|---|---|---|---|---|
| 场景数 | **15** | 2000+ | 未公开 | 23 |
| 可视化 | **✅ 实时 dashboard** | ❌ 静态排行榜 | ❌ 静态 | ❌ 静态 |
| 可复现 | **✅ 完全开源 + mock** | ✅ 开源 | ❌ 闭源 | ✅ 开源 |
| 评分 | 确定性 3 级 | 自动 + 人工 | 人工 | 自动 |
| 自托管 | **✅** | ❌ | ❌ | ✅ |
| 本地模型 | **✅ Ollama/llama.cpp** | ❌ API only | ❌ | ✅ |
| 覆盖面 | 窄（纯工具调用） | **广（多种任务）** | 广 | 广（Agent 任务） |
ToolCall-15 的定位：不是大而全的 benchmark，而是精准狙击工具调用能力的小而美测试套件。
💡 与我们的关联
1. 评估我们用的模型 ⭐⭐⭐
我们用 Claude Opus 做 Agent，工具调用质量直接影响效果。可以用 ToolCall-15 跑一遍：
LLM_MODELS=openrouter:anthropic/claude-opus-4-6
LLM_MODELS_2=ollama:qwen3.5:27b
npm run dev
看看 Claude Opus vs Qwen3.5:27b（ub2 上的本地模型）在工具调用上差多少。
2. 评估 Qwopus 蒸馏模型
我们正在测试的 Qwopus（Qwen3.5-27B-Claude-Opus-Distilled）——ToolCall-15 是完美的测试工具：
- 蒸馏后工具调用能力保留了多少？
- 和原版 Qwen3.5:27b 比差多少？
- 和 Claude Opus 比差多少？
3. Category D（Restraint）对 Agent 特别重要
Agent 不该调工具的时候乱调 = 灾难（发错邮件、执行危险命令等）。"克制与拒绝"这个类别直接测试 Agent 安全性。
4. 可以部署在 ub2 上
支持 Ollama，可以在 ub2（RTX 4090）上跑本地模型的 tool calling benchmark。
5. 设计思路可以借鉴
如果我们想做 OpenClaw 的 Agent 能力评测，ToolCall-15 的设计模式（mock 工具 + 确定性评分 + 可视化 dashboard）是很好的参考。
⚠️ 注意事项
1. 只测工具调用：不测推理、代码生成、知识等其他能力
2. 15 个场景偏少：统计意义有限，一个场景失败就影响 ~7% 的总分
3. Mock 工具 vs 真实环境：Mock 不能完全代表真实 API 的复杂性
4. 单一 system prompt：不同 prompt 可能产生不同排名
5. 新项目：2026 年 3 月刚发布，社区验证不足
📊 评分
| 维度 | 评分（/10） |
|---|---|
| 设计质量 | 9.0 — 5 类别均衡、确定性评分、可审计 trace |
| 实用性 | 8.5 — 自托管 + 支持本地模型 + 实时 dashboard |
| 创新性 | 8.0 — "可视化 benchmark" 的理念比静态排行榜好太多 |
| 覆盖面 | 6.5 — 只有 15 个场景，纯工具调用 |
| 与我们的关联 | 8.5 — 评估 Opus/Qwen/Qwopus 的工具调用能力 |
| **综合** | **8.0** |
报告由深度研究助手自动生成 | 2026-03-26
来源: GitHub