Agent工具调用失败处理指南：从异常分类到容错兜底

最近有同学投稿，说自己去宇树科技一面时被问了一道题：Agent 调用工具失败如何处理。他当时下意识回答“重试、加日志、换成更稳定的接口”，结果面试官明显不满意，后面又追着问了好几个场景，越问越深，最后直接卡住。

这道题最近在 Agent 方向的面试里出现频率非常高，不只是宇树，很多做 AI 应用、Agent 平台、机器人控制、MCP 中间层的公司都会问。原因也很简单：Agent 工具调用失败在真实业务里几乎无法避免，它直接决定了一个 Agent 系统能不能从 Demo 走到生产环境。

表面上看，这道题问的是“异常处理怎么做”，但实际上考察的是你对 Agent 工具调用全链路的理解深度。工具调用从来不是一个简单的“请求第三方 API”动作，而是一条完整链路：模型判断该不该调工具 -> 生成工具名和参数 -> 框架解析参数并校验 -> 执行工具函数 -> 捕获运行结果 -> 把结果重新喂回模型进行下一轮推理。任何一个环节出错，最终都会表现为“工具调用失败”。如果你只会回答“在执行环节加 try/except”，那基本等于没有回答到点子上。

这篇文章就把这道题完整拆开：先从失败类型讲起，再给模型侧和工程侧的解决方案，最后加一段面向机器人场景的进阶思考，以及面试回答框架和追问准备。内容尽量信息密度高一点，不绕弯，读完之后你既能应付面试，也能把这套思路直接用到自己的 Agent 系统里。

1. 这道题在考什么

Agent 工具调用可以拆成五个环节，面试官问“工具调用失败如何处理”时，真正想听的是你能不能把这五个环节的失败场景都考虑到：

1. 意图识别与工具选择：模型根据用户输入判断是否需要调用工具，以及调用哪个工具。
2. 参数生成：模型生成工具所需的参数，以结构化对象输出。
3. 参数解析与执行：Agent 运行时把模型输出解析成函数调用，并执行实际的工具函数。
4. 结果回传：工具执行完，结果封装成消息返回给模型。
5. 循环决策：模型根据返回结果决定是继续调用下一个工具，还是直接生成最终答案。

如果回答只停留在一个“Try-Catch + 重试”，说明你默认失败只发生在第 3 步。但生产环境里，第 1 步模型可能选错工具，第 2 步参数可能不符合工具定义，第 4 步结果可能太长导致截断，第 5 步模型可能看到一个失败结果后无限循环。

所以这道题的高阶回答，需要覆盖四个层面：

• 失败类型层：先分类，再谈处理，不同类型失败的处理方式完全不同。
• 模型侧策略层：让模型“看到”失败结果并自我纠正，或者用提示词和工具定义减少选错概率。
• 工程侧策略层：重试、超时、熔断、降级、幂等、人工兜底。
• 监控与复盘层：失败日志、调用链追踪、指标统计、持续优化工具定义。

面试官听到你能把链路拆开讲，并且能区分“模型问题”和“工程问题”，就知道你真的做过 Agent 落地，而不是只会念八股。

2. 先给工具调用失败分类，这是回答的骨架

工具调用失败不是一种异常，而是一族异常。分类是面试回答的骨架，也是实际排查问题的基础。我建议按“发生在哪个环节”来分，这样不会漏项。

2.1 模型侧失败：工具选择与参数生成错误

这类失败发生在模型输出阶段，最常见的表现有：

• 该调用工具时没有调用：用户问“今天上海气温多少”，模型直接凭训练数据编了一个答案，没有触发工具调用。
• 调用了不存在的工具：模型幻觉出模型的输出是search_web，但注册中心只有web_search。
• 工具名正确，参数错误：工具要求city是字符串，模型传了一个对象；或者漏传必填参数。
• 参数语义错误：工具定义里unit字段只允许celsius和fahrenheit，模型传了C。
• 多工具并行调用时参数互相矛盾：比如一个 Agent 同时调用“查询订单状态”和“申请退款”，但两个工具使用同一个订单号，参数格式却不一致，导致一个成功一个失败。

模型侧失败的本质是“模型能力不足”或“工具定义不清晰”。这类失败不是靠重试能解决的，模型重试十次可能还是同样的幻觉。处理方向是修正工具声明、优化提示词、以及失败后把错误喂回模型让模型修正。

2.2 框架侧失败：解析、校验、上下文异常

这类失败发生在 Agent 运行时，常见情况：

• 模型返回的function_call对象缺少tool_call_id或参数不是合法 JSON。
• 参数通过 Pydantic/Schema 校验时失败，类型不匹配、枚举值非法、字符串超长。
• 工具数量过多，超过了上下文窗口，模型生成的调用超出了工具描述长度限制。
• 多轮调用后上下文过长，模型把之前的工具描述“忘了”，导致后续调用参数格式错误。
• 工具执行触发了框架内部的超时保护，进程被中断。

框架侧失败的解决方向更多依赖工程手段：更严格的 Schema 设计、统一的异常捕获结构、上下文裁剪、工具数量控制。

2.3 工具侧失败：业务异常、外部依赖、权限问题

工具本身是一个函数，函数执行过程中可能抛出任何异常：

• 工具内部依赖的数据库连接失败，比如查询用户信息时 MySQL 连接超时。
• 下游第三方 API 返回 500，或者接口响应超过工具设置的时间阈值。
• 调用外部服务时鉴权失败，比如 token 过期、API Key 没有权限、调用配额耗尽返回 429。
• 工具需要操作本地文件或资源，但磁盘已满、文件不存在、权限不足。
• 对于多模态或大规模计算工具，可能显存不足、GPU 进程被占用。

这类失败是最常见的“执行失败”，它和模型侧失败的处理策略不一样：可重试性高，但重试前要判断是否会造成副作用，比如重复扣款、重复发消息、重复删除数据。

2.4 结果侧失败：返回内容不能被正确消费

工具执行成功了，但结果无法被 Agent 正确使用，这也是失败：

• 工具返回内容过长，直接超出上下文窗口被截断，模型只看到了半份 JSON。
• 工具返回的是纯文本日志，模型无法从里面提取出结构化信息。
• 工具返回空结果，模型以为“没有查到这个数据”，实际上可能是查询条件写错了。
• 工具返回了错误码但没返回错误说明，模型不知道该不该重试。

结果侧失败在高并发 Agent 场景非常常见，中文大模型在处理超长 JSON 时尤其容易出现解析问题。

2.5 失败类型对照表

3. 从模型侧入手：让模型“看到失败并自己修正”

3.1 工具声明是第一步，也是最容易被忽略的一步

在定义 Function Calling 工具时，工具名、描述、参数描述直接影响模型的选择准确率。一个描述模糊的工具，模型就只能靠猜。

下面是一个常见的 Function Calling 工具定义，这里以 OpenAI 格式为例：

{ "type": "function", "function": { "name": "get_weather", "description": "查询指定城市当天和未来三天的天气情况，适合用户询问天气、温度、降雨概率时调用。当用户只问天气相关问题时使用，不要用于查询交通或路况。", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市中文名称，例如：北京、上海、杭州。必须是实际存在的城市。" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位，中国用户默认使用 celsius。" } }, "required": ["city"] } } }

这个工具声明看起来简单，但它包含三层信息：工具什么时候该用、参数怎么填、枚举值是什么。模型选错工具、填错参数的概率会明显降低。

3.2 失败后把错误信息回喂给模型，这是最关键的机制

很多人以为工具调用失败以后只能“重试”，实际生产里最有效的做法是：把工具执行失败的结构化错误信息，作为一个tool消息重新发送给模型，让模型根据错误自行调整参数、换工具或向用户说明。

伪代码逻辑如下：

# 第一次调用 response = llm.chat(messages=messages) tool_calls = response.tool_calls tool_call_id = tool_calls[0].id tool_name = tool_calls[0].function.name tool_args = json.loads(tool_calls[0].function.arguments) try: result = execute_tool(tool_name, tool_args) error = None except Exception as e: result = None error = str(e) # 把执行结果原样回传给模型 if error is not None: messages.append({ "role": "tool", "tool_call_id": tool_call_id, "content": f"工具执行失败，错误信息：{error}，请根据错误修正参数或换一个可用工具，不要重复使用相同参数。" }) else: messages.append({ "role": "tool", "tool_call_id": tool_call_id, "content": json.dumps(result, ensure_ascii=False) }) # 让模型基于工具结果继续生成 second_response = llm.chat(messages=messages)

这个模式在 ReAct 和 Agent 循环里都适用。模型拿到“参数 city 不存在”之后，通常会修正参数重新调用；如果拿到“API key 过期”这类错误，模型不会再盲目重试，而是能直接告诉用户需要重新授权。

回答面试题时点出这个机制，面试官会认为你对 Function Calling 的闭环有真实理解。

3.3 模型输出 JSON 解析失败时要能修复

工具调用参数如果不是严格的function_call对象，而是要求模型输出 JSON，那么解析失败的概率会更高。模型可能输出成以下形式：

这个参数是：{"city": "上海", "unit": "celsius"}

或者是：

{ "city": "上海", "unit": "celsius" }

第一段带了多余文字，第二段被 Markdown 的 json 代码块包裹。这时需要先用正则提取 JSON 主体，再做修复：

import json import re def extract_json(text: str): """ 从模型输出中提取 JSON 对象字符串。 如果解析失败，可以再调用一次 LLM 让模型只返回 JSON。 """ match = re.search(r"\{.*\}", text, re.DOTALL) if not match: raise ValueError("模型输出中未找到 JSON 对象") json_str = match.group() return json.loads(json_str)

更稳妥的方案是让模型使用结构化输出，或者限制模型输出格式。但工程上永远要留一条“解析失败后把错误喂回模型”的兜底路径。

3.4 减少模型侧幻觉的工具声明技巧

有几个实践能显著降低模型选错工具、填错参数的概率：

• 工具描述里写清楚“使用场景”和“禁用场景”，避免模型把一个工具用到别的场景。
• 参数描述里写清楚取值范围和示例值，能给枚举就给枚举。
• 功能相似的工具，在名称和描述中用差异词明确区分。
• 工具数量过多时，先做工具分组或工具路由，让模型在一个小范围内选择，而不是一次性面对 50 个工具。
• 对风险操作加“二次确认”约束，在 System Prompt 中说明这类工具执行前必须先向用户确认。

这些内容面试中随口说出两三个，就能体现出你的工程经验。

4. 从工程侧入手：重试、超时、熔断、幂等、兜底

模型侧优化只能降低失败概率，不能消灭失败。真正让 Agent 系统稳住的，是工程侧的整套容错机制。这一部分要从“执行器分层”讲起。

4.1 工具执行器的分层设计

一个生产级工具执行器，不能只是简单调用函数，至少要做四件事：前置校验、执行超时、异常分类、结构化错误回传。

import time import json import asyncio from dataclasses import dataclass, field from typing import Any, Optional @dataclass class ToolResult: success: bool data: Any = None error: str = field(default="") retryable: bool = field(default=False) class ToolExecutor: def __init__(self, timeout: int = 10): self.timeout = timeout self.registry = {} def register(self, name: str, func: callable): self.registry[name] = func async def execute(self, name: str, args: dict, request_id: str) -> ToolResult: if name not in self.registry: return ToolResult(success=False, error=f"工具 {name} 未注册", retryable=False) try: # 前置参数校验，可以在注册工具时配置 pydantic 模型 self._validate_args(name, args) # 执行超时控制 coro = self.registry[name](**args) result = await asyncio.wait_for(coro, timeout=self.timeout) return ToolResult(success=True, data=result) except asyncio.TimeoutError: return ToolResult(success=False, error=f"工具 {name} 执行超时", retryable=True) except Exception as e: retryable = self._is_retryable_error(e) return ToolResult(success=False, error=str(e), retryable=retryable)

这段伪代码不完整，但结构已经表达出来：工具未注册、参数校验失败、执行超时、业务异常，都被分类捕获，并且给每个错误打上了retryable标签。这个标签决定了后面的重试策略。

4.2 重试策略：先判断可不可重试

重试不是万能的，重试前必须回答一个问题：这个工具调用是否幂等？

如果工具是“查询天气”“计算价格”，重试是安全的。如果工具是“发送短信”“创建订单”“控制机器人移动”，盲目重试可能造成重复扣费、重复下单、重复动作。

正确做法是：

• 参数错误导致的失败不重试，直接回传给模型修正。
• 外部服务超时、网络抖动导致的失败，可以重试。
• 重试次数有上限，比如最多 2 次。
• 重试使用指数退避，第一次等 1 秒，第二次等 2 秒，避免在服务抖动时继续加压。
• 涉及副作用的工具，必须通过request_id做幂等控制。

一个带指数退避的重试代码如下：

import asyncio import time async def call_with_retry(executor, tool_name, args, request_id, max_retries=2): for attempt in range(max_retries + 1): result = await executor.execute(tool_name, args, request_id) if result.success: return result if not result.retryable: return result if attempt == max_retries: return result wait_time = 2 ** attempt await asyncio.sleep(wait_time) return ToolResult(success=False, error="重试次数用尽", retryable=False)

面试官如果追问“重试导致重复发送短信怎么办”，你就可以回答：在工具层做幂等设计，消费端用request_id去重，或者把重试改成“先查询状态，再决定是否重试”，这样工具本身就是幂等的。

4.3 超时与熔断

Agent 工具调用链条比较长，任何一个下游服务慢，都会拖慢整个 Agent 的响应时间。因此：

• 每个工具级网络请求必须有超时，推荐下游请求超时设置 3 到 5 秒，工具整体执行超时 10 到 15 秒。
• 如果同一个外部工具连续失败率达到阈值，比如 5 分钟内 50% 请求失败，要触发熔断，直接快速失败，不再发起真实调用。
• 熔断后要有恢复策略，可以使用半开状态，放少量请求探测下游服务是否恢复。

这个机制在回答时可以提“Circuit Breaker”，算是加分项，但要说清楚它解决的是“下游服务长时间故障时，避免 Agent 频繁做无效调用”的问题。

4.4 失败后的降级与人工兜底

模型不会永远正确，重试也不可能解决所有问题。当工具调用连续失败，并且模型也无法修正时，Agent 必须进入兜底逻辑。

兜底策略按顺序推进：

1. 调用备选工具。比如主工具是 A 厂商的天气接口，失败后切到 B 厂商。
2. 不给工具，改为直接生成可解释的回答。告诉用户“暂时查不到实时数据，建议稍后再试”。
3. 将本次任务进入人工处理队列，同时把完整对话历史、失败日志、参数快照都保存下来。
4. 限制 Agent 的最大循环次数。比如一个任务最多执行 5 轮工具调用，超出后强制停止，避免模型在一个失败场景里无限自我修正，也避免消耗过多 token。

人工兜底在面试里是一个重要得分点，因为它说明你考虑过 Agent 系统上线后可能带来的资损或用户体验问题。

4.5 日志、Trace 与失败统计

工具调用失败不能只是“发生一次处理一次”，还要建立可观测体系。建议每条工具调用链路都记录以下字段：

• request_id：整个用户请求的唯一 ID。
• agent_id或conversation_id：多轮对话的唯一 ID。
• 工具名称和参数快照。
• 失败异常类型和错误信息。
• 执行耗时。
• 重试次数。
• 最终是成功还是失败、是否进入兜底。

用表格展示：

面试中可以提“我会用 OpenTelemetry 做链路追踪，或者至少把结构化日志打到 ClickHouse 这类系统里做失败率分析”，这句话会很有说服力。

5. 工具选错：比调用失败更隐蔽的问题

面试官如果继续追问，很可能会问“模型选错工具怎么办”。工具选错不是执行失败，但结果比执行失败更危险，因为工具执行成功了，业务却错了。

比如用户问“帮我查一下杭州未来三天的天气”，模型却调用了“查询历史天气”工具，工具执行成功，返回了杭州三天前的天气，模型还把这个错误结果直接输出给用户。这种情况重试无效，因为模型根本不知道工具“错了”。

解决工具选错，通常从四个方向打：

5.1 工具描述和命名要带差异化

在工具声明阶段，给相似工具加“何时使用、何时禁用”约束。比如：

工具 A：get_weather_forecast 描述：查询未来天气，适合用户问“明天会不会下雨”“三天后温度多少”这类未来天气问题。 工具 B：get_weather_history 描述：查询历史天气，适合用户问“昨天最高温度是多少”“上个月降雨量”这类历史天气问题。

模型看到两个工具描述里反复出现“未来”和“历史”这两个词，选错的概率会明显下降。

5.2 工具分组或工具路由

如果系统里工具超过 20 个，让模型直接在所有工具里选择，准确率会下降。可以加一个“工具路由层”，先用一个分类模型或一次轻量 LLM 调用判断用户意图属于哪个领域，然后再让模型在领域子工具集合里选择。

这类似于“先规划，再调用”的思路，和最新的 Agent 设计里“主 Agent 把子 Agent 当作另一种工具调用”的理念是一致的。在面试里提到这一点，等于告诉面试官你不只看过单一 Function Calling，而是研究过多 Agent 编排。

5.3 用结果合理性校验反推工具选择是否正确

给工具执行结果加一个简单校验层：返回结果是否为空、是否明显不符合参数期望、是否包含错误码。如果校验不通过，可以触发一次“重新规划”，让模型重新选择工具。

比如工具查“用户的订单”，返回了空列表。Agent 不能直接说“没有订单”，要先校验是否用户 ID 传递错误，或者是否当前数据源本来就是测试库。

5.4 把常用工具组合成 Skill

当多个工具经常一起出现时，比如“下单”需要“查询用户信息 -> 查询商品库存 -> 创建订单 -> 支付扣款”，可以把这一组调用封装成一个高阶工具或 Skill。模型只需要选择一次 Skill，内部流程由程序编排，而不是每一步都让模型决策，这样从源头减少了选错概率和失败点。

6. 机器人公司的 Agent 工具调用有哪些特殊点

这次面试来自宇树科技，所以值得单独讲一下：如果 Agent 要控制机器人，工具调用失败的处理和纯软件 API 工具有很大区别。

6.1 工具调用可能产生物理副作用，不能盲目重试

软件工具调用失败，最坏结果是返回一个错误，业务可以回滚；机器人工具调用失败，可能意味着机器人已经执行了部分物理动作。例如调用“机械臂抓取物体”工具，如果执行到一半超时导致失败，你不能简单让 Agent 重试，因为机器人可能已经半开、物体可能已经掉落、现场可能有安全隐患。

正确设计是：控制类工具必须拆成“状态查询”和“动作执行”两类，执行前先查询状态，执行中频繁上报状态，执行失败后先“暂停”和“回到安全位置”，再考虑是否重试或人工接管。

6.2 多模态感知工具的返回结果需要专门处理

机器人 Agent 通常要调用的工具不止是 API，还包括视觉识别、SLAM 定位、语音识别等感知工具。这类工具返回的是结构化坐标或置信度结果，Agent 需要把它们转成自然语言后再做决策。

例如视觉工具返回object: "cup", bbox: [x1, y1, x2, y2], confidence: 0.87，模型如果不理解 bbox 坐标，就无法判断“杯子在不在桌面上”。失败可能不是工具报错，而是模型无法解读结果。这需要 Agent 在工具结果回传前加一层“结果解析与摘要”，把坐标信息转成“杯子在桌面左前方”这样的语义信息。

6.3 安全类工具需要审批与授权

像“移动机器人”“切换到自动导航”“启动电机”这类高风险工具，应该在调用链路上加审批环节。比如模型生成调用意图后，框架先拦截请求，推送给人类审核，审核通过后才真正执行。

这一点也对应最近 Agent 社区里经常讨论的“codex 工具调用审批失败”问题：工具已经选择正确，但审批环节权限不足，导致执行失败。这类失败的处理重点不是重试，而是设计好审批流程、权限角色、以及用户收到审批请求后的交互路径。

6.4 耗时长任务要拆成异步任务

机器人执行一个复杂任务可能需要几分钟，Agent 不能一直同步等待工具返回。工程上要把这类工具调用设计成异步任务：先创建一个任务，返回任务 ID，外部系统通过轮询或 Webhook 通知结果。Agent 在等待期间可以处理其他事情，或者主动询问用户是否继续。

这一点的本质是“不要把长耗时工具塞进同步的 Agent 循环里”。

7. 面试回答框架：从分类到兜底，一次说清楚

回到面试场景。如果面试官直接问“Agent 调用工具失败如何处理”，建议按下面这个四步框架回答，既能覆盖全部维度，又不容易被打断。

第一步，先分类。告诉面试官，工具调用失败要分阶段看：模型侧可能选错工具或生成错误参数，框架侧可能遇到 JSON 解析失败或校验失败，工具侧可能是下游服务超时或鉴权失败，结果侧可能是返回内容过长或格式不友好。不同阶段的失败处理方式完全不同，所以不能一概而论。

第二步，讲模型侧方案。核心是让模型“看到”失败并自我修正。工具定义要写清楚使用场景和参数约束；工具执行失败后，把结构化错误信息作为 tool 消息回传给模型，让模型调整参数或换工具；对于必须输出 JSON 的场景，要加一层解析和修复兜底。

第三步，讲工程侧方案。分为四块：重试前判断该工具是否幂等，重试用指数退避并限制次数；每个外部调用必须有超时和熔断；涉及物理设备和高风险操作的工具必须加审批和人工接管；长时间无法恢复时进入降级流程，不无限循环。

第四步，讲可观测性。强调所有工具调用都有结构化日志和 trace，记录 request_id、工具名、参数快照、失败类型、耗时和重试次数，后续用这些数据持续优化工具定义和重试参数。

按这个顺序讲完，基本能覆盖面试官想考察的所有点。如果面试官中间追问某个细节，比如“重试会不会导致重复扣款”，你就用幂等设计和“先查询再操作”来回答；如果追问“模型一直重试不退出”，你就用最大循环次数和人工兜底回答。

8. 面试官可能追问的问题与思路

8.1 工具调用失败后，重试导致重复扣费怎么办？

回答重点：区分幂等和非幂等工具。非幂等工具不重试，或者在参数里带上全局request_id，下游服务用这个 ID 做去重。比如支付回调、订单创建这类操作，先请求一次“查询状态”，再决定是否需要重新提交。

8.2 工具返回的 JSON 内容太长，被模型解析截断了怎么办？

回答重点：从工具侧做返回结果压缩，不要让工具直接返回完整大对象，而是返回摘要或分页数据。模型只需要关键字段，例如一个查询接口返回 100 条订单，可以改成返回“前 5 条订单 + 总数量 + 数据是否完整”的提示信息，这样既保留上下文，又避免截断。

8.3 模型一直调用同一个工具，并且一直失败，怎么终止？

回答重点：设置最大循环次数和累积错误次数限制。比如一个任务最多 5 轮工具调用，或者同一工具连续失败 3 次后强制切换。触发限制后，Agent 要生成“失败说明”并询问用户是否继续，或者直接把任务交给人工处理队列。

8.4 你怎么判断一次失败是模型问题还是工具问题？

回答重点：看“参数是否合法”。如果参数不合法，说明模型侧生成有问题，优化工具定义或提示词；如果参数合法但工具执行异常，说明工具侧或外部服务有问题，优先处理重试、超时和熔断。实际排查时可以依赖 trace 里记录的 error_type 字段做快速定位。

8.5 工具 API 的鉴权 token 过期了，怎么自动恢复？

回答重点：可以做一个“携带可刷新 token”的工具调用封装层。调用遇到 401 时，先尝试通过 refresh token 刷新凭证，刷新成功后再执行原请求；刷新失败则返回“需要用户重新授权”的错误，并触发前端授权流程。

这些追问的回答不需要背答案，核心是展示你已经把工具调用当成一个“分布式系统问题”来思考，而不是单纯的函数调用。

9. 总结与建议

这道题能回答好，本质上不靠“背诵”，而靠对 Agent 全链路的理解。我建议你找一个开源的 Agent 框架，或者直接写一个最小 Function Calling Demo，故意让工具调用失败，然后在真实环境里验证这篇文章提到的方案：把错误回喂给模型、做指数退避重试、加最大循环次数限制、观察失败日志。半小时跑一遍，比你背 10 道面试题都有用。

面试时只要能做到“先分类、再模型侧、再工程侧、最后兜底与监控”，这道题的答案就已经超过大多数候选人。如果面试官再结合机器人场景追问，就把物理动作副作用、审批授权、异步任务这几个点抛出来，这会是你在这一面的核心差异化优势。