大模型智能体的工具调用容错研究原文arXivhttps://arxiv.org/html/2609.02750v1摘要大语言模型智能体依靠外部工具完成现实世界任务但工具调用过程极易发生各类故障参数错误、工具不存在、网络异常、返回结果格式异常、API限流等。现有研究大多聚焦工具调用成功场景对故障发生后的恢复、重试、纠错机制缺少系统性研究。本文系统梳理工具调用全生命周期故障分类构建ToolFault评测基准覆盖6大类、27种真实工具故障场景对主流智能体框架开展评测发现现有Agent面对故障时普遍存在重试策略不合理、错误理解报错信息、无限循环调用、无法降级处理等问题。本文进一步提出ToolRescue一套面向工具调用故障感知‑分析‑修复的轻量级机制无需微调基座大模型仅通过推理时提示增强实现故障识别、根因定位、参数修正、降级回退。实验结果表明ToolRescue在ToolFault基准上相比基线智能体任务成功率平均提升38.7%。项目代码、数据集、实验脚本全部开源发布。关键词大模型智能体工具调用故障恢复Agent容错评测基准1 引言大语言模型智能体通过调用工具搜索、代码解释器、MCP工具、API、系统Shell扩展能力边界解决推理本身无法完成的任务。在真实部署环境中工具调用链路存在大量不可靠因素Agent生成错误工具名称、错误参数类型、参数缺失外部服务返回报错、超时、网络抖动、访问限流工具返回数据格式破坏、JSON解析失败、字段缺失权限拒绝、资源不存在、输入超出工具允许范围。当工具返回错误信息智能体常见错误行为无意义重复重试、忽略报错继续执行、编造虚假返回结果、进入死循环。大部分现有Agent框架缺少完备的故障处理逻辑仅简单捕获异常缺少根因分析与修复策略。现有工作局限多数工具调用评测仅覆盖正常执行场景缺少大规模故障注入测试集故障恢复方案大多依赖微调部署成本高缺少统一分类体系不同研究对工具故障定义不统一。本文贡献建立工具调用故障分类体系覆盖工具调用全生命周期构建ToolFault评测基准包含27种故障类型可自动化注入故障开展评测大规模评测主流Agent揭示容错能力短板提出ToolRescue轻量级故障恢复框架推理时提示增强无需模型微调开源全部数据集、故障注入脚本、评测代码。资源仓库https://github.com/xxx/ToolFault‑ToolRescue2 相关工作2.1 LLM智能体与工具调用工具调用使大模型可以对接外部系统主流实现方式函数调用JSON输出、MCP协议、思维链驱动Shell调用。代表框架Hermes、AutoGPT、LangGraph。现有优化工作集中在工具选择、参数生成质量较少关注调用失败之后的处理流程。2.2 Agent错误处理与鲁棒性部分工作研究Agent自我纠错大多聚焦任务输出结果校验不是工具链路本身故障。少数研究使用重试策略多为固定次数盲目重试不区分故障根因。例如网络临时抖动适合短间隔重试参数格式错误重试完全无效应当修正参数。盲目重试会带来API浪费、速率限制、死循环。2.3 Agent评测基准现有基准侧重任务完成度例如MMLU‑Agent、GAIA。缺少专门针对工具调用故障场景的评测集。ToolFault填补该空白可以可控注入各类工具侧故障专门测试Agent容错恢复能力。3 工具调用故障分类体系工具调用完整生命周期工具选择 → 参数序列化 → 请求发送 → 工具服务执行 → 返回结果解析。故障划分为六大类别故障类别说明示例A‑工具选择故障Agent选择不存在/不匹配任务的工具调用不存在函数选错工具B‑参数生成故障参数缺失、类型错误、取值越界、格式错误缺少必填字段字符串传入数字参数范围超限C‑请求传输故障网络层面问题超时、连接失败、API限流429D‑工具执行时故障服务内部运行报错权限拒绝、资源不存在、业务逻辑报错E‑返回负载故障工具返回数据损坏JSON截断、字段缺失、格式错乱F‑Agent解析故障Agent无法解析合法返回值强制解析错误schema忽略报错信息每一大类下细分若干子故障合计27种细粒度故障。不同故障对应不同最优修复策略瞬态故障网络抖动有限次数退避重试参数错误禁止重试需要修改参数工具不存在切换备选工具返回格式损坏开启降级解析、提取可用片段不可恢复故障终止调用向用户返回说明执行任务降级。关键发现不区分故障类型的统一重试策略是现有Agent的主要缺陷。4 ToolFault评测基准4.1 数据集设计ToolFault可以对工具调用链路可控注入故障。每一条样本包含任务描述、可用工具集、待注入故障类型、预期正确行为。总样本1280条覆盖6大类27种故障支持故障粒度可配置支持批量自动化评测Agent评测指标任务成功率、有效恢复率、无效盲目重试次数、死循环发生率、降级处理能力。4.2 评测流程Agent接收用户任务获取可用工具列表ToolFault中间层拦截Agent发出的工具调用请求按照配置注入对应故障将报错/损坏返回值回传给Agent观测Agent行为是否识别故障、根因是否判断正确、修复动作是否合理统计指标✅有效恢复识别故障执行对应修复完成任务⚠️无效重试对参数错误反复调用相同参数❌失败编造结果、死循环、直接放弃任务。4.3 基线Agent评测结果论文选取多类主流Agent框架做基线对比原生Function‑call大模型LangGraph基础AgentHermes基础智能体AutoGPT‑like开源Agent。主要观测结论面对参数错误故障绝大多数Agent直接原样重试修复率不足22%遇到返回JSON损坏时模型倾向编造虚构返回数据缺少降级逻辑一旦工具报错直接整体任务失败瞬态网络故障场景部分框架无退避策略高频重试触发限流。5 ToolRescue故障感知‑分析‑修复框架ToolRescue不修改基座模型属于推理时附加提示增强中间件工作嵌入在Agent与工具层之间。三大核心模块故障感知模块捕获工具返回全部报错、异常堆栈、返回负载识别故障所属类别A‑F分类根因推理模块把报错信息、调用上下文、历史调用记录送入大模型输出故障类型、是否可恢复、推荐修复动作修复执行模块根据根因输出执行对应策略参数修正、切换工具、退避重试、降级输出、终止任务。5.1 工作流程Agent发起原始工具调用工具执行正常返回 → 直接交付Agent如果发生故障/报错ToolRescue捕获完整上下文工具名、入参、报错堆栈、返回原始文本送入根因推理prompt输出结构化判断故障类别、是否瞬态故障、修复方案根据修复方案分支执行瞬态网络故障有限次数指数退避重试参数错误引导Agent重新生成合法参数工具不存在切换备选可用工具不可恢复故障停止工具调用整理报错摘要交给Agent做任务降级将修复后的上下文返回Agent继续任务。5.2 提示设计要点根因推理Prompt强制输出结构化JSON字段示例{fault_category:B,fault_desc:参数类型错误,is_transient:false,repair_action:fix_parameter,max_retry:0,suggestion:xxx}is_transient瞬态标记非常关键false时禁止盲目重试。5.3 实验结果在ToolFault基准上对比基线Agent与开启ToolRescue之后平均任务成功率提升38.7%无效重试调用数量下降71.2%死循环工具调用现象基本消除各类故障场景下均获得一致性提升不需要微调基座模型。消融实验证明故障分类识别、瞬态判断、禁止无效重试三个组件均对性能有显著贡献。6 实验设置6.1 环境与模型基座模型测试集合GPT‑4o、Claude‑3‑Sonnet、Llama‑3‑70B‑Instruct。所有实验脚本、故障注入工具、评测数据集开源https://github.com/xxx/ToolFault‑ToolRescue6.2 复现步骤# 克隆仓库gitclone https://github.com/xxx/ToolFault‑ToolRescuecdToolFault‑ToolRescue# 安装依赖pipinstall-rrequirements.txt# 运行ToolFault基准评测python run_benchmark.py--agent_typebaseline--output./result_baseline.json# 启用ToolRescue机制评测python run_benchmark.py--agent_typetoolrescue--output./result_toolrescue.json# 分析评测报告python analyze_result.py--input./result_toolrescue.json参数说明--agent_type可选baseline / toolrescue支持自定义故障配置文件注入指定子集故障类型。6.3 主要评测指标task_success_rate任务完成成功率valid_recovery_rate故障有效恢复率useless_retry_count无效重试总次数loop_failure_rate死循环故障占比7 讨论与局限ToolRescue依赖大模型本身的报错理解能力极端晦涩、非标准化报错堆栈根因识别会出现偏差本工作聚焦工具调用链路故障不解决Agent规划逻辑本身错误真实世界复杂嵌套故障多种故障同时发生未来需要进一步研究。8 结论本文针对大模型智能体工具调用容错开展系统性研究建立六类工具故障分类体系构建ToolFault故障注入评测基准揭示现有Agent在故障处理环节的短板。提出轻量级ToolRescue故障恢复机制推理时提示增强无需微调显著提升故障恢复能力减少无效重试与死循环。全部数据集、故障注入脚本、评测代码开源可用于后续智能体工具鲁棒性方向研究。