AQA 配置错误排查实录：端点误指 Turing 导致 120s 超时，切回本机实例后降至 0.4s

2026-10-13 凌晨，AutoQuant Agent（AQA）的回测调度任务批量超时。

错误信息统一指向 ReShare 数据源：requests.exceptions.Timeout: 120s。

同一台机器、同一套代码，昨天还能跑通，今天就集体瘫痪。

我拉出 AQA 配置文件，发现了一个隐蔽的漂移——数据端点指向了 Turing（ModelBase 服务器），而不是本机的健康实例。

curl 实测：

# 指向 Turing（错误端点）
$ curl -w "\ntime: %{time_total}s\n" http://turing:8200/api/v1/stock/quote?symbol=517520
# 结果：连接成功但数据返回极慢，最终 120s 超时

# 切回本机（正确端点）
$ curl -w "\ntime: %{time_total}s\n" http://localhost:8200/api/v1/stock/quote?symbol=517520
# 结果：0.4s 返回完整数据

问题定位

AQA 的配置文件中有一条端点配置：

reshare:
  endpoint: http://turing:8200  # ← 错误：这是 ModelBase 服务器的 IP
  timeout: 120

Turing（ModelBase）是运行 llama.cpp 模型服务的服务器，端口 8200 被占用用于大模型推理。

本机才是 ReShare 的实际部署位置。

这个配置漂移是怎么发生的？

查看 git log，发现最近一次配置提交来自另一台机器（可能是开发机或 CI 环境），那台机器上 ReShare 确实部署在 Turing 上。但生产环境早已迁移到本机，配置没有同步更新。

修复过程

第一步：备份错误配置

cp ~/.hermes/aqa/config.yaml ~/.hermes/aqa/config.yaml.bak.20261013

第二步：修正端点

  reshare:
-   endpoint: http://turing:8200
+   endpoint: http://localhost:8200
    timeout: 120

第三步：验证

curl -w "\ntime: %{time_total}s\n" http://localhost:8200/api/v1/stock/quote?symbol=517520
# time: 0.4s  ← 正常

第四步：重启 AQA

systemctl restart aqa

后续措施

1. 配置管理：将 ReShare 端点配置化，通过环境变量 RESHARE_ENDPOINT 覆盖，避免硬编码 IP
2. 健康检查：AQA 启动时自检 ReShare 连通性，超时立即告警
3. 监控告警：心跳 cron 增加 ReShare 端点探测，失败时推送飞书

复盘

这个问题暴露了几个深层隐患：

1. 配置漂移：多环境配置不同步是常见问题，缺少自动同步机制
2. 硬编码 IP：服务器 IP 变更时配置不会自动更新
3. 无启动自检：AQA 启动时没有验证依赖服务的可达性

下次遇到类似批量超时，第一步应该是检查配置，而不是查代码。

---

日志结束 · 2026-10-13 03:10 · 韩梅梅