1. 代理环境变量（最常见）：env | grep -i proxy 看有没有 http_proxy/https_proxy。如果指向一个挂了或很慢的代理，hermes（Python httpx）每个请求都会先尝试连代理，连接超时 + 重试轻松吃掉 30~60 秒；dsh 是独立客户端，很可能直连或忽略代理。验证：curl -x http://127.0.0.1:10808 -o /dev/null -s -w '%{time_connect}\n' https://api.deepseek.com 和直连 curl --noproxy "*" ... 对比耗时，差得离谱就是它。确认后 unset 或 export NO_PROXY，重启 hermes。

2. Provider fallback / 凭据池轮换：hermes 配了多个 provider 或多个 key 时，主 provider 失败会先等一个超时周期再切下一个，每次请求都白等。hermes config 看 model 的 provider/base_url，hermes auth list 看凭据池；有异常 hermes auth reset <provider> 重置。

3. 旧模型名：deepseek-chat / deepseek-reasoner 今年 7 月 24 日已废弃，配置里还写旧名的话每次请求会报错/重试。hermes config 里 model.default 改成 deepseek-v4-flash 或 deepseek-v4-pro。

4. 会话上下文过大：resume 很长的会话时，hermes 会把完整历史 + 系统提示 + 几十个工具 schema 一起发出去，首 token 前的 prefill 时间比 dsh 的轻量 prompt 长不少。验证：/new 开新会话对比；长会话用 /compress 压缩。

5. 通用体检：hermes doctor 查配置和依赖；开 /verbose 观察请求是何时发出的，能区分慢在"请求前"（客户端问题）还是"请求中"（网络/服务端）。

90% 的情况是第 1 条，先查代理环境变量，查完再回来说结果。