如果有做过 Agent Platform 这类系统应该能体会那种感觉平时一切正常某天下午告警突然刷屏P99 从几百毫秒直接飙到 10 秒以上网关开始疯狂报超时用户陆续反馈转圈转不出来。这个月我正好在开发一个 Agent Platform——负责智能体编排、工具调用和模型交互的服务——就实打实踩了一次这种线上超时故障。从告警到初步定位花了快两个小时修复加验证又用了半天。复盘之后发现多数问题其实可以通过分层超时、线程池隔离和熔断机制提前规避。这篇文章把整个经过、根因分析和配置思路完整记下来给同样在做 Agent 编排服务的同学一个参考。1. 故障场景Agent Platform 的核心链路1.1 这个平台到底做了什么先说背景。Agent Platform 不是一个简单的 CRUD 服务它承载的是用户提问 - 调度 Agent - 模型思考 - 决定调用工具 - 工具执行 - 结果返回模型 - 生成最终回答这样一条完整链路。用户侧看到的是一次聊天实际后端要经历多轮模型交互和多次工具调用。我负责的部分是平台的核心编排引擎负责接收用户请求根据任务类型分发到不同 Agent每个 Agent 内部会决定是否调用搜索、数据库查询、内部服务接口甚至外部模型网关。链路大概长这样用户请求进入网关路由到编排服务编排服务根据会话上下文选择 AgentAgent 启动后向模型服务发起推理请求模型在推理过程中可能会输出工具调用意图编排服务解析工具调用真实发起 HTTP 请求到各类工具服务工具结果返回给模型模型继续推理最终完整答案再通过编排服务返回给用户。这个链路的特点就是同步且长。传统 API 网关请求通常几百毫秒就结束了但一个 Agent 任务可能持续 10 秒到 30 秒中间还嵌套着多个子调用。这意味着任何一个环节抖动都会被整体拉长最终表现为线上超时。1.2 为什么超时在这里会被放大在传统 Web 服务里某个接口慢只会影响它自己最多就是数据库连接池紧张一点。Agent 编排场景完全不同一次用户请求要占用线程很久而且线程是在等待多个外部依赖中间任何一次重试、任何一个工具的慢响应都会成倍消耗系统资源。尤其是在用户请求高峰期模型推理本身性能波动就大。同一个模型网关低峰期单次推理 2 秒高峰期可能要到 8 秒如果编排层还配置了重试那单个工具调用可能被放大到 20 秒以上。再加上用户侧等不到结果会刷新页面、再次发起请求前端的重试也会压到网关和编排服务上。超时问题在这种系统里不是偶发而是必然的放大效应。我这次踩的故障本质就是上游模型网关响应变慢 - 编排层重试叠加 - 线程池被打满 - 连接池资源耗尽 - 整体服务不可用这样一条链条。2. 故障现象与一线排查过程2.1 告警暴露了哪些信息故障是周四下午 2 点 47 分被监控系统捕捉到的。最开始是网关侧告警某条 Agent 路由的 P99 延迟达到 12.8 秒紧接着出现 504 错误。大概 3 分钟后编排服务自身的告警也来了Tomcat 线程池活跃线程数持续打满HTTP 客户端连接池抛出 Connection pool exhausted 异常。这里我特别强调一下告警的顺序非常重要。如果只看到网关 504 就急着重启服务大概率会跳过真正的根因。我当时的做法是先看编排服务的线程池监控确认线程堆积情况再看依赖服务的调用指标判断是本服务慢还是下游慢。同一个时刻的监控数据是这样的编排服务 QPS 没有明显上涨甚至略有下降平均响应时间从 800ms 涨到 11sTomcat 活跃线程数从 40 涨到 200达到上限HTTP 客户端连接池 Waiting 线程数持续在 60 以上下游工具服务 A 的 P99 只有 900ms看起来完全正常。这个数据组合非常有代表性本服务 CPU、内存、QPS 都正常但线程和连接池被打满。这说明系统不是计算能力不够而是大量线程在等待某个下游依赖返回。2.2 第一波排查先从基础设施和中间件入手刚开始排查我按照惯例先看基础设施指标。CPU 和内存都没事GC 也正常Young GC 频率和平常差不多Full GC 几乎没有。这说明不是 JVM 层面的问题。接着看数据库慢查询日志里只有零星几条耗时一两秒的查询不至于拖垮整个服务。Redis 的读写延迟也正常说明缓存也不是瓶颈。到了这一步基本可以判定问题存在于服务之间的同步调用链上。然后我打开了调用链追踪平台看了几个典型请求的链路。发现大部分耗时集中在两个环节一是调用模型网关推理接口的 span 上二是某个工具调用后的等待模型继续推理的 span 上。有一个请求甚至出现了同一个 HTTP 调用被连续执行 3 次的情况这就是重试的痕迹。日志里也能看到类似线索。某个 request_id 下工具调用的日志时间戳出现了三次相同的方法入口间隔分别是 4 秒和 5 秒。这明显不是正常调用而是客户端重试了两次。2.3 用线程栈和调用链锁定了嫌疑确认了重试堆积之后我直接对线上服务做了一次线程栈采样。当时用的是 arthas执行thread -n 50查看最忙的线程堆栈。大部分阻塞线程的堆栈都指向同一个位置HTTP 客户端的 execute 方法等待 upstream 模型网关返回响应。还有一部分线程阻塞在LockSupport.parkNanos看堆栈信息是 HTTP 客户端在等待可用的连接。也就是说连接池的可用连接已经被占满后续请求只能排队。排队的前提是线程池还有空闲线程一旦同步的 HTTP 连接池耗尽线程池也会跟着耗尽整个服务就进入了恶性循环。这一步让我彻底确定了方向不是代码逻辑 bug而是依赖超时和重试策略配置错误导致的级联故障。模型网关在高峰期的响应从 3 秒变成 10 秒但编排服务配置了 10 秒读超时和 2 次重试导致单个工具调用的最长耗时接近 30 秒。大量请求堆积之后连接池资源被占满新的请求无法获取连接最后表现为超时和 504。3. 根因深挖超时是如何被逐级放大的3.1 重试策略失控是元凶先讲一件很多人忽略的事HTTP 客户端重试不能随便配尤其是对模型网关这种本身在高负载下会变慢的服务。我这次踩坑的直接原因就是一个新接入的 Agent 依赖了一个新的工具服务而这个工具服务内部会调用模型网关。当时配置 HTTP 客户端时为了保证可靠性设置了retries 2退避策略是固定的 2 秒。正常情况下没问题因为工具服务本身响应很快。但高峰期的模型网关推理速度下降后第一次请求等 10 秒超时然后重试第二次又等 10 秒再重试第三次又等 10 秒。单次调用最长花了 30 秒期间线程一直被占用。更要命的是模型网关一旦进入高负载状态重试不但不会提高成功率反而会增加它的压力。客户端带着超时重试轰炸同一个已经拥堵的网关网关处理不过来排队越来越严重。这就是重试风暴本质上和服务端雪崩是一对孪生兄弟。正确的姿势应该是读超时控制在 5 秒以内对于模型推理这种场景超过 5 秒大概率是模型卡死或者网络问题等更久没有意义重试不超过 1 次并且只在明确可以安全重试的错误码下重试比如 429、502、503不要覆盖所有异常重试必须配合指数退避第一次重试等 1 秒第二次等 2 秒而不是固定 2 秒整个重试链路的总体时间要有上限比如客户端总超时配置为 8 秒即使还有重试机会也要直接放弃。3.2 同步阻塞把线程池打满Agent 编排服务天然是一个高并发场景因为每个请求都会阻塞等待模型推理。我用的是标准 Tomcat 线程池默认 200 个线程。平时请求处理得快200 个线程足够。但故障期间每个请求都卡在工具调用或模型调用上一个请求就要占住一个线程 20 到 30 秒200 个线程很快被耗尽。线程池耗尽的表现是新的请求进入 Tomcat 的 accept 队列等前面的线程释放。但前面线程短时间内不会释放于是请求在队列里越积越多最终连 accept 队列也满了后续请求直接被拒绝网关自然返回 504。这里有一个重要心得不要用默认线程池处理所有类型的任务。编排服务里既有几毫秒完成的内部逻辑也有几十秒的模型推理等待它们混在同一个线程池里慢任务会占光资源快任务也会被拖死。解决思路就是后面要讲的线程池隔离。3.3 连接池参数失配让问题雪上加霜线程池只是一个方面。我在线程栈里还看到大量线程阻塞在等待 HTTP 连接这说明连接池也不够用。当时编排服务使用的是一个通用的 HTTP 客户端连接池最大连接数是 100最大等待时间是 5 秒。这个配置单独看没问题但仔细想想100 个连接每个请求持有连接时间从原来的 1 秒变成 30 秒那么每秒能处理的新请求量就是 100 / 30 ≈ 3 个。实际 QPS 稍微一涨追不上处理速度连接池等待队列就爆了。这里有个黄金公式连接池的承载能力 最大连接数 / 平均持有时间。如果希望支撑每秒 20 个请求且平均持有时间是 5 秒那至少需要 100 个连接。反过来如果你的最大连接数是 100而平均持有时间已经是 30 秒那每秒最多只能处理 3 个左右的请求。想靠调大连接池解决也只是饮鸩止渴真正要解决的是缩短持有时间。3.4 变更分析压垮系统的最后一根稻草故障以后做 review查了最近的变更记录发现前一天晚上发布了一个新的 Agent 版本里面加了一个新的工具调用节点。这个节点会调用一个内部服务而该服务为了数据新鲜度重新配置了读超时为 10 秒。这个变更单独发布时没有压测到高峰流量所以没有暴露问题。到了第二天下午模型网关刚好因为另一个团队的上线任务出现性能波动响应时间拉长两件事叠加问题才集中爆发。复盘结论是这是一个典型的多因素叠加故障。任何一个因素单独出现都不致命但凑在一起就形成了完整的故障链上游网关变慢 - 工具服务读超时设置为 10 秒 - HTTP 客户端重试 2 次 - 单个请求最长 30 秒 - 线程池打满 - 连接池排队 - 服务拒绝新请求。4. 修复方案与参数配置实战4.1 分层超时设计把不知道等多久变成几秒就放弃超时设计是这次修复里收益最大的一部分。以前我对超时的理解比较粗给 HTTP 客户端设一个 connectionTimeout 和一个 readTimeout 就完了。现在我会把超时细化成三层连接超时Connection Timeout建立 TCP 连接的最长等待时间。内网环境建议 1 秒以内超过 3 秒基本可以断定网络有问题。读取超时Read Timeout等待响应数据的最长时间。模型推理场景建议 5 秒左右工具服务内部调用建议 2 到 3 秒。总超时Total Timeout整个调用包含重试在内的最大时间上限。这个值一定要有否则重试会让整体耗时失控。我根据这次的经验把平台内的调用参数整理成了一张配置表调用类型连接超时读取超时最大重试次数总超时上限模型网关推理1s5s18s内部工具服务500ms2s14s外部工具服务1s3s03sAgent 编排总时长不适用不适用不适用30s配置时需要注意一个逻辑重试必须在总超时内运行。不要设了 readTimeout 10 秒又重试 2 次结果总耗时 30 秒。正确的做法是先定总超时倒推单次超时和重试次数。如果总超时是 8 秒单次读取 5 秒那就只能在超时后重试 1 次而且抛掉重试前的固定等待时间否则很容易超过总限制。4.2 重试与熔断配合才能真正快速失败光有超时还不够。超时只能让单次调用不至于无限等下去但如果系统整体已经过载你需要的是快速失败而不是继续等待并重试。我引入了熔断机制基于滑动窗口统计上游调用错误率和延迟。核心参数这样配调用失败率超过 50%开启熔断熔断时间初始 10 秒后续按指数递增熔断打开时直接返回兜底结果不再发起真实调用同时配合最大并发限制例如模型网关最多允许同时 20 个请求超过直接拒绝进入队列。这个设计保证了上游出问题时编排服务不会把所有线程都放在等待上而是快速给出当前服务繁忙请稍后重试的降级响应。虽然用户没有拿到智能回答但至少服务本身的可用性保住了不会整体雪崩。熔断之后还有一个细节就是兜底结果。Agent 场景里最好在系统设计时就定义好如果模型调用失败是返回内置答案还是返回提示信息。不要等到故障时再临时想临时设计基本都会引入新的 bug。4.3 线程池隔离与异步化改造线程池隔离是这次改动中工程量最大但效果也最明显的一项。我做的核心调整是将请求接收线程池和依赖调用线程池分开。Tomcat 的工作线程只负责接收请求、解析参数、初始化上下文然后马上把任务提交给一个专门的 Agent 执行线程池。这个线程池的配置和 Tomcat 完全解耦可以独立控制大小和队列策略。具体参数是这样调出来的核心线程数 50最大线程数 200队列容量 200拒绝策略选择 CallerRunsPolicy但任务提交方Tomcat 线程也设置了超时保护避免继续堆积针对模型网关调用单独建一个最小线程池核心线程数 20最大 50队列 100专门承接模型推理调用。隔离之后的效果非常直观模型网关调用再慢最坏情况只是这个独立线程池的 50 个线程被占满Tomcat 的 200 个线程仍然可以快速处理其他请求不会再出现全网关线程耗尽。异步化改造我也做了一部分。Agent 长任务的场景本身很适合异步化用户请求先被接收返回一个任务 ID后台线程池执行 Agent 编排完成后通过轮询或回调获取结果。这比同步等待优雅得多但改动较大短期我采取了折中方案同步链路保留但把模型流式输出接进来用户侧可以边等边看到内容而不是干等。4.4 针对 Agent 场景的流式输出与超时兜底Agent 场景有一个特殊性模型本身的响应时间就是长尾分布即使没有故障95% 的请求在 5 秒内但 5% 的请求可能需要 15 到 20 秒。如果全部走同步等待用户体验很差。我当时的处理方案是模型网关调用启用流式返回SSEAgent 编排服务边接收模型输出边转发给前端工具调用结果返回后再以追加方式更新输出内容如果整个 Agent 任务超过总时长上限 30 秒立即终止后续工具调用返回已经生成的部分内容并附加一句生成超时剩余内容请重试。流式输出还有一个好处它打破了必须拿到完整结果才能返回的约束服务端的响应压力被平均分布在长尾时间内不会在最后 1 秒集中爆发。这个改造对超时故障的缓解作用是最直接的。5. 常见问题与排查技巧实录5.1 线上超时故障排查工具箱这次故障让我重新整理了一套排查工具清单分享给你告警系统除了 P99 和错误率一定要监控线程池活跃线程数和连接池等待线程数。它们是服务卡住的直接信号。调用链追踪必须保证每个请求都有唯一 request_id并且链路数据能够按时间轴展示上下游调用。没有这个排查超时要靠猜。线程栈采样工具Arthas 的thread命令比看任何监控面板都直接。它能告诉你线程到底卡在哪个方法上。依赖变更记录故障复盘时一定要查最近一次发布变更。很多超时故障都是因为某个依赖服务调整了超时参数或重试策略。压测工具日常压测不能只测正常请求要专门压依赖变慢的场景比如模拟模型网关延迟 5 秒看服务端线程池表现。5.2 容易忽略的三个坑第一个坑是DNS 解析超时。排查询时发现偶尔有请求在发起 HTTP 连接前就耗时超过 3 秒爬线程栈才看到是在做 DNS 解析。解决方法很直接针对所有内部服务域名开启 DNS 缓存并设置足够的 TTL避免每次请求都走一次完整解析。第二个坑是日志风暴加重故障。故障期间报错日志量非常大每个超时请求会输出完整堆栈日志框架在高并发下占用了大量 CPU还触发了频繁 GC。后来我把典型异常做聚合输出相同堆栈只在 1 分钟窗口内输出一次日志量下降 90% 以上。第三个坑是前端重试被忽略。用户端在请求超时会自动重试这些重试会直接打到网关等于在一个已经不稳定的服务上增加了额外流量。排查时必须结合网关日志和前端埋点数据确认用户侧是否存在重试叠加。后来我在网关层针对 Agent 路由增加了并发限制超过阈值立即返回 503不进入编排层。5.3 故障复盘清单最后是我整理的一份超时类故障复盘清单每次出了类似问题我都会逐项检查是否有任何一个上游依赖的平均耗时比正常值翻倍客户端读超时、连接超时、总超时分别是什么值是否存在重试叠加线程池是否被长时间占用的任务耗尽慢任务和快任务是否共用线程池连接池是否因为持有时间过长而排队是否配置了熔断熔断阈值和恢复时间是否合理上游故障期间本服务是快速失败还是依然在等待是否存在 DNS、日志、GC 等次生问题用户侧是否有自动重试逻辑网关层是否做了并发保护按照这份清单排查效率会有明显提升至少不会再出现我这次花两小时才定位根因的情况。结语一点实际体会这个故障让我把 Agent Platform 的超时设计从能用就行提到了必须系统化设计的高度。后来我再写调用代码时最优先想的一定是超时、重试和熔断三个词代码逻辑反而是后面的事。做 Agent 编排和做普通 Web 接口心态差异真的很大普通接口只对数据库负责Agent 编排是对一整个依赖网络负责任何一层不稳定都要想到。另外一个小建议每次故障修复后记得把当时的线程栈片段、监控截图和修复参数一起存档。这些资料在下次遇到类似问题时非常有用比任何文档都可靠。希望大家不要像我这次一样被同一个石头绊倒两次。