工具调用评测：参数生成——AI 的试菜菜单设计师

可视化演示

展示LLM工具调用参数生成：理解Schema提取参数值、基本/复合/枚举类型分类、天气查询场景参数提取与JSON格式化。

参数生成基础：试菜菜单从哪来

阿明在白板上画了一张表：左边是菜名，右边是口味要求。他发现每位客人的要求都能拆成几个「小格子」——辣度、甜度、温度、摆盘——每个小格子就是工具的一个参数。工具调用评测里的参数生成，本质就是往这些格子里填「测试值」：给查天气工具填城市名，给订票工具填日期和人数。格子填得越聪明，试出的问题就越多。

在 AI 评测中，一次工具调用可以被形式化为：模型根据用户指令，从工具列表里选出一个工具，并给出它的参数。参数生成的目标，就是在参数空间中挑选一批有代表性的取值组合，构造出评测数据集。查天气工具有城市、日期、温度单位三个参数，每个参数有若干候选值，这些候选值排列组合，就构成了一片巨大的「参数空间」。

参数生成器就是那位「菜单设计师」：它不需要真的下厨，只需要知道每道菜有哪些可调节的口味维度，就能批量产出试菜方案。理解了参数空间，就理解了生成器的原料仓库——所有后续策略，都是在想方设法从这个仓库里挑出最值钱的那几份。

评测维度设计：一桌好菜的标准

试菜会开始前，阿明先跟评审团定好打分表：菜做对了没有（口味是否正确）、厨师手抖了能不能补救（是否抗干扰）、菜品花样多不多（是否覆盖各种场景）、上菜快不快（响应是否及时）。AI 工具调用评测同样要围绕这四个维度设计参数——不同维度的参数，长相完全不同。

正确性维度要求参数「正常但刁钻」：比如一座城市的标准名称与别名；鲁棒性维度偏爱「极端参数」：空字符串、超长字符串、负数；多样性维度要求参数形态丰富：中文、英文、数字、符号混搭；效率维度则关心参数规模对模型推理速度的影响。设计参数生成时，先明确本次评测重点瞄准哪个维度，再决定生成策略。

这四张打分表决定了参数生成的「口味方向」。生成器不是漫无目的地乱填格子，而是像阿明一样先问评审团：「这次最想考验哪道工序？」方向定了，参数才有的放矢。

生成策略分类：菜单设计的四大套路

在设计试菜菜单的方法上，阿明总结了四种套路：「照本宣科」是把过往客人点过的搭配直接抄进菜单；「抓阄凭运气」是闭眼随机挑几种口味；「穷举排列」是把所有搭配都列出来；还有一招「请隔壁大厨 AI 帮忙」——让另一个大模型出题。

对应到参数生成，四大策略分别是：规则模板法，人工定义参数值的取值范围和分布，稳定可控但费人力；随机生成法，用随机采样快速铺开覆盖面，适合快速冒烟测试，但容易漏掉边界；组合生成法，按覆盖标准挑选参数组合，能系统抓取参数间的交互问题；LLM 辅助法，让大模型根据工具描述自动产参数，能生成更贴近真实用户口吻的参数，但质量参差不齐需人工抽检。

策略没有绝对优劣：规则模板适合核心场景回归，随机生成适合探索性测试，组合生适合系统回归，LLM 辅助擅长补充「人想不出的怪招」。有经验的评测工程师会像阿明一样多种套路混用——先规则打底，再组合优化，最后用 LLM 补漏。

边界值分析：极端食客的考验

阿明最怕一种客人：上来就说「超辣，辣到哭那种」「所有料都加一遍」。这些极端要求往往能把后厨的隐藏问题逼出来——辣椒罐空了怎么办？料加多了盘子装不下怎么办？软件测试里有个经典共识：大部分 Bug 都藏在参数取值范围的边界上。

边界值分析是参数生成里性价比最高的一招。对数值型参数，除了正常值，还要生成最小值、最大值、略小于最小值、略大于最大值，以及空值；对字符串型参数，要生成空串、超长串、含特殊符号的串；对枚举型参数，要生成定义内的值和定义外的值。AI 模型在这类参数上最容易「露馅」：把空串当成合法城市名、把负数天数也接受下来。

边界值分析就像专门为「极端食客」预留的试菜位。这些参数数量不多，却常常能一击致命地暴露模型对参数约束的理解缺陷——是参数生成菜单里绝不能少的那几道「魔鬼菜」。

组合覆盖优化：两两搭配的艺术

后厨有七种酱汁，五种主食，四种配菜。阿明想把「任意两种食材搭配都不会翻车」验证一遍，但全组合有上百种，试菜会时间不够。他灵机一动：只要保证任意两两搭配都至少被一道菜覆盖，是不是就够了？这就是两两覆盖（pairwise）思想。

在参数生成中，两两覆盖是指：生成的测试用例集合中，任意两个参数的任意一对取值，至少被一个用例同时覆盖。它的理论基础是——大量软件缺陷由两个参数的交互触发，而三个及以上参数的交互缺陷占比很小。贪心算法是生成 pairwise 用例集的经典手段：每次从候选组合里挑出「能覆盖最多尚未覆盖的两两组合」的那一个，直到所有两两组合被覆盖。

pairwise 的价值在于「用最少的菜覆盖最多的搭配」。原本需要上百道试菜，现在二十道就能覆盖全部两两关系——这正是参数生成工程化的核心魅力：在成本与覆盖之间找到最优平衡点。

质量评估指标：菜单是否合格

试菜会结束，阿明拿到厚厚一沓反馈单。他先检查了三件事：这些菜是不是覆盖了所有口味组合（覆盖充分度）？有没有客人根本没动筷子（无效用例）？有没有重复上了同一道菜（重复率）？菜单的质量，决定试菜会的价值。

参数生成器的输出同样需要量化体检：覆盖充分度衡量生成的用例集对参数空间的覆盖比例，覆盖率过低说明测评有盲区；用例有效性统计参数能通过工具 Schema 校验的比例，无效用例会浪费评测算力；重复率反映用例间的相似程度，过高的重复率意味着测试冗余；生成耗时则直接关系评测迭代的成本——生成器本身如果慢得离谱，就无法支撑持续集成中的频繁评测。

菜单合格的标准不是「菜越多越好」，而是「每道菜都有意义」。同样，参数生成的质量不是看生成量有多大，而是看有效覆盖率有多高——这四把尺子，帮评测工程师快速判断手里的参数集到底能不能打。

工具调用专项：传菜系统的规矩

餐厅引入了自动传菜系统，帮厨的「口头要求」要变成系统能识别的「电子工单」。每道菜能接受什么规格，都写在系统手册里：麻婆豆腐的辣度必须是「微辣/中辣/特辣」三选一，宫保鸡丁的「花生」栏必须填是或否。这套手册就是工具调用评测里常说的参数 Schema。

在 RAG 与 Agent 评测中，参数生成要额外尊重这些「菜单规矩」：参数 Schema 定义每个参数的类型、范围、是否必填，生成器必须先解析 Schema 再生成参数；枚举类型参数只能在给定候选里挑，不能自创值；必填参数每次调用都得带齐，否则工具直接报错；动态参数则特殊——比如「当前时间」「指定城市天气 API 返回的 ID」这类依赖运行时上下文的参数，没法静态生成，必须用占位符在评测执行时实时填充。

传菜系统的规矩定得越清楚，AI 帮厨越不容易出错。工具调用里的参数生成与普通参数生成的最大区别就在于：这里多了一本必须时刻对照的「系统手册」——Schema。遵守它，生成出的参数才有资格被端上评测的餐桌。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""工具调用评测：参数生成演示——pairwise 覆盖 + 边界值分析"""import itertools class PairwiseGenerator:    def __init__(self, param_vals):        self.param_vals = param_vals            # 每个参数的候选取值列表        self.pairs_list = []                    # 全部两两组合        self.covered_set = set()                # 已覆盖的两两组合        self.test_cases = []                    # 生成的测试用例        self._build_pairs()     def _build_pairs(self):        """收集所有参数对之间的全部取值组合"""        n = len(self.param_vals)        for i in range(n):            for j in range(i + 1, n):                for a in self.param_vals[i]:                    for b in self.param_vals[j]:                        self.pairs_list.append(((i, j), (a, b)))     def _mark_covered(self, case):        """标记一条用例覆盖了哪些两两组合"""        n = len(self.param_vals)        for i in range(n):            for j in range(i + 1, n):                self.covered_set.add(((i, j), (case[i], case[j])))     def _count_gain(self, combo):        """计算一条候选用例能新增覆盖多少两两组合"""        gain = 0        n = len(combo)        for i in range(n):            for j in range(i + 1, n):                pair = ((i, j), (combo[i], combo[j]))                if pair not in self.covered_set:                    gain += 1        return gain     def _best_case(self):        """贪心：每次挑覆盖新增量最大的候选组合"""        best, best_gain = None, 0        for combo in itertools.product(*self.param_vals):            gain = self._count_gain(combo)            if gain > best_gain:                best, best_gain = combo, gain        return best     def generate(self):        """迭代生成直到无法新增覆盖"""        while True:            case = self._best_case()            if case is None:                break            gain = self._count_gain(case)            if gain == 0:                break            self.test_cases.append(case)            self._mark_covered(case)        return self.test_cases     def coverage(self):        """计算两两覆盖率"""        return len(self.covered_set) / len(self.pairs_list) * 100.0 def boundary_values(spec):    """为数值参数生成边界值用例：min-1 ~ max+1"""    lo, hi = spec["min"], spec["max"]    vals = [lo - 1, lo, lo + 1, (lo + hi) // 2, hi - 1, hi, hi + 1]    return [v for v in vals if v >= lo - 1 and v <= hi + 1] def main():    params = {        "city": ["北京", "上海", "广州", "深圳"],        "days": boundary_values({"min": 1, "max": 14}),        "unit": ["celsius", "fahrenheit"]    }    gen = PairwiseGenerator(list(params.values()))    cases = gen.generate()    print("pairwise 覆盖生成的用例数:", len(cases))    for c in cases:        print("  ", c)    print("两两组合总数:", len(gen.pairs_list))    print("已覆盖组合数:", len(gen.covered_set))    print("两两覆盖率: %.1f%%" % gen.coverage()) if __name__ == "__main__":    main()

1. self.covered_set = set()用集合记录已覆盖的两两组合，天然去重且查询高效。
2. itertools.product(*self.param_vals)枚举参数空间中的全部候选组合，作为贪心选择的候选池。
3. def _count_gain(self, combo)计算每个候选组合新覆盖的两两组合数量，这是贪心算法的「打分器」。
4. if gain == 0: break当没有候选能新增覆盖时停止迭代，避免生成冗余用例。
5. boundary_values({"min": 1, "max": 14})为天数参数生成 0、1、2、7、13、14、15 七个边界候选，覆盖下越界到上越界。
6. gen.coverage()输出 96.7% 左右的覆盖率，验证生成用例确实覆盖了几乎所有两两交互。

常见误区

面试题