# H-4 前端切换与并行评估

## 1. 目标

让 chat 页面在尽量不改变现有体验的前提下，支持切换 `jarvis | hermes`，并进入受控评估期。

重点不是做新 UI，而是：
- 能切换 runtime
- 能继续对话
- 能收集真实效果
- 不影响现有默认使用路径

## 2. 前端最小改动原则

### 2.1 继续复用现有页面
主要锚点：
- `frontend/src/pages/chat/composables/useChatView.ts`
- `frontend/src/api/conversation.ts`
- `frontend/src/pages/chat/index.vue`

### 2.2 最小改动内容

1. 增加 `selectedRuntime`
2. 在发送消息时把 runtime 放入 request body
3. 页面可加一个轻量 toggle / selector
4. 不改变现有消息渲染逻辑
5. 不把页面改造成“网页终端”

## 3. 评估期策略

### 3.1 默认值
- Jarvis 仍为默认 runtime
- Hermes 为显式选择项

### 3.2 评估维度

必须记录：
- 首 token 延迟
- 完整回复耗时
- 第二轮/第三轮连续对话体验
- session 是否稳定复用
- 工具调用效果
- memory 是否有效承接
- 异常率 / 重启率
- 开发维护复杂度

### 3.3 用户体验标准

如果 Hermes 要成为默认 runtime，至少应满足：
1. 不比 Jarvis 更割裂
2. 不出现频繁 session 丢失
3. 前端不需要额外理解复杂运行细节
4. 整体体验更像连续助手而不是一次性问答器

## 4. 验收建议

### Frontend
- [ ] Jarvis 默认聊天体验不变
- [ ] 可切换到 Hermes 并成功发消息
- [ ] 历史会话读取不崩
- [ ] orchestration panel 不因 Hermes 字段较少而崩溃

### Backend
- [ ] Hermes 路径不影响 Jarvis 默认路径
- [ ] SSE 解析不需要重写
- [ ] conversation/message 结构保持兼容

### Product
- [ ] 可以真实比较两个 runtime
- [ ] 结论可支持“继续替换”或“放弃替换”

## 5. 阶段结论输出

本阶段结束后，应明确给出以下结论之一：

### 结论 A：Hermes 明显更优
- 新开一轮“默认切换 / 逐步替换”规划

### 结论 B：Hermes 可保留为实验 runtime
- 不切默认
- 继续特定场景使用

### 结论 C：Hermes 不适合当前 Jarvis
- 中止替换计划
- 保留本轮探索结论供后续参考