背景

很多人一看到 AI 相关接口超时，第一反应就是模型慢。这个判断不一定错，但在 Spring Boot 接 MCP 的场景里，超时链路其实比想象中更长。

我自己排查过一次类似问题：表面现象是接口偶发超时，调用链里也确实有模型请求，但最后发现真正拖慢整体响应的并不只是大模型。

先把超时拆成几层

排查这类问题时，我一般不会直接盯着模型，而是把整个链路拆开：

• Web 层请求超时
• 业务线程等待超时
• MCP 服务端处理超时
• 下游工具本身执行慢
• 模型响应慢或重试过多

如果不分层，最后通常会把所有问题都算到模型头上。

第一类问题：线程池把请求卡住了

很多 Spring Boot 服务在刚接入 AI 能力时，仍然沿用原来的线程池配置。平时普通接口没问题，一旦 MCP 工具调用变多，阻塞时间拉长，线程池就容易出现：

• 核心线程数偏小
• 队列太长，堆积不明显但延迟变高
• 拒绝策略不合理，业务方感知为随机失败

这种情况下，监控上看到的是“超时增多”，但根因其实是线程调度和等待时间变长。

第二类问题：工具调用比模型还慢

MCP 的价值在于把工具能力接进来，但这也意味着延迟不再只取决于模型。

如果一个请求里包含：

• 查询数据库
• 调内部 HTTP 接口
• 走一次缓存 miss 回源
• 再做结果整理

那总耗时往往是这些环节叠加出来的。模型只是其中一段，并不一定是最慢的一段。

第三类问题：超时配置没有对齐

我见过最常见的坑，是不同层的超时配置根本不一致。比如：

• 控制器超时 10 秒
• HTTP 客户端读超时 30 秒
• MCP 服务自己的超时 20 秒
• 网关超时 15 秒

这会带来一个很麻烦的现象：最先超时的那层不一定是真正最慢的地方，但它最先把请求打断了，导致排查方向容易跑偏。

更靠谱的排查方法

我后来用了一个比较笨但有效的方法：给每层都补耗时日志。

重点记录：

• 请求进入时间
• 模型调用开始和结束时间
• 每个工具执行开始和结束时间
• MCP 服务端接收和返回时间
• 最终响应时间

只要这些日志打齐，超时问题通常不会“玄学”太久。

真正落地时可以先做的优化

如果你现在也在做类似接入，我建议优先做这几件事：

1. 对齐各层超时配置，避免谁先断都不清楚
2. 给模型调用和工具调用分别打耗时日志
3. 检查业务线程池是否还是旧配置
4. 对高延迟工具做降级或结果缓存
5. 压测时单独看工具耗时分布，不要只看总响应时间

总结

Spring Boot 接 MCP 时出现超时，表面看像是“AI 太慢”，但实际常常是线程池、工具执行、配置不一致一起造成的。把链路拆开看，比直接围着模型转更容易定位问题。

对这类系统来说，真正重要的不是一句“优化模型调用”，而是把整条链路的耗时结构看清楚。