考察点
生产级 Agent 和 demo 的分水岭就在错误处理。面试官想听你把失败场景拆开来分类讨论，而不是一句「加重试」。追问方向：重试会不会把删除执行两次、模型陷入反复重试死循环怎么办、工具超时怎么定。
参考答案
先把错误分三层
不同层的错误，处置策略完全不同：
参数层错误：模型填的参数不合法——类型错、枚举外取值、格式不对。这类错误不要重试原样调用，正确做法是把校验失败原因以可读文本回传给模型（「days 必须是 1-90 的整数，你传了 365」），模型大概率下一轮自己改正。这层靠 schema 校验加错误信息反馈解决。
执行层错误：参数合法但业务执行失败——订单不存在、库存不足、权限不够。同样回传可读错误，模型可以选择换参数重试、换工具、或者告知用户。关键是错误信息要包含「下一步可以怎么办」的线索，只返回「error 500」模型只能瞎猜。
系统层错误：超时、网络断、Server 崩溃、限流。这类模型解决不了，靠应用层的重试、熔断、降级机制处理，处理不了再把「服务暂时不可用」这个事实告诉模型，让它优雅地回复用户而不是卡死。
应用层容错机制
超时：每次工具调用必须设超时，按工具特性分级——本地查询几秒，外部 API 十几秒，长任务走异步任务制（发起后轮询或推送，不占住调用链）。没有超时兜底，一个挂死的第三方接口能把整个 Agent 会话拖死。
重试：只对系统层的瞬时错误重试（网络抖动、限流），指数退避，上限两三次。业务错误和参数错误绝不自动重试，重试模型已经知道答案的调用纯属浪费 token。
幂等：这是重试安全的前提。写操作工具必须支持幂等——客户端生成 request id，服务端去重；或者用 upsert 语义代替裸 insert。否则网络超时后重试，可能把一笔扣款执行两次。设计工具接口时就要把幂等键放进参数。
熔断与降级：某个工具连续失败超过阈值，熔断一段时间，期间把该工具从候选列表摘掉或标记不可用，避免模型反复往墙上撞。有备用路径的工具（主搜索 API 挂了切备用源）在应用层透明切换。
模型侧的死循环防护
Agent 场景特有的问题：工具一直失败，模型一直「再试一次」，烧着 token 原地打转。防护手段：应用层记录同一工具同一参数的调用次数，超过两三次直接拒绝并提示「请改变策略」；给整个会话设最大轮次和 token 预算，超限中断；系统提示里写明「同一方法失败两次后换思路或如实告知用户做不到」。
失败也要可观测
每次失败调用记录日志：工具名、参数、错误类型、第几轮、最终是否恢复。线上按工具维度统计失败率，失败率突增的工具优先排查。很多「模型变笨了」的反馈，查到最后是某个工具悄悄挂了，模型一直在收拾残局。
可能的追问
- 工具部分成功怎么处理？ 批量操作类工具返回逐项结果（成功几条失败几条及原因），别用「全成功/全失败」二值语义，模型能针对失败项单独补救。
- 回填给模型的错误信息会污染上下文吗？ 会有一点，所以错误文本要精简。长链路的 Agent 可以在自我纠正成功后把冗余的错误中间轮做摘要压缩。
- MCP 协议层面怎么表达失败？ 区分协议错误（JSON-RPC error，如方法不存在）和工具执行错误（tool result 带 isError 标记），后者是给模型看的业务失败，语义要分清。