# H-2 长驻 Hermes Session Manager

## 1. 目标

让 Hermes 以 conversation 级别的长驻 session 运行，而不是每条消息都重新冷启动。

这是本次接入最关键的用户体验目标：
- 连续上下文
- 无缝多轮对话
- 降低重复初始化耗时
- 避免“每次都像重新开机”

## 2. 会话归属原则

Hermes session 以 `conversation_id` 作为主键绑定。

原因：
1. Jarvis 现有 chat 的持久化中心本来就是 conversation
2. 前后端现有逻辑都已围绕 conversation 组织
3. conversation 是最自然的“连续对话上下文容器”

必要时可组合：
- `user_id + conversation_id`

## 3. 会话管理职责

建议新增 `HermesSessionManager`，负责：

1. 根据 conversation 获取或创建 Hermes session
2. 保存内存态句柄
3. 记录 last_used 时间
4. 做每会话锁，防止并发 turn 污染
5. 做 idle timeout 回收
6. 在异常时受控重建 session

## 4. 与持久化层的关系

### 4.1 内存态
内存里保存：
- session handle
- lock
- last_used
- health status
- restart count

### 4.2 数据库存储
建议把 Hermes runtime 元数据落入 `Conversation.agent_state`，但不要覆盖现有 Jarvis continuity。

建议结构：

```json
{
  "runtime": "jarvis | hermes",
  "runtime_state": {
    "jarvis": { ... },
    "hermes": {
      "session_id": "...",
      "last_used_at": "...",
      "restart_count": 0,
      "status": "healthy"
    }
  }
}
```

这样支持：
- 并存
- 切换
- 回滚
- 不破坏旧 continuity 数据

## 5. 生命周期建议

```text
用户发起消息
  -> 根据 conversation 找 session
  -> 有则复用
  -> 无则创建
  -> 执行消息
  -> 更新 last_used / 状态
  -> 空闲超时后回收
```

### 5.1 回收策略
- conversation 长时间无活动后可回收
- 但回收前要把必要 runtime 元数据保存到 `agent_state`

### 5.2 异常策略
- 首次异常：尝试一次受控重建
- 重建失败：返回 clean error
- 不能因此破坏 Jarvis 默认路径

## 6. 关键设计约束

1. 一个 conversation 同一时刻只能有一个进行中的 Hermes turn
2. 不允许两个并发消息写进同一个 Hermes session
3. session manager 不能成为 Jarvis 主流程的单点故障
4. Hermes 失败时，不能污染 conversation 的历史结构

## 7. 完成标准

- [ ] `conversation_id` 能稳定映射到 Hermes session
- [ ] session 可复用，不是每轮冷启动
- [ ] 有 per-conversation lock
- [ ] 有 idle timeout / cleanup 机制
- [ ] 有 crash / recreate 基础机制
- [ ] metadata 可写入 `Conversation.agent_state`