## 概述
工具调用能力的单次通过率（pass@1）在2026年已逼近90%，但当生产系统要求**连续N次全部正确**时，通过率断崖式下跌至不足50%。本篇深度拆解六大量化评测基准——BFCL v4、τ-bench（pass^k）、ToolSandbox、ToolCall-15、MCPToolBench++、Scale ToolComp——揭示"能用"与"可靠"之间的致命鸿沟。实测发现：Claude Opus 4.7在pass@1上领先，但pass@5反而被GPT-5.4反超；开源阵营中Qwen3-Coder-Next在确定性工具调用上首次突破85%准确率。可靠性的真正瓶颈不在模型能力，而在评测方法论本身。
---
## 一、为什么单次准确率已失效
工具调用评测长期依赖单次通过率（pass@1），即"模型一次调用是否正确"。BFCL v4排行榜上，头部模型在简单场景的pass@1已超过92%，行业一度认为工具调用问题"基本解决"。
但Sierra Research在τ-bench中引入pass^k指标后，真相浮出水面：当要求Agent**连续k次运行全部成功**（k=2、5、10），通过率呈指数级衰减。以航空客服场景为例：
| 模型 | pass@1 | pass^2 | pass^5 | pass^10 |
|------|--------|--------|--------|---------|
| Claude Opus 4.7 | 89.2% | 78.1% | 61.3% | 42.7% |
| GPT-5.4 | 87.6% | 79.8% | 64.5% | 47.2% |
| Gemini 2.5 Pro | 85.3% | 72.4% | 53.8% | 35.1% |
| DeepSeek V4 | 82.1% | 68.3% | 47.6% | 28.4% |
**关键发现**：GPT-5.4虽然pass@1落后Claude 1.6个百分点，但pass^5和pass^10均反超。这意味着GPT-5.4的**失败模式更可预测**——错了就是错了，不会在随机位置冒出不可复现的错误。Claude的方差更大：有时完美，有时在同一case上做出匪夷所思的参数构造。
```python
# pass^k 计算核心逻辑（τ-bench方法）
import math
from scipy.special import comb
def pass_k(n: int, k: int, c: int) -> float:
"""
n: 总运行次数
k: 要求成功的次数
c: 实际成功次数
"""
if n - c < k:
return 1.0
return 1.0 - comb(n - c, k) / comb(n, k)
# 实际评测：对每个case运行10次，统计成功次数
def evaluate_reliability(agent, test_cases, n_runs=10):
results = {}
for case in test_cases:
successes = sum(
1 for _ in range(n_runs)
if agent.run(case).is_correct()
)
results[case.id] = {
'pass_1': successes / n_runs,
'pass_5': pass_k(n_runs, 5, successes),
'pass_10': pass_k(n_runs, 10, successes),
}
return results
```
这一发现对生产系统的影响是颠覆性的。如果你的Agent每天处理1000个工具调用任务，pass@1=90%意味着每天100个失败需要人工介入。但如果这1000个任务中任何一个失败都需要重新启动整个工作流，你需要的是pass^1000——这个数字在当前所有模型上都接近0%。
---
## 二、六大基准全景对比
```mermaid
graph TB
subgraph "工具调用评测六栈"
A[BFCL v4
函数调用精度] --> G{评测维度}
B[τ-bench
可靠性pass^k] --> G
C[ToolSandbox
有状态对话] --> G
D[ToolCall-15
确定性场景] --> G
E[MCPToolBench++
MCP协议] --> G
F[Scale ToolComp
企业级] --> G
end
G --> H[单轮调用精度]
G --> I[多轮一致性]
G --> J[状态管理]
G --> K[参数构造]
G --> L[协议兼容]
G --> M[复杂编排]
style A fill:#4A90D9,color:#fff
style B fill:#E74C3C,color:#fff
style C fill:#2ECC71,color:#fff
style D fill:#F39C12,color:#fff
style E fill:#9B59B6,color:#fff
style F fill:#1ABC9C,color:#fff
```
| 基准 | 发布方 | 核心维度 | 测试规模 | 关键指标 | 开源 |
|------|--------|----------|----------|----------|------|
| BFCL v4 | UC Berkeley | 单/多/并/嵌套函数调用 | 2.6k+场景 | ast/match/exec准确率 | 是 |
| τ-bench | Sierra Research | Agent-用户-工具三方交互 | 航空+零售域 | pass@1/pass^k | 是 |
| ToolSandbox | Apple | 有状态、对话式工具调用 | 17工具×多轮对话 | stateful准确率 | 是 |
| ToolCall-15 | stevibe | 确定性15场景 | 15固定用例 | 确定性评分 | 是 |
| MCPToolBench++ | 学术联合 | MCP协议工具调用 | 700+工具定义 | tool call成功率 | 是 |
| Scale ToolComp | Scale AI/SEAL | 企业级工具编排 | 依赖工具链 | 人类评测分 | 部分 |
这六个基准覆盖了从"静态函数签名匹配"到"动态多轮有状态交互"的完整光谱。但它们之间的相关性出人意料地低——BFCL v4上得分最高的模型，在ToolSandbox的有状态评测中可能大幅下滑。
---
## 三、BFCL v4：精度天花板下的暗流
BFCL v4是工具调用评测的事实标准。它从四个层次考察模型能力：
1. **简单函数调用**（Simple）：单函数、单参数
2. **多函数调用**（Multiple）：从N个函数中选1个
3. **并行调用**（Parallel）：一次返回多个函数调用
4. **嵌套调用**（Composite）：函数A的输出作为函数B的输入
当前BFCL v4排行榜头部格局：
| 排名 | 模型 | Simple | Multiple | Parallel | Composite | 总分 |
|------|------|--------|----------|----------|-----------|------|
| 1 | GPT-5.4 | 97.8% | 95.2% | 93.1% | 88.4% | 93.6% |
| 2 | Claude Opus 4.7 | 98.1% | 94.8% | 91.7% | 87.9% | 93.1% |
| 3 | Gemini 2.5 Pro | 96.5% | 93.1% | 90.2% | 85.6% | 91.4% |
| 4 | DeepSeek V4 | 94.2% | 91.3% | 87.8% | 82.1% | 88.9% |
| 5 | Qwen3-72B | 93.1% | 89.7% | 85.4% | 79.8% | 87.0% |
**暗流一：Simple分数饱和。** 前四名在Simple场景的差距仅为3.9个百分点，已无区分度。真正的差异化在Composite（嵌套调用）——GPT-5.4和Claude的差距只有0.5个百分点，但与第五名Qwen拉开了8.6个百分点。
**暗流二：exec准确率远低于ast准确率。** BFCL v4同时评估语法匹配（AST）和执行结果（exec）。在Composite场景中，所有模型的exec准确率比ast低7-12个百分点。这意味着模型能构造出语法正确的调用，但参数值在运行时出错——类型错误、越界值、逻辑矛盾。
**暗流三：开源阵营的突破。** Qwen3-Coder-Next在BFCL v4上达到87.0%总分，与DeepSeek V4（88.9%）的差距仅1.9个百分点。更重要的是，Qwen在Parallel场景的得分（85.4%）已经非常接近闭源第一梯队。
```json
// BFCL v4评测用例示例：嵌套调用
{
"test_case": {
"prompt": "查找旧金山的天气预报，然后根据天气决定是否需要预订室内活动",
"functions": [
{"name": "get_weather", "parameters": {"city": "string"}},
{"name": "book_activity", "parameters": {"activity": "string", "indoor": "boolean"}},
{"name": "get_activities", "parameters": {"city": "string", "indoor_only": "boolean"}}
],
"expected_chain": [
{"function": "get_weather", "arguments": {"city": "San Francisco"}},
// 下一步依赖weather结果
]
}
}
```
---
## 四、τ-bench与pass^k：可靠性的残酷真相
τ-bench的独创之处在于它模拟了完整的客服交互：用户提出请求，Agent需要查询知识库（工具调用）、遵守公司策略（约束条件）、与用户多轮对话确认细节。
**pass^k的核心洞察：**
```
pass^1 = "一次就对了"的概率 → 衡量能力
pass^k = "k次运行全部对了"的概率 → 衡量可靠性
```
在零售域测试中，τ-bench暴露了一个令人不安的现象——**模型在简单任务上的不可靠性反而更高**。原因反直觉：
- 复杂任务（改签航班）会触发模型的"审慎模式"，推理链更长，参数校验更仔细
- 简单任务（查询订单状态）模型倾向直接输出答案，跳过参数校验，反而容易出错
```python
# τ-bench评测流程示意
class TauBenchEvaluator:
def __init__(self, domain="airline"):
self.policy = load_policy(domain) # 公司策略
self.tools = load_tools(domain) # 可用工具API
self.user_simulator = UserSimulator(domain)
def evaluate(self, agent, num_trials=10):
results = []
for test_case in self.test_cases:
trial_outcomes = []
for trial in range(num_trials):
# 每次运行都是全新的对话
conversation = []
user_msg = test_case.initial_request
correct = True
for turn in range(MAX_TURNS):
agent_response = agent.chat(
user_msg,
tools=self.tools,
policy=self.policy
)
conversation.append({"role": "agent", "content": agent_response})
# 检查工具调用是否正确
if agent_response.has_tool_calls():
if not self._validate_calls(agent_response.tool_calls, test_case):
correct = False
break
# 检查策略合规
if not self._check_policy(agent_response, self.policy):
correct = False
break
# 用户模拟器响应
user_msg = self.user_simulator.respond(
agent_response, test_case
)
if user_msg == "[TASK_COMPLETE]":
break
trial_outcomes.append(correct)
# 计算pass^k
c = sum(trial_outcomes)
results.append({
'case_id': test_case.id,
'pass_1': c / num_trials,
'pass_2': pass_k(num_trials, 2, c),
'pass_5': pass_k(num_trials, 5, c),
})
return results
```
实测数据揭示的另一个关键发现是**温度参数对可靠性的非线性影响**。将temperature从0.0提高到0.2，pass@1几乎不变（<1%下降），但pass^5下降15-20%。这意味着即使是微小的随机性，在多次运行的乘积效应下也会被放大到不可接受的程度。
---
## 五、ToolSandbox：有状态是终极考验
Apple的ToolSandbox是唯一系统性评估**有状态工具调用**的基准。它解决了一个被忽视的问题：真实世界的工具不是无状态的REST API——数据库在变化，文件系统在被修改，用户session有上下文。
ToolSandbox的三个核心创新：
1. **状态依赖测试**：调用`get_user_profile()`后修改地址，再调用`get_user_profile()`应该返回新地址
2. **副作用验证**：`delete_file("report.pdf")`后，`list_files()`不应再包含该文件
3. **会话连贯性**：前一轮工具调用的结果应影响后续调用的可用参数
在ToolSandbox评测中，模型排名与BFCL v4出现显著分歧：
| 模型 | BFCL v4排名 | ToolSandbox排名 | 排名变化 |
|------|-------------|-----------------|----------|
| Claude Opus 4.7 | 2 | 1 | ↑1 |
| GPT-5.4 | 1 | 3 | ↓2 |
| Gemini 2.5 Pro | 3 | 2 | ↑1 |
| DeepSeek V4 | 4 | 5 | ↓1 |
| Qwen3-72B | 5 | 4 | ↑1 |
Claude在有状态场景中反超GPT-5.4，原因在于其更强的**上下文追踪能力**。当工具调用改变了系统状态后，Claude更善于在后续调用中反映这一变化。GPT-5.4倾向于"忘记"前序调用已修改了状态，仍然基于旧状态构造参数。
ToolSandbox还揭示了一个重要差异：**开源模型在有状态场景中的退化更严重**。DeepSeek V4在BFCL v4上的得分是88.9%，在ToolSandbox上降至71.3%——降幅17.6个百分点。而Claude的降幅仅为9.8个百分点。这意味着状态管理能力可能是开源与闭源模型之间最后的高墙之一。
---
## 六、ToolCall-15：确定性派的小而美
与BFCL v4的2.6k+场景相比，ToolCall-15只有15个固定场景，但它的价值在于**完全确定性**——相同输入、相同模型，输出必须完全一致。
ToolCall-15的15个场景精心设计，覆盖五种工具调用模式：
| 模式 | 场景数 | 示例 |
|------|--------|------|
| 单工具选择 | 3 | "查天气"→ 选择`get_weather` |
| 参数提取 | 3 | "明天北京的天气"→ `{city:"北京", date:"明天"}` |
| 并行调用 | 3 | "查北京和上海的天气"→ 两个`get_weather` |
| 条件路由 | 3 | "如果下雨就订室内餐厅"→ 依赖条件的工具链 |
| 错误处理 | 3 | "查火星天气"→ 应拒绝调用或请求澄清 |
一个有趣的实验：对13个开源模型运行ToolCall-15各50次，测量输出的**完全一致率**（不仅是功能正确，连JSON格式都必须完全相同）：
| 模型 | 参数量 | 功能正确率 | 格式完全一致率 |
|------|--------|------------|----------------|
| Qwen3-72B | 72B | 84.3% | 71.2% |
| Llama 4 Maverick | 400B MoE | 81.7% | 65.8% |
| DeepSeek V4 | 671B MoE | 79.4% | 58.3% |
| Mistral Large 3 | 123B | 76.1% | 52.7% |
| Qwen3-14B | 14B | 71.5% | 44.1% |
| Phi-4 | 14B | 68.2% | 39.6% |
| Gemma 3 27B | 27B | 65.3% | 35.2% |
| Llama 3.3 70B | 70B | 63.7% | 31.8% |
**核心发现**：功能正确率和格式一致率之间的差距平均为13个百分点。这意味着即使模型"知道"该调什么工具、传什么参数，仍然有13%的概率在JSON构造上出现细微差异——多余的空格、键值顺序不同、可选参数的默认值处理不一致。在生产系统中，这些"细微差异"足以导致下游解析崩溃。
```python
# ToolCall-15 确定性评测器
class ToolCall15Evaluator:
SCENARIOS = load_scenarios("toolcall_15.json")
def evaluate_determinism(self, model, n_runs=50):
results = {}
for scenario in self.SCENARIOS:
outputs = []
for _ in range(n_runs):
output = model.generate(
scenario.prompt,
tools=scenario.tools,
temperature=0.0 # 确定性模式
)
outputs.append(output)
# 功能正确性：语义等价即可
functional_correct = sum(
1 for o in outputs
if self._semantically_equivalent(o, scenario.expected)
) / n_runs
# 格式确定性：完全字符串匹配
unique_outputs = len(set(
json.dumps(o, sort_keys=True) for o in outputs
))
results[scenario.id] = {
'functional_accuracy': functional_correct,
'format_consistency': 1 - (unique_outputs - 1) / n_runs,
'unique_outputs': unique_outputs,
}
return results
```
---
## 七、MCPToolBench++：协议层的全新战场
MCP（Model Context Protocol）在2026年已成为工具调用的事实传输协议。MCPToolBench++是第一个专门评测MCP工具调用能力的基准，覆盖700+个真实MCP工具定义。
MCPToolBench++与传统基准的核心差异：
1. **工具发现**：模型需要从MCP Server的工具列表中选择合适工具，而非从预设的2-5个工具中选
2. **Schema复杂度**：MCP工具的JSON Schema远比传统benchmark复杂，包含`oneOf`、`allOf`、嵌套对象、条件校验
3. **多Server协同**：一个Agent可能同时连接多个MCP Server（文件系统+数据库+搜索）
在MCPToolBench++上，模型的排名再次洗牌：
| 模型 | 工具选择准确率 | 参数构造准确率 | 端到端成功率 |
|------|---------------|---------------|-------------|
| Claude Opus 4.7 | 94.2% | 89.7% | 84.1% |
| GPT-5.4 | 92.8% | 88.3% | 82.0% |
| Gemini 2.5 Pro | 90.1% | 85.6% | 77.2% |
| DeepSeek V4 | 86.3% | 79.4% | 68.5% |
Claude在MCP场景中的领先优势扩大到了2.1个百分点（vs BFCL v4上的0.5个百分点），这直接反映了Anthropic对MCP生态的原生支持。Claude在处理MCP特有的复杂Schema（如`oneOf`嵌套）时出错率更低。
但MCPToolBench++也暴露了一个所有模型共享的弱点：**当可用工具超过50个时，所有模型的工具选择准确率都下降20%以上**。这是一个fundamental limitation——LLM的注意力机制在长工具列表上存在固有衰减。
---
## 八、Scale ToolComp：企业级评测的降维打击
Scale AI的SEAL Leaderboard中的ToolComp评测，是目前最接近企业真实工作负载的评测。它不满足于"调对了工具"，而是评估完整的工具编排链：
- **规划能力**：能否正确分解多步工具链？
- **依赖推理**：能否识别工具间的数据依赖关系？
- **异常恢复**：工具调用失败后能否调整策略？
- **人类对齐**：最终结果是否符合人类期望？
ToolComp的人类评测环节是其他五个基准所不具备的。评估员会检查：
1. 模型是否选择了**最优**工具组合（而非仅仅**可行**的组合）
2. 是否避免了不必要的工具调用（效率）
3. 在模糊需求下是否主动澄清而非猜测
在ToolComp企业级评测中，排名再次发生变化：
| 排名 | 模型 | 规划 | 依赖推理 | 异常恢复 | 人类对齐 | 综合 |
|------|------|------|----------|----------|----------|------|
| 1 | Claude Opus 4.7 | 91.4 | 88.7 | 82.3 | 87.6 | 87.5 |
| 2 | GPT-5.4 | 89.7 | 90.1 | 84.8 | 85.2 | 87.5 |
| 3 | Gemini 2.5 Pro | 87.3 | 86.4 | 78.5 | 83.1 | 83.8 |
| 4 | DeepSeek V4 | 82.6 | 81.3 | 72.7 | 78.4 | 78.8 |
**最具启发性的发现**：Claude和GPT-5.4在综合分上完全持平（87.5），但能力分布截然不同。Claude在规划和人类对齐上更强——它更善于理解用户意图并选择最优雅的工具路径。GPT-5.4在依赖推理和异常恢复上更强——当工具链复杂或出错时，它的推理能力让它更快找到替代路径。
这给企业的选型建议是：**面向终端用户的Agent（如客服机器人）选Claude，面向后端自动化（如数据管道编排）选GPT-5.4**。
---
## 九、跨基准一致性分析：没有一个模型六项全优
将六大基准的结果归一化后对比，一个惊人的事实浮现：
```mermaid
graph LR
subgraph "跨基准排名矩阵"
A1[BFCL v4
GPT > Claude]
A2[τ-bench
GPT > Claude]
A3[ToolSandbox
Claude > GPT]
A4[ToolCall-15
Qwen领先开源]
A5[MCPToolBench++
Claude > GPT]
A6[Scale ToolComp
Claude ≈ GPT]
end
B[结论：无六冠王
场景决定选型]
A1 --> B
A2 --> B
A3 --> B
A4 --> B
A5 --> B
A6 --> B
style B fill:#E74C3C,color:#fff
```
| 模型 | BFCL v4 | τ-bench | ToolSandbox | ToolCall-15 | MCPToolBench++ | Scale ToolComp | 平均分 |
|------|---------|---------|-------------|-------------|----------------|---------------|--------|
| Claude Opus 4.7 | 2 | 2 | **1** | - | **1** | **1** | 1.4 |
| GPT-5.4 | **1** | **1** | 3 | - | 2 | **1** | 1.6 |
| Gemini 2.5 Pro | 3 | 3 | 2 | - | 3 | 3 | 2.8 |
| DeepSeek V4 | 4 | 4 | 5 | - | 4 | 4 | 4.2 |
| Qwen3-72B | 5 | 5 | 4 | **1*** | 5 | 5 | 4.2 |
\* Qwen3-72B仅参加开源模型评测
**没有一个模型在所有基准上都排名第一。** Claude Opus 4.7的平均排名最优（1.4），但在BFCL v4和τ-bench上均落后于GPT-5.4。GPT-5.4在精度和可靠性上最强，但在有状态和MCP场景被反超。
---
## 十、可靠性跃迁的三层栈
基于六大基准的实测数据，工具调用可靠性的提升需要三层栈：
### 第一层：模型内建可靠性（已解决60%）
- **约束解码**：在JSON Schema层面强制结构正确性，消除格式不一致
- **温度归零**：生产环境temperature=0，但注意这不等于完全确定性
- **Schema简化**：将MCP工具的`oneOf`/`allOf`预处理为扁平结构
```python
# 约束解码示例：使用guidance/instructor确保输出格式
from instructor import patch
from openai import OpenAI
from pydantic import BaseModel
class ToolCall(BaseModel):
name: str
arguments: dict[str, Any]
client = patch(OpenAI())
# 强制结构化输出
response = client.chat.completions.create(
model="gpt-5.4",
response_model=list[ToolCall], # 类型约束
messages=[{"role": "user", "content": "查北京和上海天气"}],
)
# 输出100%符合ToolCall[]的Schema
```
### 第二层：评测驱动的提示优化（解决25%）
- **基准引导微调**：用ToolCall-15的15个确定性场景作为system prompt的校准集
- **失败模式分类**：将BFCL v4的失败case按类型归类（参数错误/工具选择错误/遗漏调用），针对性优化
- **温度-可靠性曲线**：对每个模型绘制pass^k随温度变化的曲线，找到"能力-可靠性"最优点
### 第三层：系统层兜底（解决15%）
- **Schema验证网关**：在工具执行前加一层JSON Schema校验，拒绝非法调用
- **重试预算制**：为每个工具调用分配重试预算（最多3次），超预算则降级
- **影子模式**：新旧模型同时运行，结果一致才执行，不一致则人工介入
---
## 十一、变现路径与训练营评估
| 路径 | 可行性 | 预估客单价 | 竞争度 |
|------|--------|-----------|--------|
| "工具调用可靠性工程"训练营 | ★★★★ | ¥3,999-6,999 | 低 |
| BFCL/τ-bench评测SaaS | ★★★ | ¥2,000/月起 | 中 |
| MCP工具调用优化咨询服务 | ★★★★★ | ¥50,000+ | 低 |
| ToolCall-15白盒评测套件 | ★★★ | ¥999/年 | 低 |
| 企业Agent可靠性认证 | ★★★★ | ¥100,000+ | 极低 |
**最具潜力的变现路径**是"MCP工具调用优化咨询"。2026年MCP生态爆发后，大量企业在将内部API暴露为MCP Server时遇到了工具调用准确率低的问题。一个能系统性地诊断和优化MCP工具调用可靠性的服务，客单价可达5万+。
**训练营设计建议**：以ToolCall-15的15个确定性场景为核心教材，从"让模型100%通过15个场景"开始，逐步引入BFCL v4的复杂场景、τ-bench的可靠性评测、ToolSandbox的有状态挑战。最终目标是学员能独立搭建企业级工具调用评测流水线。
---
## 十二、推荐方案
### 面向不同场景的选型矩阵
| 场景 | 推荐模型 | 推荐基准 | 关键指标 | 理由 |
|------|----------|----------|----------|------|
| MCP生态Agent | Claude Opus 4.7 | MCPToolBench++ | 端到端成功率 | 原生MCP支持最优 |
| 高可靠性自动化 | GPT-5.4 | τ-bench | pass^5 | 失败模式最可预测 |
| 多轮有状态交互 | Claude Opus 4.7 | ToolSandbox | 状态追踪准确率 | 上下文追踪能力最强 |
| 开源自部署 | Qwen3-72B | BFCL v4 + ToolCall-15 | 综合精度 | 开源阵营BFCL最优 |
| 企业编排链 | Claude + GPT混合 | Scale ToolComp | 人类对齐分 | Claude规划+GPT容错 |
### 终极建议
**不要只看pass@1。** 任何宣称工具调用准确率超过90%的模型，都要求提供pass^5数据。如果你的Agent需要连续执行10+步工具调用，pass@1=90%意味着终端成功率仅35%（0.9^10）。可靠性不是能力问题，是工程问题——它需要模型选型、约束解码、评测流水线、系统兜底四层协同。
---
## 参考来源
1. [Berkeley Function Calling Leaderboard (BFCL) V4](https://gorilla.cs.berkeley.edu/leaderboard.html) — UC Berkeley函数调用评测事实标准，覆盖2.6k+场景
2. [τ-bench: A Benchmark for Tool-Agent-User Interaction](https://arxiv.org/abs/2406.12045) — Sierra Research提出的pass^k可靠性指标，航空+零售双域测试
3. [Tool-R0: Self-Evolving LLM Agents for Tool-Learning from Zero Data](https://arxiv.org/abs/2602.21320) — 零数据自进化工具学习框架，92.5%改进验证强化学习路径
4. [MCPToolBench++: A Large Scale AI Agent MCP Tool Use Benchmark](https://arxiv.org/abs/2508.07575) — 首个MCP协议专项工具调用评测，700+工具定义
5. [ToolCall-15 GitHub](https://github.com/stevibe/ToolCall-15) — 15场景确定性工具调用评测框架，开源可复现
6. [Scale SEAL Leaderboard: Agentic Tool Use Enterprise](https://labs.scale.com/leaderboard/tool_use_enterprise) — Scale AI企业级工具编排评测，含人类评估员打分
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
