工具调用错误恢复评测：给 AI 主厨的“救场”能力打分

可视化演示

展示自然语言处理中的完整流水线：从原始文本到分词、嵌入、模型推理直至输出结果的逐阶段流动过程。

错误类型识别

后厨的“翻车”各有各的翻法。主厨按下烤箱开始键，烤箱毫无反应——这是“工具罢工”；设定 200 度，面板却显示“200度！”，机器直接报错——这是“指令被误解”；烤到一半迟迟没有完成提示——这是“迟迟不答”；冰箱明明返回了一串数据，却是一堆乱码——这是“答非所问”。救场之前，主厨必须先搞清楚：到底是设备坏了，还是自己操作错了，还是沟通出了问题。

AI 智能体调用外部工具时，失败同样不是同一种病。业界把工具调用错误归纳为四类典型：参数异常（调用时缺字段、类型不对、格式非法，相当于把“200 度”说成“200度！”）、工具不可用（服务宕机、接口 404、鉴权失败，相当于设备压根没通电）、执行超时（工具没在约定时间内返回，相当于烤箱半小时没反应）、返回格式错（工具返回了但结构破损、解析失败，相当于设备吐出一张乱码小票）。这四类错误的成因不同，对应的恢复动作也完全不同，所以评测的第一步永远是“分诊”。

为了量化“分诊”的观察结果，我们可以把总错误率拆成四类互斥子事件的概率之和：

分清故障类型，就像主厨先判断“是设备坏了还是自己按错了”，才能决定是拍两下重试，还是直接换一台设备。评测时如果把这四类错误混成一锅粥，后面的恢复策略和指标都会失去意义。

场景构建方法

品控主管不会等真实后厨着火才考验主厨，而是会精心“埋雷”：故意把某台烤箱的温控调偏、在化冻鸡肉里混入一块生肉、暂时屏蔽网络让订菜系统失联。这些雷埋在哪个环节、密度多大、大概多久爆一次，都要写进演练方案。评测场景构建，就是这场“埋雷演习”的沙盘设计。

具体来说，构建评测场景有四件套：故障注入是最核心的手法——通过 mock 服务、代理拦截或环境变量，按预设比例注入四类错误；任务设计要把工具调用装进端到端任务里，比如“查询订单并生成对账单”，保证一次任务内出现多次调用、多个失败机会；环境控制要求固定随机种子、隔离外部依赖、使用沙箱，保证同一套雷埋下去，每次引爆的时间点都一样；数据分布则规定四类错误在测试集中的占比，尽量贴近线上真实的故障分布，避免评测偏向某个角落。

为了衡量“雷埋得够不够全”，我们引入故障覆盖率：

埋雷要有章法：雷的数量、位置、种类记录在案，主厨考出来的成绩才能跨版本对照、被他人复现。否则今天埋三颗、明天埋十颗，报告上的分数根本没有可比性。

恢复策略分类

熟手主厨都有自己的救场打法：按钮没反应，先吸口气再按一次；显示温度格式不对，重新输入一遍；这台烤箱彻底罢工，改用旁边的备用烤箱；火势失控，立刻大喊店长。每一种动作对应一类故障，也对应 AI Agent 的一种恢复策略。

在工具调用错误恢复里，策略分为四档：直接重试最适合瞬时抖动与超时，但要注意配合指数退避，否则重试风暴会压垮下游服务；参数修正是让 Agent 从错误信息中提取线索（比如“缺少参数 city”），补全或改对参数后重新调用；备选方案是在原工具不可用时切换到功能等价或降级工具，保证任务链不断；人工介入是兜底策略，当自动恢复多次失败时主动放弃或转交人类，避免无限空转浪费 token。评测时，我们要观察 Agent 面对不同错误是否会“对症下药”。

衡量“救场是否成功”，最核心的是恢复成功率：

策略之间不是越花哨越好，而是要与错误类型匹配：超时适合重试，格式错适合修正参数，工具宕机必须换备选。一个只会无限重试的 Agent，就像一个只会反复按同一个按钮的主厨，遇到设备真坏了照样出不了菜。

指标设计体系

评委给一桌菜打分，不光看“有没有上齐”，还会看“等了多久”“摔了几个盘子”“浪费了多少食材”。AI 评测也一样：只报一个最终成功率，会把救场过程的笨拙与昂贵全部掩盖。指标设计体系，就是给救场能力配一套多维度的“成绩单”。

这套成绩单至少包含四个维度：恢复成功率回答“错误最终有没有被纠正”；重试效率回答“纠错过程轻不轻巧”；任务成功率回答“端到端目标有没有达成”；代价衡量回答“为了恢复多花了多少成本”，包括额外 token、额外调用次数、时延增加。四个维度合在一起，才能全面刻画一个 Agent 的鲁棒性。其中重试效率可以用平均重试次数表达：

任务成功率则是从任务层面收口：

一桌菜全部按时上齐才算赢，但中途救场太多次、摔了太多盘子，评委一样会打低分。这就是为什么成绩单上既要写“成没成”，也要写“快不快、贵不贵”。

评测流程实施

一场规范的厨艺品控，要提前定好菜单、架好摄像机、记录每道菜出锅时间，最后给出书面品控报告。评测流程实施，就是把救场能力的考核变成一套可重复、可追溯的标准化动作，而不是灵机一动的抽查。

标准流程分四步：基线建立——先在无故障模式下把任务完整跑一遍，得到“黄金成绩”，作为所有对比的标尺；用例生成——按“错误类型 × 工具 × 触发条件”矩阵批量生成调用用例，保证四类错误都有代表；结果记录——把每次调用的状态、重试链、耗时、错误详情结构化成 trace，像后厨录像一样完整留痕；对比报告——把故障模式下的成绩与基线对比，输出指标表、失败案例分析与改进建议。为了量化恢复过程中的额外开销，流程中常计算调用放大率：

没有记录的真实救场叫“事故”，有记录、有对比的才叫“经验”。评测流程的意义，就是把每一次救场都变成可追踪的数据资产，让下一次迭代有据可依。

鲁棒性评估

一次考试过关不算真本事。晚市高峰期，后厨同时来十桌客人，设备还坏了一半，主厨能否照样出菜？鲁棒性评估要回答的正是这个问题：不是“偶尔能救场”，而是“在刁难不断升级时依然稳定”。

鲁棒性评估要做四件事：故障密度扫描——把错误占比从 0%、10%、30% 一路抬到 50%，画出“成功率-故障密度”衰减曲线，看 Agent 在哪个密度点开始崩盘；覆盖广度——用错误类型和工具的笛卡尔积铺满矩阵，保证没有一个角落被遗忘；压力测试——并发任务、超长调用链同时压上来，看恢复策略是否出现雪崩；回归对比——每次模型或策略升级后，在同一故障矩阵上重跑一遍，防止“修好 A 处弄坏 B 处”。综合这些表现，可以用鲁棒性得分来概括“抗跌能力”：

鲁棒性不是单次考试及格，而是把各种刁难变成日常之后依然稳定。一个真正可靠的主厨，不是从不遇到设备故障，而是晚市再忙、坏得再多，也能端出稳定的一桌菜。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""工具调用错误恢复评测模拟器"""import random  class KitchenTool:    """模拟一个厨房工具(外部API), 按概率产生不同错误"""     def __init__(self, name, fail_rate=0.3, timeout_chance=0.2):        self.name = name        self.fail_rate = fail_rate        self.timeout_chance = timeout_chance     def call(self, param=None):        """调用工具, 返回 (成功?, 结果或错误消息)"""        r = random.random()        if r < self.timeout_chance:            return False, "timeout: 设备响应超时"        if r < self.timeout_chance + self.fail_rate:            return False, "error: 参数格式不正确"        return True, "ok"  class ChefAgent:    """带错误恢复策略的Agent(主厨)"""     def __init__(self, tools, max_retries=2):        self.tools = tools        self.max_retries = max_retries        self.retry_count = 0        self.fallback_count = 0     def run_task(self, tool_names):        """按顺序调用工具, 遇到错误自动重试或切换备选"""        total_calls = 0        success_calls = 0        for name in tool_names:            _, total_calls, success_calls = self._call_with_recovery(                name, total_calls, success_calls            )        return total_calls, success_calls     def _call_with_recovery(self, name, total_calls, success_calls):        for _ in range(self.max_retries + 1):            total_calls += 1            ok, msg = self.tools[name].call()            if ok:                success_calls += 1                return True, total_calls, success_calls            self.retry_count += 1        # 重试耗尽后尝试备选工具        fallback = self.tools.get("backup")        if fallback and name != "backup":            self.fallback_count += 1            total_calls += 1            ok, msg = fallback.call()            if ok:                success_calls += 1        return False, total_calls, success_calls  def evaluate(agent, tasks, repeat=50):    """评测: 跑多轮任务, 统计恢复成功率与重试效率"""    total_tasks = len(tasks) * repeat    task_ok = 0    total_calls = 0    total_retries = 0    for _ in range(repeat):        for task in tasks:            calls, _ = agent.run_task(task)            total_calls += calls            total_retries += agent.retry_count            agent.retry_count = 0            if calls <= len(task) + 2:                task_ok += 1    report = {        "任务成功率": round(task_ok / total_tasks, 3),        "平均调用次数": round(total_calls / total_tasks, 2),        "平均重试次数": round(total_retries / total_tasks, 2),    }    return report  def main():    random.seed(42)    tools = {        "oven": KitchenTool("oven", fail_rate=0.3, timeout_chance=0.1),        "fridge": KitchenTool("fridge", fail_rate=0.1, timeout_chance=0.05),        "backup": KitchenTool("backup", fail_rate=0.05, timeout_chance=0.02),    }    agent = ChefAgent(tools, max_retries=2)    tasks = [["oven", "fridge"], ["oven"], ["fridge", "oven", "fridge"]]    report = evaluate(agent, tasks, repeat=100)    for k, v in report.items():        print(f"{k}: {v}")  if __name__ == "__main__":    main()

1. class KitchenTool:模拟一个外部工具接口，每次调用都按概率产生超时或参数错误。
2. def call(self, param=None):一次工具调用的核心入口，返回布尔成功标志与消息。
3. class ChefAgent:带恢复策略的主厨 Agent，内部记录重试与备选次数。
4. ok, msg = self.tools[name].call()发一次真实调用，拿到成功与否的结果。
5. self.retry_count += 1每失败一次记一次重试，供后续指标统计。
6. fallback = self.tools.get("backup")重试耗尽后寻找备选工具，对应“备选方案”策略。
7. total_retries += agent.retry_count汇总所有任务的重试总次数，用于计算平均重试次数。

常见误区

面试题