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

108 lines
2.5 KiB
Markdown
Raw Normal View History

# 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`