# Server Connection and Debugging Issues

## 诊断结果

### 实例1（讯飞 API - astron-code-latest）

**核心问题：API URL 路径重复**  
config.yaml 中 `base_url` 设置为 `https://maas-coding-api.cn-huabei-1.xf-yun.com/v2`，但 Claude Code SDK 会自动在 base_url 后追加 `/v1/messages`，导致实际请求路径变成了 `/v2/v1/messages`——这是一个错误的路径。  
调试日志明确显示：  
`[API REQUEST] /v2/v1/messages source=sdk`  
`[ERROR] Stream completed without receiving message_start event`

**另外**，实例1 的 Hermes Gateway 进程目前没有正常运行，只剩一个空壳 bash wrapper。

---

### 实例2（meai.cloud API - claude-sonnet-4-6）

**核心问题：辅助任务全部超时**  
主 API（meai.cloud）本身是通的，但所有辅助任务（上下文压缩、记忆刷新、会话搜索）使用 `provider: auto`，自动回退到讯飞 API（astron-code-latest），而讯飞 API 响应极慢导致连锁超时：  
`Auxiliary compression: connection error on auto (Request timed out.)`  
`Failed to generate context summary: Request timed out.`

最终导致：  
- 达到最大迭代次数 60/60，被强制停止  
- 会话被压缩2次，精度严重下降  
- 出现未知工具错误 (`Unknown tool 'runbook_generator'`, `Unknown tool 'list'`)
  
---

## 修复方案

需要修改两处配置。你要我现在直接上服务器修复吗？具体修复步骤：  
1. **实例1** 
   - 修改 `base_url`，去掉末尾的 `/v2`，改为 `https://maas-coding-api.cn-huabei-1.xf-yun.com`  
   - 同时重启 Gateway

2. **实例2** 
   - 在 config.yaml 中将辅助任务的 provider 指向 meai.cloud 而非 auto（避免回退到讯飞），同时重启 Gateway

3. 重新启动两个实例的 Hermes Gateway 进程

---

## 当前问题诊断

结合我刚才查看服务器的结果：  
### 实例1（Hermes Gateway，讯飞 API）
- Gateway 进程基本是挂掉的状态，只剩一个空壳 bash wrapper  
- 日志显示讯飞 API 的 auxiliary 任务（压缩、记忆刷新）频繁超时 `Request timed out`

### 实例2（Telegram Bot，meai.cloud API）
- 上次会话最后 bot.py 被 sed 搞乱了，重写没完成  
- 日志同样有大量 `ReadTimeout` 和 `APITimeoutError`  
- 达到了 60 次迭代上限被强制停止

---

要我现在开始修复吗？需要做的事情：  
1. **实例2 bot.py** — 检查/修复上次被 sed 搞乱的代码  
2. **重启实例1的 Hermes Gateway**  
3. **重启实例2的 Hermes Gateway**  
4. **检查讯飞 API 超时问题** — 可能需要调大 auxiliary 任务的 timeout 配置

---

## 问题汇总

一共有 **5 个问题**：  
| # | 问题 | 影响 |  
| --- | --- | --- |  
| 1 | 实例1 Hermes Gateway 进程已死，只剩空壳 bash wrapper | 实例1 完全不工作 |  
| 2 | 实例2 Hermes Gateway 迭代耗尽(60/60)，功能异常 | 实例2 卡死 |  
| 3 | 实例2 bot.py 没在运行（上次会话 sed 搞乱了代码，重写后没完成重启） | 实例2 Telegram Bot 不工作 |  
| 4 | 两个实例的 auxiliary 任务（压缩/记忆/搜索）全部超时 — `provider: auto` 回退到讯飞 API，讯飞响应慢导致连锁超时 | 上下文压缩失败，会话越来越大直到崩溃 |  
| 5 | 讯飞 API 的 cron 定时任务 401 "apikey not found" 错误（19次） | 定时任务全部失败 |

---

## 修改说明
**实例1（讯飞为主）:**
| 配置 | 作用 |
| --- | --- |
| `fallback_providers` → meai.cloud | 讯飞失败/超时时，自动切换到 meai.cloud 继续回答，不会卡死 |
| `auxiliary.compression` → meai.cloud | 上下文压缩用快的 API（60秒超时），不再等讯飞 300 秒 |
| `api_max_retries` → 1 | 讯飞失败一次就切 fallback，不傻等 3 次重试 |

**实例2（meai.cloud 为主）:**
| 配置 | 作用 |
| --- | --- |
| `fallback_providers` → 讯飞 | meai.cloud 挂了时切到讯飞 |
| `api_max_retries` → 1 | 快速切换 |

---

**总结与建议**  
要继续观察刚才配置的 fallback + 辅助任务走 meai.cloud 后，稳定性是否改善。如果讯飞持续不稳定，考虑将主模型也换成 meai.cloud，保持 128K 但用刚才的早压缩策略，让讯飞始终在其能力范围内工作。