AI诊断系统全链路压测通关：我们如何解决模型超时问题，把接口响应稳定在30s内？

上周五下午3点，验收组临时拉了一场 SCENE-01（工业设备故障诊断）演示。结果诊断接口响应直接飘到 127 秒，整条由诊断、优化、安全、知识 4 个核心 Agent 加数字人交互模块、WebSocket 通信层组成的调用链卡在半路，运维盯着服务器日志一头汗。这是我们做 AI 多 Agent 诊断系统 M6 阶段验收前最惊险的一次突发状况。

模型加载超时：接口从 2 分钟压到 30 秒内

第一反应以为是服务器资源不够，临时加了 2 核 4G 内存，接口响应还是在 1-2 分钟之间晃。翻日志才看清根因：后端启动时自动去连 HuggingFace Hub 拉 sentence-transformer 模型的版本元数据，国内网络一抖就反复超时，每次诊断调用都要重试验证版本，整个链路被拖死。

方向其实很清楚：要么走网络代理，要么把模型校验改成本地离线模式。考虑到项目之后要离线部署到工业现场，我们选了后者——在启动脚本里加两个环境变量，关掉在线版本校验，直接读本地缓存的模型文件：

HF_HUB_OFFLINE=1
TRANSFORMERS_OFFLINE=1

改完第一次压测，诊断接口响应就稳在 8-30 秒，验收要求达标。这个坑也暴露了 AI 服务部署里一个很常见的问题：开发阶段本地有模型缓存，所有在线请求都秒回，一到生产或测试环境，缓存没了、网络又受限，之前藏着的那层依赖问题全炸出来了。

把四个 Agent 跑通整条链路

M6 阶段的核心目标是完成集成测试，系统里有 4 个核心 Agent、统一编排器、数字人模块和 WebSocket 通信层，任何一环出问题链路就断。

最典型的是 SCENE-03（设备运维知识问答）的调试：一开始数字人模块和知识 Agent 的响应时序对不上，经常出现数字人把回答播完了，知识 Agent 的结果才回来，WebSocket 消息还时不时丢。后来我们改了编排器的消息回调，给所有 Agent 响应加了 5 秒超时重试，同时给 WebSocket 连接加了心跳检测，最终 SCENE-01 到 SCENE-04 四个验收场景都按预期通过，只有 SCENE-05 因为要真实工业数据暂时没验。

最终整条链路的测试覆盖了 26 个 API 接口、3 个核心端点的并发压测，72 个测试用例通过率稳定在 98.6%，满足验收标准。

这次最值钱的交付物

M6 阶段我们一共交了 6 类文档：API 测试用例、性能压测脚本、测试用例手册、现场调优手册、操作说明书、全链路集成报告。以前做项目只盯着代码交付，这次因为要参赛被迫把文档补全，反而有了意外收获：后续迭代时新人上手时间从 3 天压到 1 天，现场调优手册直接帮运维解决了 3 个常见部署问题，后来别的团队做类似项目，直接拿我们的测试用例框架复用，少绕了不少路。

现在回头看，这些文档的价值甚至比代码本身还高：代码会一直变，但测试逻辑、调优经验、操作规范是能留下来反复用的东西。

几点体会

M6 验收虽然磕磕绊绊，还是攒下些能复用的经验：

1. 部署 AI 服务前一定先做网络依赖排查，所有在线拉模型、验版本的逻辑提前做离线适配，别等上线再踩。
2. 集成测试别只跑正常路径，WebSocket 丢包、Agent 响应超时、网络波动这些异常场景必须覆盖，不然验收时最容易翻车。
3. 交付物别只堆代码，测试用例、操作文档、调优手册是后面迭代的依靠，花 1 天写文档，后面能省 10 天沟通成本。

目前项目 M0 到 M6 已经全部跑完，接下来准备竞赛初赛演示，后面再有新的踩坑接着写。