Function Calling 回退策略工具不可用时的优雅降级方案一、查询订单的工具突然挂了Agent 应该怎么办生产环境中Agent 调用的工具函数不可能 100% 可用。第三方 API、内部服务、数据库访问任何一个环节都可能因为网络抖动、服务重启、限流等因素不可用。如果 Agent 调用工具时直接返回服务不可用的错误消息给用户用户体验会非常差。更糟的是如果 Agent 不理解工具的不可用状态会反复重试导致整条对话链条卡死。问题在于LLM 本身不知道工具的可用性状态它只会根据 Function Schema 的描述来决定调用哪个工具。我们需要在 Agent 和 LLM 之间增加一层回退策略。二、分层回退策略架构flowchart TB LLM[LLM 推理\n决定调用工具] -- Dispatcher[工具调度器] Dispatcher -- Check{工具可用?} Check --|可用| Execute[执行工具] Check --|不可用| Fallback[回退策略引擎] Fallback -- Strategy1[策略一功能降级\n用替代工具完成任务] Fallback -- Strategy2[策略二部分返回\n返回缓存/默认结果] Fallback -- Strategy3[策略三延迟重试\n放入消息队列异步执行] Fallback -- Strategy4[策略四人工升级\n通知运维 告知用户等待] Execute -- Result[返回结果] Strategy1 -- Result Strategy2 -- Result Strategy3 -- User[告知用户稍后通知] Strategy4 -- User四种回退策略的选择逻辑功能降级有可替代工具 → 自动切换部分返回有缓存/默认值 → 返回历史数据延迟重试工具暂时不可用 → 异步处理人工升级无可替代方案 → 通知运维三、Go 实现分层回退package fallback import ( context encoding/json fmt time ) // ToolStatus 工具状态 type ToolStatus int const ( StatusHealthy ToolStatus 0 // 健康 StatusDegraded ToolStatus 1 // 降级部分功能不可用 StatusUnhealthy ToolStatus 2 // 不可用 StatusUnknown ToolStatus 3 // 未知 ) // FallbackStrategy 回退策略 type FallbackStrategy interface { // Execute 执行回退策略返回替代结果 Execute(ctx context.Context, toolCall ToolCall) (*FallbackResult, error) } // ToolCall 工具调用请求 type ToolCall struct { ToolName string Arguments map[string]interface{} MaxRetries int } // FallbackResult 回退结果 type FallbackResult struct { Data interface{} // 替代结果 Strategy string // 使用的回退策略 Original error // 原始错误用于日志 } // FallbackEngine 回退引擎——管理中心 type FallbackEngine struct { registry *ToolRegistry // 工具注册表 healthCheck *HealthChecker // 健康检查器 cache *ResultCache // 结果缓存 strategies map[ToolStatus][]FallbackStrategy // 状态 → 策略映射 } // ExecuteWithFallback 带完整回退的执行 func (fe *FallbackEngine) ExecuteWithFallback( ctx context.Context, call ToolCall, ) (*FallbackResult, error) { // 第一步检查工具健康状态 status : fe.healthCheck.GetStatus(call.ToolName) if status StatusHealthy { // 正常执行 result, err : fe.registry.Execute(ctx, call) if err nil { // 成功执行缓存结果 fe.cache.Set(call.ToolName, call.Arguments, result) return FallbackResult{ Data: result, Strategy: direct, }, nil } // 执行失败降级到回退 status StatusDegraded } // 第二步根据状态选择回退策略 return fe.applyFallback(ctx, call, status) } func (fe *FallbackEngine) applyFallback( ctx context.Context, call ToolCall, status ToolStatus, ) (*FallbackResult, error) { strategies : fe.strategies[status] for _, strategy : range strategies { result, err : strategy.Execute(ctx, call) if err nil { return result, nil } // 当前策略失败尝试下一个 fmt.Printf([FALLBACK] 策略失败: %v, 尝试下一个\n, err) } // 所有回退策略均失败 return nil, fmt.Errorf( 工具 %s 不可用所有回退策略均失败, call.ToolName, ) }四种回退策略的实现// DegradeStrategy 策略一功能降级——用替代工具 type DegradeStrategy struct { // 工具降级映射主工具 → 替代工具 degradeMap map[string]string // 参数转换将主工具的参数转为替代工具的参数 paramMapper map[string]ParamMapper } type ParamMapper func(original map[string]interface{}) map[string]interface{} func (ds *DegradeStrategy) Execute( ctx context.Context, call ToolCall, ) (*FallbackResult, error) { // 查找替代工具 altTool, hasAlt : ds.degradeMap[call.ToolName] if !hasAlt { return nil, fmt.Errorf(工具 %s 无降级方案, call.ToolName) } // 转换参数 args : call.Arguments if mapper, has : ds.paramMapper[call.ToolName]; has { args mapper(args) } // 用替代工具执行 altCall : ToolCall{ToolName: altTool, Arguments: args} // 实际执行交由 Registry fmt.Printf([DEGRADE] %s → %s\n, call.ToolName, altTool) return FallbackResult{ Strategy: fmt.Sprintf(degrade:%s→%s, call.ToolName, altTool), }, nil } // CacheStrategy 策略二部分返回——使用缓存 type CacheStrategy struct { cache *ResultCache } func (cs *CacheStrategy) Execute( ctx context.Context, call ToolCall, ) (*FallbackResult, error) { result, err : cs.cache.Get(call.ToolName, call.Arguments) if err ! nil { return nil, fmt.Errorf(缓存未命中: %w, err) } fmt.Printf([CACHE] 返回缓存数据: %s\n, call.ToolName) return FallbackResult{ Data: result, Strategy: cache, }, nil } // RetryStrategy 策略三延迟重试——放入队列 type RetryStrategy struct { queue MessageQueue config RetryConfig } type RetryConfig struct { MaxRetries int // 最大重试次数 Backoff time.Duration // 退避间隔 } func (rs *RetryStrategy) Execute( ctx context.Context, call ToolCall, ) (*FallbackResult, error) { // 序列化任务并放入队列 task : RetryTask{ ToolCall: call, Retries: 0, MaxRetries: rs.config.MaxRetries, CreatedAt: time.Now(), } taskData, _ : json.Marshal(task) if err : rs.queue.Push(ctx, tool_retry_queue, taskData); err ! nil { return nil, fmt.Errorf(放入重试队列失败: %w, err) } return FallbackResult{ Strategy: retry_queued, Data: map[string]string{ message: 操作已提交完成后将通过通知告知。请稍候。, }, }, nil } // EscalateStrategy 策略四人工升级——通知运维 type EscalateStrategy struct { alerter Alerter // 告警接口 } func (es *EscalateStrategy) Execute( ctx context.Context, call ToolCall, ) (*FallbackResult, error) { alert : AlertMessage{ Title: fmt.Sprintf(工具降级告警: %s, call.ToolName), Content: fmt.Sprintf(工具 %s 不可用所有自动回退策略均失败, call.ToolName), Level: critical, Time: time.Now(), } if err : es.alerter.Send(ctx, alert); err ! nil { return nil, fmt.Errorf(发送告警失败: %w, err) } return FallbackResult{ Strategy: escalated, Data: map[string]string{ message: 当前服务繁忙已通知运维团队处理请稍后再试。, }, }, nil }健康检查器——感知工具状态type HealthChecker struct { checks map[string]*HealthCheckConfig cache map[string]HealthStatus // 缓存的健康状态 mu sync.RWMutex } type HealthCheckConfig struct { Endpoint string // 健康检查端点 Interval time.Duration // 检查间隔 Timeout time.Duration // 单次检查超时 FailThreshold int // 连续失败次数阈值 } type HealthStatus struct { Status ToolStatus FailCount int LastCheck time.Time LastError string } func (hc *HealthChecker) StartBackgroundCheck(ctx context.Context) { for name, config : range hc.checks { go hc.checkLoop(ctx, name, config) } } func (hc *HealthChecker) checkLoop( ctx context.Context, name string, config *HealthCheckConfig, ) { ticker : time.NewTicker(config.Interval) defer ticker.Stop() for { select { case -ctx.Done(): return case -ticker.C: err : hc.doCheck(config) hc.updateStatus(name, err, config.FailThreshold) } } }四、边界分析与 Trade-offs回退策略的顺序很重要能降级的先降级保持响应速度有缓存的先给缓存用户体验 数据新鲜度都不行再排队重试最后升级到人工缓存策略的数据一致性返回缓存数据时必须告知用户这是 XX 分钟前的数据金融和交易类工具不应该使用缓存回退重试队列的幂等性重试任务必须保证幂等多次执行结果一致使用唯一 ID 防止重复处理健康检查的误判间歇性故障可能导致健康检查状态来回切换使用连续失败计数 最低健康持续时间来避免抖动五、总结Function Calling 的回退策略设计目标不是永不失败而是失败时用户体验不受影响先降级用替代工具完成 80% 的功能后缓存返回近期的有效数据再重试异步处理给用户预期时间最后告警通知运维保持用户知情实现的成本很低核心逻辑约 200 行但对 Agent 生产可靠性的提升是数量级的。