来源：GitHub (★303)
URL: https://github.com/SeraphimSerapis/tool-eval-bench
精读日期：2026-08-27
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • tool-eval-bench 是一个面向 LLM serving 栈的 工具调用质量基准测试，包含 80+ 确定性场景，覆盖多轮编排、安全边界和结构化输出。
  • 支持主流开源 serving 框架：vLLM、SGLang、llama.cpp，并提供可插拔的准确率基准（如 MMLU、IFEval、GSM8K）。
  • 场景分为 69 个标准场景 + 19 个可选 Hard Mode 场景，按 7 大类别组织：参数正确性、链式推理、失败处理、多语言/时区、消息路由、输出格式、工具选择。
  • 评分机制：按场景数量加权计算最终分数（0–100），每个场景有难度等级（1–5）；若 Safety & Boundaries 类别得分低于 50%，总评级上限封顶为 ★★★ Adequate。
  • 超时/连接错误/持续 429/5xx 场景不计入分子分母（视为环境问题而非模型问题），但会完整报告，并提示 completion rate 供对比。
  • Mock 工具响应包含 真实噪声（额外元数据、时间戳、嵌套对象），测试模型从嘈杂 API 响应中提取相关字段的能力。
  • 集成 llama-bench 风格吞吐基准（prefill 和 token 生成速度），支持可配置上下文深度和并发扫描。

二、方法/架构拆解

基准结构（7 大类别，69+19 场景）：

  • TC-01–TC-24：参数正确性（单位、日期、多值）、链式推理、数据线程、并行调用、异步轮询、失败处理与数据完整性
  • TC-25–TC-27, TC-46–TC-50, TC-62–TC-63：德语、时区感知、翻译+转发；消息路由、数据提取、约束验证
  • TC-28–TC-30, TC-37–TC-40, TC-44–TC-45, TC-51–TC-56, TC-61：输出格式、工具禁止、多约束、tool_choice 合规；交叉引用、状态一致性、多轮修正、5 轮链式、约束累积
  • TC-31–TC-36, TC-41–TC-43, TC-57–TC-60：读前写、解释 vs 执行、链式条件；歧义、提示注入（文件/搜索/系统/sleeper）、权限升级、矛盾参数、参数验证
  • TC-64–TC-69：52 工具选择、拥挤命名空间多步、富余约束；目标分解、开放研究、条件工作流；跨工具综合、数据管道、通知工作流
  • Hard Mode（19 个）：JSON schema 合规、工具→schema 链式、嵌套 schema、枚举约束、违规抵抗；天花板级对抗、有状态、事务性、恢复、推理连续性场景

准确率插件（可插拔）：

  • GSM8K：8-shot 思维链，小学数学推理
  • MMLU：57 个学科（STEM、人文、社科、其他），5-shot
  • IFEval：25 种约束类型，确定性程序化检查（无 LLM-as-judge）

评分机制：

  • 每类别按得分百分比计，最终分数 =（总得分 / 总分）× 100，按场景数量加权
  • 可选用 --hard-weighted 计算加重困难场景的替代分数
  • 准确率插件使用 更严格的总项分母（超时不能把 1 个正确答案变成完美运行）
  • 评估器检查场景关键语义：显式工具错误不能支撑虚构答案数据、依赖和关键参数必须有效、结构化输出必须满足声明的类型和字段

实现要点：

  • 全局安装：uv tool install git+https://github.com/SeraphimSerapis/tool-eval-bench.git
  • 吞吐基准：tool-eval-bench[perf]（捆绑 llama-benchy）
  • 快速运行：tool-eval-bench run --short --base-url http://localhost:8000（核心 15 场景）
  • 本地发现：自动扫描 vLLM、llama.cpp 等常用 localhost 端口
  • 每次运行输出两个产物（相对运行目录），包含详细 trace 报告

三、值得注意的局限/争议

作者承认的局限：

  • 不是完整的 agentic 系统基准（与 BFCL、PinchBench、Claw-Eval 的对比见文档）
  • 合成测试可能省略结果记录；缺失与结果兼容，但无法证明依赖结果的行为（如完成的异步轮询）
  • 超时/连接错误场景被丢弃，需检查 completion rate 才能公平对比两次运行

AI 判断的局限：

  • 场景数量（80+）相比真实世界工具调用的多样性仍有限，Hard Mode 的"天花板级对抗"可能过度拟合特定失败模式
  • 评分加权方式（按场景数而非难度）可能导致简单场景主导总分，虽有 --hard-weighted 但非默认
  • 依赖 OpenAI 兼容端点，对非标准 serving 栈（如自定义协议）适配有限
  • 德语场景仅覆盖单一语言，多语言泛化能力验证不足
  • 未提及对工具定义本身（如 schema 复杂度、参数类型多样性）的系统性压力测试

四、与 RRLab 研究的关联

Harness 工程：

  • 可借鉴其 确定性场景设计 思路：将工具调用质量拆解为可重复验证的原子场景（参数、链式、安全），而非端到端黑盒测试
  • 其 超时/错误场景丢弃机制 和 completion rate 报告 是评测工程中处理环境噪声的成熟实践，可直接用于 RRLab 评测管线
  • 全局安装 + 无 venv 管理的 uv 方式，简化了评测环境的部署和 CI 集成

多模型协同：

  • 其 52 工具选择 + 拥挤命名空间 场景，可用于测试多模型路由/调度时工具选择的准确性
  • 链式推理、数据线程、并行调用 场景为多模型协同中的任务分解和结果聚合提供评测基准

模型评测：

  • 7 大类别 + 难度分级 + 加权评分的体系，可作为 RRLab 工具调用评测的 评分框架参考
  • Safety & Boundaries 类别一票否决制（低于 50% 封顶 ★★★）是安全评测的强约束设计，值得借鉴
  • 可插拔准确率插件（GSM8K/MMLU/IFEval）与工具调用基准的 组合评测模式，可扩展 RRLab 的评测维度

Agent 落地：

  • 读前写、解释 vs 执行、权限升级、提示注入 等场景直接对应 Agent 生产环境的安全边界，可作为 RRLab Agent 上线前的 安全验收测试
  • 异步轮询、事务性、恢复 场景覆盖真实业务中 Agent 的长时间运行和故障恢复需求

AI 原生产品：

  • Mock 工具响应噪声（额外元数据、时间戳、嵌套对象）的设计，模拟真实 API 环境，可用于 RRLab 产品中工具调用的鲁棒性测试
  • trace 报告 的详细输出（每场景得分、难度、失败模式）可作为产品中 可观测性和调试工具 的设计参考

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/SeraphimSerapis/tool-eval-bench