VAKRA深度解析Agent推理失败和工具使用

VAKRA 数据集 | 排行榜 | 发布博客 | GitHub | 提交到排行榜

我们最近推出了 VAKRA，一个工具支撑的可执行基准，用于评估 AI 智能体在类企业环境中的推理和行动能力。

与测试孤立技能的传统基准不同，VAKRA 通过完整的执行轨迹跨 API 和文档来衡量组合推理能力，评估智能体能否可靠地完成多步骤工作流程。

VAKRA 提供了一个可执行的环境，其中智能体与 8000+ 个本地托管的 API 交互，这些 API 由跨越 62 个域的真实数据库支撑，还有域对齐的文档集合。任务可能需要 3-7 步推理链，将结构化的 API 交互与非结构化检索相结合，受自然语言工具使用约束的限制。

如下所示，模型在 VAKRA 上的表现较差。在这篇博客中，我们包含了关于 VAKRA 中任务的额外数据集细节，并分析了我们在不同任务上观察到的失败模式。

如下所示，VAKRA 基准包含四个任务，每个任务测试不同的能力集。

图 1：VAKRA 基准中每种能力的代表性示例

能力 1：数据操作

此能力在 54 个域上包括 2,077 个测试实例，需要使用来自 SLOT-BIRD 和 SEL-BIRD 集合的工具（Elder et al., 2026）。与 Elder et al. 中的设置相比，SLOT-BIRD 和 SEL-BIRD 中的工具集通过包含更多域得到了扩展。每个域仅限于一个工具集合，任务涉及链式调用 1-12 个工具来得到最终答案。

{
  "query": "Which football team has a build-up play speed of 31, build-up plan dribbling of 53, and build-up play passing of 32?",
  "tool_calls":[
      {
        "name": "get_data",
        "arguments":{"tool_universe_id="486ea46224d1-aeb8037c5e78"},
        "label": "retrieved_data_1"
      },
      {
        "name": "select_data_equal_to",
        "arguments":{"data_label":"retrieved_data_1","key_name":"play_speed","value":31},
        "label": "FILTERED_DF_0"
      },
      {
        "name": "select_data_equal_to",
        "arguments":{"data_label":"FILTERED_DF_0","key_name":"play_dribble","value":53},
        "label": "FILTERED_DF_1"
      },
      {
        "name": "select_data_equal_to",
        "arguments":{"data_label":"FILTERED_DF_1","key_name":"play_passing","value":32},
        "label": "FILTERED_DF_2"
      },
      {"name":{get_team_name},"arguments":{"data_label":"FILTERED_DF_2","n":1}}}],
  "answer": "FC Barcelona"
}

图 2：来自 SEL-BIRD 集合的数据样本

如上所示，每个实例都有关联的 JSON 数据源，答案必须从中获取。支持此任务的 MCP 服务器包括一个特殊工具，称为 get_data(tool_universe_id=id)，必须在每个实例开始时调用。此工具初始化数据源，返回数据的轻量级预览（见下方图 3），并将完整数据集存储在服务器端以避免大规模数据传输。这样可以防止通过 MCP 协议低效地传输大数据。该调用还配置 MCP 服务器基于 tool_universe_id 公开适当的工具集，并使数据源与实例的域特定数据库对齐。

SLOT-BIRD 集合为通用数据操作（如过滤、排序）提供了一套全局 7 个工具，灵感来自 Tableau 和 Google Analytics 等系统。SEL-BIRD 集合通过引入更专门的工具来扩展这一点：一些与 SLOT-BIRD 共享，而其他则是通过将分类论证展平为单独的函数得出的（例如，带有参数 ascending: bool = False 的 sort_data 变为 sort_data_ascending 和 sort_data_descending）。此外，来自 SLOT-BIRD 的通用 retrieve_data 函数被替换为查询特定的获取器。给定实例中数据的每个键都有一个关联的 get 函数（get_KEY_NAME），平均每个实例有 4 个 get 函数。

{
  "handle": "retrieved_data_1",
  "num_records": 2,
  "key_details": [
    {"name": "team_name", "dtype": "str", "first_3_values": ["FC Barcelona", "Manchester City"]},
    {"name": "play_speed", "dtype": "int32", "first_3_values": [31, 40]},
    {"name": "play_dribble", "dtype": "int32", "first_3_values": [53, 30]},
    {"name": "play_passing", "dtype": "int32", "first_3_values": [32, 16]}
  ]}

图 3：从 get_data 函数获得的数据预览

能力 2：API 选择

此能力在 17 个域上包括 1,597 个实例，需要来自扩展 REST-BIRD 集合的工具（Elder et al.）。这些使用端点风格的接口，提供高度特定的、与查询对齐的端点，封装了大部分计算。它们以 FastAPI 服务器中运行的 REST API 形式提供，由 MCP 服务器包装。此任务需要从域特定的工具集中选择正确的 API（如图 1 中的示例所示）。每个域包含最少 6 个到最多 328 个工具（平均 116 个）。与前一个任务类似，get_data 工具配置 MCP 服务器仅公开相关的域特定 API。

OpenAI API 规范限制工具列表输入的最大长度为 128 个工具。此限制要求使用此 API 的智能体构建者通过短列表机制直接管理工具列表的长度。在我们代码库中的基线智能体中，一个简单的短列表能力处理了这一挑战。

能力 3：多跳推理

基准的能力 3 部分有 869 个测试实例，来自 38 个主题域。这些实例再次依赖 REST-BIRD API 集合，但为挑战增加了多跳推理（参考图 1 中的示例）。多跳问题需要提取和结合多条支持证据来得到答案。本部分中的实例需要一到五个逻辑跳跃来回答查询。下面图 4 中显示了测试数据集内查询的问题类型分布。

图 4：能力 3（多跳）的 API 跳跃类型分布和能力 4（多跳多源推理）的混合跳跃类型分布

能力 4：多跳多源推理

能力 4 包括跨 41 个域的 644 个实例，同样基于 REST-BIRD API 集合。上方图 4 显示了无策略测试查询的混合跳跃分布。它包含具有以下特征的最复杂的查询：

多源：此部分为每个域添加了文档索引。此能力中的查询可能需要来自这些文档索引以及 API 调用的信息。与能力 3 类似，此任务也具有多跳查询。所需的信息源在每跳级别适用，例如，一个问题可能涉及三个逻辑跳跃，来源为：API - RAG（文档检索）- API。为了强制正确的推理，在数据生成期间对源进行了去污染，即给定跳跃所需的信息仅在一个源中可用。例如，如果要使用 API 回答某个跳跃，文档索引是通过移除可能包含回答问题所需信息的文档来构建的。

多轮对话：数据集的此部分还在设置中添加了多轮对话。每个实例都是具有多个轮次的对话。数据以上下文-响应对的形式发布，其中上下文编码当前对话历史，智能体仅负责回答当前轮次。

工具使用策略：这些实例的一个子集包括智能体必须遵循的工具使用策略。这些策略采用关于智能体可以访问哪些知识源以及在何种情况下访问的纯文本指令形式。例如：

If a user's query pertains to Technology & Software, which is/are about Topics focusing on codebases,
software platforms, applications, and user interactions in tech, make sure you try answering them by
only using document retrievers. Do not use other types of tools.

项目代码库中的基线智能体通过向提示中添加简单内容来强制执行这些策略："You are a helpful assistant with access to tools.\n Tool Usage Constraint: {additional_instructions}."。当然，智能体构建者可以自由选择任何约束执行机制。

执行中心的评估

VAKRA 在工具环境中评估智能体，其中成功取决于执行连贯的多步骤工作流程和答案正确性的能力。我们引入了一个执行中心的评估框架，不仅评估最终输出，还评估包括工具调用、输入和中间结果的完整工具执行轨迹。

VAKRA 评估器对每个样本的两个关键输入进行操作：预测的最终响应和相应的工具调用轨迹。来自预测轨迹的工具调用在与真实值相同的环境中执行，以验证中间工具输出。

评估遵循瀑布式流程（图 6），其中后期阶段以早期的成功为条件：

对于能力 4 的任务，首先以编程方式验证策略遵从性（此步骤不适用于其他能力）。

然后将预测的工具调用序列与标准答案序列进行比较。

只有具有有效轨迹的样本才能进行最终响应评估。

图 6：瀑布式评估流程

工具序列比较 由于存在可执行环境，AI 智能体可以探索环境，有时可能通过调用与我们确定的 API 不同的 API 集合来返回答案。为了支持替代但有效的工具调用和推理路径，正确性通过执行每个预测工具并比较工具响应集与标准答案的工具响应集来评估（而不是强制执行严格的步骤级别匹配）。

具体来说，我们首先执行程序化检查，验证标准答案工具响应中存在的所有信息是否由预测的工具响应恢复。在涉及部分匹配、语义等价或表示差异（例如排序、聚合或格式）的情况下，此检查可能不明确。在这些情况下，我们应用基于 LLM 的次级评估（改编自 CRAG 框架 Yang 等，2024），以确定预测的轨迹是否检索了所有必需的信息，尽管存在结构差异。此步骤使用改编的提示来确定预测的轨迹是否捕获了所有必需的信息，即使是通过不同的工具调用序列获得的。

最终响应评估 对于通过前一个检查的轨迹，使用基于 LLM 的评判器来评估最终响应。此步骤确保响应（i）基于预测的工具输出，且（ii）与标准答案在事实上一致，考虑到措辞或结构可能的变化。

这种设计确保 AI 智能体不仅因产生正确的答案而获得奖励，还因通过有效且完整的推理过程获得答案而获得奖励。

每个能力都被平等加权以获得最终排行榜得分

为了获得能力得分，能力 1 至 3 中的每个样本都被平等加权。

对于能力 4，我们给异构查询赋予更高权重：

我们现在对四个 VAKRA 能力进行详细的错误分析。为了促进我们的分析，我们采用分阶段错误分类，将每个失败分配给第一个故障点。具体来说，我们按顺序评估：(i) 是否选择了正确的工具，(ii) 是否提供了所需的参数而没有遗漏或幻觉，(iii) 参数值是否正确，以及 (iv) 最终响应是否既准确又基于工具输出。

由于单个样本可能在不同步骤中表现出多个错误，我们按顺序将每个实例分类到最早出现故障的阶段（例如，工具选择错误优先于参数错误）。这避免了重复计数，并允许错误类别被解释为数据集的不相交部分。虽然更细粒度的指标（例如，工具使用的精确率/召回率）是可能的（Elder 等，2026），但我们认为这个公式提供了一个简单且可解释的 AI 智能体失败的分解。

能力 1：多工具序列 该基准的这一部分中的实例需要选择并排序多个工具来解决单个任务。我们在此能力中有 2077 个样本。这对所有模型都很有挑战性，但 GPT-OSS-120B 在该基准的这一部分中表现最佳。

GPT-OSS-120B 以很大的优势超越了其他模型，主要是因为对工具模式的理解更好。

这一部分基准的工具涉及大量参数，其中许多是可选的，与其他模型相比，GPT-OSS-120B 在选择正确的参数填充方面特别稳健。

总体而言，在进行所有工具调用后合成正确答案在该基准这一部分中的挑战性较小，很可能是因为工具调用序列使工具选择问题相比于仪表板 API 能力而言不太易于猜测。

图 7：SEL-BIRD 与 SLOT-BIRD 错误类型分析

能力 2：商务智能 API 商务智能 (BI) API 能力包含来自 SLOT-BIRD 和 SEL-BIRD 工具集合的两组 API。该基准的 SEL 部分有 600 个样本，而基准的 SLOT 部分有 1477 个样本。这两个集合在 BI API 能力下分组，但具有略微不同的特征。SLOT-BIRD 集合有较少数量的通用工具，需要填充大量参数值，而 SEL-BIRD 集合有较大的工具集和每个工具的较少参数。这一焦点反映在使用这两个工具集合的模型做出的相对错误中。

使用 SLOT-BIRD，除 GPT-OSS-120b 外的所有模型在为工具参数生成正确名称时犯了大量错误。这在很大程度上是 GPT-OSS-120b 在该基准这一部分中整体表现如此出色的原因。

由于参数填充较少，这些模型在使用 SEL-BIRD 工具集合时很少出现此类错误，但他们在选择正确工具方面犯了更多错误，反映了从更大（和动态）工具集中选择的难度增加。

能力 3：仪表板 API 如上所示，对于 1597 个工具选择能力的样本，Gemini-3-flash-preview 在所有错误类别上都优于测试的其他模型。

如预期的那样，由于仪表板 API 实例需要模型从大量工具选项中选择，但每个工具只需要少数参数，因此工具选择和参数值选择中有大量错误。

似乎在幻觉或跳过所需参数方面没有问题。然而，即使进行了所有工具调用，模型（特别是 Gemini-3-flash-preview 和 Claude-Sonnet-4-5）仍在努力从工具响应中合成正确的答案，如图右侧的大幅下降所证实的。

图 8：模型按跳数深度的准确率比较

能力 4：多跳推理与策略 多跳推理通过要求模型成功回答多个隐式耦合的问题来增加原始任务的难度，每个问题都需要选择和调用正确的 API。如预期的那样，所有模型在只有单个逻辑跳的问题上表现最佳，在 2 跳问题上看到性能下降，在 3+ 跳问题上再次下降。

图 9：模型按交互类型（API、文档检索器、混合）的准确率

数据集的最后一部分除了其他部分中的工具/API 源外，还包括文档源。这导致实例需要单个或多个 API 调用、单个或多个文档搜索，或 API 调用和文档搜索的某种组合。

如前所述，在需要单个 API 调用（1 跳 API）的实例与需要多个 API 调用（2 跳 API）的实例之间有明显的性能差异，包括文档检索器使任务更具挑战性（RAG 跳数和混合）。

有趣的是，我们发现在需要单个文档检索器调用（1 跳 RAG）的问题上，GPT-OSS-120B 尝试直接从参数知识返回答案，但当问题似乎需要多跳时，它会回答问题。我们假设，由于 1 跳 RAG 的问题非常注重维基百科实体，该模型跳过了工具调用（我们在 1 跳 API 上没有看到这个问题，其中后端数据库特定的实体/事实可能更频繁地出现在问题中）。

有趣的是，Gemini-3-flash-preview 在 2 跳 API-RAG 上的性能相比其他混合跳数模式大幅提升。这可能是因为 Gemini-3-flash-preview 在仪表板 API（工具选择能力）上表现相对强劲，因此，一旦使用工具调用确定了正确的中间答案，检索查询可能会更成功。

图 10：模型按策略类型的准确率

策略在多跳、多源推理之上引入了额外的难度层。当策略与回答所需的源对齐时，即它们不影响模型回答问题所需的工具列表，我们称其为"不更新答案"——如图 10 所示，除 Granite-4.0-h-Small-32B 外的所有模型在限制访问最相关信息源（即"策略更新答案"）的策略约束下都经历了明显的性能下降。

总体而言，我们发现模型要么违反约束，要么无法检索到足够的信息，有些时候它们理解了策略但无法正确回答问题，或者表现出之前分析过的某种失败模式。

总的来说，在工具使用受策略约束的设置中，虽然模型可以对工具和数据源进行推理，但它们在将外部约束纳入推理时苦苦挣扎——这通常是可靠的实际部署的关键要求。

VAKRA 暴露了表面级工具能力和稳健的端到端 AI 智能体可靠性之间的关键差距。虽然现代模型越来越能够选择 API 并执行隔离的工具调用，但 VAKRA 表明这些能力单独对于实际部署是不够的。在实践中，当需要在执行约束下进行组合推理时，模型经常崩溃——这些约束跨越 API、文档、对话上下文和策略要求。

试试 VAKRA——你的 AI 智能体在哪里崩溃？

你认为你的 AI 智能体很稳固？把它放在测试中。

在 VAKRA 上运行它，看看它在哪里出问题——工具选择、多跳推理或策略约束。

⭐ 提交到排行榜：https://github.com/IBM/vakra?tab=readme-ov-file#submitting-to-the-live-leaderboard

📦 探索数据集：https://huggingface.co/datasets/ibm-research/VAKRA

🛠️ 查看代码：https://github.com/IBM/vakra

👉 试一试，告诉我们你的 AI 智能体学到了什么

本文提及的数据集 1

本作者的更多文章

Model Routing Is Simple. Until It Isn't.

ScarfBench: Benchmarking AI Agents for Enterprise Java Framework Migration

· 登录或注册以评论

本文提及的数据集 1