200 条请求的同一组压测里，三跳链路由 181 条成功升至 200 条，关键不是增加总预算或重试，而是把单跳超时从 3 秒放宽到 12 秒。这组结果提醒我们：多步骤 AI 系统的瓶颈，常藏在按平均值或模板设定的超时参数里。

这是什么

这是一次三跳链路调优实验。所谓“三跳”，指一次请求依次经过三个处理环节，例如检索、生成和汇总。测试显示，3 秒单跳超时叠加两次重试，会让链路在仍有 18 秒预算时提前失败；改成 12 秒且不重试后，整条请求反而从约 11.3 秒缩短至 9.7 秒并全部成功。

方法并不复杂：先给每一跳单独记录耗时、截断和重试状态，再观察完整分布，最后按真实长尾上限设置单跳超时。总预算应放在最后计算，而不是作为最先调整的旋钮。

行业怎么看

我们的判断是，多跳 Agent（由模型自主规划并连续调用工具完成任务的系统）进入生产环境后，评估重点会从“能否跑通”转向“能否解释失败发生在哪一环”。只记录整条链路的平均耗时或 p95，容易掩盖真正拖慢系统的少数请求；尤其是超时已生效时，日志里的长尾还可能是被截断后的假数据。

但放宽超时也有代价。12 秒方案的 p95 从 9466 毫秒升至 10366 毫秒，尾部延迟增加约 900 毫秒。更关键的是，文章只验证了 200 条请求和固定延迟，样本规模与场景覆盖有限，不能据此认定所有业务都应采用 12 秒。

另一个风险是，重试可能放大成本和负载。若失败来自模型本身响应慢，而非连接抖动、限流或临时故障，重复调用只会消耗更多时间与算力。行业需要接受一个现实：成功率并非唯一指标，延迟、费用和容量必须一起权衡。

对普通人的影响

对企业 IT：部署 AI 工作流时，应要求业务团队提供分环节日志和真实长尾数据，避免直接采用统一超时模板；容量规划也要把重试可能带来的算力与费用计入。

对个人职场：使用智能助手处理长文档、检索和报告生成时，响应变慢未必代表“回答能力差”，有时是某个后台环节被过早截断。重要任务可保留人工复核和分步确认。

对消费市场：面向消费者的 AI 服务将逐步从追求瞬时回应，转向在稳定性、等待时间与价格之间做选择。短期内，更多重试和更长等待可能转化为订阅价格或算力成本。