多工具编排能力评测方法

可视化演示

展示Agent多工具编排的链路规划指标、编排正确性评估与并行串行效率对比，切换模式查看各评测维度核心方法。

场景设计：给指挥家一份总谱

乐团评委拿到演出季安排时，第一件事不是听彩排，而是看总谱。总谱里写着哪个乐章需要长笛、哪个段落需要定音鼓、哪里需要弦乐与木管呼应。没有总谱，指挥家只能即兴发挥，评委也无法判断他到底是高手还是运气好。

AI 评测里，场景设计就是给 Agent 写一份“任务总谱”。你不能只丢给它一句“给我做个行程规划”，而是要把任务抽象成剧本：用户真实目标是什么？需要调用哪些工具？这些工具之间是否有依赖关系？比如“查北京天气并计算是否适合户外跑步”，就同时依赖天气查询工具和计算器，且天气结果要先于计算器出现。依赖关系建模越清晰，后面评分就越有依据。

在构建基准测试集时，还要加入难度分级。最简单的是线性链路：搜索一个词、返回一句话；中等的是分支链路：根据用户位置决定调天气接口还是地图接口；困难的是循环与异常恢复：工具调用失败后，Agent 能否换一条路径继续完成目标。难度梯度决定了评测集能区分出“只能独奏”和“能指挥全乐团”的模型。

总谱越厚、声部交错越复杂，越能看出指挥家的真实调度功力。场景设计正是用同样的思路，把不同复杂度的“乐谱”放进评测集里。

工具链路：看清乐手之间的传谱顺序

指挥家必须清楚长笛吹完这段旋律后，下一个接棒的是双簧管还是圆号。若是没有传谱顺序，整支乐团会同时发出噪音。多工具编排中，“工具链路”就是乐手之间的传谱顺序。

工具链路通常被定义成一张有向图：节点是工具，边是数据或控制流。比如一个订机票的 Agent，可能要先调登录接口拿身份令牌，再用令牌查航班，最后调支付接口完成下单。令牌没有拿到就去查航班，就是典型的链路结构错误。节点依赖关系决定了一个工具能否在另一个工具之前被调用，这是评测最基本的是非判断。

评测时，不能只记录 Agent 最终说了什么，还要完整记录它的执行轨迹：每一步调了哪个工具、传了什么参数、拿回了什么结果。基于参考链路和实际轨迹，可以计算规划路径指标，比如路径有效率，用来衡量预测轨迹中有多少步骤真正符合任务要求。

一个合格指挥家不仅要选对乐手，还要让乐手们按正确顺序接棒。工具链路的评测，就是在捕捉“谁先谁后、谁给谁传谱”这些过程信息。

编排指标：给指挥打出量化分数

评委手里有一张评分表，不是凭感觉打“很棒”或“一般”，而是分维度量化。多工具编排评测同样需要一套清晰的编排指标，才不会让模型的好坏变成玄学。

工具选择准确率看“有没有找对人”：正确调用集是任务必须用到的工具，实际调用集是 Agent 调用的工具，两者交集占正确调用集的比例越高，说明它没有漏掉关键乐手。顺序正确率看“有没有排对队”：即使工具选对了，先调支付再查库存依然会出错。参数正确率看“指令是否传到位”：同样调搜索工具，查询词写错也会让整个任务失败。总体成功率则是“整首曲子是否完整演完”，通常要求每一步结果都满足参考答案才算成功。

评分表上每一项都握住一根指挥棒，只看其中一个指标，就像只凭“曲子没断”就判断指挥完美，显然不够严谨。

正确性评估：不只问“到没到终点”

如果乐评人等到最后一个音符结束才鼓掌，多半会漏掉中间大量的错音。多工具编排也一样，只看任务最终有没有完成，很容易放过“中途折腾了很久才侥幸成功”的模型。

正确性评估采用步骤级评判：它把标准答案拆成一个个步骤，再与 Agent 的实际动作逐一比对。比对不是要求文本逐字相同，而是看工具名、关键参数、前置条件是否语义等价。关键路径判定则会给某些决定性环节更高权重：比如支付接口是否在库存确认之后调用，这一点比“先查询天气还是先查询日历”重要得多。

与此同时，还要记录容错与恢复表现：某个工具调用失败后，Agent 是卡死、重试，还是改走备用工具？这能反映真实业务场景中最宝贵的“临场救场”能力。

正确的编排评估既要听到最后一个音符，也要确认每个乐句是不是按总谱演奏。步骤级评判就是那个坐在台下逐小节打分的乐评人。

评测流程：像乐团排练一样可重复

同一支乐团在不同夜晚演出，状态可能有波动，但评委不能因此给出完全不同的分数。评测流程的意义就是让过程可复现、标准统一，像乐团的固定排练流程一样。

一个标准的多工具编排评测流程包含四个环节。第一是评测环境搭建：把模型接入一个可控沙箱，外部工具全部用 Mock 服务替代，避免真实接口波动污染结果。第二是模型调用采集：自动把任务输入给 Agent，记录它每一轮的工具调用、参数和返回结果。第三是自动评分执行：用预设的参考答案和指标脚本对采集到的轨迹打分，不依赖人工感觉。第四是结果汇总输出：把单任务得分聚合成任务成功率、各维度平均分等。

为了判断整套评测体系是否稳定，我们通常还会同时记录多个模型在同一批任务上的表现，用同一个评分脚本跑分。这样就避免了“换个人打分，结果就不一样”的尴尬。

固定排练流程，才能把不同指挥家放在同一把尺子上比较。评测流程越标准化，结果的可信度和横向可比性就越高。

结果分析：从成绩单找到薄弱乐手

演出结束后，评委还要写出评语：问题不在开头，而在第二乐章定音鼓迟迟没有进入。结果分析就是这份“评语”，它的目标不只是给出总分，而是找到 Agent 到底弱在哪一环。

结果分析常用三种手段。第一是失败模式聚类：把所有失败轨迹按出错位置、错误类型归类，看看是“选错工具”多，还是“参数缺失”多。第二是瓶颈环节定位：计算每个工具步骤的条件失败率，找出最容易让任务中断的薄弱环节。第三是能力雷达图：把工具选择、顺序、参数、恢复能力画成多个维度，直观看到模型的长板与短板。最后，所有这些分析会汇入评测报告，为模型迭代提供依据。

下一次排练时，指挥家就会重点加练那位总是迟到的定音鼓手。结果分析的意义，正是让评测从“给个分数”升级为“给出改进方向”。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-class ToolChainEvaluator:    """多工具编排评测：选择、顺序、参数与总分的简单实现"""     def __init__(self, reference, w_sel=0.4, w_ord=0.3, w_par=0.2, w_suc=0.1):        self.ref_items = list(reference)        self.need_tools = set(item["tool"] for item in self.ref_items)        self.w_sel = w_sel        self.w_ord = w_ord        self.w_par = w_par        self.w_suc = w_suc     def selection_score(self, calls):        used = set(item["tool"] for item in calls)        if not self.need_tools:            return 0.0        return len(self.need_tools & used) / len(self.need_tools)     def parameter_score(self, calls):        used_args = {item["tool"]: item.get("args", {}) for item in calls}        hit = 0        for item in self.ref_items:            key = item["tool"]            if key in used_args and used_args[key] == item.get("args", {}):                hit += 1        return hit / len(self.ref_items)     def order_score(self, calls):        ref_seq = [item["tool"] for item in self.ref_items]        pred_seq = [item["tool"] for item in calls]        lcs = self._lcs_len(ref_seq, pred_seq)        return lcs / max(len(ref_seq), len(pred_seq))     def task_success(self, calls):        return self.parameter_score(calls) >= 1.0 - 1e-9     def total_score(self, calls):        sel = self.selection_score(calls)        ord_ = self.order_score(calls)        par = self.parameter_score(calls)        suc = 1.0 if self.task_success(calls) else 0.0        return self.w_sel * sel + self.w_ord * ord_ + self.w_par * par + self.w_suc * suc     def _lcs_len(self, a, b):        m, n = len(a), len(b)        dp = [[0] * (n + 1) for _ in range(m + 1)]        for i in range(1, m + 1):            for j in range(1, n + 1):                if a[i - 1] == b[j - 1]:                    dp[i][j] = dp[i - 1][j - 1] + 1                else:                    dp[i][j] = max(dp[i - 1][j], dp[i][j - 1])        return dp[m][n]  if __name__ == "__main__":    reference = [        {"tool": "search", "args": {"query": "北京天气"}},        {"tool": "calculator", "args": {"expr": "rain_prob * 0.6"}},        {"tool": "report", "args": {"format": "markdown"}}    ]    prediction = [        {"tool": "search", "args": {"query": "北京天气"}},        {"tool": "report", "args": {"format": "markdown"}},        {"tool": "calculator", "args": {"expr": "rain_prob * 0.6"}}    ]     ev = ToolChainEvaluator(reference)    print("selection: %.2f" % ev.selection_score(prediction))    print("order: %.2f" % ev.order_score(prediction))    print("parameter: %.2f" % ev.parameter_score(prediction))    print("total: %.2f" % ev.total_score(prediction))

1. self.need_tools = set(item["tool"] for item in self.ref_items)把参考链路中必须出现的工具转成集合，方便后续算交集。
2. used = set(item["tool"] for item in calls)提取 Agent 实际调用过的工具集合，用于计算选择准确率。
3. used_args = {item["tool"]: item.get("args", {}) for item in calls}以工具名为键保存实际参数，便于逐参数比对。
4. lcs = self._lcs_len(ref_seq, pred_seq)计算参考顺序和预测顺序的最长公共子序列，衡量顺序还原度。
5. return len(self.need_tools & used) / len(self.need_tools)工具选择准确率等于“命中的必需工具数”除以“必需工具总数”。
6. dp[i][j] = max(dp[i - 1][j], dp[i][j - 1])经典动态规划递推，在状态转移中保留最长公共子序列长度。
7. return self.w_sel * sel + self.w_ord * ord_ + self.w_par * par + self.w_suc * suc加权合成总分，便于对不同 Agent 做横向比较。

常见误区

面试题