MCP-GRANITE 基准：面向基于 MCP 的大语言模型智能体的粒度接口测试

MCP-GRANITE 基准：面向基于 MCP 的大语言模型智能体的粒度接口测试（中文全译）

翻译说明：本文是 arXiv 论文 MCP-GRANITE Benchmark: GRANularity Interface TEsting for MCP-Based LLM Agents（arXiv:2609.24161）的中文全译，由智测团队翻译。原作者：Demetris Paschalides、Moysis Symeonides、George Pallis、Marios D. Dikaiakos。原文以 CC BY 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

arXiv:2609.24161v1 [cs.DC] 2026 年 9 月 21 日

许可：CC BY 4.0

作者： Demetris Paschalides，Moysis Symeonides，George Pallis，Marios D. Dikaiakos

单位： 塞浦路斯大学计算机科学系，尼科西亚，塞浦路斯

电子邮箱： {dpasch01, msymeo03, pallis, mdd}@ucy.ac.cy

摘要

随着大语言模型（LLM）智能体越来越多地通过 MCP 等标准化协议与外部工具交互，工具接口设计成为一个关键却研究不足的因素。功能如何被分解为工具，会影响智能体能否选对工具并构造出合法参数。这一选择在边缘侧尤其关键：资源约束限制了哪些模型可以本地运行，而扩大模型规模往往并不可行。

我们提出 MCP-GRANITE，一个开源、可扩展的基准框架。它把工具接口粒度当作基于 MCP 的智能体的受控变量，并在边缘与物联网场景下进行评估。该基准包含 9 个领域的 81 个多步骤场景，并在 4 个粒度级别上实例化，从细粒度原子工具直到单一工具。我们评估了 9 个本地部署模型（参数量 268M–20.9B），共 8,748 次试验，指标包括任务完成、工具选择 F1、参数准确率、时延与资源使用。结果表明，4 工具接口给出最佳权衡：相对细粒度原子工具，任务完成提升 16.4%；相对单一单体工具，提升 33.6%；同时参数准确率接近翻倍。模型规模与任务完成仅弱相关，与时延强相关，而与参数准确率的关联则不够稳健；在最优粒度上，一个 3.2B 模型的表现优于粒度不匹配时的 20.9B 模型。这些发现表明，工具接口粒度是基于 MCP 的智能体的一项关键设计参数。

关键词： 模型上下文协议，工具接口粒度，LLM 智能体，本地人工智能，资源感知基准测试

I 引言

大语言模型（LLM）正越来越多地被用作智能体系统的推理核心。这些系统把 LLM 规划与外部工具使用结合起来，例如调用 API、读取传感器数据、与服务交互，从而把决策落实到可执行上下文中 [1, 2, 3, 4]。这一转变要求有标准化接口，使智能体能够可靠地发现、调用并协调外部工具。模型上下文协议（Model Context Protocol，MCP）[5] 已迅速成为把 LLM 智能体连接到此类能力的事实标准。MCP 服务器把工具暴露为具名操作，基于 LLM 的客户端在运行时把这些工具的模式加载进模型上下文，从而发现它们。然而，MCP 并未规定接口如何设计：同一能力既可以暴露为许多原子工具、若干任务级函数、读/写拆分，也可以暴露为单一单体工具。因此，工具接口分解是每一位 MCP 服务器开发者都必须做出的显式设计决策。

这一决策在实践中很重要，因为智能体工具的功能分解——包括工具数量与抽象层次——会直接影响智能体如何选择工具并填充其参数。在现代应用设计中，“接口塑造使用者成功”这一原则已经确立。API 可用性研究表明，抽象层次、命名与可发现性会显著影响开发者如何使用软件接口 [6]。近期工作证实，同一原则对 LLM 智能体同样成立：专门构建的工具接口能大幅提升其表现 [7]，而可用工具集构成上的细微变化，甚至会动摇函数调用的稳定性 [8]。尽管已有这些证据，主流工具使用基准主要评估模型能否正确选择并调用工具 [9, 10, 11]。类似地，面向 MCP 的基准 [12, 13] 把工具接口视为固定不变，只评估模型能否成功使用它。

因此，这些基准忽视了工具功能分解所扮演的角色。它们没有把同一能力集合的接口分解——例如工具数量、抽象层次与参数结构——作为首要实验因素加以系统变化。对云端 LLM 而言，这一遗漏可能不那么显眼，因为它们往往无需精细的接口设计也能取得较强的工具使用表现。然而，当增大模型规模不可行时，工具接口就成为开发者少数可用的设计参数之一。这一点在边缘侧尤为相关：LLM 智能体越来越多地用于物联网与信息物理应用，并受严格的时延、能耗与内存约束 [14]。在这些场景中，工具调用常常中介与本地传感器、执行器及设备的交互，而固定硬件通常限制了可行的 LLM 规模。

在此类部署中，接口分解成为边缘侧托管 LLM 智能体的一个实用设计旋钮。细粒度接口暴露许多语义更清晰的专用工具，但增加了模型必须推理的选项数量，以及必须组合的调用序列。粗粒度接口简化了工具选择，但要求智能体通过更少的工具、更大且更复杂的参数模式来编码更丰富的操作意图。这些权衡使工具接口粒度成为边缘侧托管 LLM 智能体的一个有实质影响的因素，对性能、稳健性与能耗都有可度量的效应。这促使我们建立一个受控基准，使研究者与 MCP 开发者能够在任务语义与执行环境保持固定的前提下，比较同一能力集合的不同接口分解。

在本工作中，我们研究工具接口粒度如何塑造受约束环境中模型规模与性能之间的关系，并做出三项贡献：（i）我们提出 MCP-GRANITE，一个开源 [15]、可扩展的基准，用于对 MCP 工具接口分解进行受控比较。它包含 9 个边缘/物联网领域的 81 个场景，每个场景在 4 个粒度级别上实例化；（ii）我们对 9 个本地部署模型（参数量从 268M 到 20.9B）开展系统实证，表明粒度级别 3 的接口（4 个工具）始终优于细粒度（级别 4，8–10 个工具）与高度合并（级别 1–2，1–2 个工具）的方案，过度合并导致 28.2% 的 L1 运行在未调用任何工具的情况下即告完成；（iii）我们提供结合功能指标与 GPU 利用率、功耗监测的规模与资源感知分析，表明模型规模与任务完成弱相关（ρ = 0.285），与时延强相关（ρ = 0.946），而与参数准确率的关联（ρ = 0.686）则不够稳健。我们的结果显示，处于最优粒度级别的 3.2B 模型优于粒度不匹配的 20.9B 模型，证实接口设计可以压过模型规模。

II 相关工作

随着工具增强型 LLM 走向成熟 [4, 3, 16, 10]，基准沿两条并行轨道发展。第一条评估函数调用的正确性：从带有层次化指标的小型工具集，发展到伯克利函数调用排行榜（Berkeley Function Calling Leaderboard，BFCL）[9]——它对 100 多个模型在并行与嵌套调用上排名——再到 ToolBench [10] 与 ToolSandbox [11]，它们把多步推理扩展到真实世界与有状态 API。第二条轨道在交互环境中评估更广泛的智能体能力，涵盖操作系统交互、网页任务与软件工程 [17, 18, 19]。更近一些，面向 MCP 的基准开始评估模型能否在运行时可靠地发现并调用 MCP 服务器所暴露的工具。MCP-Universe [12] 表明，即便前沿模型在 231 个真实世界 MCP 任务上的成功率也只有 43.7%；MCPGAUGE [13] 则得出结论：MCP 增强并不一律提升性能。ToolPlanner [20] 与 MTU-Bench [21] 也变化了它们所谓的“粒度”，但在这两种情形中，粒度指的是用户指令的具体程度或评估场景的复杂度，而不是工具本身如何被组织。这些工作共同提高了评估的真实性，但它们共享一个假设，即工具接口大体上是预先定义的，所测量的只是模型相对该接口的能力。

此外，API 可用性研究早已表明，抽象层次、命名与可发现性会塑造人类开发者学习并使用软件接口的有效程度 [6]。随着从既有 API 自动生成 MCP 服务器的流水线变得可用 [22]，这些问题变得更加重要，因为原始 API 中的设计问题可能被直接转移到面向智能体的工具接口上。专门构建的工具接口，例如 SWE-agent [7]，相较通用替代方案能大幅提升 LLM 智能体的表现；而即便加入语义相关的工具，也可能动摇函数调用 [8]。近期研究进一步表明，工具描述是一块关键的设计表面：对描述进行学习式改写可提高智能体在未见工具上的准确率 [23]，而描述上的小幅编辑却可能不成比例地改变工具选择，暴露出智能体行为的脆弱性 [24]。在边缘约束下，这些观察更为重要，因为内存、时延与能耗预算限制了更大模型的使用 [14]。既然小语言模型可以在边缘支持函数调用，当模型扩规模不可行时，工具接口就成为关键设计旋钮；同时，可用工具的数量会影响智能体性能与能耗 [25]。因此，这些结果确立了一点：服务器暴露什么、以及它如何把功能呈现给智能体，并不是背景条件，而是对智能体行为有可度量效应的设计变量。尽管如此，尚无现有基准把同一组经 MCP 暴露的能力的粒度作为首要实验因素加以系统变化，尤其是针对资源约束现实条件下可本地部署的模型。

图 1： MCP-GRANITE 架构

III MCP-GRANITE 框架

MCP-GRANITE 通过把工具接口分解当作核心设计变量，填补上述缺口。它被实现为一条受控的执行与评估流水线（图 1），把工具接口分解与实验规约、工具模拟、智能体执行、监测以及结果汇聚分离开来。一份 YAML 配置由配置解析器解析为目标模型、场景提示，以及决定暴露给智能体的接口的、按领域与粒度区分的工具定义。这些定义被转发到模拟服务器实例化器，后者为每个粒度级别启动一个容器化的 MCP 模拟服务器；每个服务器在相同领域逻辑之上暴露不同的工具模式，并返回固定响应，从而使评估受控且可重复。

在目标边缘设备上，智能体服务运行于容器化环境中，提供可移植、与架构无关的执行基底。依据解析后的配置，该服务从 HuggingFace 获取指定的 LLM 权重，并把模型加载为智能体的推理核心。一个 MCP 连接器把智能体的工具调用路由到对应的模拟服务器。随后，负载生成器按顺序提交场景提示，记录每次交互的起止时间戳与完整响应。在整个执行过程中，监测模块收集 GPU 利用率、内存使用与功耗等指标。这些指标被转发到支持后处理阶段按时间范围查询的时序后端。

执行完成后，评估引擎把每条轨迹与对应场景及粒度级别所定义的黄金标准解答进行比较。依据观察到的工具调用、参数值、调用顺序，以及任何失败或超时，它计算第 IV 节所定义的功能指标。利用记录下的执行区间，引擎从监测后端取出选定的资源指标，并与轨迹级结果整合。引擎输出一份评估报告，同时刻画智能体的功能行为及其底层资源足迹，使 MCP-GRANITE 能够跨模型、领域与工具粒度支持可复现、资源感知的基准测试。

III-A 粒度建模与实验规约

MCP-GRANITE 的核心设计变量是工具接口粒度级别，它控制同一组领域操作如何被划分成经 MCP 暴露的工具。这些级别系统采样了 API 与服务设计中所公认的粒度谱 [26]，并沿两个维度定义：对智能体可见的工具数量，以及每次调用必须编码的操作意图的多少。各粒度级别的工具在框架内创建，细节见第 IV 节与第 V 节，代码见我们的仓库 [15]。用户可以增加领域、场景与粒度设计来扩展该基准，同时保留同一套受控比较方法。每个级别都被实现为覆盖同一底层领域逻辑的另一种工具暴露模块，而不是自动生成的。然后，用户通过基于 YAML 的场景模型指定场景，如图 2 所示。每个场景文件包含一段自然语言提示，以及按粒度给出的黄金标准；黄金标准定义完成该任务所需的期望工具调用序列与参数。所有级别使用同一用户提示，从而把工具接口粒度的效应与任务复杂度隔离开来。

为说明各粒度级别背后的理由，考虑一个智能家居场景（图 2）：要求智能体启动夜间安防协议。这需要把客厅设为夜间模式、锁门、开启带夜视的摄像头录制、检查前门传感器、查看事件，并创建自动化规则——若晚上 11 点之后有门被打开则触发警报。MCP-GRANITE 跨越四个粒度级别（L4 到 L1），把同一功能逐步合并为更宽泛的工具。

id: smarthome-007

domain: smarthome

difficulty: hard

user_prompt: Activate the full night security protocol.

Set the living room to night mode, lock all doors, enable

camera recording with night vision, check front door sensor,

review recent events, and create a rule that sounds the

alarm if any door opens after 11pm.

gold_standard:

 L4: # 8 expected calls using Level-4 single-purpose tools

 - tool: set_device

 arguments: { device_id: "DV003", settings: {...} }

 - tool: read_sensor

 arguments: { sensor_id: "SN005" }

 - tool: create_automation_rule

 arguments: { name: "Night door alarm", ... }

 # ... 5 more calls

 L3: # 3 expected calls using Level-3 task-level tools

 - tool: set_room_mode

 arguments: { location: "living room", mode: "night" }

 - tool: get_room_status

 arguments: { location: "front door" }

 - tool: manage_automation

 arguments: { action: "create", ... }

 L2: # 5 expected calls using Level-2 query/control tools

 - tool: smart_home_control

 arguments: { action: "set_mode", ... }

 - tool: smart_home_query

 arguments: { action: "sensor_reading", ... }

 # ... 3 more calls

 L1: # 5 expected calls using the Level-1 monolithic tool

 - tool: smart_home

 arguments: { action: "set_mode", ... }

 - tool: smart_home

 arguments: { action: "sensor_reading", ... }

 # ... 3 more calls

图 2： 智能家居场景摘录。

在级别 4（L4），开发者为每个操作设计一个专用工具（例如 set_device、read_sensor 等）。该粒度级别暴露 8–10 个单一用途的原子工具（智能家居场景中为 8 个），因此智能体必须在许多候选中做出选择，但每次调用只需要少量、直截了当的参数。这类似于细粒度的 CRUD（创建、读取、更新、删除）API，其中每个函数只执行一个动作。

级别 3（L3）采用任务类分组，把工具组织为任务级粒度，例如 set_room_mode 与 manage_automation。在我们的基准中，L3 把工具分为四个功能类别：状态查询、动作执行、配置与分析。在这一级别，智能体在更少的工具中选择，但每次调用必须同时指定目标实体与期望操作，因而需要更复杂的参数。这类似于面向资源或聚合端点，相关操作被归到同一接口之下。

在级别 2（L2），接口缩减为两个工具，采用读/写分离。例如，在智能家居场景中，接口包含 smart_home_query 与 smart_home_control，把读操作与写操作分开。原先编码在工具名中的操作被移入显式的 action 参数，例如 action: "set_mode"，因此大部分操作意图现在位于参数模式之中，参数复杂度上升。这类似于命令查询职责分离（Command-Query Responsibility Segregation，CQRS），即分布式系统中把数据检索与状态修改分开的标准模式。

最后，级别 1（L1）引入单入口设计，暴露一个单体工具，所有操作都通过它访问。在我们的场景中，单一的 smart_home 工具处理一切。工具名不承载操作含义，智能体必须完全通过参数来编码操作类型、目标实体以及全部参数。这类似于外观模式或 API 网关模式：单一接口依据请求参数把调用分派到内部逻辑。

四个级别沿着合并谱画出一条有原则的路径。L4 按单个操作分离，L3 按任务类分离，L2 按数据流方向分离，L1 则取消一切分离。这产生非单调的难度剖面：合并减轻了工具选择负担，但逐步加重了参数构造负担。此外，在我们的配置中，黄金标准按每个粒度级别分别定义，使基准能够在每个级别上评估正确的工具选择与参数准确率。例如，L4 所需的 8 次细粒度调用在 L3 可能收缩为 3 次调用，而 L1 仍可能需要对同一单体工具反复调用。因此，合并可能减少所暴露的工具数量，但不一定减少所需调用次数，从而把接口规模与任务执行长度区分开来。

models: [llama-3.2, granite-4, gpt-oss, xlam-2, qwen-3, ...]

domains: [agriculture, robotics, energy, industrial, ...]

granularities: [L4, L3, L2, L1] # Level 4 to Level 1

repetitions: 3

# Agent-level controls

max_agent_turns: 10

agent_timeout_seconds: 360.0

temperature: 0.0

max_tokens: 4096

图 3： 实验配置。

最后，一次实验由单个 YAML 文件（图 3）指定，其中声明被评估的模型、目标领域、粒度级别与重复次数，以及智能体级控制项。智能体级控制项定义每个任务允许的最大工具使用步数、执行超时、调节输出随机性的采样温度，以及每次模型响应的最大生成长度。在内部，框架枚举模型 × 领域 × 粒度 × 场景的完整笛卡尔积，并按配置的重复次数执行每一种组合。

IV 实现细节

MCP 服务器实现： MCP 模拟服务器实现为 FastMCP 服务器 [5]，使框架能够在保持实验控制的同时，模拟真实的基于 MCP 的工具交互。实现采用分层设计，把领域表示、状态管理与工具暴露分开。在最底层，每个领域定义一组类，描述服务器所操纵的实体，例如农业中的传感器、医疗中的患者，或车队管理中的车辆。在这一层之上，每个领域提供一组函数，封装其业务逻辑，并在维护领域状态的内存存储上操作（例如当前传感器读数、设备配置与运行状态）。随后，工具暴露层通过相互独立的服务器模块实现，每个粒度级别一个模块。在全部四个级别上，底层领域逻辑与数据存储保持相同。唯一的差别在于暴露给智能体的工具的模式与抽象层次，从而保证工具接口粒度是唯一的实验变量。为确保可复现性，存储以确定性测试数据初始化，使同一场景的重复执行观察到相同条件。为防止跨运行干扰，智能体运行框架为每个实验条件启动一个全新的 MCP 服务器容器，确保运行之间没有状态残留，且每个场景都从一个干净、确定的环境开始。

智能体服务： 智能体服务负责实例化被评估的 LLM，并中介它与基于 MCP 的工具环境之间的交互。该服务的一个关键性质是工具发现在运行时动态进行：每个会话开始时，智能体通过 MCP 的 tools/list 方法获取可用工具列表，而不是依赖静态定义或硬编码的规约。这紧密反映了真实的 MCP 部署：智能体必须适应当时所连接服务器在执行时暴露的工具模式，而不是在一个固定、预先配置的接口上操作。该服务使用 Google 的智能体开发套件（Agent Development Kit，ADK）[^1] 实现，由 McpToolset 负责与 MCP 服务器通信，由 LiteLLM[^2] 为模型推理提供统一抽象。这一组合使同一条基准流水线能够通过共同的、兼容 OpenAI 的接口评估多种 LLM，而无需修改编排逻辑。因此，不同模型家族与规模可以在相同的交互工作流下、以完全相同的动态发现工具模式进行比较，从而在所有模型上保证可复现的执行协议。

评估与利用率指标： 为评估智能体表现，每次执行都与该工具粒度级别所定义的黄金标准解答进行比较。令 \(G\) 表示工具调用的黄金序列，\(\hat{G}\) 表示智能体产生的序列。工具选择 F1 在所调用工具名的多重集上计算，忽略顺序。精确率是预测工具调用中与 \(G\) 中工具匹配的比例，召回率是在 \(\hat{G}\) 中被找回的黄金工具调用的比例，F1 是二者的调和平均。参数准确率（Argument Accuracy，ArgAcc）衡量：在按序列顺序对齐同一工具的预测调用与黄金调用之后，被正确产生的、所要求的黄金参数键值对所占比例。缺失的调用、参数或不匹配的值都计为不正确。任务完成（Task Completion，TC）是二元指标：当所执行轨迹按照黄金标准的状态与输出条件满足场景目标时为 1，否则为 0。置信区间（CI）在按模型平均之后，使用 2,000 次模型级自助重抽样。相对 L4 的比较使用配对重抽样，并在 9 项检验上做 Benjamini–Hochberg 校正。

我们还报告稳健性与效率指标。零工具调用率是智能体在未调用任何工具的情况下即返回最终答案的运行所占比例。错误率覆盖因解析错误、非法工具调用、运行时异常或模式违规而终止的运行，超时率覆盖超出执行预算的运行。效率通过挂钟时间、工具调用次数，以及每个成功任务的能耗来衡量；聚合结果的能耗计算方式为：由平均 GPU 功率与执行时间估计的 GPU 总能量，除以完成的任务数。由于评估使用受控的模拟服务器，这些测量刻画的是智能体侧执行，而不是真实物联网部署的端到端时延或能耗。为捕获平均 GPU 功率，我们在边缘节点上部署了使用 Prometheus 与 NetData 的监测栈[^3]，并辅以自定义的 nvidia-smi 包装器，以 5 秒间隔采样。

除这里报告的指标外，框架还收集更广泛的轨迹级与资源指标，包括词元计数、冗余调用率，以及节点级资源遥测，例如 GPU 利用率、内存、功耗、温度等。由于篇幅限制，我们聚焦于与粒度分析最相关的 GPU 利用率、功耗与挂钟时间（第 V-D 节）。

V 实验评估

我们在 9 个物联网领域上实例化 MCP-GRANITE，这些领域组织为三个应用方向 [14]：工业自动化（工业、机器人、仓储）、智能环境（智能家居、监控、能源），以及现场作业（农业、车队、医疗）。每个领域由一个内存数据存储来操作化，其中保存智能体与之交互的实体，例如传感器、设备、患者或车辆，每个实体由固定 ID 标识（例如 SN005、DV003）。对每个场景，黄金标准指定每个粒度级别上期望的工具调用序列及其参数。这些黄金标准通过在存储上实际运行并确认达到正确的最终状态来核验。场景按所需工具调用次数与不同实体数量分为三个难度档：简单（1–2 次调用，单一实体）、中等（4–5 次调用，2–3 个实体）与困难（9–10 次调用，4 个及以上实体）。9 个领域各自在每个难度档贡献 3 个场景，得到均衡设计下的 81 个场景。完整场景定义与基准构建细节公开于本文仓库 [15]。

我们评估九个模型，参数量从 268M 到 20.9B（表 I），通过 Ollama[^4] 提供服务。所选模型既包括通用模型，也包括函数调用变体。量化方式因模型而异：FunctionGemma 使用 8 位，xLAM-2 使用 3 位，Qwen3 使用 6 位，GPT-OSS 使用 MXFP4（分块缩放的 4 位），其余五个使用 4 位。这些选择会影响各模型的表现，因为更高位宽的量化保留更多权重保真度，但增加内存占用与推理时间。全部实验运行于一台具备 GPU 的边缘工作站：NVIDIA Tesla T4、16GB 显存、128GB 内存以及多核 CPU，代表边缘服务器或网关级部署 [14]。我们的全因子设计组合了 9 个模型、9 个领域、4 个粒度级别、9 个场景与 3 次重复，得到 8,748 次运行（每个模型 972 次）。最后，每种配置采用与图 3 相同的智能体级控制项。

V-A 总体模型表现

表 I 汇总了全部场景上的平均表现。Qwen3（14.8B）取得最佳表现，任务完成为 0.762，F1 为 0.857，参数准确率为 0.531，但时延为 164.5 秒；这由其庞大的参数量以及内置推理能力驱动，后者会在每次调用之前产生延长的思考轨迹。Llama3.2（3.2B）是次优模型，任务完成达到 0.579，F1 为 0.760，仅用 6.7 秒且零错误，比 Qwen3 快 24.5 倍，同时保留其约 76% 的任务完成。Mistral-Nemo 的表现也具有竞争力，任务完成为 0.488，F1 为 0.676，错误率低至 1.9%。相比之下，GPT-OSS 与 xLAM-2 的错误率非常高，分别为 55.6% 与 52.8%，尽管它们规模更大。GPT-OSS 是混合专家（Mixture-of-Experts）模型，总参数 20.9B，但每次前向传播仅激活约 3.6B。其错误主要由畸形的工具调用输出与模式违规主导。xLAM-2 采用激进的 3 位量化，表现出类似的结构化输出失败，尤其是当工具模式在运行时被发现、而不是静态提供时。在另一端，FunctionGemma 是最快的模型，为 2.9 秒，但其表现仍远低于更强的模型。

表 I： 模型总体表现。TC 附 95% 置信区间。F1、ArgAcc 为均值 ± 标准差。G / G+T / G+C / FC = 通用 / +思考 / +对话 / 函数调用。Calls = 每场景平均工具调用次数。

要点： 模型规模并不是工具使用表现的可靠预测因子。Qwen3 取得最高准确率，但 Llama3.2 提供更好的效率–稳健性权衡；而 GPT-OSS 与 xLAM-2 表明，更大的模型或函数调用模型并不能泛化到动态工具接口。

图 4： 按模型与级别 L1–L4 划分的任务完成

V-B 工具接口粒度的效应

在几乎所有模型上，代表适度合并的 L3 都是最有效的粒度配置（图 4），在 9 个模型中的 8 个上取得最高任务完成。唯一的例外是 Mistral-Nemo，其 L4 略优。L3 的任务完成达到 0.49，相对 L4 提升 +16.4%，相对 L1 提升 +33.6%，二者均由未四舍五入的均值计算（表 II）。其零工具调用率略高于 L4（10.7% 对 10.2%），表明 L3 并非改善每一项单独指标。它也给出最高的参数准确率（0.40）以及 0.66 的 F1，同时缩短执行时间。配对自助检验确认 L3 的提升是显著的（表 II）。为核验这一点，我们拟合了包含模型规模、量化、领域与难度的逻辑回归，确认 L3 独立地将完成几率提高 1.36 倍（CI [1.12, 1.66]，p = 0.002），而 L1 将其降低 22%（p = 0.009）。

相比之下，完全合并的 L1 设定大幅劣化表现：任务完成降至 0.36（相对 L4 为 −12.9%），零工具调用率从 L4 的 10.2% 升至 28.2%（表 II）。把接口塌缩为单一单体工具，迫使模型在每次调用中于多种动作类型之间选择，并填充更大的模式。这一效应在较弱模型（FunctionGemma 与 xLAM-2）上最为明显，但也降低了 Granite4 与 Hermes3 的任务完成，证实过度合并以执行可靠性为代价来简化接口。

表 II： TC、F1、ArgAcc 为来自 2,000 次模型级自助重抽样的均值 [95% CI]。粗体 = 最佳。†：相对 L4，p < 0.05；‡：相对 L4，p < 0.01（经 BH 校正的配对自助法）。

表 III： 按模型规模类别划分的粒度效应。单元格为 <8B 与 ≥8B 两组，以 \|\| 分隔。

参数准确率从合并中获益最为一致。从 L4 到 L3，平均准确率接近翻倍，从 0.20 到 0.40（提升 +99.5%）。L2 同样保持高位，为 0.38（相对 L4 为 +85.8%）。适度合并减轻了工具辨识负担，并帮助模型构造更准确的参数。任务完成也在 9 个模型中的 8 个上改善，表明 L3 的优势可以泛化。

工具选择 F1 上出现更细微的模式。尽管任务完成在 L3 达到峰值，最高的平均 F1 却由 L2 取得（0.71，相对 L4 为 +20.8%）。这很可能反映了该粒度上更小的决策空间：在两个宽泛工具之间选择，比在四个或更多专用工具之间选择更容易。相比之下，L1 相对 L4 的 F1 优势很小（+6.7%），且在配对自助比较下并不显著（表 II），因此把接口塌缩为单一工具并不能保住适度合并所带来的 F1 增益。L2 更高的 F1 并没有转化为最高的任务完成，因为成功执行依赖于在所选工具之内准确指定参数。这表明仅有正确的工具选择是不够的，参数构造仍然是瓶颈。这与函数调用评估相一致：它们把选择正确性与参数准确率区分开来，并发现二者可以独立失败 [9, 13]。

要点： 以 L3 进行的适度工具合并是最有效的设计选择，在任务完成、参数准确率与时延之间给出最佳平衡。过度合并增加失败，并证实主要瓶颈是参数构造，而不是工具选择。

V-C 规模分析

图 6 把每个模型画在其取得最高任务完成的粒度级别上，并对照相应的挂钟时间。三个模型定义了帕累托前沿：FunctionGemma（3.1 秒，TC = 0.21）、Llama 3.2（6.6 秒，TC = 0.61）与 Qwen 3（167 秒，TC = 0.79），其余模型都至少在一个轴上被支配。在被支配的模型中，Hermes 3 与 Granite 4 最接近前沿，以中等时延提供有竞争力的任务完成。相比之下，GPT-OSS 与 Ministral 3 付出高得多的挂钟时间，却没有成比例的收益，进一步说明仅凭模型规模并不能决定最佳的边缘部署权衡。

图 5： 最佳任务完成对时间（对数刻度）

图 6： 平均挂钟时间对模型规模（双对数）。

图 7： 按模型与级别 L4–L1 划分的平均 GPU 利用率。

图 8： 按模型与级别 L4–L1 划分的平均 GPU 功耗。

在所评估的九个模型之内，参数量与参数准确率及时延的关联，强于与任务完成的关联。参数量与参数准确率正相关（ρ = 0.686，p = 0.041），表明在该样本中较大模型的参数准确率更高；与挂钟时间的关联更强（ρ = 0.946，p < 0.001）。例如，平均执行时间从 FunctionGemma 的 2.9 秒增加到 Qwen3 的 164.5 秒，增幅为 56 倍。图 6 进一步表明，在双对数刻度上，时延大致随参数量线性增长，但有两处例外：Qwen3 因延长的推理轨迹而更慢；GPT-OSS 则快于其 20.9B 参数所暗示的水平，因为其 MoE 架构每次前向传播只激活约 3.6B 参数。作为敏感性检验，排除 Qwen3 与 GPT-OSS 后，参数准确率的关联降至 ρ = 0.360（p = 0.427），而时延关联仍然很强（ρ = 0.991，p < 0.001）。相比之下，参数量与任务完成仅弱相关且不显著（ρ = 0.285，p = 0.458），表明仅靠规模并不能决定端到端的智能体成功。

为考察工具接口粒度是否依赖于模型规模，表 III 把模型分为小型（<8B）与大型（≥8B）。两者都从适度合并中受益，L3 取得最佳任务完成。小型模型的增益略高，为 17.7%，大型模型为 15.0%。在 L2，小型模型提升 6.8%，大型模型下降 2.5%，提示较小模型从缩小的工具选择空间中获益更多，而较大模型更能利用 L3 所保留的结构。L1 使两组都劣化，证实过度合并在各种规模上都有害。这些趋势也可能反映量化与训练差异，因为 FunctionGemma 使用 8 位量化，而 xLAM-2 使用激进的 3 位量化，后者可能降低结构化输出的可靠性。因此，这些规模关联是描述性的，不应脱离量化、架构与工具使用对齐来独立解释。

要点： 仅凭模型规模，很难预测端到端的智能体成功。它最清晰的关联是与时延，而观察到的与参数准确率的关系则不够稳健。较小模型似乎对工具接口设计更敏感，并从适度合并中获益更多。

表 IV： L3 下每个任务的焦耳数。功率、时间与 J/任务为均值 ± 标准差。TC 给出其 95% 置信区间。

表 V： 效率（每秒 TC，均值 ± 标准差），按模型与粒度。粗体 = 该模型的最佳粒度。

V-D 资源利用与能效

图 8 与图 8 汇总了各模型与各粒度级别上的 GPU 利用率与功耗。两项指标主要由模型规模驱动：GPU 利用率从 FunctionGemma 的 8–17% 到 Qwen3 的 96–97%，而 GPU 功率的上升更为温和，大约从 40W 到 69W。功率随规模次线性增长：Qwen3 大约比 FunctionGemma 大 55 倍，但功耗只高出 1.7 倍，因为较小模型使 GPU 计算能力处于空闲。显存占用由已加载的模型权重主导，因此跨粒度级别变化很小。

粒度对利用率的影响主要出现在 GPU 未饱和时。对大模型，各级别之间的利用率变化不到 3%；较小模型则波动更大（例如 FunctionGemma 从 L4 的 8.3% 升至 L2 的 17.6%）。每个模型的 GPU 功率变化至多约 5W。因此硬件成本由模型选择主导，粒度则调制未饱和的边缘模型。

为评估端到端效率，我们由平均 GPU 功率与挂钟时间计算每个成功任务的 GPU 能量（表 IV）。Llama3.2 是最有利的工作点，在 L3 下为 621 J/任务，而 Qwen3 需要 14,544 J/任务，成本高出 23 倍。FunctionGemma 看似有竞争力（618 J/任务），但只完成 20.6% 的任务，因此其能量有很大一部分浪费在失败任务上；Llama3.2 消耗相近的能量，却多完成 3 倍的任务。更大的模型以不成比例的时间与能量成本换取能力提升，而中等规模模型提供最佳权衡（表 V）。

要点： 资源与能效由模型选择驱动，粒度是次要因素。由于功率随规模次线性增长，更长的执行时间主导了能耗。粒度主要影响未饱和的小型与中型模型。

V-E 领域难度与失败分析

图 9 显示模型与领域两方面都有强烈变化：Qwen3 在大多数领域上表现最好，而医疗（0.202）与机器人（0.244）的平均完成最低，工业（0.608）与能源（0.596）最高。尽管存在这些差异，工具选择 F1 保持稳定（0.614–0.667），表明模型通常能识别正确的工具，但在多步推理与参数构造中失败。这一模式在场景层面同样成立：任务完成从 0.852（warehouse-001）到 0.009（healthcare-003），但即便最难的场景也能达到中等 F1（0.596–0.671）。在全部 8,748 个条件中，13.6% 以错误结束，1.3% 超时。失败高度依赖模型：GPT-OSS 与 xLAM-2 的错误率分别为 55.6% 与 52.8%，而 Llama3.2 与 Hermes3 为零。工具接口粒度也影响稳健性：L3 的错误率最低（11.4%），其次是 L4（12.9%）、L2（14.1%）与 L1（15.8%）。L1 的劣化主要由零工具调用行为驱动（占 L1 条件的 28.2%）：模型或者在不调用任何工具的情况下幻觉式地宣称完成，或者退回到与 MCP 模式不匹配的、记忆中的工具名。

图 9： 按模型与领域划分的任务完成

要点： 智能体表现的限制，较少来自工具辨识，更多来自可靠的动作排序。L3 提供最稳健的行为，而 L1 产生的是质变式崩溃，而不是渐进劣化。

VI 结论与未来工作

MCP-GRANITE 是一个可扩展的开源框架，用于研究 MCP 工具接口粒度；它在基于 T4 的平台上、以受控的模拟服务器响应，跨 9 个模型与 9 个边缘/物联网领域进行了评估。适度合并（L3，4 个任务类工具）表现最好：相对细粒度工具，任务完成提升 16.4%；相对单体接口，提升 33.6%，主要途径是更高的参数准确率。较小模型受益最多，而硬件成本主要由模型选择驱动：在 L3，一个 3.2B 模型每个成功任务的能耗比表现最好的 14.8B 模型低 23 倍。过度合并使任务完成降低 12.9%，且 28.2% 的 L1 运行不调用任何工具。总体而言，我们的实验结果支持紧凑的、具有任务语义的接口，并支持在部署之前评估不同的粒度方案。

我们的未来工作将把基准扩展到真实 MCP 服务器、更广泛的模型与边缘硬件覆盖，并利用所收集的指标来建模接口复杂度如何影响智能体行为，以及形式化工具粒度设计。

致谢

本工作由 Pharos-CY 共同资助，资金来自 EuroHPC JU（拨款协议号 GA：101263007），并得到欧盟“地平线欧洲”计划与塞浦路斯共和国政府的支持；同时得到欧盟委员会通过 AI-DAPT 项目的资助（HORIZON-CL4-2023-HUMAN-01-01，GA：101135826）。语言经 ChatGPT 润色；全部内容与思想归作者本人。

参考文献

参考文献列表从略。原文引用编号 [1]–[26] 在正文中保留。

[^1]: https://google.github.io/adk-docs/ [^2]: https://github.com/BerriAI/litellm [^3]: https://prometheus.io/ 与 https://www.netdata.cloud/ [^4]: https://ollama.com/

署名与许可

• 原文：MCP-GRANITE Benchmark: GRANularity Interface TEsting for MCP-Based LLM Agents
• 链接：https://arxiv.org/abs/2609.24161
• 原作者：Demetris Paschalides、Moysis Symeonides、George Pallis、Marios D. Dikaiakos（塞浦路斯大学计算机科学系，尼科西亚，塞浦路斯）
• 许可：CC BY 4.0
• 译者：智测团队