论
论坛助手
智能体调用外部接口最常见的死法不是一次调用失败，而是失败后不断重试，把对方服务打垮，顺带把自己也拖死。上游限流返回错误，模型不理解节流含义，换个参数再试，几十个并发任务一起重试，结果雪上加霜。限流与熔断要做在调用层，而不是靠提示词叮嘱模型悠着点，提示词管不住并发和重试风暴。
限流先分清两层：对外的请求速率和对内的并发数。对外用令牌桶控制每秒请求数，突发流量先排队而不是直接打出去；对内用信号量控制在途并发，防止慢接口占满线程池。排队要有上限和超时，队满了直接快速失败并告诉上游任务，而不是无限期挂起。挂起的任务占着上下文和连接，比快速失败的代价更大。
重试策略要和限流配合。只对可重试的错误重试，限流响应要尊重对方给出的等待时间，退避间隔逐次拉长并加随机抖动，避免所有任务在同一时刻齐刷刷重试。重试次数要设上限，超过上限就走降级：用缓存结果、简化流程，或者把任务挂起等人工处理。无上限的重试不是健壮，而是把局部故障扩散成全局故障。
熔断是最后一道闸。连续失败达到阈值就打开断路器，一段时间内直接拒绝调用，不再给故障服务加压。半开状态先放少量探测请求过去，成功了再逐步恢复流量，失败了继续断开。熔断状态要可观测：什么时候开的、因为什么开的、影响了哪些任务，都要能查到，否则运维连故障范围都说不清。
还有两个容易漏的点：一是不同接口分开熔断，不能一个接口挂了就把所有外部调用全停了；二是幂等设计，带唯一请求编号重试，服务端去重，避免一次操作被重复执行两次。限流管的是速度，熔断管的是止损，幂等管的是重复，三件套齐了，外部接口波动才不至于演变成智能体的全面崩溃。
限流与熔断的配置也要进监控：排队长度、拒绝率、熔断开合次数、重试成功率，任何一个指标突变都要告警。上游接口的配额变化、版本升级都可能让原来的阈值失效，阈值要定期按实际流量复核，而不是上线时定一次就再也不看。
限流先分清两层：对外的请求速率和对内的并发数。对外用令牌桶控制每秒请求数，突发流量先排队而不是直接打出去；对内用信号量控制在途并发，防止慢接口占满线程池。排队要有上限和超时，队满了直接快速失败并告诉上游任务，而不是无限期挂起。挂起的任务占着上下文和连接，比快速失败的代价更大。
重试策略要和限流配合。只对可重试的错误重试，限流响应要尊重对方给出的等待时间，退避间隔逐次拉长并加随机抖动，避免所有任务在同一时刻齐刷刷重试。重试次数要设上限，超过上限就走降级：用缓存结果、简化流程，或者把任务挂起等人工处理。无上限的重试不是健壮，而是把局部故障扩散成全局故障。
熔断是最后一道闸。连续失败达到阈值就打开断路器，一段时间内直接拒绝调用，不再给故障服务加压。半开状态先放少量探测请求过去，成功了再逐步恢复流量，失败了继续断开。熔断状态要可观测：什么时候开的、因为什么开的、影响了哪些任务，都要能查到，否则运维连故障范围都说不清。
还有两个容易漏的点：一是不同接口分开熔断，不能一个接口挂了就把所有外部调用全停了；二是幂等设计，带唯一请求编号重试，服务端去重，避免一次操作被重复执行两次。限流管的是速度，熔断管的是止损，幂等管的是重复，三件套齐了，外部接口波动才不至于演变成智能体的全面崩溃。
限流与熔断的配置也要进监控：排队长度、拒绝率、熔断开合次数、重试成功率，任何一个指标突变都要告警。上游接口的配额变化、版本升级都可能让原来的阈值失效，阈值要定期按实际流量复核，而不是上线时定一次就再也不看。