错误处理与重试：Agent容错的进阶课

可视化演示

动态演示错误处理与重试的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。

一、错误分类：先分清“该不该再敲门”

阿杰被客户投诉后冷静下来，开始把失败分成两类。一种是“客户在洗澡没听到门铃”，等几分钟再敲门就能送到；另一种是“地址写成了月球”，你敲一百次门也没用。外卖小哥不可能每次失败都盲目重试，他要先判断错误是哪一种。Agent 调用工具同样如此：工具返回的错误里，有的是暂时性的，有的是确定性的。

对应到技术层面，可重试错误包括网络连接超时、HTTP 503 Service Unavailable、429 限流——它们意味着服务还在，只是暂时忙或者网络抖了一下。不可重试错误则包括 400 参数非法、401 未授权、404 资源不存在、业务校验失败——这些错误无论重试多少次，结果都一样，因为问题出在请求本身。如果对不可重试错误也傻傻重试，只会浪费时间和算力，比如让外卖小哥对着错误的地址反复跑十趟。

可是现实中并不总是这样黑白分明，这时候就要算一笔账。重试是否划算，可以用期望收益来衡量：

阿杰把这两种错误贴在了调度台前：“暂时失败，稍后再试；确定失败，立刻换方案。”那之后，骑手们不再对着错误地址白跑，餐厅的配送准时率反而上去了。这就是错误分类的力量——重试不是无脑重复，而是有判断的再尝试。

二、重试策略：约定“敲几次门、每次隔多久”

阿杰发现，就算判断出“客户应该在家”，也不能一直敲门。敲一次没应，等 30 秒再敲一次；还没应，等 1 分钟再敲一次；再不应，就打电话。这个“敲几次、隔多久”的约定，就是重试策略。Agent 对工具的每一次重试，同样要有明确的次数上限和间隔规则。

首先，最大重试次数要设置得克制。生产经验里通常 2-3 次就够：第一次重试能解决绝大多数瞬时故障，第二次能覆盖大部分网络恢复场景，第三次之后成功率提升已经非常有限，反而会把负载放大好几倍。其次，重试间隔不能太短也不能太长——太短等于没等，服务还没来得及恢复；太长则让用户等到绝望。最后，重试会占用整体时间预算，得提前算好总账。

一次工具调用的完整时间预算，就是所有尝试耗时的总和：

这里还有一个容易忽略的前提：幂等性。幂等可以这样理解——客户点了一份宫保鸡丁，你因为没收到确认而重复派了三次餐，但客户只吃一份、只付一份钱。如果后端逻辑被重复执行会产生不同结果（比如重复扣款、重复下单），那么重试本身就是事故源。所以生产级系统会给每次请求带上唯一的 request_id，让服务端识别“这单我已经处理过了”，从而安全地去重。

阿杰后来给每个订单加了一串唯一的配送编号，骑手重复敲门时，客户只需要说“我已经签收过了”就能结束这次对话。重试策略的真正艺术，是把“不放弃”和“不打扰”同时装进一套规则里。

三、指数退避：越失败，等得越久

阿杰发现，晚上 8 点到 10 点是小区门禁最繁忙的时候，很多骑手会在同一栋楼下反复刷门禁。他定了一条新规则：第一次刷不开，等 30 秒；第二次刷不开，等 1 分钟；第三次，等 2 分钟——每次等待时间翻倍。这就是指数退避（Exponential Backoff）。

为什么不是每次都等同样久？因为失败往往意味着服务端正处于过载或恢复期。如果每次都隔同样短的时间去重试，等于在服务最脆弱的时候持续施压。而指数退避让重试频率随时间快速降低，给服务留出喘息空间。它的核心公式非常简单：

这里的参数选择很讲究。初始间隔决定了系统恢复的速度：设得太短（比如 10ms），第一次重试可能撞上还没恢复的故障；设得太长（比如 10 秒），用户等待太久。常见实践是 100ms 到 1 秒之间起步。封顶上限则保护了用户体验和任务整体时间预算，一般设为 8 秒到 30 秒。如果把退避曲线的参数画出来，“陡峭上涨然后撞到天花板的曲线”就是指数退避的形态。

阿杰在调度台里给每个小区设置了一个“最长等待 3 分钟”的封顶，之后无论刷多少次门禁都不再等了。他笑着对骑手们说：“等得越久，说明门越难开；门越难开，越要冷静下来想别的办法，而不是越敲越急。”

四、抖动机制：别让所有外卖员同时敲门

指数退避用了一段时间，阿杰又发现一个诡异的现象：某天晚上，同一栋楼的 6 个订单全部超时，而且超时时间惊人地一致。查了日志才发现，6 个骑手都遵循“30 秒、60 秒、120 秒”的等待节奏，结果每次重试都像约好了一样同时刷卡、同时挤在门口，把门禁系统撞出了新的故障。这就是同步风暴（Thundering Herd）——当大量客户端用完全相同的退避节奏重试时，它们会同时冲击服务。

解决办法是在退避时间上加入随机扰动（Jitter），让每个客户端的重试时刻不一样。最常用的策略是全抖动（Full Jitter）：等待时间不取计算出的那个确定值，而是在 0 到该值之间随机取一个数：

除了全抖动，还有等量抖动（Equal Jitter）：把退避时间对半切开，前半段固定等待，后半段加随机，表达式是 cap/2 + random(0, cap/2)。它保证了至少等待一半的时间，又保留了随机性，适合对“最早重试时刻”有要求的场景。全抖动简单粗暴、分散效果好；等量抖动更温和、能保证基础退避。选哪种取决于你的系统对“过早重试”有多敏感。

阿杰给调度系统加了一个“随机小闹钟”：每个骑手的重试等待时间在规则基础上上下浮动。从此之后，门禁再也没在晚高峰被大家同时挤爆过。抖动看起来是在“破坏规则”，但恰恰是这点不精确的随机，让整体系统更加稳定。

五、熔断保护：连败太多就挂免战牌

就算有了重试和抖动，阿杰还是遇到过一次大事故：某小区门口修路，所有骑手送到门口都进不去。大家按照退避规则一遍遍地试，结果一晚上几十个骑手全堵在那一条路上，其他区域的订单反而没人送。阿杰恍然大悟——重试本身也会放大故障，必须有一个机制在“失败到一定程度”时彻底停下来。

这个机制就是熔断（Circuit Breaker），它像一个电路保险丝：当连续失败率超过阈值，就主动跳闸，后续请求不再真正发出，而是快速失败。熔断器内部是一个三态状态机：关闭（Closed）→ 打开（Open）→ 半开（Half-Open）。关闭时请求正常放行；打开时请求一律拦截；半开时放行少量探测请求。触发熔断的判定基于滑动窗口内的失败率：

熔断打开后的快速失败非常关键：请求不再浪费在网络往返上，而是立即返回一个“服务暂不可用”的错误，让 Agent 可以马上走兜底逻辑，把资源留给真正有能力处理的任务。这就像阿杰发现某小区进不去后，立刻在系统里挂了“免战牌”：新订单不再派往该小区，已经堵在路上的骑手立刻撤离，而不是继续死磕。

阈值怎么定？太敏感会把偶发抖动误判为故障；太迟钝又保护不了下游。一般从连续失败次数（如 5 次）或窗口失败率（如 60% 窗口内 50% 失败）起步，再根据线上监控调整。熔断不是惩罚，而是战略性的撤退——承认暂时打不下来，把资源留给能打赢的仗。

六、半开恢复：悄悄试一单小的

熔断打开的“免战牌”不能永远挂着。阿杰发现，小区修路三天后通车了，但因为是“免单区”，所有订单还是绕道走，客户怨声载道。他需要一种方式来确定“这个小区到底恢复没有”。于是他定了个规矩：隔一段时间，派一个骑手带一单小订单去试试。如果送成功了，就恢复正常派单；如果又失败了，继续挂免战牌。这个“试一单”的过程就是半开（Half-Open）状态。

半开状态的核心价值，是用小成本试探大服务。它不会放行全部流量（那等于让刚恢复的服务再次被压垮），而是只放行一个或一小批探测请求。这个探测请求成功，说明服务已经恢复，熔断器可以关闭；失败则说明服务还很脆弱，熔断器回到打开状态，重新开始冷却计时。半开恢复是否成功的判定，用探测成功率来衡量：

这里还有一个关键参数：冷却时间（Cooldown）。熔断打开之后，不能立刻进入半开，要等一段冷却时间（比如 30 秒到 2 分钟）。这是因为服务故障后往往需要一段时间恢复，过早试探只会再次失败。冷却时间一到，熔断器自动转入半开，开始放探测请求。

阿杰发现，“试一单小的”这个策略妙极了：通车第一天，他派了 3 个骑手去试了 3 次，全部成功，于是系统自动恢复了该小区的派单。半开恢复的智慧在于，它把“信任”变成了一个可验证的过程——每一次探测，都是对系统状态的一次投票。

七、兜底与告警：守好最后一道防线

所有手段都用尽之后，最坏的情况还是发生了：小区持续封闭，熔断开了、探测失败，订单怎么都送不进去。这时阿杰会做什么？他会给客户打电话道歉、退还配送费、推荐客户换一家餐厅——总之，绝不会让客户干等着。对于 Agent 来说，这就是兜底（Fallback）与告警（Alerting）：重试和熔断都解决不了问题时，必须有优雅的退出方案。

降级方案是第一选择：调用备用工具、使用缓存数据、走人工审核流程。比如天气 API 挂了，就返回昨天的天气数据并标注“数据可能延迟”。如果连降级都没有合适的，就返回默认安全值：例如风险评分接口失败时，返回一个保守的“需人工审核”结果，而不是让整个流程崩溃。同时，告警必须立刻响起——但要分级：

最后别忘了日志追踪。日志不是写给机器看的，而是写给明天凌晨背锅的自己看的。每一条失败和重试，都要记录下错误类型、重试序号、退避时长、最终是否成功、是否触发兜底。这些数据不仅是排查问题的线索，也是未来调优重试参数、熔断阈值的依据。阿杰在调度台留了一本“配送事故簿”，每场事故都记下时间、原因、处理方式，三个月后他赫然发现，大部分问题其实早已被这本簿子预言过了。

兜底和告警，是容错体系的最后一道防线。它告诉我们：即便一切努力都失败了，系统依然要体面地失败——把损失降到最低，把原因讲清楚，把改进方向留给明天。

AI 应用场景

Python 演示

import randomimport time  class CircuitBreaker:    def __init__(self, fail_threshold=3, cooldown=0.02):        self.fail_count = 0        self.fail_threshold = fail_threshold        self.cooldown = cooldown        self.state = 'closed'        self.last_fail_time = 0.0     def allow(self):        if self.state == 'closed':            return True        if self.state == 'half_open':            return True        if time.time() - self.last_fail_time > self.cooldown:            self.state = 'half_open'            return True        return False     def record(self, ok):        if ok:            self.state = 'closed'            self.fail_count = 0            return        self.fail_count += 1        if self.fail_count >= self.fail_threshold or self.state == 'half_open':            self.state = 'open'            self.last_fail_time = time.time()  def exponential_backoff(attempt, base=0.01, cap=0.5):    wait = min(base * (2 ** attempt), cap)    return random.uniform(0, wait)  class FlakyService:    def __init__(self):        self._calls = 0     def invoke(self):        self._calls += 1        if self._calls <= 4:            raise ConnectionError('service timeout')        return {'data': 'ok'}  def call_tool(service, attempts=6):    breaker = CircuitBreaker()    for i in range(attempts):        if not breaker.allow():            time.sleep(0.01)            continue        try:            result = service.invoke()            breaker.record(True)            return result        except Exception as exc:            print('attempt', i + 1, 'failed:', exc)            breaker.record(False)            wait = exponential_backoff(i)            time.sleep(wait)    return None  if __name__ == '__main__':    result = call_tool(FlakyService())    print('final result:', result)

1. wait = min(base * (2 ** attempt), cap)指数退避核心，等待时间随重试次数翻倍并封顶
2. return random.uniform(0, wait)全抖动，把确定性的等待时间变成随机区间
3. if not breaker.allow(): time.sleep(0.01); continue熔断打开时快速失败，不真正调用服务
4. if self.fail_count >= self.fail_threshold or self.state == 'half_open'达到阈值或半开探测失败时，熔断打开
5. if time.time() - self.last_fail_time > self.cooldown冷却时间结束，自动转入半开状态
6. breaker.record(True); return result探测成功，熔断关闭并立即返回结果

常见误区

面试题