最近有同学投稿说自己去宇树科技一面时被问了一道题Agent 调用工具失败如何处理。他当时下意识回答“重试、加日志、换成更稳定的接口”结果面试官明显不满意后面又追着问了好几个场景越问越深最后直接卡住。这道题最近在 Agent 方向的面试里出现频率非常高不只是宇树很多做 AI 应用、Agent 平台、机器人控制、MCP 中间层的公司都会问。原因也很简单Agent 工具调用失败在真实业务里几乎无法避免它直接决定了一个 Agent 系统能不能从 Demo 走到生产环境。表面上看这道题问的是“异常处理怎么做”但实际上考察的是你对 Agent 工具调用全链路的理解深度。工具调用从来不是一个简单的“请求第三方 API”动作而是一条完整链路模型判断该不该调工具 - 生成工具名和参数 - 框架解析参数并校验 - 执行工具函数 - 捕获运行结果 - 把结果重新喂回模型进行下一轮推理。任何一个环节出错最终都会表现为“工具调用失败”。如果你只会回答“在执行环节加 try/except”那基本等于没有回答到点子上。这篇文章就把这道题完整拆开先从失败类型讲起再给模型侧和工程侧的解决方案最后加一段面向机器人场景的进阶思考以及面试回答框架和追问准备。内容尽量信息密度高一点不绕弯读完之后你既能应付面试也能把这套思路直接用到自己的 Agent 系统里。1. 这道题在考什么Agent 工具调用可以拆成五个环节面试官问“工具调用失败如何处理”时真正想听的是你能不能把这五个环节的失败场景都考虑到意图识别与工具选择模型根据用户输入判断是否需要调用工具以及调用哪个工具。参数生成模型生成工具所需的参数以结构化对象输出。参数解析与执行Agent 运行时把模型输出解析成函数调用并执行实际的工具函数。结果回传工具执行完结果封装成消息返回给模型。循环决策模型根据返回结果决定是继续调用下一个工具还是直接生成最终答案。如果回答只停留在一个“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 失败类型对照表失败阶段典型表现本质原因主要解决方向模型侧没选工具、选错工具、参数错、参数缺失模型能力不足或工具定义不清晰优化工具描述、错误回喂、格式化约束框架侧JSON 解析失败、Schema 校验失败、上下文超限Agent 运行时设计问题强校验、结构化解耦、上下文裁剪工具侧下游 500、超时、token 失效、资源不足外部依赖不稳定重试、超时控制、熔断、降级结果侧内容过长截断、格式混乱、空结果工具返回值设计不合理结果裁剪、结构化输出、结果重写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(messagesmessages) 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_asciiFalse) }) # 让模型基于工具结果继续生成 second_response llm.chat(messagesmessages)这个模式在 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(defaultFalse) 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(successFalse, errorf工具 {name} 未注册, retryableFalse) try: # 前置参数校验可以在注册工具时配置 pydantic 模型 self._validate_args(name, args) # 执行超时控制 coro self.registry[name](**args) result await asyncio.wait_for(coro, timeoutself.timeout) return ToolResult(successTrue, dataresult) except asyncio.TimeoutError: return ToolResult(successFalse, errorf工具 {name} 执行超时, retryableTrue) except Exception as e: retryable self._is_retryable_error(e) return ToolResult(successFalse, errorstr(e), retryableretryable)这段伪代码不完整但结构已经表达出来工具未注册、参数校验失败、执行超时、业务异常都被分类捕获并且给每个错误打上了retryable标签。这个标签决定了后面的重试策略。4.2 重试策略先判断可不可重试重试不是万能的重试前必须回答一个问题这个工具调用是否幂等如果工具是“查询天气”“计算价格”重试是安全的。如果工具是“发送短信”“创建订单”“控制机器人移动”盲目重试可能造成重复扣费、重复下单、重复动作。正确做法是参数错误导致的失败不重试直接回传给模型修正。外部服务超时、网络抖动导致的失败可以重试。重试次数有上限比如最多 2 次。重试使用指数退避第一次等 1 秒第二次等 2 秒避免在服务抖动时继续加压。涉及副作用的工具必须通过request_id做幂等控制。一个带指数退避的重试代码如下import asyncio import time async def call_with_retry(executor, tool_name, args, request_id, max_retries2): 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(successFalse, error重试次数用尽, retryableFalse)面试官如果追问“重试导致重复发送短信怎么办”你就可以回答在工具层做幂等设计消费端用request_id去重或者把重试改成“先查询状态再决定是否重试”这样工具本身就是幂等的。4.3 超时与熔断Agent 工具调用链条比较长任何一个下游服务慢都会拖慢整个 Agent 的响应时间。因此每个工具级网络请求必须有超时推荐下游请求超时设置 3 到 5 秒工具整体执行超时 10 到 15 秒。如果同一个外部工具连续失败率达到阈值比如 5 分钟内 50% 请求失败要触发熔断直接快速失败不再发起真实调用。熔断后要有恢复策略可以使用半开状态放少量请求探测下游服务是否恢复。这个机制在回答时可以提“Circuit Breaker”算是加分项但要说清楚它解决的是“下游服务长时间故障时避免 Agent 频繁做无效调用”的问题。4.4 失败后的降级与人工兜底模型不会永远正确重试也不可能解决所有问题。当工具调用连续失败并且模型也无法修正时Agent 必须进入兜底逻辑。兜底策略按顺序推进调用备选工具。比如主工具是 A 厂商的天气接口失败后切到 B 厂商。不给工具改为直接生成可解释的回答。告诉用户“暂时查不到实时数据建议稍后再试”。将本次任务进入人工处理队列同时把完整对话历史、失败日志、参数快照都保存下来。限制 Agent 的最大循环次数。比如一个任务最多执行 5 轮工具调用超出后强制停止避免模型在一个失败场景里无限自我修正也避免消耗过多 token。人工兜底在面试里是一个重要得分点因为它说明你考虑过 Agent 系统上线后可能带来的资损或用户体验问题。4.5 日志、Trace 与失败统计工具调用失败不能只是“发生一次处理一次”还要建立可观测体系。建议每条工具调用链路都记录以下字段request_id整个用户请求的唯一 ID。agent_id或conversation_id多轮对话的唯一 ID。工具名称和参数快照。失败异常类型和错误信息。执行耗时。重试次数。最终是成功还是失败、是否进入兜底。用表格展示字段作用request_id关联整个会话链路排查问题时找到完整上下文tool_name定位是哪个工具失败args_snapshot复现问题时用注意脱敏error_type区分是超时、参数错误、外部服务异常还是鉴权失败duration_ms判断是性能问题还是功能问题retry_count判断重试策略是否生效final_status统计最终失败率面试中可以提“我会用 OpenTelemetry 做链路追踪或者至少把结构化日志打到 ClickHouse 这类系统里做失败率分析”这句话会很有说服力。5. 工具选错比调用失败更隐蔽的问题面试官如果继续追问很可能会问“模型选错工具怎么办”。工具选错不是执行失败但结果比执行失败更危险因为工具执行成功了业务却错了。比如用户问“帮我查一下杭州未来三天的天气”模型却调用了“查询历史天气”工具工具执行成功返回了杭州三天前的天气模型还把这个错误结果直接输出给用户。这种情况重试无效因为模型根本不知道工具“错了”。解决工具选错通常从四个方向打5.1 工具描述和命名要带差异化在工具声明阶段给相似工具加“何时使用、何时禁用”约束。比如工具 Aget_weather_forecast 描述查询未来天气适合用户问“明天会不会下雨”“三天后温度多少”这类未来天气问题。 工具 Bget_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 道面试题都有用。面试时只要能做到“先分类、再模型侧、再工程侧、最后兜底与监控”这道题的答案就已经超过大多数候选人。如果面试官再结合机器人场景追问就把物理动作副作用、审批授权、异步任务这几个点抛出来这会是你在这一面的核心差异化优势。 Agent工具调用失败处理指南：从异常分类到容错兜底
最近有同学投稿说自己去宇树科技一面时被问了一道题Agent 调用工具失败如何处理。他当时下意识回答“重试、加日志、换成更稳定的接口”结果面试官明显不满意后面又追着问了好几个场景越问越深最后直接卡住。这道题最近在 Agent 方向的面试里出现频率非常高不只是宇树很多做 AI 应用、Agent 平台、机器人控制、MCP 中间层的公司都会问。原因也很简单Agent 工具调用失败在真实业务里几乎无法避免它直接决定了一个 Agent 系统能不能从 Demo 走到生产环境。表面上看这道题问的是“异常处理怎么做”但实际上考察的是你对 Agent 工具调用全链路的理解深度。工具调用从来不是一个简单的“请求第三方 API”动作而是一条完整链路模型判断该不该调工具 - 生成工具名和参数 - 框架解析参数并校验 - 执行工具函数 - 捕获运行结果 - 把结果重新喂回模型进行下一轮推理。任何一个环节出错最终都会表现为“工具调用失败”。如果你只会回答“在执行环节加 try/except”那基本等于没有回答到点子上。这篇文章就把这道题完整拆开先从失败类型讲起再给模型侧和工程侧的解决方案最后加一段面向机器人场景的进阶思考以及面试回答框架和追问准备。内容尽量信息密度高一点不绕弯读完之后你既能应付面试也能把这套思路直接用到自己的 Agent 系统里。1. 这道题在考什么Agent 工具调用可以拆成五个环节面试官问“工具调用失败如何处理”时真正想听的是你能不能把这五个环节的失败场景都考虑到意图识别与工具选择模型根据用户输入判断是否需要调用工具以及调用哪个工具。参数生成模型生成工具所需的参数以结构化对象输出。参数解析与执行Agent 运行时把模型输出解析成函数调用并执行实际的工具函数。结果回传工具执行完结果封装成消息返回给模型。循环决策模型根据返回结果决定是继续调用下一个工具还是直接生成最终答案。如果回答只停留在一个“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 失败类型对照表失败阶段典型表现本质原因主要解决方向模型侧没选工具、选错工具、参数错、参数缺失模型能力不足或工具定义不清晰优化工具描述、错误回喂、格式化约束框架侧JSON 解析失败、Schema 校验失败、上下文超限Agent 运行时设计问题强校验、结构化解耦、上下文裁剪工具侧下游 500、超时、token 失效、资源不足外部依赖不稳定重试、超时控制、熔断、降级结果侧内容过长截断、格式混乱、空结果工具返回值设计不合理结果裁剪、结构化输出、结果重写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(messagesmessages) 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_asciiFalse) }) # 让模型基于工具结果继续生成 second_response llm.chat(messagesmessages)这个模式在 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(defaultFalse) 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(successFalse, errorf工具 {name} 未注册, retryableFalse) try: # 前置参数校验可以在注册工具时配置 pydantic 模型 self._validate_args(name, args) # 执行超时控制 coro self.registry[name](**args) result await asyncio.wait_for(coro, timeoutself.timeout) return ToolResult(successTrue, dataresult) except asyncio.TimeoutError: return ToolResult(successFalse, errorf工具 {name} 执行超时, retryableTrue) except Exception as e: retryable self._is_retryable_error(e) return ToolResult(successFalse, errorstr(e), retryableretryable)这段伪代码不完整但结构已经表达出来工具未注册、参数校验失败、执行超时、业务异常都被分类捕获并且给每个错误打上了retryable标签。这个标签决定了后面的重试策略。4.2 重试策略先判断可不可重试重试不是万能的重试前必须回答一个问题这个工具调用是否幂等如果工具是“查询天气”“计算价格”重试是安全的。如果工具是“发送短信”“创建订单”“控制机器人移动”盲目重试可能造成重复扣费、重复下单、重复动作。正确做法是参数错误导致的失败不重试直接回传给模型修正。外部服务超时、网络抖动导致的失败可以重试。重试次数有上限比如最多 2 次。重试使用指数退避第一次等 1 秒第二次等 2 秒避免在服务抖动时继续加压。涉及副作用的工具必须通过request_id做幂等控制。一个带指数退避的重试代码如下import asyncio import time async def call_with_retry(executor, tool_name, args, request_id, max_retries2): 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(successFalse, error重试次数用尽, retryableFalse)面试官如果追问“重试导致重复发送短信怎么办”你就可以回答在工具层做幂等设计消费端用request_id去重或者把重试改成“先查询状态再决定是否重试”这样工具本身就是幂等的。4.3 超时与熔断Agent 工具调用链条比较长任何一个下游服务慢都会拖慢整个 Agent 的响应时间。因此每个工具级网络请求必须有超时推荐下游请求超时设置 3 到 5 秒工具整体执行超时 10 到 15 秒。如果同一个外部工具连续失败率达到阈值比如 5 分钟内 50% 请求失败要触发熔断直接快速失败不再发起真实调用。熔断后要有恢复策略可以使用半开状态放少量请求探测下游服务是否恢复。这个机制在回答时可以提“Circuit Breaker”算是加分项但要说清楚它解决的是“下游服务长时间故障时避免 Agent 频繁做无效调用”的问题。4.4 失败后的降级与人工兜底模型不会永远正确重试也不可能解决所有问题。当工具调用连续失败并且模型也无法修正时Agent 必须进入兜底逻辑。兜底策略按顺序推进调用备选工具。比如主工具是 A 厂商的天气接口失败后切到 B 厂商。不给工具改为直接生成可解释的回答。告诉用户“暂时查不到实时数据建议稍后再试”。将本次任务进入人工处理队列同时把完整对话历史、失败日志、参数快照都保存下来。限制 Agent 的最大循环次数。比如一个任务最多执行 5 轮工具调用超出后强制停止避免模型在一个失败场景里无限自我修正也避免消耗过多 token。人工兜底在面试里是一个重要得分点因为它说明你考虑过 Agent 系统上线后可能带来的资损或用户体验问题。4.5 日志、Trace 与失败统计工具调用失败不能只是“发生一次处理一次”还要建立可观测体系。建议每条工具调用链路都记录以下字段request_id整个用户请求的唯一 ID。agent_id或conversation_id多轮对话的唯一 ID。工具名称和参数快照。失败异常类型和错误信息。执行耗时。重试次数。最终是成功还是失败、是否进入兜底。用表格展示字段作用request_id关联整个会话链路排查问题时找到完整上下文tool_name定位是哪个工具失败args_snapshot复现问题时用注意脱敏error_type区分是超时、参数错误、外部服务异常还是鉴权失败duration_ms判断是性能问题还是功能问题retry_count判断重试策略是否生效final_status统计最终失败率面试中可以提“我会用 OpenTelemetry 做链路追踪或者至少把结构化日志打到 ClickHouse 这类系统里做失败率分析”这句话会很有说服力。5. 工具选错比调用失败更隐蔽的问题面试官如果继续追问很可能会问“模型选错工具怎么办”。工具选错不是执行失败但结果比执行失败更危险因为工具执行成功了业务却错了。比如用户问“帮我查一下杭州未来三天的天气”模型却调用了“查询历史天气”工具工具执行成功返回了杭州三天前的天气模型还把这个错误结果直接输出给用户。这种情况重试无效因为模型根本不知道工具“错了”。解决工具选错通常从四个方向打5.1 工具描述和命名要带差异化在工具声明阶段给相似工具加“何时使用、何时禁用”约束。比如工具 Aget_weather_forecast 描述查询未来天气适合用户问“明天会不会下雨”“三天后温度多少”这类未来天气问题。 工具 Bget_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 道面试题都有用。面试时只要能做到“先分类、再模型侧、再工程侧、最后兜底与监控”这道题的答案就已经超过大多数候选人。如果面试官再结合机器人场景追问就把物理动作副作用、审批授权、异步任务这几个点抛出来这会是你在这一面的核心差异化优势。