JARVIS/development-doc/plan/hermes-update/phase-h-2-long-lived-session-manager.md

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。

建议结构：

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

这样支持：

• 并存
• 切换
• 回滚
• 不破坏旧 continuity 数据

5. 生命周期建议

用户发起消息
  -> 根据 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