WIN-JHFT4D3SIVT\caoxiaozhu
21c869db62
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
86 lines
2.1 KiB
Markdown
86 lines
2.1 KiB
Markdown
# 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
|
||
- 中止替换计划
|
||
- 保留本轮探索结论供后续参考
|